The Goal Is Not Maximum Autonomy
TLDR: Instead of pursuing maximum autonomy, effective AI agent systems use "bounded autonomy" to assign authority levels based on decision risk factors like reversibility, blast radius, and evaluator reliability. By implementing an authority ladder rather than a binary switch, teams can better allocate human attention to critical edge cases while automating routine, low-risk tasks.
Every agent decision needs an authority level
Most engineering discussions about AI agents start with a single question: "how autonomous is your agent?" The answer is supposed to be a number — level 3, level 4, fully autonomous. Vendors compete on it. Investors ask about it. The destination is implied to be a system that runs without people.
This framing misses two things.
First, a single agent makes many different kinds of decisions. Some are cheap to undo and affect nothing outside the current draft. Others change a client's knowledge base, commit budget, or publish an asset. Putting one autonomy label on the whole system hides these differences.
Second, the goal is not maximum autonomy. The better goal is bounded autonomy: each decision routed to the right authority level based on error cost, reversibility, and the reliability of available evaluation. A system that ships 80% of decisions autonomously but occasionally publishes a bad creative asset can be worse than one that ships 40% autonomously but never does. Whether the trade-off actually favours less autonomy depends on the cost of the error, the cost of the review, and the volume of decisions.
Production research suggests that calibrated oversight is common. The current MAP paper reports a survey of 86 deployed-systems practitioners across 26 domains, alongside 20 case studies. It reports that 68% of agents execute at most 10 steps before human intervention and 74% depend primarily on human evaluation [1]. These findings describe the studied deployments; they do not establish a universal optimum for autonomy.
Every decision has a risk profile
Before assigning authority, you need to inventory the decisions. A creative production workflow, for example, contains many distinct steps:
- Propose an idea or campaign concept
- Generate script variants
- Decompose a script into scenes
- Produce visual assets
- Check an asset against format and brand rules
- Rank candidates for expert review
- Select a final creative
- Reject a candidate as unsuitable
- Update a reusable rule based on reviewer feedback
- Publish or deploy the result
These are not the same kind of decision. The dimensions that determine appropriate authority are:
- Reversibility. Can the action and its consequences be undone cleanly? A draft scene can be discarded. A published asset can sometimes be removed, but its exposure and downstream effects cannot necessarily be reversed. Reversibility is a useful signal for gate placement [2]. Map each step to its practical undo cost and assess that cost together with the consequences, evaluation evidence and required controls.
- Blast radius. How many entities does this action affect? Proposing a creative variant affects one candidate. Changing a client-wide brand rule affects every future output. High blast radius raises the gate requirement even for actions that seem low-risk in isolation.
- Evaluator reliability. Do you have representative evidence that the system can detect relevant failures? A format check (is this the right aspect ratio?) is highly reliable. A semantic check (does this creative communicate the right message?) is harder to automate confidently. Low evaluator reliability means the system should recommend rather than decide.
- Decision frequency. How often does this decision occur? Format checks happen on every asset. Publishing happens once per campaign. Frequent, low-cost decisions can justify more automation investment; infrequent, high-consequence ones should default to human approval.
These dimensions combine. A highly reversible decision with a small blast radius and a reliable evaluator can run autonomously. An irreversible decision with a large blast radius and uncertain evaluation needs a human gate, regardless of how confident the model is.
An authority ladder, not a switch
Autonomy is often treated as binary: the agent acts, or a human reviews. A more useful design assigns authority per decision type. Safin and Balta describe five interaction levels, adapted from earlier work [3]. The table below follows those interaction definitions and adds illustrative creative-production examples. Other frameworks use different numbering and boundaries; the CSA Lab Space framework, for example, defines six levels [4]. The numbers are not interchangeable.
| Level | Human role | Agent behaviour | Example in creative production |
|---|---|---|---|
| 1 — Operator | Directs a specific action | Executes the requested sub-task | Apply a format transform to one asset |
| 2 — Collaborator | Works iteratively with the agent | Drafts and revises in a shared workflow | Revise a script together with an expert |
| 3 — Consultant | Confirms the proposed direction | Leads planning and pauses for direction checks | Propose a production plan and confirm which creative criteria to prioritise |
| 4 — Approver | Approves consequential actions before execution | Works within scope and waits for required sign-off | Prepare a final asset and wait for approval before publication |
| 5 — Observer | Monitors and can intervene | Operates autonomously within its assigned scope | Run routine checks end-to-end and flag exceptions for monitoring |
The key insight from the Anthropic study of millions of agent interactions is instructive: experienced users in Claude Code auto-approve more frequently as they gain trust, but they also interrupt more often [5]. They shift from per-action approval to monitoring and intervention. This is not a binary move from "supervised" to "autonomous." It is a reallocation of attention: the human spends less time on routine decisions and more time on the edge cases that actually benefit from their judgement.
A system that supports this kind of graduated authority needs three things:
- A decision inventory that classifies each step along the dimensions above.
- An enforcement layer outside the model prompt. A human-in-the-loop instruction inside the system prompt is not a reliable gate. The model can ignore it, reinterpret it, or have it stripped by injection. The enforcement needs to live in the execution layer — the dispatcher refuses to execute until the gate clears. This is not about prompt engineering; it is about architecture [2].
- A promotion and demotion policy. Authority should change with evidence. Start new domains or materially changed models at a conservative level. Promote only after representative held-out results meet decision-specific error bounds. Demote after drift, unexplained disagreement, or a serious incident.

