Guide · human-in-the-loop
Human approval for AI agents: build it or buy it
Pausing an agent is the easy part. Every framework can do it. The work is everything around the pause: who should answer, where they answer, what happens when nobody does, and how you show afterwards who decided what.
What a pause gives you
LangGraph can interrupt a graph, the AI SDK can mark a tool call as needing approval, and an MCP client can prompt the person at the keyboard. Each one stops the agent and waits. None of them decides who should be asked, reaches somebody who is not at that keyboard, or keeps the answer anywhere you can find it next quarter.
That is fine while the person running the agent is the person who should decide. It stops being fine the first time the decision belongs to someone else — a finance lead, a client, a colleague on call — or the first time someone asks for the record.
What an approval actually needs
| Need | Why it matters |
|---|---|
| Route to the right person | The decision belongs to whoever has the authority, not whoever started the agent. |
| Reach them where they are | A phone, an email, Slack or Teams — not a terminal they will never open. |
| Let them correct, not just reject | Most bad requests are one wrong figure. Rejecting the whole thing wastes the run. |
| Handle silence | Escalate to more people after a while, then expire, rather than wait forever. |
| Cover absence | Someone on holiday names a colleague, instead of the queue stalling. |
| Keep the agent out of the decision | An agent must never approve its own request, or any request. |
| Settle the routine cases without anyone | Rules decide the obvious ones, so people only see what needs them. |
| Prove it afterwards | Who was asked, what they saw, what they decided and when, exportable. |
Building it yourself
A working version is a small system of its own: a store for requests and their states, a decision page behind your sign-in that works on a phone, notifications on two or three channels, a way back to the agent (a callback or polling), timers for reminders, escalation and expiry, an audit log that cannot be edited, and, sooner or later, a rules engine so people stop approving the same safe thing all day.
- Build it when one internal agent asks one person about low-stakes actions, and the framework's own pause is enough.
- Build it when the approval is a single step inside a product you already own end to end.
- Buy it when several agents or tools need the same approvals, when the approver is outside the team or the company, or when somebody will one day ask for the evidence.
How Deliverd does it
An agent makes one call to ask a named person for approval, a review or some information, and carries on when they answer. The person decides on a page built for a phone, from an email link, or from a Slack or Teams card; they can approve with changes to the values the agent marked as correctable, bring someone in, or ask the agent a question. Requests escalate and expire, a colleague can cover approvals for up to 90 days, and the agent can never approve anything.
Before an action, an agent can declare it at a gate instead: with no rules a named person decides; with rules, which are included in Business and Enterprise, the routine cases are settled and the rest go to a person. Afterwards the agent records what ran, and every step exports as an evidence pack in JSON, CSV or PDF. Flow and the gate are on every plan.