Agentic AI Operating Model: Assign Decision Rights Before You Add Autonomy

A practical framework for mapping agent autonomy to risk, reversibility, observability, and failure cost.

The hard part of production agents is usually not getting an LLM to call a tool. It is deciding which actions the model is allowed to take when nobody is watching.

Most agent demos answer: “Can the model do the task?”

Production systems need a different question: who owns the decision when the task goes wrong?

An agentic AI operating model is the set of rules, controls, and feedback paths that determine what an agent may decide and do. The useful unit is not “autonomous” versus “not autonomous.” It is AI decision rights: which decisions belong to the model, deterministic software, policy rules, tools, or humans for a specific task.

This post proposes a practitioner framework for assigning those decision rights before increasing autonomy. It is intended for AI engineering leads, platform engineers, and product teams shipping LLM-based systems into production.

Evidence boundary

This is a practical operating framework, not a production case study or a report on validated internal results. It does not claim measured ROI, productivity gains, adoption, safety improvements, AGI, ASI, or human replacement. Treat the framework as a starting point for system design and review, not as legal, compliance, privacy, or security advice.

For related context on why production agents need more than a prompt, tools, and a loop, see The Agent Loop Ceiling: When LLM Agents Need More Than a Prompt, Tools, and a While Loop.

Terms used in this operating model

Term	Meaning in this post
Agentic AI operating model	Rules, controls, and feedback paths that determine what an agent may decide and do
Decision rights	Assignment of which decisions belong to the model, deterministic software, policy rules, tools, or humans
Autonomy level	A graduated level of execution authority, from advisory to narrow unreviewed execution
Human review boundary	Explicit definition of when review happens, who reviews, what evidence is shown, what actions are allowed, and how escalation works
Policy gate	Deterministic control that blocks, allows, or routes an action for review before execution
Tool gateway	Runtime control layer that enforces tool permissions, schemas, budgets, rate limits, and environment boundaries
Trajectory	The intermediate path an agent takes: retrieved context, decisions, tool calls, policy checks, reviews, actions, and rollback
Operational confidence	Confidence that the system can execute safely, detect failure, contain blast radius, recover, and learn — not merely that the model output looks plausible
Demotion criteria	Conditions that reduce autonomy after unsafe actions, policy violations, rollback failures, poor auditability, or ownership gaps

Agent failures are trajectory failures, not just answer failures

A chatbot can be wrong in a visible, bounded way: it returns a bad answer.

An agent can be wrong across a chain of decisions:

It retrieves the wrong context.
It chooses the wrong tool.
It interprets policy incorrectly.
It skips escalation.
It mutates state.
It sends a message, updates a record, opens access, changes configuration, or triggers another workflow.

That does not make agents unusable. It means the operating model has to decide where judgment belongs.

A production agentic AI operating model should answer:

What is the task?
What downstream action follows the model output?
What can the model decide?
What must deterministic software constrain?
What requires human review?
What must be logged, reversible, and measured before autonomy increases?

That is the mental model for the rest of the post: autonomy is a distribution of decision rights, not a product toggle.

The Decision Rights Ladder

The Decision Rights Ladder is a proposed operating framework for assigning autonomy levels. It is not a validated internal standard or universal industry taxonomy.

Higher autonomy is not inherently better. The right level depends on the task’s risk profile and the maturity of the surrounding controls.

Choose the lowest acceptable autonomy level

Use this as an operating heuristic, not empirical proof of safety.

Start with the task and downstream action.

1. Is the action high-impact, irreversible, sensitive, privileged, regulated, or poorly observable?
   → Yes: keep Level 1 Advisory or Level 2 Drafted action.
   → No: continue.

2. Can deterministic software define safe boundaries for the task?
   → No: use Level 2 Drafted action or Level 3 Supervised execution.
   → Yes: continue.

3. Are tools scoped by task, permission, input schema, rate/budget limit, and environment?
   → No: do not grant autonomous execution yet.
   → Yes: continue.

4. Is rollback or compensation available for material actions?
   → No: keep supervised execution.
   → Yes: continue.

5. Is the task low-cost to fail, reversible, observable, and narrow?
   → Yes: consider Level 4 Bounded autonomous execution.
   → Only if exceptionally low-risk and strongly observable: consider Level 5.

