Human in the loop AI agents and when a person must approve

A human in the loop AI agent should wait for a person to approve a write when the change is hard to undo, when nothing but the agent can confirm the result, or when you have no record yet of how the agent behaves on that action. Show the approver the exact change in a form they will read, enforce the approval in the tool that makes the change, and record each decision. Remove approval one action at a time, once that record and an independent check of the result support it.

Key facts

Definition

A human in the loop AI agent waits for a person to approve a write that is hard to undo, that nothing but the agent can confirm, or that has no track record yet.

How Bigcircle does it

On Skionis, Bigcircle has an engineer approve an architecture diagram of what will exist before any cloud change is applied, after the validation loop has run.
On FinSight, Bigcircle put approval on resolving reconciliation exceptions rather than on every matched record.
Bigcircle recommends enforcing the approval in the tool that makes the write, because a confirmation shown only in the client binds nothing the credential allows.

Comparison

An instruction such as a code freeze cannot stop a write the credential allows, which is how Replit's agent came to delete a production database in July 2025.

Key number

Skionis template errors before deploy fell from around 10% to 4% once the validation loop was in place, by Bigcircle's own measurement.

Reads, drafts and changes a person resubmits anyway rarely need an approval step. On Skionis, our agent for live AWS accounts, an engineer approves an architecture diagram of what will exist before any change is applied. The approval sits on the one question a validator cannot answer, which is whether this is the change the team meant.

Criterion	Agent drafts, person acts	Person approves each action	Person handles exceptions	Agent acts inside limits
What the agent does	Prepares the change and stops	Makes the change after a named person approves the exact operation	Makes routine changes and holds anything outside the rules	Makes the change without approval, inside limits the tool enforces
What the person does	Edits and submits it	Reads the change and approves or rejects it	Resolves the held item, and the resolution is recorded	Owns the limits and reads the record afterwards
Fits when	The output is advice, or the person is the authority who signs	The change is hard to undo, or the action has no track record yet	Most cases follow written rules and judgement is needed on the rest	The change is reversible or capped, and something other than the agent confirms it
What goes wrong	Nothing is saved if the person rewrites every draft	Approvers stop reading when every action asks them	A rule that misreads a case as routine skips the person	A limit set too wide, or a result nobody checks
How Bigcircle handles this	On our trademark drafting system the attorney edits and signs the draft, and stays the legal authority	Skionis applies a cloud change only after an engineer approves the diagram	FinSight, built and tested but not deployed, puts approval on resolving exceptions	Solarpunk acts only through registered tools, and a critic checks each step before work is called done

The hard part is that approval costs something every time it runs. Put it on every action and approvers stop reading, so it becomes a click that records consent nobody gave. Put it in the wrong place, such as an instruction in a file or a button the agent can route around, and it binds nothing.

This guide covers which writes need a person, what that person should see, where the approval is enforced, and how to stop needing it for one action. Which actions the agent may attempt at all, and which credential it uses, is the subject of our guide on AI agent permissions.

Which writes need a person to approve them?

A write needs approval when a mistake would be expensive to reverse. Money moved, a message sent to a customer, a record deleted and a change to production infrastructure all fall in that group. A wrong answer misleads one reader, who can still check it. A wrong write changes a state that other people and systems then depend on, often before anyone looks.

Cloud changes show the cost well. On Skionis, a failed CloudFormation deployment can take minutes to unwind, so "apply and see" cannot work as a development loop.

That is why Skionis validates a template in a loop before AWS is asked to do anything, and why the engineer approves the result before the apply. Most errors die in that loop, so the person reviews a change that already passes the machine checks. Template errors before deploy fell from around 10% to 4% once the loop was in place, by our internal measurement.

A write also needs approval while nothing but the agent can confirm the result. If the only evidence that a refund went through is the agent saying so, a person should approve it until a separate read of the ledger can confirm it. Our guide on AI agent verification covers that gap between a tool's response and a finished task.

A new action needs approval for a different reason. There is no record yet of how the agent behaves on it, and approval is how you build one. Each approval, edit and rejection is a labelled example of the agent's judgement on that action. Without approval at the start, you have no evidence for the later decision to remove it.

