Skip to main content
If you take away one idea from this knowledge base, make it this one. Every piece of work an agent prepares passes through a human before it counts.

What it is

Every piece of work an agent prepares passes through a human-in-the-loop review gate before it’s treated as final. The agent prepares; a person approves. This is structural — it is not a setting you can turn off.

Why it exists

Finance and accounting work carries professional and regulatory responsibility. A prepared workpaper, a filed return, a reconciliation — these need a qualified person to stand behind them. The HITL gate makes that explicit and auditable: there is always a named reviewer and a timestamp on every approval.

How it works

1

A run finishes

An agent run completes and produces output.
2

It lands in the review queue

The output lands in the review queue for that engagement, marked action needed, and the assigned reviewers are notified.
3

A reviewer decides

A reviewer opens it, checks the work against its cited sources, and either approves it (it becomes final) or sends it back with notes (it returns for correction).
4

The decision is recorded

The decision, the reviewer’s identity, and the time are all recorded in the audit trail.

What a gate looks like in practice

Gates aren’t only an end-of-run yes/no — an agent can pause mid-run at a specific decision point. In a Revenue Flux run, for example, the agent completes its variance analysis and then opens a Controller exceptions gate: it lists the exceptions it couldn’t resolve on its own (say, an unfamiliar vendor in Data Costs) with the supporting detail, and waits. Only once a controller clears those exceptions does the agent go on to draft commentary and build the workbook. The gate is a checkpoint inside the workflow, not a rubber stamp at the end.
A gate can be conditional — always, only on low-confidence items, or only on flagged exceptions — so routine work flows through while genuinely uncertain items stop for a human. Builders configure this; the gate itself is always present.

Who reviews

Reviewers are assigned per engagement (per process), not per client. R&D reviewers and transfer-pricing reviewers for the same client can be different people, each seeing only their own queue. This lets review responsibility follow expertise.

For end users

Most of your time in Adopt is spent at this gate. See Reviewing and approving work for the day-to-day.

For builders

You don’t wire the gate up — it’s always present. What you control is who the reviewers are, and (in Advanced setup) how routing and escalation behave. See Instructions and skills and Notifications.

Next steps

  1. Reviewing and approving work
  2. The object model
  3. Notifications