Level 1: Advisory

The agent provides information, summaries, rankings, classifications, or recommendations.

Decision right: human or deterministic system decides and acts.

Good fit:

summarizing long records,
ranking candidate next steps,
extracting evidence for review,
suggesting categories without mutating state.

Required controls:

source/context visibility,
confidence or uncertainty presentation where useful,
reviewer or downstream system ownership,
audit log of recommendation and final decision.

Failure mode:

Users may treat advisory output as authoritative even when it is only a recommendation.

Level 2: Drafted action

The agent prepares an action, but does not execute it without approval.

Examples:

draft a customer response,
draft a ticket update,
draft a remediation plan,
draft a configuration change,
prepare a data entry update for review.

Decision right: model drafts; human or deterministic policy approves.

Required controls:

explicit approval before execution,
diff view or evidence packet,
reviewer identity or role,
ability to edit or reject,
audit log of draft, edits, approval, and final action.

Failure mode:

Reviewers may rubber-stamp if evidence is poor or queues are overloaded.

Level 3: Supervised execution

The agent executes steps within a workflow, but humans approve sensitive transitions, exceptions, or final submission.

Examples:

gather context, call read-only tools, and prepare an action;
execute non-sensitive steps, then pause before external communication;
run diagnostics, then request approval before remediation.

Decision right: model can act inside the workflow; humans or policy gates own sensitive transitions.

Required controls:

step-level permissions,
transition gates,
exception routing,
review triggers,
audit trail for intermediate tool calls,
rollback or compensation for executed steps.

Failure mode:

The system may appear safe because final submission is reviewed, while earlier tool calls or state changes are under-observed.

Level 4: Bounded autonomous execution

The agent acts without pre-approval inside explicit constraints.

Constraints should include scoped tools, typed inputs, allowlists, rate limits, budgets, environment boundaries, policy checks, audit logs, and rollback paths.

Examples:

tag low-risk records,
update internal metadata,
schedule a non-critical follow-up,
resolve a reversible internal workflow step,
execute a known remediation with bounded blast radius.

Decision right: model can plan and execute within a constrained action space; deterministic software owns boundaries.

Required controls:

tool gateway,
policy gate,
rate and budget limits,
permission checks,
observability,
rollback hook,
demotion criteria,
owner for incidents and autonomy changes.

Failure mode:

Constraints drift from business risk as tools, policies, or product behavior change.

Level 5: Narrow unreviewed execution for reversible tasks

Use this sparingly.

This level should only apply to narrow tasks where failure cost is low, reversibility is high, observability is strong, and policy exposure is minimal.

Examples might include internal housekeeping tasks, reversible metadata updates, or low-impact workflow cleanup. Whether those examples are acceptable depends on the organization’s context and controls.

Decision right: model can decide and execute the task end-to-end within a narrow domain.

Required controls:

narrow task definition,
strong auditability,
automatic rollback or easy compensation,
monitoring by task class,
clear demotion criteria,
periodic review of whether the task remains low risk.

Failure mode:

“Low risk” becomes stale as the workflow becomes more user-visible, more privileged, or more integrated with downstream systems.

The ladder in one table

Level	Name	Model may do	Must be constrained by	Good fit
1	Advisory	Recommend, summarize, classify, rank	Human or deterministic decision owner	Evidence packets, summaries, suggested categories
2	Drafted action	Prepare an action but not execute it	Approval, diff/evidence view, audit trail	Draft responses, remediation plans, updates
3	Supervised execution	Execute bounded workflow steps	Transition gates, exception routing, review triggers	Diagnostics, context gathering, non-sensitive steps
4	Bounded autonomous execution	Plan and execute inside explicit constraints	Tool gateway, policy gate, permissions, rollback, monitoring	Reversible internal metadata or low-risk workflow actions
5	Narrow unreviewed execution	Decide and execute end-to-end in a narrow domain	Strong observability, low failure cost, rollback, periodic review	Narrow, low-risk, reversible housekeeping tasks

Flowchart showing how a team classifies an agent task, scores risk, checks reversibility and observability, applies deterministic policy constraints, selects an autonomy level from advisory through bounded autonomy, instruments the task, and promotes or demotes autonomy based on production signals. — A practical flow for assigning an autonomy level to a task before granting an agent execution authority. The key distinction is between model confidence and operational confidence: irreversible, poorly observable, or policy-sensitive actions should remain constrained by software gates and human review.