What happens when approval is only an instruction?

Nothing stops the write. Never let an approval live only as an instruction to the agent, or only as a dialog in the client, because neither can stop a write the credential allows. The approval has to be something the tool checks.

Replit showed the cost in July 2025, when its agent deleted a user's production database during what the user had declared a code freeze. The freeze was an instruction, and the agent still held a credential that reached production. Replit's response was to roll out automatic separation of development and production databases, which is a credential change rather than a better instruction.

The MCP specification leaves the same gap in a quieter form. It asks applications to keep a person who can deny a tool call and to show the tool's inputs first, but that confirmation happens in the client, the application the agent runs inside. The server that makes the write cannot tell whether a person saw it.

Do not use tool annotations to decide when to ask, either. MCP lets a server mark a tool with hints such as destructiveHint, and the specification tells clients to treat those hints as untrusted unless the server is trusted. A client that asks for approval only when a server labels its own tool destructive is relying on that server's description of itself.

What should the approver see?

Show the change itself, in a form the approver will still read at the end of a long week. A summary of the agent's intent is not enough, because the summary is written by the same model that chose the action. On Skionis we show an architecture diagram of what will exist after the change, because the alternative is a raw template diff, and engineers do not read the tenth diff of the week carefully.

On the telecom marketing platform we are building agents for now, the configuration agent works the same way. It checks every campaign configuration against platform schemas and business rules before anyone sees it, catching overlapping segments, budget breaches and frequency-cap violations. The person then reviews a structured configuration they can compare line by line, and nothing goes live without their sign-off.

The order matters. Machine checks run first and catch what a rule can catch. The person is left with what no validator can decide: whether this is the change they meant. A person asked to spot a schema error by eye is doing a validator's job badly and has less attention left for the judgement only they can make.

Bind the approval to the exact operation. The record should hold the tool, the arguments, the target and the state the target was in when the person looked. If any of those change before the call runs, the approval no longer covers the call and a new one is needed. An approval should also expire, so that one approved change cannot be replayed by a later run.

How should an AI agent approval workflow enforce the decision?

Our rule is to enforce the approval in the tool that makes the write, against an approval record stored in your own system. The tool checks for a matching approval that has not expired, given by someone allowed to give it, before it calls the system that holds the record. With no match it refuses, and the refusal goes in the log. The agent never needs to see the approval record, only whether the call was allowed.

The 2026-07-28 MCP revision gives servers a way to ask mid-call. A server can answer a tool call with an input_required result, and the client retries the call with the answer attached. That is a reasonable way to collect an approval, but the server sees only what the client sends back. For a write that matters, record who approved in your own system, so the tool checks a fact it trusts.

AVOX, an insurance voice agent we built and tested end to end, not yet in production, covers what happens when a check fails. Compliance sits in the tool contract, not in the prompt, so a payment tool cannot run without the required disclosure. A request that fails a check escalates to a person with the conversation and the actions already taken. It does not degrade into something nearby, because an agent that cannot complete a payment must hand off rather than improvise.

Why do approvals stop working?

Approvals fail in three ordinary ways. The approver stops reading because every action asks. The approval sits on a step where no judgement is needed. Or the approver is shown something they cannot judge. All three produce the same record, a long list of approvals that nobody could defend later.

FinSight, our fund reconciliation system, puts approval in one place. Matching rules are explicit and versioned, and anything unmatched becomes an exception with its own lifecycle: raised, investigated, resolved, with the resolution attached. Access and approval sit on resolving exceptions, because that is the step where human judgement enters the data.

The routine matches need no approval because the rules are written down and reviewable. The unmatched records, which reconciliation teams call breaks, need a person because no rule covers them. Approving every matched line would bury the few decisions that matter under many that do not.

Do not treat approval as proof that a write worked. An approval shows a person meant the change, and nothing about whether it happened. On Solarpunk the record of each run compares the agent's claimed completion with the actual state of the target application. That comparison catches an agent claiming success on work that never took effect, which an approval given before the call cannot catch.

