How to build supervised automation with human approval
Supervised automation is the middle path between a human doing every step and an agent doing all of them unwatched. This is the sequence that works, the rule for deciding which steps deserve a gate, and the five ways teams get it wrong.
To build supervised automation: pick one recurring workflow with a named owner, write the outcome and its rules in plain language, connect only the tools that workflow touches, mark every irreversible action as an approval gate, choose a trigger, replay the agent against real past cases before it can act on live data, and read the traces for the first week. Supervised automation means routine steps run unattended while consequential ones pause for a designated reviewer, who approves, modifies, or rejects them on the record.
What "supervised" buys you
Most automation projects stall on the same question: this would save real time, but I can't have software emailing customers or issuing refunds on its own. The usual resolutions are both bad. Either the project dies, or someone ships it unattended and finds out about the mistake from the customer.
Supervision is the third answer. The agent does the reading, gathering, drafting, and reconciling — the ninety percent nobody enjoys. Then it stops, hands the consequential action to a named human, and waits. The person approves it, edits it, or rejects it, and the run continues from there with that decision on the record.
What you get is not a smaller version of automation. It's a different risk profile: the throughput of software on the tedious steps, and a human veto on the ones that can't be undone.
A point in an automated run where execution pauses before a specific action is taken, waits for a designated person to approve, modify, or reject it, and records that decision alongside the run. Nothing past the gate executes until someone decides.
Write the brief. Don't draw the diagram.
This is the step people get wrong, and it's worth its own section because every later step inherits the mistake.
The habit from a decade of flow builders is to enumerate: first do this, then check that, then if the amount is over ten thousand, branch here. Written as prose, that's still a flowchart — you've just moved it from a canvas into a paragraph, and you've kept the brittleness while adding non-determinism. It is the worst of both models.
A brief describes the destination and the rules of the road. What does a good outcome look like? What are the inputs? What are the exceptions, and what should happen when the agent isn't sure? What must never happen without a human? Say those things, and let the agent work out the route on each run — including on the case you didn't think to diagram.
There's a practical longevity argument here too, and it's the reason to care rather than a philosophical one. A flowchart is a description of one vendor's node library. A brief is a description of your business. When a field gets renamed, the flowchart breaks and the brief doesn't; and if you ever leave the tool you wrote it in, the brief is still a readable paragraph you can hand to something else. Your canvas isn't.
The test for a good brief: could a competent new hire read it and do the work on their first day, without a diagram? If yes, an agent can plan from it. If the answer depends on a diagram, you have written a procedure, not a brief — and you have signed up to maintain it forever.
Before you start
- One workflow, not a program. Pick the single most annoying recurring process. Automation initiatives that begin as portfolios finish as slide decks.
- A named owner who can answer questions. If nobody can say authoritatively what the right outcome is, you have a process problem that automation will amplify rather than solve.
- Access to the tools it touches, with permission to connect them. Get this sorted before you write anything; it is the most common week-one blocker.
- Five to ten real past cases, including at least two that went wrong. These become your test set, and the wrong ones are worth more than the clean ones.
- An honest guess at volume and time per case. Prefer low-volume, high-judgment work — two hundred runs a month where each one touches money, access, or a customer — over high-volume plumbing, which a trigger-action tool will always do more cheaply.
The seven steps
- 01
Pick one workflow and name its owner
Choose recurring, cross-tool work with judgment in it — invoice follow-up, onboarding, lead routing, triage, weekly reporting. Write down who owns the outcome today. That person authors the brief and approves the gated steps; if you can't name them, stop here and fix that first.
- 02
Write the outcome, not the procedure
Describe what a good result looks like the way you'd brief a competent new hire: the inputs, the rules, the exceptions, and what to do when unsure. Resist listing steps in order — that's the flowchart habit, and it constrains the agent to the path you happened to think of. Include the things that feel too obvious to say; those are exactly the rules that live only in someone's head.
- 03
Connect only the tools this workflow touches
Grant the mailbox, CRM, ticket system, or ledger the work actually needs, and nothing else. The tool list is the blast radius: an agent cannot act on a system it was never given. Resist connecting everything now because it might be handy later.
- 04
Mark every irreversible step as a gate
Anything a customer sees, anything that moves money, anything that changes access, anything that deletes. Agree on who reviews each one — a role is not enough when the run is waiting, so name the individual even where the tool only asks you for a policy. In Boring these pause in the console; a reviewer with approval rights on that agent approves, modifies, or rejects, and an approving note comes back to the agent as context so the run continues informed rather than restarting.
- 05
Choose the trigger, and start slower than feels right
A schedule, an inbound webhook or email, a form submission, or an event in a connected app. For a first agent, prefer a daily schedule over real-time: one batch a day is far easier to review than a trickle of runs all afternoon, and you can tighten it once you trust it.
- 06
Backtest it against real past cases before it can touch anything live
Run the agent over the cases you collected and compare what it would have done to what actually happened — same tool calls, same arguments, same approval behavior? In Boring this is backtesting, and the product name for it is Confidence checks: successful runs become saved baselines that an unpublished draft replays with fixture-only tool responses, reporting where the tool sequence, arguments, or approvals drifted. Whatever the mechanism, do not let the first real run be the first run.
- 07
Enable it, then actually read the first week of traces
Open each run: what it reasoned, which tools it called with what arguments, what came back, what got approved. This is where you find the unwritten rules, and where you tighten the brief from "mostly right" to "right." Budget the time — the teams whose agents survive are the ones that did this, and the ones whose agents get switched off in month two are the ones that didn't.
Which steps deserve a gate
Gate too little and you've built the thing you were afraid of. Gate too much and you've built a queue of approvals nobody clears, which is just manual work with extra clicks. The test that holds up: gate an action when undoing it costs more than reviewing it.
| Action | Gate it? | Why |
|---|---|---|
| Reading data, searching, summarizing | No | Reversible and invisible. Gating reads is how approval fatigue starts. |
| Writing an internal draft or note | No | A human sees it before it matters anyway. |
| Anything a customer or candidate receives | Yes | You can't unsend it, and tone is a judgment call. |
| Money: refunds, credits, payments, invoices | Yes | Irreversible, and the error is measured in currency. |
| Access: accounts, permissions, licenses, offboarding | Yes | Both directions are harmful — wrongly granted and wrongly revoked. |
| Deleting or overwriting records | Yes | The definition of irreversible. |
| Updating an internal status or field | Usually no | Cheap to correct. Gate it only when a downstream system fires off it. |
| Posting to a shared internal channel | Depends | Gate it if the channel is executive, customer-facing, or noisy enough that a wrong post costs trust. |
Five ways this goes wrong
- 01
Approval fatigue
Gate everything and reviewers start rubber-stamping within two weeks — at which point the gate is decoration and you have less safety than an honest unattended run, because you also believe you're covered. Gate the irreversible steps and let the rest run.
- 02
A role instead of a person
"The finance team approves this" means the run waits while three people each assume someone else has it. Name an individual, and decide explicitly what happens when they're on holiday.
- 03
A brief that describes steps instead of outcomes
Writing the flowchart in prose gets you the worst of both worlds: the rigidity of a fixed graph plus the non-determinism of a model. Say what good looks like and what's off-limits; let the agent find the route.
- 04
No dry run
Enabling straight into production is the single most common cause of an agent being switched off permanently. One bad first week costs more trust than three months of quiet correctness earns back.
- 05
Nobody reads the traces
A trace nobody opens is the same as no trace. Put a recurring fifteen minutes on someone's calendar for the first two weeks; it's the cheapest quality control in the whole project.
How to know it's working
"It hasn't broken" is not evidence, because a silently mis-scoped agent looks exactly like a working one from the outside. Watch for signals instead:
- Approval outcomes are trending toward approve-as-is. If reviewers keep editing the same field, that edit belongs in the brief.
- Rejections are rare and specific. A rising rejection rate means the brief drifted from the work, not that the model got worse.
- The owner can explain any given run from its trace without asking anyone.
- Failures never lose a run. Ask the platform this directly: after a mid-run failure, does it resume from the step that failed, or start over? If a hiccup means redoing everything, you'll stop trusting it — and if step three already sent an email, starting over is worse than not recovering at all.
- A month later, someone new can read the brief and understand what the agent does. That's the real test — it's the same test as good documentation, because that's largely what a brief is.
An approval gate is a control, not a compliance artifact. In Boring, run traces are reviewable in the console and exports cover run and workspace summaries rather than the full step-by-step payload record, and there's no immutability or attestation story yet — so treat the trace as something your team reviews, not as an audit archive you can hand to a regulator. Approvals happen in the authenticated web console; the Chrome extension can start and watch runs but cannot approve, and there's no native mobile app yet.
Questions about this
What does human-in-the-loop mean in automation?
It means a person is a required participant in the automated run, not an observer of it. At a defined point the run pauses, a named human approves, modifies, or rejects the pending action, and the run continues from their decision — which is recorded with the run. The human isn't reviewing a report afterwards; nothing past the gate happens until they decide.
Which steps should require human approval?
The ones that cost more to undo than to review: anything a customer receives, anything that moves money, anything that changes access, and anything that deletes or overwrites data. Reads, searches, summaries, and internal drafts should run unattended — gating them is the fastest route to approval fatigue, which quietly destroys the value of every other gate.
Doesn't approval defeat the point of automating?
It would if the human were doing the work. They're not — they're deciding on it. The agent has already gathered the context, reconciled the systems, and drafted the action; a review that takes fifteen seconds replaces a task that took fifteen minutes. The saving comes from the ninety percent, not from removing the person.
How do you test an automation agent before trusting it?
Backtest it: replay it over real past cases and compare what it would have done with what actually happened — the same tool calls, the same arguments, the same approval behavior. In Boring the feature is called Confidence checks; successful runs become saved baselines that an unpublished draft replays with fixture-only tool responses, so no live tool call happens, and the result reports where the tool sequence, arguments, or approvals drifted. Model calls in a replay are real and cost the same as a normal run.
What happens if an agent fails mid-run?
On a platform that never loses a run, it retries from the step that failed rather than from the beginning, so completed work isn't repeated and half-finished side effects aren't duplicated. Ask any vendor this question specifically — "replay" sometimes means re-running the whole thing, which is a very different promise when step three already sent an email.
What if we outgrow the tool, or the vendor shuts down?
This is the right question to ask any automation vendor in 2026, and the answer depends on what you authored. A node graph or a workflow JSON export is worth almost nothing outside the tool that produced it — it describes that vendor's node library, not your business. A plain-language brief is portable by construction: it stays readable, and you can hand it to a different platform or a person. Ask specifically what leaves with you, in what format, and whether it's usable elsewhere.
How long before a supervised automation pays for itself?
That depends on your volume, the minutes per case, and how much of the work genuinely automates — which is why we published a calculator that uses your numbers instead of a benchmark we made up. The honest framing: the value shows up in the first month if the workflow is high-frequency, and the first two weeks is spent tightening the brief rather than banking savings.
Stop reading. Describe the workflow.
Request access and describe it in a sentence — or ask about white glove and our team will build and run it with you.