Agent Architecture and Orchestration
Autonomy Levels
What it is
The graded scheme fixing how much an agent may do without a person deciding: proposing only, acting after explicit approval of each consequential step, acting within declared limits and reporting afterwards, or acting freely within a bounded domain. A level attaches to a class of action in a context — this tool, this blast radius, this tenant — rather than being a single setting on the agent as a whole.
Why it matters
The distance between drafting a reply and sending it is the entire risk profile of an agent product. Making the level explicit is what allows the same capability to launch cautiously and be relaxed on evidence, instead of being held back entirely or released at full authority because those were the only two options anyone defined. It is also the thing regulators, auditors, insurers, and customers actually ask about: not how the model works, but what it was permitted to do unsupervised, who agreed to that, and what record exists of the agreement.
Policy, not mechanism
Deciding which actions require a person is a policy question answered by risk, regulation, and product judgement. Stopping a run at the right moment, holding it cheaply while someone decides, and continuing correctly afterwards is machinery. The machinery is useless without the policy — a system that can pause has nothing to pause for — and the policy is unenforceable without the machinery. They are specified, owned, and changed by different people, which is the practical reason to keep them apart.
Key decisions
- What the level attaches to: a tool, an action class, a blast radius measured in reversibility and affected records, a tenant, or a whole agent.
- What approval means in operation — each action, a whole plan, a working session, or standing permission with sampled review after the fact.
- What evidence justifies raising a level, and whether anything automatically lowers it when that evidence stops holding.
- Who grants a level, who may override it in the moment, and whether an end user can raise their own.
- What the agent does when it lacks a permission it needs: halt, request it, or take a different route to the same outcome.
- Whether the level is enforced by code outside the model, which is the only form of enforcement that survives a successful prompt injection.
Failure modes
- Approval fatigue: everything prompts, approvers stop reading, and the control degrades into a click-through that documents consent while providing no oversight.
- The permission envelope exists only in the instructions, and the first injection establishes that it was a suggestion.
- The level is set per agent rather than per action, so an agent that needed to send one kind of message unsupervised is granted unsupervised authority over everything else it can do.
- An action classified as reversible turns out not to be at scale: four thousand notifications were sent, each one individually retractable.
- The person approving has neither the context nor the time to evaluate, so the approval transfers accountability without adding judgement.
- Levels are raised during an incident to get through it and never lowered afterwards, because nothing tracks that they were raised temporarily.
- Monitoring was designed for the supervised mode; when the agent is promoted to unsupervised operation, the only remaining signal is customer complaints.
- Supervisors lose the situational awareness and practised skill needed to intervene well, precisely because the agent has been reliable enough that they stopped paying attention.
Related capabilities
- Interrupt and Resume — the machinery that makes an approval pause affordable
- Agent Definition — where the permitted action set is declared
- Agent-as-a-Tool — an inner agent's permissions must not be inherited by default
- Termination Conditions — lacking a permission is a legitimate way for a run to end
- Multi-agent Orchestration — participants in one effort may hold different levels
Applies: Production readiness · Design questions