Autonomy Is a Spectrum
Autonomy is a dial you set per action, not a badge an agent wears — and turning it up multiplies both capability and blast radius.
"Agentic" is not a yes/no property. It is a dial, and the sensible engineering position is to set that dial as low as the task allows. Autonomy has three separable dimensions, and conflating them is a common source of bad designs.
- Decision autonomy — how much of the control flow the model owns.
- Action autonomy — what the agent may change in the outside world.
- Duration autonomy — how long it may run and how many steps it may take unattended.
The rungs of the ladder
| Level | What the agent may do | Where it fits |
|---|---|---|
| Advisory | Propose an answer or a draft action; a human executes | Anything regulated, or a brand-new agent in its first weeks |
| Read-only tools | Query systems freely, change nothing | Diagnostics, research, triage, reporting |
| Write with confirmation | Choose an action, but a human approves before it runs | Refunds, account changes, outbound messages |
| Bounded write | Act freely inside a hard limit — value cap, single tenant, reversible operations only | High-volume, low-value operations |
| Self-directed | Long-running, sets its own sub-goals, spawns sub-agents | Rare in production; needs strong evaluation and observability |
Why more autonomy is not better
The first reason is arithmetic. Agent reliability compounds: if each step is right 95% of the time, ten independent steps end up right roughly 60% of the time. Every step you remove buys accuracy back. The second is blast radius. A read-only agent that hallucinates wastes a user's minute. A write-enabled agent that hallucinates corrupts records, and a prompt-injection payload hidden in a ticket body now has a path to a real API call. The third is auditability: the longer the unattended run, the harder it is to explain afterwards why a particular action happened.
Set the dial per action, not per agent
The practical pattern is a single agent with mixed permissions: reads are free, writes are gated. Amazon Bedrock Agents supports this directly. Action group functions can be defined with confirmation required, in which case the agent pauses and surfaces the proposed call and its arguments for approval before anything executes. You can also configure an action group to return control to your application instead of invoking a Lambda function, so your own code decides whether to carry out the action, applies its own validation and enforces the caller's entitlements.
Back that up outside the model. The agent's execution role should grant only the operations it truly needs; guardrails should sit on both input and output; and irreversible operations — payments, deletions, external communications — should be the last things you ever automate. Autonomy is something an agent earns from evaluation results, not something you grant at design time because it demos well.
Example
{
"actionGroupName": "billing-actions",
"agentId": "AGENT123456",
"agentVersion": "DRAFT",
"actionGroupExecutor": {
"customControl": "RETURN_CONTROL"
},
"functionSchema": {
"functions": [
{
"name": "get_invoice",
"description": "Read a single invoice. Safe, read-only.",
"parameters": {
"invoice_id": {"type": "string", "required": true}
},
"requireConfirmation": "DISABLED"
},
{
"name": "issue_refund",
"description": "Refund an amount to the customer's card. Irreversible.",
"parameters": {
"invoice_id": {"type": "string", "required": true},
"amount_gbp": {"type": "number", "required": true}
},
"requireConfirmation": "ENABLED"
}
]
}
}When to use it
- A retail refund agent auto-approves credits under a small threshold and routes anything larger to a human queue with the reasoning attached.
- A cloud operations agent starts read-only for a quarter, and only gains restart permissions once its diagnosis accuracy is measured on real incidents.
- A recruitment assistant drafts candidate emails but never sends them, because outbound communication is irreversible and reputationally sensitive.
Discussion