“Human-in-the-loop” is too vague to be a control plane

“Human-in-the-loop” is often used as if it resolves the safety question.

It does not.

A human review step is only useful if the system defines the review boundary:

Question	Vague HITL	Designed human review boundary
Trigger	“When needed”	Explicit conditions: risk class, policy conflict, irreversible action, sensitive data, abnormal tool sequence
Reviewer	“A human”	Named role, queue, ownership, escalation backup
Evidence	Model output only	Task classification, retrieved context IDs, proposed action, policy checks, tool calls, uncertainty signals, prior state
Reviewer action	Approve/reject	Approve, reject, edit, request more evidence, escalate, rollback
Latency	Undefined	Review expectation appropriate to the workflow
Escalation	Manual discovery	Predefined owner for ambiguity, dispute, policy conflict, or tool failure
Rollback	Not considered	Required for material actions before autonomy increases
Audit record	Partial logs	Reviewer identity or role, decision, rationale where appropriate, timestamp, final action state

The same issue applies to tool access. Broad tool access can turn model uncertainty into system-level risk if permissions are not scoped to the task. That claim is an engineering inference; validate it against your own threat model and production traces before turning it into policy.

A more precise production question is:

Can the organization detect, contain, reverse, and learn from bad intermediate decisions before they reach users or critical systems?

If the answer is no, adding a human somewhere in the workflow is not enough.

For a narrower example of bounded workflow design, see AI support triage should be a bounded workflow, not an autonomous agent. For a more operational discussion of what production exposure reveals, see If Your Agent Has Never Embarrassed You, You’re Probably Not in Production.

Autonomy decisions must account for risk, reversibility, observability, and failure cost

Before choosing an autonomy level, classify the task by operational risk.

A practical starting matrix:

Dimension	Lower-risk signal	Medium-risk signal	Higher-risk signal
Failure cost	Mistake is cosmetic or easy to ignore	Mistake causes user confusion, rework, or degraded workflow	Mistake causes financial, operational, legal, security, or safety impact
Reversibility	Action can be undone automatically	Action can be corrected with manual work	Action is irreversible or expensive to compensate
Observability	System can inspect inputs, tool calls, decision state, and outcome	Some intermediate state is visible	Failure may be hidden until downstream harm occurs
Data sensitivity	Public or low-sensitivity data	Internal business data	Personal, confidential, regulated, or privileged data
Security exposure	Read-only or low-privilege action	Limited write access	Privileged access, access control, secrets, infrastructure, or identity changes
Regulatory exposure	No meaningful compliance dependency	Policy-sensitive but bounded	Legal, compliance, contractual, or regulated decision impact
User trust impact	Low user visibility	Visible but recoverable	User-facing decision that can damage trust if wrong

Security, privacy, legal, and compliance interpretations should be reviewed by qualified owners before production use.

The key distinction is model confidence versus operational confidence.

A model can be confident and still not be operationally safe to execute. If the action is irreversible, poorly observable, policy-sensitive, or security-sensitive, confidence in the generated answer is not enough. That is an inference from the risk framework rather than a measured claim.

Useful operating questions:

Can the action be undone?
Can the system know it made a mistake?
Can a reviewer understand the evidence quickly enough to intervene?
Does the action expose private data, privileged systems, or regulated workflows?
Is there a deterministic policy that should override model judgment?
Is the model selecting tools from a constrained set or improvising across broad permissions?
What audit record would be needed during an incident review?

Observability should exist at the decision level, not only the request level. For agentic workflows, inspectable state may include prompts, retrieved context identifiers, tool calls, policy checks, reviewer decisions, final action state, rollback status, and safe summaries of intermediate reasoning where appropriate.

External references on agent workflow evaluation and trace inspection include OpenAI agent evaluations and OpenAI trace grading.

Assign decision rights separately for each part of the workflow

A common mistake is assigning one autonomy level to the whole system.

Instead, assign decision rights separately:

