An agent that can act is only useful if the business can trust what it does. That trust is not a property of the model. It is a property of the system around the model. This paper sets out the pattern we use to give agents genuine autonomy while keeping a human accountable for every consequential action: approval lanes, reversible actions and a complete audit trail.
1. The control problem
Autonomy and safety are usually treated as a trade-off: the more an agent can do on its own, the less oversight there is. That framing is wrong. The real variable is not how much an agent does, but which actions are allowed to happen without a human in the loop, and how visible every action is after the fact.
A useful agent touches real systems: it sends messages, moves money, changes records. The question a business actually asks is simple: if this goes wrong, will I know, and can I undo it? Everything below is an answer to that question.
2. Approval lanes
We classify every action an agent can take into one of three lanes, by blast radius, not by how "smart" the step is.
| Lane | Meaning | Human involvement |
|---|---|---|
| Green | Reversible, low-consequence (draft a reply, tag a record, propose a plan) | None: the agent acts, and it's logged |
| Amber | Consequential but recoverable (send an email, issue a refund under a threshold) | Notify + allow undo within a window |
| Red | Irreversible or high-value (delete data, pay above a threshold, sign) | Explicit human approval before it happens |
The lane is a property of the action type and its parameters, decided by deterministic rules, not by the model's confidence. A model that is confidently wrong must still not be able to cross a red line on its own.
3. Reversibility as a first-class design goal
The cheapest form of safety is an undo button. Wherever an action can be made reversible, we make it reversible and move it to a lower lane: a held send, a soft delete, a staged change that commits after a delay. Reversibility turns an approval gate into a notification, which keeps the operation fast without giving up control.
4. The audit trail
Every action (proposed, approved, taken, reversed) is recorded as an immutable event: what the agent did, the inputs it saw, the rule that set the lane, who approved it, and the outcome. The trail is not a log file; it is the primary interface for trust. It answers "what happened and why" for any single action, and it is where the system's behaviour is reviewed and improved. It is also the record that transparency regulation leans on: how we engineer for the EU AI Act's Article 50 duties on top of exactly this trail is set out in Engineering for the EU AI Act.
5. Why this makes agents more autonomous, not less
Counter-intuitively, strict lanes increase how much you let an agent do. Once every consequential action is either reversible or gated, and every action is on the record, there is no reason to keep the agent on a short leash for the reversible majority of its work. Governance is what lets you safely widen autonomy, and the audit trail is what makes each exception a lesson that tightens the rules over time. The multi-agent intelligent warehouse is a worked example of the same lanes applied to a system where safety and compliance agents sit alongside operational ones.
Trust is not the absence of oversight. It is oversight made cheap enough to always be on.
6. Where this sits against the standards
None of this is novel as governance. What is novel is applying it at the granularity of an individual agent action rather than at the granularity of a system or a release, and the established frameworks all point the same way.
The EU AI Act requires human oversight and record keeping for high-risk systems, and its Article 50 transparency duties require a disclosure trail that only exists if something recorded the interaction at the time. We set out the engineering of that in engineering for the EU AI Act, and what enforcement actually looked like in practice in the first month.
The NIST AI Risk Management Framework organises risk around govern, map, measure and manage, and the measure function is the one that fails silently: you cannot measure what you did not record. The lanes in section 2 are a way of deciding what to record before an incident makes the question urgent.
ISO/IEC 42001, the AI management system standard, asks for documented decision authority. An approval lane is that authority expressed as code rather than as a policy document, which is the difference between a control that holds under load and one that holds in an audit.
The reversibility argument in section 3 is the same instinct as NIST SP 800-207 on zero trust: stop asking whether an actor is trusted and start asking whether this specific action, right now, is permitted and recoverable. The agent-specific version of that boundary is worked through in AI agent security: the real attack surface and in OpenAI's dots: the boundary is the product.
7. Sources
- Regulation (EU) 2024/1689, the AI Act, the consolidated text, for human oversight, record keeping and the Article 50 transparency duties. A readable navigator is maintained at the AI Act Explorer.
- NIST, AI Risk Management Framework 1.0, 2023.
- ISO/IEC, 42001:2023, AI management systems.
- NIST, SP 800-207, Zero Trust Architecture, 2020, the per-action framing this paper borrows.
This paper sits in our Research track, alongside the governance and agentic threads. The full library is at Research.