Every agent that does real work will reach a moment where a person has to decide. Get that moment wrong in one direction and the agent becomes a slow form that asks permission for everything. Get it wrong in the other and it acts on things nobody would have allowed. This guide shows where approvals belong, the patterns that keep them safe, and how to design the hand-off so it stays fast.
The problem
Agents act at machine speed; people decide at human speed. When the two meet without design, one of three things happens. Everything waits for approval, and the agent saves nobody any time. Nothing waits, and the first expensive mistake ends the project. Or approvals exist but carry so little context that people click "approve" without reading — the worst case, because it looks safe and is not.
An approval is where speed and safety are traded. It deserves the same design attention as the agent itself.
Concept overview
An approval is a decision point where a named person accepts responsibility for an action before — or, in some patterns, after — it takes effect. Designing one means answering three questions:
- What needs a person? Which actions, in which circumstances.
- Who decides? One accountable person or role, with a backup.
- What do they see? Enough to decide well in under a minute, most of the time.
Approvals are not a permanent tax. As an agent proves itself, actions move from "approve each one" to "approve the exceptions" to "review a sample". That is how autonomy is earned rather than assumed.
When to require approval
Require a person when an action is:
- Irreversible — payments, deletions, contract changes, anything you cannot undo.
- Financially material — above an amount you would not want decided without a look.
- External and sensitive — messages to customers, partners or regulators about money, complaints or commitments.
- About personal data — sharing, exporting or changing it.
- An exception to policy — a discount outside the rules, a deadline extension, a refund outside terms.
- New — the first time an agent performs an action, or the first weeks at a new autonomy level.
- Uncertain — the agent's evidence is incomplete or contradictory, or the situation does not match anything it was tested on.
Do not require approval for reversible, low-impact, high-volume actions with a good record. Review a sample of them instead.
Architecture
Approvals sit between what the agent proposes and what the systems record.
- Propose — the agent prepares the action and the evidence for it.
- Check policy — the action is compared with the agent's boundaries; anything outside them is blocked or routed.
- Route — actions that need a person go to an approval queue, addressed to the right owner.
- Decide — the person approves, edits, declines or asks for more information.
- Execute — the agent carries out the approved action, exactly as approved.
- Record — the proposal, the evidence, the decision, the person and the result are kept together.
In the Citadel these steps map to the Approvals module — "where is human judgment required before work continues?" — and the Activity Ledger, which records what changed, who acted and on what evidence. Athena owns the approval points in the Guild's evaluation model; Sentinel owns the boundaries they protect.
Seven approval patterns
| Pattern | How it works | Use when | Watch for |
|---|---|---|---|
| 1. Gate before action | Each action waits for a person | High stakes, new agents, irreversible steps | Becomes a bottleneck at volume |
| 2. Approve the plan | A person approves a plan; the agent executes its steps | Multi-step work with a clear outline | Steps drifting from the approved plan |
| 3. Threshold routing | Below a limit the agent acts; above it, a person decides | Amounts, quantities, risk scores | Splitting one action to stay under the limit |
| 4. Exception only | The agent acts within policy; only exceptions reach a person | Mature agents with a proven record | Exceptions the policy did not foresee |
| 5. Sample review | Actions take effect; a person reviews a sample afterwards | Reversible, high-volume work | Sample too small to catch rare errors |
| 6. Two-person rule | Two people must approve | Bank details, large payments, access rights | Both approvers assuming the other checked |
| 7. Time-boxed with safe default | If nobody decides in time, the safe option happens | Time-sensitive work | A default that is not actually safe |
Most agents use several patterns at once: threshold routing for amounts, a two-person rule for bank details, sample review for routine updates.
Implementation
Design the approval request
A person should be able to decide from the request alone. Every request shows:
- The action, in plain words — "Refund order 4417 in full", not a JSON payload.
- Why — the agent's reason and the policy it is applying.
- The evidence — the messages, records or documents it relied on, linked.
- What happens next — on approve, on decline.
- Options — approve, edit and approve, decline with a reason, ask a question.
- Deadline and default — when the decision is needed and what happens if it is not made.
Capture the reason for every decline. Declines are the most useful evidence you will collect: they show exactly where the agent's judgement and the business's differ.
Keep approvals fast
- Route to a person, not a group. "Someone in finance" means nobody. Name an owner and a backup.
- Meet people where they work. Approvals in the tool they already use get answered; approvals in a separate portal wait.
- Batch the similar. Twenty routine approvals reviewed as a list beat twenty interruptions.
- Set deadlines with safe defaults, and say what the default is in the request.
- Measure time to decision. If approvals routinely wait, the design is wrong, not the people.
Evaluation
Before launch, test that decisions which need a person reach a person. In the Guild's readiness scorecard this is the approvals dimension: the evidence is the approval trail, and Athena owns it (see Evaluation Kit 001).
Write scenarios for each rule — above and below every threshold, every exception type, attempts to split an action — and check the routing. In production, track:
- approval and decline rates, and the reasons for declines;
- time to decision, by approver;
- edits made before approval (the agent was close but not right);
- errors found in sample reviews;
- actions taken without the approval they needed (this should be zero).
Security and governance
- The agent never approves itself, and the person who requested an action should not be the one who approves it.
- Approvals are tied to identity. Every decision records who made it, when, and on what evidence.
- Approvals expire. If the situation changes before execution, the agent asks again.
- Execution matches approval. The agent carries out exactly what was approved; any change needs a new decision.
- Decision records are kept with the action, so an audit can follow the whole chain.
Cost considerations
The cost of an approval is a person's attention plus the delay while the work waits. Both are worth paying where the risk is real and wasteful where it is not.
The way to reduce the cost is not to remove approvals but to move them as evidence accumulates: from gating every action, to approving exceptions, to sampling. This is the same path the Citadel's trust model describes — observe, assist, operate within limits, optimise — and each move should be a recorded decision based on the numbers above. The Citadel Trust Model sets out the evidence for each step.
Example
Illustrative example, not a client engagement.
An agent processes supplier invoices. It matches each invoice to a purchase order and a delivery record.
- Invoices that match within tolerance, from known suppliers, are scheduled for payment (exception only).
- Invoices above an amount set by the finance lead go to the finance lead (threshold routing).
- Any change to a supplier's bank details needs two people (two-person rule).
- Mismatches go to the buyer who raised the order, with the three documents side by side (gate before action).
- Each month the finance lead reviews a sample of the automatically scheduled payments (sample review).
After a few months of clean samples, the finance lead decides whether to raise the tolerance. That decision, and its evidence, is recorded too.
Failure modes
- Rubber-stamping. Too many approvals with too little context, and people stop reading. Fewer, better requests fix it.
- The single bottleneck. One approver for everything; work stops when they are away. Name backups.
- Context-free requests. "Approve action #2231?" Nobody can decide that well.
- Threshold gaming. One payment split into three below the limit. Check aggregates, not just single actions.
- Stale approvals. Approved on Monday, executed on Friday after the facts changed. Expire approvals.
- Blurred accountability. If it is unclear who approved, nobody did.
Checklist
- Every action the agent can take is classified: act, approve first, exception only, or sample.
- Each approval type has a named owner and a backup.
- Requests show the action in plain words, the reason, the evidence and the default.
- Decline reasons are captured and reviewed.
- Deadlines and safe defaults are set and visible.
- The agent cannot approve its own actions.
- Approvals expire when circumstances change.
- Routing is tested above and below every threshold before launch.
- Time to decision is measured.
- Moving an action to a lighter pattern is a recorded decision, based on evidence.