Decision type	Model may own	Software/policy should own	Human should own
Observation	Summarize, classify, extract evidence	Validate schemas, enforce data access, filter unavailable sources	Resolve ambiguous or contested evidence
Interpretation	Suggest meaning, identify likely category	Apply deterministic policy, validate thresholds	Decide policy-sensitive or disputed interpretation
Planning	Propose steps	Enforce allowed workflow graph	Approve high-impact plan
Tool selection	Choose from allowed tools	Restrict tool list by task, role, environment, risk	Approve unusual or sensitive tool use
Execution	Execute bounded, reversible actions	Enforce permissions, budgets, rate limits, state preconditions	Approve irreversible or high-impact action
Exception handling	Detect uncertainty or conflict	Trigger escalation rules	Resolve ambiguity, dispute, or exception
Final impact	Generate response or state update	Verify constraints and final state	Own high-risk user/system impact

The same agent may be Level 1 for policy interpretation, Level 3 for workflow execution, and Level 4 for low-risk metadata updates.

That is the core benefit of decision rights: they let teams avoid both extremes — banning useful automation and granting broad autonomy.

Alternatives teams usually try — and why each is incomplete

A decision-rights model does not mean every workflow should become an agent. Most production systems need a mix of deterministic software, human judgment, and model assistance.

Operating pattern	Best fit	Failure mode if overused
Fully manual workflow	High-impact, ambiguous, or sensitive decisions where human accountability is required	Slow queues, inconsistent review quality, unclear evidence presentation
Deterministic workflow only	Known paths, policy enforcement, repeatable state transitions	Brittle rules, stale assumptions, poor handling of messy input
LLM as advisor only	Summaries, rankings, classifications, recommendations, evidence packets	Leaves low-risk reversible actions manual even when automation may be acceptable
Broad autonomous agent	Demos, sandbox tasks, constrained experiments	Risky in production if tool access, memory, permissions, and recovery are not constrained
Generic human-in-the-loop	Initial safety layer when autonomy is immature	Rubber-stamping, unclear ownership, no escalation path, weak audit trail

These are qualitative engineering tradeoffs, not benchmarked findings.

The point is not to pick one architecture for every workflow. The point is to assign decision rights by task.

A support triage workflow, for example, might use:

deterministic routing rules for known categories,
an LLM to summarize user context,
a human to review sensitive escalations,
bounded autonomous execution for low-risk ticket tagging,
and policy gates before refunds, account changes, or access decisions.

That decomposition matters more than whether the system is marketed as an “agent.”

For a third-party framing of workflows versus more autonomous agents, see Anthropic’s Building effective agents.

Translate autonomy levels into runtime control surfaces

An autonomy policy only matters if it changes runtime behavior.

At implementation time, bind each autonomy level to concrete control surfaces.

Architecture diagram of an agent runtime where a user request enters task classification, policy checks, an agent planner, a tool gateway, human review queue, audit log, rollback service, and evaluation pipeline. The diagram shows constrained tool access and feedback from evals into autonomy policy updates. — A production agentic system needs control surfaces around the model, not just a prompt and a tool list. This architecture shows generic components for policy enforcement, tool permissioning, review, auditability, evaluation, and rollback. It is a reference pattern, not an internal implementation claim.

Tool access should be scoped by autonomy level

Tool access should not be a flat list in the prompt.

Use a tool gateway or equivalent control layer to enforce:

tool allowlists by task type,
read versus write separation,
typed inputs and schema validation,
environment boundaries,
rate limits,
budget limits,
preconditions,
idempotency requirements where applicable,
rollback or compensation registration.

Typed tool interfaces and schema-constrained outputs are one practical building block for this pattern. See OpenAI’s reference on function calling and structured outputs.

Policy enforcement should not depend only on model self-policing

For high-impact actions, deterministic checks should sit before execution.

Examples of policy checks may include:

“This action requires review.”
“This tool is not available for this task class.”
“This record contains sensitive data.”
“This state transition is not allowed.”
“This action is irreversible and lacks rollback.”
“This user or system role does not have permission.”

Security-, privacy-, legal-, and compliance-sensitive checks require review by the appropriate owners before production use.

Human review boundaries should be explicit

Define review triggers such as:

high risk class,
low reversibility,
insufficient observability,
policy conflict,
abnormal tool sequence,
sensitive data access,
privileged tool use,
user dispute,
model uncertainty,
unexpected state transition,
rollback failure.

