Promote one action class by one authority level, and only after that action has produced the exit evidence the change requires. A read, a case update, a message, a credit, and an infrastructure change do not share a consequence, so promoting the agent moves all of them. Bigcircle releases agents on client systems this way, and a drift or an incident demotes the action.
Key facts
Definition
Agent autonomy is promoted one action class at a time, by one authority level, and only after that action has produced the exit evidence the change requires.
How Bigcircle does it
- Bigcircle releases against separate levels, because a read, a case update, a message, a credit, and an infrastructure change do not share a consequence.
- Bigcircle moves one action class up one level only after the exit evidence for that change exists.
- A drift or an incident demotes the action, and Bigcircle holds the other classes where they were.
Comparison
A broad autonomy decision moves several action classes at once, while Bigcircle promotes one class and keeps the rest fixed.
In this guide we set out the five authority levels we release against. Each level has exit evidence it demands before an action moves up, conditions that should move an action back down, and a review cadence that makes those decisions routine rather than exceptional. The levels start once the work needs an agent. When not to build an AI agent is the prior question: a scripted workflow, a retrieval app, or the loop.
Autonomy is not one switch
An agent's capability changes every time the model, tool catalogue, workflow, prompt or data source changes, which in practice means it changes most weeks. Its authority should not expand at anything like that speed, and keeping the two decoupled is the central discipline of releasing this kind of system.
The way to keep them apart is to treat authority as a set of decisions applied to action classes rather than to the agent. A case-routing action may run inside a bounded policy while a customer message still needs approval, and a refund or production change remains unavailable entirely. That mixed maturity is not a temporary defect on the way to full autonomy. It is a precise operating model, and it lets the product ship useful execution while high-consequence actions stay at a lower authority level.
The alternative is a broad autonomy decision that changes several unknown properties at once. That makes failures harder to attribute, and safe progress harder to prove to the people who have to sign it off.
Promote an action class, not the whole agent
Define the promotion unit before you define the release, because a release cannot be evaluated against a boundary nobody wrote down. An action class is one verb on one resource type, in one environment, with the eligible states, allowed fields, approval, and verification written down:
- one action verb;
- one target system and resource type;
- eligible current states;
- allowed fields and parameters;
- tenant and environment;
- approval conditions;
- credential scope and lifetime;
- expected-state and verification rules;
- retry and recovery limits.
Each release then changes one material authority property while holding the rest fixed. A team can move one case update from prepare to act-after-approval without also expanding the eligible records, the parameter range, the tenant, the volume or the credential lifetime. When performance changes afterwards the team knows which authority change created the new risk, which is the entire reason for the constraint.
Five authority levels sit on that action class, and read and recommend still leave the system of record to a person. Prepare builds the pending change and waits for someone to submit it. Act after approval runs one approved object, and act inside a policy runs only inside limits the action has already held. Each step up is a separate release.
| Level | What the agent may do | Who still acts | Exit evidence |
|---|---|---|---|
| 1. Read | Read permitted information and change no state | A person interprets and acts | Correct tenant access, fresh sources, restricted data held back, and a trace of every read |
| 2. Recommend | Propose one action with the evidence behind it | A person decides and executes | The right action, no forbidden action, and exceptions escalated rather than guessed |
| 3. Prepare | Create the exact pending change | A person reviews and submits | Eligible target, fields inside policy, and no write before that submission |
| 4. Act after approval | Execute one exact approved action | A person approves that object | Fresh approval, a matching precondition, an independent final-state check, and no duplicate retry |
| 5. Act inside policy | Execute without case-by-case approval, inside proven limits | The operational owner, on stop or demotion | Continuous evidence that outcomes stay inside the approved range |
Level 1: read
At Level 1 the agent reads permitted information and changes no state. The release has to prove:
- correct tenant and user access;
- source provenance and freshness;
- protection of restricted data;
- resistance to untrusted instructions in retrieved content;
- reliable handling of missing evidence;
- complete read traces.
Read-only is not risk-free, and treating it as a formality is a common mistake. A prompt injection can still alter the agent's next decision, and a permission bug can expose another tenant's data. Read-only operation buys a limit on direct system consequences, bought while the team is still learning about context quality and the shape of the workflow. Exit Level 1 when the agent consistently finds the right evidence, respects access limits, and recognises when it does not have enough information to proceed.
Level 2: recommend
At Level 2 the agent proposes one action and a person decides and executes it. A recommendation that a reviewer can actually act on has to carry the exact target and proposed parameters, the evidence and its provenance, the current state, the expected result, the known uncertainty, and the policy or rule the recommendation rests on.
The eval suite at this level tests whether the agent selects the correct action, avoids forbidden ones, and escalates the exceptions instead of guessing. Track acceptance and correction rates by action class rather than in aggregate. A high overall acceptance rate will comfortably hide repeated errors concentrated in one sensitive segment. Exit Level 2 when reviewers can identify the proposed action quickly, the correction patterns are understood rather than only counted, and the proposal is useful enough to justify preparing the change.
Level 3: prepare
At Level 3 the agent creates the exact pending change and a person reviews and submits it, which closes the gap between a recommendation and a set of executable parameters. The system has to prove that:
- the target is eligible and the current record version matches;
- the fields and values stay inside policy;
- the prepared object cannot change silently after review;
- the approval view contains the evidence a decision needs;
- no write occurs before human submission.
Hash or version the prepared action, and invalidate the review if the target, the evidence or the parameters change between preparation and submission. Without that, a reviewer can approve one thing and submit another. Exit Level 3 when prepared actions are correct, reviewers can detect the exceptions, and submission does not conceal a hidden execution path.
Level 4: act after approval
At Level 4 the agent executes one exact action after fresh human approval, and the approval has to bind to the target, the parameters, the evidence, the expected result, the policy and a time window. The release must prove that:
- the approval is current and belongs to the correct role;
- the action matches the approved object;
- the credential is available only for the approved scope;
- the current state still matches the precondition;
- the final state is verified independently;
- timeouts enter an explicitly unknown state;
- retries do not duplicate the business effect;
- failures preserve a useful handoff to a person.
This level is often the correct long-term state for high-consequence work rather than a stage to be outgrown. Human approval is a control selected by consequence, and there are actions whose consequence never falls far enough to justify removing it. Proving the action finished, rather than that the call returned, is covered in why agents report unfinished work as done.
Level 5: act inside a bounded policy
At Level 5 the agent executes without case-by-case approval, inside limits it has already proven it stays within. The policy has to define:
- eligible records and current states;
- allowed fields and parameter ranges;
- value, volume, and frequency limits;
- tenant and environment;
- credential scope and lifetime;
- required evidence;
- expected-state and invariant checks;
- retry and recovery limits;
- the conditions that trigger stop, demotion, or containment.
Bounded execution is not permission to improvise beyond the contract. The agent can still adapt its path to the situation; what the policy constrains is the set of consequences it is able to create. Exit evidence at this level is continuous rather than a one-time gate, and the action stays promoted only while production evidence remains inside the approved range.
Require exit evidence at every level
Promotion is a release decision backed by evidence, and that evidence should cover five dimensions rather than collapsing into a single number. Each asks a different question, and a system can pass four of them while failing the fifth in a way that only shows up in production.
| Dimension | Evidence question |
|---|---|
| Boundary adherence | Did every action stay inside target and parameter policy? |
| Decision quality | Did the system choose the correct action and escalate exceptions? |
| Execution reliability | Did permitted actions reach the expected final state? |
| Recovery safety | Did unknown and partial states avoid duplicate or broader effects? |
| Operational control | Can people inspect, stop, contain, and complete the work? |
Resist reducing this to one overall pass rate. An agent can perform routine cases well and still fail precisely the exceptions that make write access dangerous. An aggregate score is designed to hide exactly that. Review failure clusters by action class, tenant, state, parameter range, tool, model version and recovery path, and use observability to connect offline evaluation with production outcomes so that promotion evidence does not stop accumulating at launch.
Mixed maturity is the correct end state
Different actions should stop at different levels and stay there. A low-risk case label may reach bounded execution, a customer-state transition may require approval indefinitely, a financial adjustment may remain at prepare, and a production deletion may remain unavailable.
Treating authority at the action level improves product planning, because it replaces one vague autonomy roadmap with several measurable release tracks that can move independently. It also improves stakeholder trust in a way that a single autonomy decision cannot: security can approve a narrow action without endorsing every future capability, product can ship value without waiting on the highest-risk action, and engineering can build shared controls while keeping policy specific to each consequence.
Stop, demote, or roll back when evidence changes
Authority is not permanent, and the conditions that should reverse it are knowable in advance rather than discovered during an incident. Writing them down at promotion time turns demotion into a decision someone can take without relitigating the original release. Demote or stop an action when:
- the model, prompt, tool, or policy changes materially;
- a new target or parameter range is introduced;
- the verifier becomes unavailable;
- production outcomes drift outside the approved range;
- retries or partial failures exceed the recovery design;
- the system cannot reconstruct the authority chain;
- an incident reveals a new consequence;
- review capacity or containment ownership changes.
A change can require fresh evaluation even when the action name stays the same. Moving from an API to computer use, for instance, changes how the agent observes state, how it selects a target, and how likely a duplicate submission becomes, none of which is visible in the name of the action.
Promotion records should preserve the approved versions and the exit evidence behind each decision, and demotion should be a normal operating control rather than an exceptional admission of failure. Teams that treat it as the latter stop demoting, which is how an action stays promoted after the evidence for it has gone.
A practical release cadence
Run a short action review with product, engineering, security and the operational owner. Seven steps, and the discipline is that each one produces a written answer rather than a shared impression, because the next review needs to know what this one decided.
| Step | What it means |
|---|---|
| Select one action | One with material value, manageable consequence, clear verification and precise boundaries |
| Record the current level | Do not assume a prototype sitting at recommend is ready for act-after-approval |
| Define one promotion | State the exact authority property that changes, and keep every other boundary fixed |
| Agree the exit evidence | Evaluation cases, production signals, review window and failure thresholds, before release |
| Release to a bounded population | Limit tenant, environment, volume, record class or user group, and keep a containment path |
| Review outcomes and exceptions | Final-state evidence, unknown states, corrections, retries, recovery, human intervention |
| Promote, hold, or demote | Decide per action class, and do not let product pressure substitute for missing evidence |
Map the first action before you discuss autonomy
The first useful question is not how autonomous the agent should be. It is:
Which one state-changing action is ready for a higher authority level, and what evidence supports that decision?
The one-page Agent Action Boundary decision sheet helps a team compare candidate actions, and the full Agent Action Boundary Canvas captures the action contract alongside the evidence required for promotion. How to scope AI agent permissions is that contract written out for one action.
Bigcircle builds production AI systems and agent workflows with these controls inside the existing product and engineering environment. If your next release depends on one action the team still cannot approve, tell us what the action changes. That is enough context to begin the right technical conversation.
Production takeaways
- Autonomy is not one switch. Capability changes every time the model, tools, prompt or data source changes, and authority should not move with it.
- Promote an action class, not the agent, and change one authority property per release so failures stay attributable.
- The five levels are read, recommend, prepare, act after approval, and act inside a bounded policy.
- Each promotion needs exit evidence across five dimensions rather than one aggregate score.
- Track acceptance and correction rates by action class. A high overall rate hides errors concentrated in one sensitive segment.
- Mixed maturity is the correct end state, not a stage on the way to full autonomy.
- Write the demotion conditions at promotion time, so reversing authority is a decision rather than an incident.
Common questions
How do you roll out AI agent autonomy?#
Promote one action class by one authority level, and hold every other boundary fixed for that release. A read, a message, a credit, and an infrastructure change do not share a consequence. The next level waits until that action has produced its exit evidence. A material change to the model, the tool, or the policy sends the action back for a fresh review.
What are the five levels of AI agent autonomy?#
The five levels are read, recommend, prepare, act after approval, and act inside a bounded policy. At read the agent changes no state. Recommend proposes an action and a person executes it. Prepare creates the pending change and a person submits it. Act after approval executes one approved object, and the last level executes only inside limits the action has already stayed within.
Should every AI agent action become fully autonomous?#
Mixed maturity is the operating model, so an action stops at the level its consequence supports. A low-risk label can run inside a bounded policy while a customer-state change keeps human approval. A financial adjustment can stay at prepare, and a production deletion can stay unavailable. Security can approve the narrow action without endorsing every later capability.
What evidence should an agent promotion include?#
Promotion evidence covers boundary adherence, decision quality, execution reliability, recovery safety, and whether a person can stop and finish the work. Do not collapse those into one pass rate. An agent can pass routine cases and still fail the exception that makes a write dangerous. Review the failures by action class, tenant, state, and recovery path.
When should you take authority away from an agent action?#
Demote or stop the action when the model, prompt, tool, or policy changes, or when a new target or parameter range appears. Also demote when the verifier goes unavailable, when outcomes leave the approved range, or when retries exceed the recovery design. Write those conditions down when you promote, so a later reversal does not reopen the original release.
What is an action class in an agent release?#
An action class is one verb on one resource type, in one environment, with the states, fields, approval, and verification written down. A release changes one of those properties and holds the rest fixed. Moving a case update up from prepare does not also expand the records, the tenant, the volume, or how long the credential lives.