How do you stop needing approval for one action?

Record every decision on the action: approved as proposed, edited before approval, or rejected, and why. When approvers have stopped editing or rejecting that action, the approval step is no longer adding judgement. Decide in advance how many decisions you need before you will look, so the number is not chosen afterwards to fit the result.

Three more conditions have to hold before approval comes off. Something other than the agent must confirm the final state. The tool must enforce a limit on what one call can do, such as an amount or a record count. And there must be a known way to undo the change, or to make up for it, that someone owns.

Then move that one action to acting inside limits, and leave approval on every other action. A support agent can update a ticket tag without approval and still need one for a refund, and that mixed state is normal. Our guide on AI agent governance covers moving one action at a time and who signs off on each move.

On the telecom engagement, every agent action in the current phase is proposed and approved, and the plan is to widen autonomy per action type as the audit history supports it. On Skionis, engineers went from refusing to let an agent near production to letting it own routine cloud changes, and what the engineers were shown earned that, not the model.

Can an agent switch off the check that watches it?

It can if any tool reaches the check, so give it none. Keep the alerting, audit and approval configuration out of every tool and credential the agent holds. Never let the agent's own account of what it did become the record a person approves against.

Both rules come from the same failure. OpenAI's misalignment report of 20 October 2026 covers two internal coding tasks in October 2026. In one, an agent told not to send Slack messages switched off the monitor's alerts to the security team. In the other, an agent removed a monitoring integration while matching a reference implementation, then called the migration complete without mentioning the removal. Each had read routine instructions as permission to weaken monitoring, and an approval written as an instruction would have been read the same way.

When is approval the wrong control?

When the person rewrites every draft anyway, an approval step adds a click without adding judgement. Let the agent prepare the change and let the person submit it in the screen they already use. Our trademark drafting system works that way: the attorney edits and signs, and the draft saves them starting from a blank page.

When an action is frequent, capped and easy to check afterwards, approval spends attention where a limit and an independent check would do the job. Approval also fails when the approver cannot judge from what they are shown. In that case, change what they are shown before adding a second approver, since a second person reading the same raw diff will miss the same things.

Common questions

What are human in the loop AI agents?#

Agents that stop before certain actions and wait for a person to approve, edit or reject them. The person sees the exact change, and the tool that makes the write refuses to run without a matching approval. Most agents mix modes. Reads and drafts run freely, while money moved, customer messages, deletions and production changes wait for a person until the record supports removing that step.

When should an AI agent need human approval?#

When the change is hard to undo, when nothing but the agent can confirm the result, or when the action has no track record yet. Reads, drafts and changes a person submits themselves rarely need an approval step. Money moved, messages sent to customers, deletions and production changes usually do, at least at first, because a wrong write changes a state other people depend on.

What is human-in-the-loop authorization for AI agents?#

An approval that the tool making the write checks before it runs. The tool looks for an unexpired approval for the exact tool, arguments and target, given by someone allowed to give it and stored in your own system. With no match it refuses and logs the refusal. A confirmation shown only in the client, or written into the prompt, can be skipped by anything that reaches the credential.

What should a person see before approving an agent action?#

The change itself, in a form they will read, rather than the agent's summary of it. On Skionis an engineer approves an architecture diagram of what will exist, because engineers stop reading raw template diffs carefully by the tenth change of the week. Run the machine checks first, so the person judges only whether this is the change they meant.

How do you avoid approval fatigue?#

Put approval only where judgement is needed. Write rules for the routine cases, and send a person only what the rules cannot decide, as FinSight does by putting approval on resolving reconciliation exceptions. Show approvers something they can judge quickly, such as a diagram or a structured diff, instead of raw output, and change what they are shown before adding a second approver.

How do you remove human approval from an agent action?#

Record every approval, edit and rejection for that action. Remove approval when approvers have stopped changing anything, when something other than the agent confirms the result, when the tool enforces a limit, and when there is a known way to undo the change. Do it for one action at a time and keep approval on the rest.