“Launch the autonomous agent” is not a useful release unit.
One agent can read customer data, prepare a case update, send a message, apply a credit, and change infrastructure. Each action has a different consequence and evidence base.
Do not promote the whole agent at once.
Promote one action class by one authority level after the system has produced the evidence required for that change.
Autonomy is not one switch
An agent’s capability can change every time the model, tool catalogue, workflow, prompt, or data source changes.
Its authority should not expand at the same speed.
Treat authority as a set of decisions applied to action classes.
A case-routing action may run inside a bounded policy. A customer message may still need approval. A refund or production change may remain unavailable.
This mixed maturity is not a temporary defect. It is a precise operating model.
It lets the product release useful execution while keeping high-consequence actions 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 safer progress harder to prove.
Promote an action class, not the whole agent
Define the promotion unit before defining the release.
An action class includes:
- 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.
The release changes one material authority property at a time.
For example, the team can move one case update from “prepare” to “act after approval” without also expanding the eligible records, parameter range, tenant, volume, or credential lifetime.
This makes the evidence causal. If performance changes, the team knows which authority change created the new risk.
Level 1: read
At Level 1, the agent reads permitted information and does not change state.
The release must 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. A prompt injection can still alter the agent’s next decision. A permission bug can expose another tenant’s data.
However, read-only operation limits direct system consequences while the team learns about context quality and workflow shape.
Exit Level 1 when the agent consistently finds the right evidence, respects access limits, and knows when it lacks enough information.
Level 2: recommend
At Level 2, the agent proposes one action and a person decides and executes it.
The recommendation should include:
- the exact target and proposed parameters;
- evidence and provenance;
- the current state;
- the expected result;
- known uncertainty;
- the policy or rule behind the recommendation.
The eval suite should test whether the agent selects the correct action, avoids forbidden actions, and escalates exceptions.
Track acceptance and correction by action class. A high acceptance rate can hide repeated errors in one sensitive segment.
Exit Level 2 when reviewers can identify the action quickly, correction patterns are understood, and the proposal is useful enough to justify a prepared change.
Level 3: prepare
At Level 3, the agent creates the exact pending change. A person reviews and submits it.
Preparation closes the gap between a recommendation and executable parameters.
The system must prove that:
- the target is eligible;
- 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 needed for a decision;
- no write occurs before the human submission.
Hash or version the prepared action. If the target, evidence, or parameters change, invalidate the review.
Exit Level 3 when prepared actions are correct, reviewers can detect exceptions, and submission does not reveal a hidden execution path.
Level 4: act after approval
At Level 4, the agent executes one exact action after fresh human approval.
Approval must bind to the target, parameters, evidence, expected result, policy, and time window.
The release must prove:
- 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;
- current state still matches the precondition;
- the final state is verified independently;
- timeouts enter an unknown state;
- retries do not duplicate the business effect;
- failures preserve a useful human handoff.
This level is often the correct long-term state for high-consequence work.
Human approval is not a stage that every action must outgrow. It is a control selected by consequence.
Level 5: act inside a bounded policy
At Level 5, the agent executes without case-by-case approval inside proven limits.
The policy must 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;
- stop, demotion, and containment conditions.
Bounded execution is not permission to improvise beyond the contract.
The agent can still adapt its path. The policy constrains the consequences it can create.
Exit evidence for Level 5 is continuous. 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.
The evidence should cover five dimensions:
| 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? |
Do not reduce this to one overall pass rate.
An agent can perform routine cases well and still fail the exact exceptions that make write access dangerous.
Review failure clusters by action class, tenant, state, parameter range, tool, model version, and recovery path.
Observability should connect offline evaluation with production outcomes so promotion evidence does not end at launch.
Mixed maturity is the correct end state
Different actions should stop at different levels.
A low-risk case label may reach bounded execution. A customer-state transition may require approval. A financial adjustment may remain prepared. A production deletion may remain unavailable.
This action-level model improves product planning.
It replaces one vague autonomy roadmap with several measurable release tracks.
It also improves stakeholder trust. Security can approve a narrow action without endorsing every future capability. Product can ship value without waiting for the highest-risk action.
Engineering can build shared controls while keeping policy specific to each consequence.
Stop, demote, or roll back when evidence changes
Authority is not permanent.
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 may require new evaluation even when the action name stays the same.
For example, moving from an API to computer use changes observation, target selection, and duplicate-submission risk.
Promotion records should preserve the approved versions and exit evidence. Demotion should be a normal operating control, not an exceptional admission of failure.
A practical release cadence
Use a short action review with product, engineering, security, and the operational owner.
1. Select one action
Choose an action with material value, manageable consequence, clear verification, and precise boundaries.
2. Record the current authority level
Do not assume that a prototype at “recommend” is already ready for “act after approval.”
3. Define one proposed promotion
State the exact authority property that changes. Keep the other boundaries fixed.
4. Agree on exit and stop evidence
Define the evaluation cases, production signals, review window, and failure thresholds before release.
5. Release to a bounded population
Limit tenant, environment, volume, record class, or user group. Preserve a clear containment path.
6. Review outcomes and exceptions
Inspect final-state evidence, unknown states, corrections, retries, recovery, and human intervention.
7. Promote, hold, or demote
Make the decision per action class. Do not let wider product pressure replace missing evidence.
Map the first action before you discuss autonomy
The first useful question is not “How autonomous should the agent 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.
The full Agent Action Boundary Canvas captures the action contract and the evidence required for promotion.
BigCircle builds production AI systems and agent workflows with these controls inside the existing product and engineering environment.
If the next release depends on one action that the team still cannot approve, tell us what the action changes. That is enough context to begin the right technical conversation.