How much autonomy should an agent have?
A practical framework for deciding what agents may do alone, what needs approval, and how to expand trust.
Every agent project reaches the same question within a week: what is this thing allowed to do on its own? The answer is not a single setting. It is a ladder, and the job is to decide which rung each action sits on.
Four rungs
Observe: the agent reads and reports, nothing more. Recommend: it drafts an action for a person to approve. Act with review: it acts, logs everything, and a person reviews after the fact. Act autonomously: it acts within limits and only exceptions surface. Most actions in a new deployment belong on the first two rungs.
Classify actions by reversibility and blast radius
Sending an internal notification is reversible and narrow: it can go autonomous early. Changing a customer's credit limit is narrow but hard to reverse: it needs approval. Bulk updates across a CRM are broad and hard to reverse: they stay on the recommend rung for a long time. A simple two-by-two of reversibility against blast radius settles most arguments.
Shadow mode before live mode
On an HR operations deployment we ran the agent against real requests for weeks while humans continued to handle them. Comparing the agent's proposed actions with what people actually did gave us a measured agreement rate per action type. Autonomy was granted per type once agreement was consistently high.
Guardrails that survive contact with reality
Scoped tool permissions, so an agent that reads tickets cannot delete them. Spend and rate limits per run. A full trace of every decision and tool call. And a kill switch owned by the process owner, not the engineering team.
Expanding trust is a process
Review agreement rates monthly, promote action types up the ladder when they earn it, and demote them when they don't. Autonomy is something an agent earns, one action type at a time.
More from the blog
Working on something similar?
Tell us what you're building; we'll share what we've learned.