For each trigger, define:

reviewer role,
evidence packet,
allowed reviewer actions,
escalation path,
latency expectation,
audit record,
recovery behavior.

Escalation paths should be designed before launch

Ambiguity needs a destination.

Route specific cases to specific owners:

Escalation condition	Possible owner
Tool failure	Owning service team or platform on-call
Policy conflict	Policy owner or domain SME
User dispute	Product/customer operations owner
Security-sensitive action	Security owner
Privacy-sensitive action	Privacy/legal owner
Reviewer queue saturation	Operations owner
Repeated unsafe action	Agent system owner and incident process

The exact ownership model depends on the organization. The important part is that escalation is not discovered during an incident.

Audit logs should capture trajectories, not just outputs

For agentic workflows, audit records should capture enough information to reconstruct what happened without exposing unnecessary sensitive data.

A practical audit record may include:

task classification,
assigned autonomy level,
risk class,
retrieved context identifiers,
tool calls,
tool inputs and outputs where safe to retain,
policy checks,
reviewer actions,
final state,
rollback or compensation status,
exception reason,
autonomy policy version.

Privacy and retention rules must be reviewed before logging sensitive prompts, outputs, user data, tool payloads, or intermediate reasoning artifacts. In many systems, audit logging should also include minimization, redaction, access controls, retention limits, and deletion or correction workflows where required.

Memory should be treated as a privileged capability

Persistent memory is not harmless context.

If an agent can write memory, retrieve it later, and use it to make future decisions, memory becomes state. Treat it like a privileged capability:

constrain what can be written,
constrain what can be read,
define retention rules,
separate user-visible memory from internal operational memory,
audit memory writes that affect future actions,
provide deletion or correction paths where required.

This is a practitioner inference from the broader control-surface model; teams should adapt it to their privacy, security, and product requirements.

For broader production-runtime considerations, see LangChain’s discussion of the runtime behind production agents.

A policy-gated tool call should make the review boundary visible

The implementation goal is not to stop the model from proposing actions. It is to prevent proposed actions from becoming system changes without passing the right gates.

A simplified policy-gated invocation:

def handle_agent_action(task, proposed_action, context):
    risk = classify_risk(task, proposed_action, context)
    autonomy_level = autonomy_policy.lookup(task.type, risk)

    audit.record(
        event="action_proposed",
        task_id=task.id,
        action_type=proposed_action.type,
        risk_class=risk.label,
        autonomy_level=autonomy_level,
        context_ids=context.ids,
    )

    policy_decision = policy_gate.evaluate(
        task=task,
        action=proposed_action,
        risk=risk,
        autonomy_level=autonomy_level,
    )

    if policy_decision.blocked:
        audit.record(
            event="action_blocked",
            task_id=task.id,
            reason=policy_decision.reason,
        )
        return safe_response_or_escalation(task, policy_decision)

    if policy_decision.requires_review:
        review_id = review_queue.enqueue(
            task=task,
            proposed_action=proposed_action,
            evidence=build_evidence_packet(task, context, policy_decision),
            allowed_reviewer_actions=["approve", "edit", "reject", "escalate"],
        )
        audit.record(
            event="review_requested",
            task_id=task.id,
            review_id=review_id,
            reason=policy_decision.reason,
        )
        return {"status": "pending_review", "review_id": review_id}

    permission_decision = tool_gateway.check_permissions(
        tool=proposed_action.tool,
        inputs=proposed_action.inputs,
        autonomy_level=autonomy_level,
        risk=risk,
    )

    if not permission_decision.allowed:
        audit.record(
            event="tool_denied",
            task_id=task.id,
            reason=permission_decision.reason,
        )
        return safe_response_or_escalation(task, permission_decision)

    result = tool_gateway.execute(proposed_action)

    rollback.register_if_available(
        task_id=task.id,
        action=proposed_action,
        result=result,
    )

    audit.record(
        event="action_executed",
        task_id=task.id,
        tool=proposed_action.tool,
        result_state=result.state,
        rollback_status=rollback.status(task.id),
    )

    return result

This is illustrative pseudocode, not a production implementation. Do not copy it without adapting authentication, authorization, privacy, retention, idempotency, observability, and incident-response requirements.