What runs autonomously, what stops and asks
Applied to a creative production workflow, the mapped decisions look something like this:
Execute autonomously (with audit). Format checks, aspect-ratio validation, resolution requirements and explicit, measurable palette constraints can use deterministic rules. Semantic brand consistency needs separate evaluation. These checks affect one candidate, and rejection can be reversed only if the candidate and its evidence are retained. The system can run reliable checks on every candidate and audit a sample of rejections for alignment.
Rank for expert review. The system scores candidates against taxonomy dimensions and presents them in priority order. The human sees the top candidates with the evidence, but the decision to select or reject remains with the expert. This is recommendation support: the system analyses, and the human decides. It should not be confused with approval after an action has already occurred.
Execute with rejected-sample audit. A specialist evaluator checks for semantic failures, such as a creative that contradicts the brief, uses a disallowed hero type or fails a gameplay rule. A blocking failure can stop a candidate while retaining it and its evaluation evidence. Experts review survivors and a sample of rejections. This audit is a monitoring control, not a substitute for pre-action approval where that is required. If the sample reveals systematic false rejections, reduce the evaluator’s authority, investigate the cause, and validate any change before restoring it. Frameworks such as the CSA Lab Space framework distinguish bounded execution, monitoring and escalation controls [4].
Require human approval. Changing a reusable rule or knowledge entry based on one reviewer comment. Publishing an asset. Committing budget. These are irreversible or high-blast-radius decisions. The system prepares the evidence and the proposed action, then waits.
Human-only. The system may supply evidence, but a named human retains the decision. This applies to decisions where evaluator reliability is unproven, the action is irreversible, and the blast radius is large — for example, updating client-wide brand guidelines.
The common failure modes
Three patterns recur across teams that get this wrong.
Over-gating. Every action requires approval. The agent proposes, and the human clicks approve. Repeated low-value requests can lead to approval without meaningful review [2]. Audit the gates: how often is the human asked, and what evidence do they use? A gate with a 99% approval rate warrants investigation, but that rate alone does not justify removing it. Replace it with sampled review only when decision-specific error evidence, consequence reversibility and required controls justify the change.
Under-gating. The agent has full tool access and no pre-execution check. The model is capable, so it "should be fine." It is fine until a single bad action — a bulk delete, a publish to the wrong environment, a budget commitment — produces an incident that takes longer to recover from than the automation ever saved. The fix is the decision inventory: map every action to its reversibility and blast radius before granting any autonomy.
Rubber-stamp approval. The human is in the loop, but the context package is insufficient. They see "approve candidate Y" with no evidence of what the agent evaluated, what alternatives were considered, or why this one passed. The human cannot meaningfully assess the decision, so they approve. The fix is a decision-ready context package: the action in plain language, the agent's reasoning, the alternatives evaluated, a reversibility flag, and an approval deadline [4].
Measure decision quality, not autonomy rate
A commonly reported metric is the percentage of decisions handled autonomously. On its own, this says little about value. An agent that autonomously generates 1,000 unusable candidates is fully autonomous and still unhelpful. A system that resolves routine checks for 9,950 of 10,000 assets and routes 50 ambiguous cases to a human handles 99.5% automatically. Whether it is useful still depends on error rates, review effort and accepted outputs.
The metrics that matter:
- False acceptance and false rejection rates by decision type. How often does the system approve a bad candidate? How often does it reject a good one?
- Human review minutes per accepted output. Is the automation actually reducing expert burden, or is it shifting the work to review?
- Escalation and override rates. How often does the human disagree with the system's recommendation? Rising rates signal drift or a mis-set authority level.
- Time to detect and recover from a bad action. If the system executes something wrong, how long before someone notices? How long to undo?
- Audit-detected failures. In autonomous-with-audit mode, how often does the sampled review find a problem?
These metrics let you tune authority per decision type, rather than brag about an aggregate autonomy number.
The framework has a cost
Inventorying decisions, building an enforcement layer and maintaining an authority policy require engineering work. A small internal research tool may need only a simple approach if its actions are low-consequence and reversible. A multi-client creative production system usually needs more explicit boundaries because decisions can affect shared rules, customer assets and external publication.
A useful heuristic is to assess whether a single bad autonomous action could cause a support incident, lost revenue or harm to a client relationship. Those consequences can justify investment in explicit authority levels. If the worst case is a disposable draft, a simpler workflow with limited tools and post-action review may be sufficient. The controls should follow the action’s consequences, not team size alone.
Bounded autonomy is the production pattern
The MAP study reports simple, controllable approaches in its production sample, with reliability identified as the main development challenge [1]. These observations support evaluating autonomy as an engineering trade-off. They do not prove that lower autonomy is always better or establish a causal relationship between a particular authority level and reliability.
The Anthropic data tells a complementary story: even as users gain experience and trust, they shift their oversight pattern rather than abandoning it. They monitor more and approve less, but they remain on the loop [5].
This is the pattern that works. Not a single autonomy setting for the whole system. Not a binary human-in-the-loop switch. A decision inventory, an authority ladder, an enforcement layer outside the prompt, and a promotion policy that changes authority only when evidence justifies it.
The goal is not to remove people. It is to use their attention where it changes the outcome, and to earn broader authority through measured performance.
We are building agentic creative production systems that encode expert judgement into executable, measurable, and improvable workflows. This post is part of a technical series on specialised AI agents. Earlier posts introduced the system architecture and how pre-launch evaluation works; a later post will examine how feedback becomes durable system improvement and other areas we are working on.
References
- Pan, M. Z. et al. (2025; revised 2026). Measuring Agents in Production (MAP), arXiv:2512.04123v4.
- AgentPatterns.ai. Human-in-the-Loop Placement: Where and How to Supervise.
- Safin, D., & Balta, D. (2026). Autonomy and Agency in Agentic AI: Architectural Tactics for Regulated Contexts, arXiv:2605.12105.
- Cloud Security Alliance AI Safety Initiative (2026). Agentic AI Autonomy Levels and Control Framework, version 2.0. CSA Lab Space.
- Anthropic (2026). Measuring AI agent autonomy in practice.
