wanile.
Start free trial
Message the founder
All posts
Blog
Agents · · 5 min read

Human-in-the-loop AI agents: where to put the approval step

An approval step makes AI agents safe to run on real data, if it sits in the right place. How to choose that place, with TalVagt as the example.

Muhammad AbdullahFounder & CEO, Wanile

Every team building AI agents reaches the same question: should a person approve what the agent does? For anything that touches real money, real customers or real records, the answer is yes, at least to start with. The harder question is where.

Put the approval too early and too often, and people click "approve" without reading. Put it too late, and the agent has already done the thing you wanted to check. Put it in the right place, and the agent does nearly all of the work while a person makes the one decision that matters.

The rule: approve at the point of no return

Look at every step the agent takes and ask one question: can this be undone without anyone outside the system noticing?

  • Reversible: reading an email, extracting fields, searching records, drafting a reply, preparing an entry. If the agent gets these wrong, you throw the draft away.
  • Irreversible: sending an email, posting to a ledger, paying an invoice, filing a form, changing a customer's record. Someone outside the system sees the result.

The approval goes directly before the first irreversible step. Everything before it can run on its own, be retried and be thrown away. Everything after it happens because a person said yes.

That gives you one approval per real decision, instead of one per step.

A worked example: TalVagt

TalVagt is an AI bookkeeper for Danish small businesses. Wanile engineered the agent system behind its first version: a 9-week MVP, with a core team of two engineers.

The flow is simple to describe:

  1. An invoice arrives in the business's Microsoft Outlook inbox. An orchestrator agent hands the work to a dedicated bookkeeping agent.
  2. The bookkeeping agent reads the invoice and drafts the journal entry.
  3. The owner looks at the draft and approves it.
  4. Only then is the entry posted to e-conomic, the accounting system.

Steps 1 and 2 are reversible: a wrong draft costs nothing. Step 4 changes the books. So the approval sits between them, and the rule is strict: nothing is posted without a click.

The hard part of the project wasn't the agent. It was letting AI touch real accounting data safely. Three things did that together: the strict approval step, memory that learns from every approval, and personal-data scrubbing before any model call.

Make every approval teach the system

An approval step that only records yes or no throws away the most useful signal you have. TalVagt keeps a pattern memory on pgvector, so every approval improves the next suggestion. A decision the owner has already made becomes something the agent can draw on when a similar invoice arrives.

That is the aim of the whole design: the owner's job shifts from correcting drafts to confirming them.

Keep data the model doesn't need away from it

On TalVagt, GDPR scrubbing removes personal data before anything reaches the AI. That is a design decision, not a setting. You decide what the model needs to see to do the job, and remove the rest before the call. It is far easier to build in on day one than to add after a privacy review.

Let people watch a browser agent

Some steps need a real browser. For those, TalVagt uses Computer Use with live browser streaming. When an agent is driving a browser, streaming it means a person can see what it is doing as it happens, rather than finding out afterwards.

Designing the approval screen

Where the approval sits is half the design. The other half is what the person sees when they are asked.

  • One decision per screen. "Post this entry" is a decision. "Review this agent run" isn't.
  • The evidence next to the action. Show the source document, the drafted output, and what will change if they say yes. If they have to open another tab to check, they won't.
  • A one-line reason. If the suggestion came from a past approval or a rule, say so.
  • Easy edits. Much of the value is in small corrections. Capture them: they are what the next suggestion learns from.
  • A safe wait. Decide what happens when nobody answers. A pending approval must wait, never time out to "yes". For work that can sit for hours or days, use a durable workflow engine such as Temporal, so a pending step survives restarts and deploys.
  • A log of every decision. Who approved what, when, and what the agent proposed. You will need it the first time someone asks why an entry is there.

Enforce it in code, not in the prompt

"Always ask before posting" in a prompt is a hope, not a control. The approval has to be enforced where the action happens.

  • The tool checks for an approval. The agent's tool for the irreversible action should refuse to run unless an approval record exists for that exact action.
  • The credentials can't act alone. The agent's own access should not be enough to do the irreversible thing without that approval.
  • Agents stay away from what they don't need. It is the same principle as our security rules for the coding agents our engineers use: agents work on code, never on live systems or customer data.

Sometimes the agent should only draft

Sometimes the right place for the approval is outside the product altogether. On Go Legal AI, the assistant explains and drafts, but never files or sends anything for the user, and never presents itself as a lawyer. The user takes the irreversible step themselves. For regulated work, that is often the simplest boundary to defend.

When can the approval go?

Not on a schedule. When the data supports it, and when the business decides.

Track, for each type of action, how often the person approves without changing anything. A category that has been approved unchanged for a long run may be a candidate for automatic handling, with spot checks. The same invoice from the same supplier every month is a better candidate than a new supplier with a new format.

Two cautions. First, removing an approval is a business decision, not an engineering one: the person who carries the risk makes it. Second, keep the audit log, and keep the ability to switch the approval back on for each category. You will want both.

A checklist

  • List every action the agent can take, and mark the irreversible ones.
  • Put one approval directly before each irreversible action.
  • Show the source, the draft and the change on the approval screen.
  • Capture edits, and feed approved decisions back as examples.
  • Scrub personal data before any model call.
  • Enforce approvals in the tool and in permissions, not in the prompt.
  • Log every decision, and never let a pending approval default to "yes".

Get the approval in the right place and the agent stops being a risk you manage. It becomes work that is done before anyone asks, waiting for one click.

All posts

Have a similar problem?

Tell us what's stuck. We'll say honestly if we can take it.

Book a free call