Sequence diagram showing a user request sent to an agent, the agent classifying the task and proposing a tool call, policy and permission services evaluating the request, optional human review, tool execution, audit logging, and rollback registration. — This sequence makes the review boundary explicit. The model may propose a plan or tool call, but deterministic checks decide whether the action is allowed, must be reviewed, or must be blocked and escalated.

Evaluate trajectories, not just final answers

Final-answer accuracy is not enough for agentic systems.

Production risk often lives in intermediate decisions:

Was the right context retrieved?
Was the right tool selected?
Were tool inputs valid?
Did the agent skip a required review?
Did a policy check fire?
Did the system escalate ambiguity?
Did rollback work?
Was the audit trail complete?

Evaluation template: measure by task class and autonomy level

These are recommended measurement targets, not current findings.

Metric	Segment by	Why it matters
Task success rate	Task class, autonomy level, risk class	Prevents aggregate metrics from hiding risky categories
Human intervention rate	Task class, review trigger	Shows where the system still needs judgment or better automation
Escalation frequency	Escalation reason, owner	Reveals ambiguity, policy conflict, tool failure, or ownership gaps
Unsafe or false action rate	Action type, tool, autonomy level	Tracks actions that should not have happened
Policy violation rate	Policy type, task class	Detects boundary failures
Rollback/compensation rate	Action type, autonomy level	Shows how often recovery is needed
Rollback success rate	Action type, system owner	Tests whether reversibility is real
Audit-log completeness	Required event type	Determines whether incidents can be reconstructed
Latency	Review path, tool path, task class	Captures orchestration and review cost
Cost per task	Model, tool, review, infrastructure	Prevents unmeasured automation cost claims
User trust/satisfaction signal	User-facing task class	Captures impact where appropriate
Security incident rate	Security-reviewed definitions	Tracks security-relevant failures; requires security review

Measure the review system too:

reviewer agreement,
override reasons,
time-to-review,
stale queue count,
unresolved escalations,
review edits by category,
reviewer fatigue or rubber-stamping indicators.

Use trace-level inspection where appropriate to understand why the agent chose a tool, skipped a review, or escalated. External references include trace grading and agent evaluations.

Promotion and demotion criteria

Do not promote a task up the ladder because a demo looked good.

A task should not move to a higher autonomy level until the team has evidence for:

reliability by task class,
reversibility,
observability,
policy compliance,
tool permission correctness,
review effectiveness,
rollback or compensation behavior,
incident ownership,
acceptable latency and cost.

Demote autonomy when you observe:

repeated unsafe actions,
skipped reviews,
policy violations,
poor auditability,
rollback failures,
unresolved escalations,
unclear ownership,
drift in task risk,
new tool permissions that expand blast radius.

This is a lifecycle model, not a one-time launch checklist.

Tradeoffs: control reduces risk, but adds latency, cost, and ownership burden

A decision-rights model is not free.

Control surface	Benefit	Cost	Failure mode
Human review	Prevents high-impact actions from executing unchecked	Adds latency, queue management, reviewer training	Rubber-stamping, stale queues, unclear accountability
Tighter tool permissions	Reduces blast radius	More engineering maintenance, more denied actions	Overly narrow permissions cause unnecessary escalations
Deterministic policy gates	Enforces known constraints	Rules can become brittle or stale	Legitimate edge cases get blocked
Audit logging	Improves debuggability and incident review	Privacy, retention, storage, and data-minimization concerns	Logs are incomplete or too sensitive to use
Rollback hooks	Makes autonomy safer for reversible actions	Requires system design work and state tracking	Rollback fails or only partially compensates
Risk classification	Makes autonomy decisions explicit	Can become abstract or bureaucratic	Teams treat the class as truth instead of a review aid
Eval pipeline	Supports promotion/demotion decisions	Requires test cases, traces, labeling, and maintenance	Aggregate metrics hide task-specific failures

The tradeoff is not “safety versus speed.” It is more specific:

More review can reduce unchecked execution, but increases latency.
Less review can improve responsiveness, but may let failures reach users or critical systems.
Tighter tool permissions reduce blast radius, but can increase failed tasks and escalations.
More logging improves investigation, but creates privacy and retention obligations.
Deterministic policy gates constrain known risks, but can encode stale policy.

