Relay.app earned its place in a lot of tech stacks by doing one thing well: automation that stops and asks a human before it does anything irreversible. Approve this refund. Edit this AI-drafted reply. Confirm which of three vendors gets the purchase order. When the company wound down and much of the team landed on Google’s Chrome group, plenty of operations teams discovered how deeply those little pauses had been woven into their week. The account of how quickly the product rose and vanished is a good read on its own, but the more urgent question is practical: what do you build now?
Below is a six-step rebuild process for the most common Relay pattern, which was always some version of trigger, AI draft, human approval, downstream action. Every step uses a concrete example so you can follow along with your own workflows open in another tab.
Inventory the Pauses, Not the Automations
Before you open a single new tool, write down what you actually had. The mistake most teams make is counting workflows instead of counting decisions. A 14-step flow with one real approval in it is a two-step project wearing a costume.
For each workflow, record four things:
- The trigger and how often it fires (a demo form that lands 60 times a week versus a contract renewal that shows up twice a month)
- Which step needs a person, and what that person is genuinely deciding
- Where the approved result gets written: CRM, helpdesk, accounting system, spreadsheet
- Who owns it when it breaks on a Sunday night
You will almost certainly find that half your approvals were notifications in disguise. Nobody ever rejected them, nobody edited them, and they existed to make someone feel included. Those become plain automations now. The handful that people really engage with are the ones worth rebuilding carefully.
Step 1: Rebuild the Trigger and Data Shape First
Get the input landing correctly before you add any intelligence. Take a concrete case: a website form where prospects request a demo. The fields are name, work email, company, company size, and a free-text box labelled “what are you trying to solve?”.
In n8n that’s a Webhook node feeding a Set node that normalises the field names. In Zapier it’s the form app trigger plus a Formatter step. In Make it’s a webhook plus a Variables module. Whatever you pick, log the raw payload to a database or a sheet on the first run. You will need those rows later when you test the AI step, and having 200 real submissions on hand is worth more than any prompt tutorial.
Step 2: Turn the AI Step Into a Drafting Job
The original Relay.app AI steps worked best when the model was asked to classify and draft, never to decide. Keep that discipline. Ask for structured JSON with a fixed schema so the next node can read it reliably:
{ "intent": "pricing | integration | security | other", "size_bucket": "smb | mid | enterprise", "confidence": 0.0, "draft_reply": "..." }
Two rules make this dependable. First, if confidence comes back below 0.7, skip the draft entirely and route the request straight to a human with the source text attached. A confident wrong answer is worse than no answer. Second, use a small fast model for classification and a larger one only for drafting, which typically keeps a run in the fraction-of-a-cent range.
Step 3: Pick the Stack That Matches Your Tolerance for Maintenance
Relay’s disappearance was a reminder that the tool matters less than how portable your logic is. The realistic options:
- n8n: self-hosted or cloud, cheapest at volume, excellent control over retries and error branches
- Zapier: the widest app catalogue and the fastest assembly, with costs that climb past a few thousand tasks a month
- Make: mid-priced and visual, good when you want the whole scenario visible on one screen
- Plain code: a small Python service with a job queue if the workflow is business-critical and you have an engineer on staff
If you go the n8n route and your workflows involve reasoning rather than simple routing, it’s worth studying how to build AI agent workflows that hold up in production, because the failure modes are different from classic automation.
Step 4: Make the Human Step a Real Task
A notification says “something happened”. A task says “here is the source data, here is the draft, pick one of three buttons”. Build the second kind.
Post to a Slack channel with the original message text quoted underneath the AI draft, plus Approve and send, Edit, and Reject buttons. Set an expectation of a 30-minute response window during working hours and escalate to a second channel after two hours. Include the confidence score in the message so reviewers learn when to trust the model and when to slow down.
Step 5: Write the Approved Result Back Where It Belongs
Once someone clicks approve, three things should happen automatically: create the deal or ticket in your CRM at the correct stage, send the reply through the reviewed mailbox, and append a row to a review sheet with the timestamp, the reviewer, and whether the draft was edited. That last one is quiet but valuable, since it tells you your edit rate over time without anyone doing manual reporting.
A Worked Example End to End
Here is the whole thing assembled for inbound demo requests, which is close enough to a support queue that the same shape applies to both. If your volume is in tickets rather than sales, there’s a full walkthrough of building an agent that triages support tickets that maps onto this almost one for one.
- Trigger: form submission, 60 per week
- Clean: normalise fields, reject personal email domains with a gentle auto-reply
- Classify: small model returns intent, size bucket, and confidence
- Branch: confidence above 0.7 gets a drafted reply, below that goes to a human with no draft
- Review: Slack task with Approve, Edit, and Reject buttons, 30-minute target
- Act: approval creates a CRM deal, sends the reply, logs the row
On a test set of 200 historical submissions, a setup like this usually lands somewhere between 85% and 90% agreement with what a human would have chosen. That’s good enough to save serious time and not good enough to remove the reviewer.
Three Places These Rebuilds Break
Prompt drift
Someone adds “make it sound warmer” in month two and the edit rate quietly doubles. Version your prompts in a file or a database field, and treat changes as deploys rather than quick tweaks.
Silent failures
The webhook returns 200, the field arrives empty, and the model confidently classifies nothing. Add a validation node after every intake step that halts the run and pings the owner if required fields are missing. A workflow that fails loudly is a workflow you can trust.
Approval theatre
If 96% of drafts are approved without edits and the median response time is four minutes, the human step is decoration. Either raise the confidence threshold, widen the model’s autonomy, or delete the step. Three genuine reviews a day beat forty rubber stamps.
Replay Historical Data Before You Switch It On
Run the last 200 real submissions through the rebuilt flow in dry-run mode, meaning the AI step executes but nothing writes to your CRM or mailbox. Compare the model’s classification against what a human actually chose, and measure how heavy the edits to the drafts are. Set a floor for yourself: below 85% agreement on classification, go back and tighten the prompt or add examples before you expose the workflow to live customers.
What to Watch After Two Weeks
Three numbers tell you whether the rebuild earned its keep. The median time from trigger to approved action, which should sit under an hour for sales and under four for support. The share of AI drafts sent with zero edits, which is your best proxy for prompt quality. And the fully loaded cost per run, which combines task pricing with token spend, and on a self-hosted setup with a small model often lands near half a cent per execution.
The broader lesson from Relay’s shutdown and the team’s move into Google’s browser division isn’t that human-in-the-loop automation was a bad idea. It’s that the logic was always more valuable than the platform. Rebuild it somewhere you can export, keep your prompts in version control, and the next time a vendor disappears, you’ll be migrating an afternoon’s work instead of a quarter’s worth.