Bounded autonomy may improve throughput for low-risk reversible tasks, but that should be measured rather than assumed.

Failure modes: where agent autonomy breaks down

The following failure modes are practitioner syntheses from the operating-model framework, not claims from a production incident dataset.

Failure mode	What it usually means	Control to add or strengthen
Reviewers rubber-stamp outputs	Evidence is poor, queues are overloaded, or accountability is unclear	Better evidence packets, reviewer actions, queue metrics, escalation paths
Agent skips required review	Review trigger is model-discretionary or weakly enforced	Deterministic review triggers and policy gates
Tool call is valid but unsafe	Tool permission model is too broad for the task risk	Task-scoped allowlists, read/write separation, input schemas, preconditions
Final answer looks fine but path was unsafe	Evaluation focuses only on outputs	Trace-level evaluation of retrieval, tool choice, policy checks, escalation, rollback
Rollback fails	Reversibility was assumed rather than tested	Rollback hooks, compensation plans, rollback success tracking
Autonomy becomes stale	Workflow, tools, permissions, or business risk changed	Periodic autonomy review and demotion criteria
Audit trail cannot reconstruct incident	Logs capture outputs but not trajectory	Log task class, autonomy level, context IDs, tool calls, policy checks, reviewer decisions, final state
Memory carries bad state forward	Persistent memory is treated as harmless context	Treat memory reads/writes as privileged operations with retention and correction paths

The anti-patterns below are the same failures expressed as authority-design mistakes.

Anti-pattern 1: Treating autonomy as binary

The question is not “Should this agent be autonomous?”

The better question is:

Which decisions in this workflow can the model own, which must software constrain, and which require human judgment?

Anti-pattern 2: Granting broad tool access before defining allowed actions

A tool list is not a permission model.

Before granting execution authority, define:

allowed actions,
preconditions,
input schemas,
rate limits,
budgets,
environment boundaries,
rollback behavior,
audit records.

Anti-pattern 3: Using human review as a generic safety blanket

If you cannot say who reviews, what they see, when they intervene, and how failures recover, you do not have a human review boundary.

You have a hope.

Anti-pattern 4: Evaluating only final answers

An agent can produce an acceptable final answer after taking unacceptable intermediate steps.

Evaluate trajectories:

context retrieval,
tool choice,
policy checks,
escalation behavior,
review triggers,
rollback success,
final state.

Anti-pattern 5: Letting the model decide when human review is needed

The model can help identify uncertainty, but deterministic triggers should handle high-risk conditions.

Examples:

sensitive data access,
irreversible action,
privileged tool use,
policy conflict,
user dispute,
abnormal tool sequence.

Anti-pattern 6: Promoting autonomy based on demo success

Demo success is not production evidence.

Promotion should depend on observed signals by task class and autonomy level, including intervention rate, escalation frequency, unsafe action rate, rollback behavior, latency, cost, and audit completeness.

Anti-pattern 7: Treating memory as harmless context

Persistent memory affects future behavior.

If an agent can remember, it can carry forward stale, sensitive, incorrect, or policy-relevant state. Treat memory writes and reads as privileged operations.

Anti-pattern 8: Failing to define incident ownership

Production failures may come from:

model output,
tool execution,
stale policy,
bad retrieval,
reviewer error,
insufficient permissions,
excessive permissions,
rollback failure,
unclear escalation.

If nobody owns the boundary between those systems, incident response will be slow and ambiguous.

A worked example: support triage without broad autonomy

This example is illustrative and fictional. It is meant to show how the framework can be applied, not to describe a deployed system.

Field	Example assignment
Task	Triage inbound support tickets
Downstream action	Assign category, summarize context, route to queue, optionally tag metadata
Affected users/systems	Support team, ticketing system, customer communication workflow
Risk class	Mixed: low for internal tags; higher for refunds, account changes, access decisions, or external replies
Autonomy level	Level 1 for policy interpretation; Level 2 for drafted customer replies; Level 4 for reversible internal tagging
Model decision rights	Summarize issue, suggest category, draft response, propose next step
Software/policy constraints	Enforce allowed categories, detect sensitive data, block refunds/account/access changes without review
Allowed tools	Read ticket history; write internal low-risk tags; draft but not send replies
Denied actions	Refunds, account changes, permission changes, external send without approval
Human review trigger	Sensitive data, customer dispute, account change, refund request, policy conflict, low observability
Evidence packet	Ticket summary, source message IDs, proposed category, policy checks, draft response, prior state
Rollback path	Remove/rewrite internal tags; revert routing; do not rely on rollback for external messages
Metrics	Tag correction rate, escalation rate, review override rate, stale queue count, policy violations, audit completeness

The useful design move is decomposition. The “support agent” is not globally autonomous or non-autonomous. It has different decision rights for summarization, routing, drafting, tagging, and high-impact actions.

A practical checklist for assigning AI decision rights

Use this as a starting template. Adapt it to your regulatory, security, privacy, product, and operational context.

Step	Question to answer	Output
Classify the task	What decision is being made, and what downstream action follows?	Task class and affected system/user
Score operational risk	What are the failure cost, reversibility, observability, data sensitivity, security exposure, regulatory exposure, and user trust impact?	Risk class
Pick autonomy level	What is the lowest autonomy level that satisfies the product need?	Level 1–5 assignment
Assign decision rights	Which decisions belong to the model, software/policy, tools, or humans?	Decision-rights map
Scope tools	Which tools, inputs, permissions, budgets, rate limits, and preconditions are allowed?	Tool access policy
Define review boundary	What triggers review, who reviews, what evidence is shown, and what actions can the reviewer take?	Human review contract
Require recovery	Can the action be rolled back or compensated? Who owns recovery?	Rollback/compensation plan
Instrument trajectory	What will be logged across context retrieval, tool calls, policy checks, reviews, execution, and rollback?	Audit and observability plan
Set lifecycle rules	What signals promote, hold, or demote autonomy?	Promotion/demotion criteria

Rollout template: document one task before increasing autonomy

Security, privacy, legal, and compliance fields should be reviewed by qualified owners before production use.

Field	Fill in
Task name
Task owner
Downstream action
Affected users/systems
Current autonomy level
Proposed autonomy level
Risk class	Low / medium / high
Failure cost
Reversibility	Automatic / manual / hard / impossible
Observability	Strong / partial / weak
Data sensitivity
Security or regulatory exposure
Model decision rights
Software/policy constraints
Allowed tools
Denied tools/actions
Human review triggers
Reviewer role
Evidence packet
Escalation owner
Rollback or compensation path
Audit events required
Promotion criteria
Demotion criteria
Open security/privacy/legal review items

Treat decision rights as part of the system contract. Document autonomy levels alongside APIs, tool permissions, policy rules, evals, runbooks, incident response, data retention, and reviewer operations.

Three things to remember

Autonomy is not one switch. Assign decision rights separately for observation, interpretation, planning, tool selection, execution, exception handling, and final impact.
Model confidence is not operational confidence. Irreversible, sensitive, privileged, poorly observable, or high-impact actions need stronger gates regardless of how plausible the model output looks.
Autonomy should have a lifecycle. Promote, hold, or demote by production signals segmented by task class, risk class, and autonomy level — not by demo success.

Conclusion: autonomy is a decision-rights system

Production agent autonomy should not be granted as a binary capability.

It should be assigned as graduated decision rights across the model, deterministic software, policy rules, tools, and humans.

The Decision Rights Ladder gives teams a practical vocabulary:

Advisory — the agent recommends; humans or deterministic systems decide.
Drafted action — the agent prepares; humans or policy gates approve.
Supervised execution — the agent executes bounded steps; humans approve sensitive transitions.
Bounded autonomous execution — the agent acts inside explicit constraints, with auditability and rollback.
Narrow unreviewed execution — only for narrow, low-risk, reversible, strongly observable tasks.

A more defensible next step is not always adding more humans. It is not always adding more automation either.

The next step is making decision rights explicit and measurable.

Pick one production workflow. For each decision and action:

classify the task,
score risk,
assign an autonomy level,
constrain tools,
define human review boundaries,
instrument the trajectory,
require rollback where material,
and set promotion and demotion criteria.

That is the core of an agentic AI operating model: not whether the agent is autonomous, but what it is allowed to decide.