What Is an Agentic AI Autonomy Tier? A Band, Not a Grant

An agentic AI autonomy tier is a named band of actions an agent may take without a human in the loop, with a hard ceiling on what it may not do at that band, and a rule for how it moves up or down. The tier is not a switch. It is a range with a floor, a ceiling and an exit test on each side. Most teams treat it as a setting a developer flips. That is the mistake this post is about.

You cannot grant autonomy. You can let it be earned.

A grant is a decision made once, by whoever had the permission that day. A band is a position an agent holds on evidence and can lose on evidence. The difference decides whether your agent program is governable at all.

What a tier actually is

Strip the vendor names away and every autonomy tier answers three questions. What can the agent do without asking? What can it never do at this level, no matter what it argues? What has to be true before it moves to the next level, and what sends it back?

Most tier schemes answer the first question well, the second badly, and the third not at all. The first question is the convenient one. It sets how many prompts a developer sees. The second is where the ceiling lives, and it is only real if something outside the agent enforces it. The third is the one that makes a tier a band instead of a grant, and it is the one nobody writes down.

A tier that describes capability without describing the handoff is a marketing table, not a control.

How the vendors build it

Anthropic’s Claude Code ships six permission modes, documented on its permission modes page: manual, which prompts for every state change; acceptEdits, which auto-approves file edits inside the working directory; plan, which reads and proposes but does not edit; auto, in which a second model reviews each action instead of you; dontAsk, which denies anything not pre-approved; and bypassPermissions, which runs everything and is meant for isolated containers only.

Three details in that page matter more than the six names. First, deny rules block in every mode, including bypass, so the ceiling can be made independent of the tier. Second, auto mode demotes itself: if the classifier blocks three actions in a row or twenty in a session, the mode pauses and prompting resumes, and those thresholds are not configurable. Third, an organization can remove a tier from the cycle entirely through managed settings, so developers cannot select bypass or auto at all.

OpenAI’s Codex builds the same thing from two dials rather than six names. Its approvals and security page separates a sandbox mode, which decides what a command can reach, from an approval policy, which decides whether the agent asks first. Read Only, Auto and Full Access are presets over those two dials. The workspace-write sandbox blocks the network by default, so a git push surfaces as a prompt rather than running.

I read the two designs as convergent. Both vendors now separate how much oversight from what is physically reachable. Both ship a self-demoting middle tier. Both give an administrator a way to delete the top tier from the menu. That is the shape of a band, and it arrived in the developer tools before it arrived in most enterprise agent programs.

Where a tier sits in the six layers

In the six layers of agentic AI architecture the tier belongs to the autonomy layer, not to enforcement. The distinction is the whole post. An agent hook or a deny rule says what cannot happen. A tier says how much of what can happen gets a human’s eyes first. Enforcement sets the walls of the room. The tier sets how far the leash runs inside it.

That is why a tier on its own is weak. Set bypass mode with no deny rules and no sandbox and you have a leash with no walls. Set manual mode with airtight deny rules and you have walls with a very short leash, which is safe and slow. The autonomy layer only works when it sits on top of an enforcement layer that does not move when the tier does.

On my Five-Stage Agentic AI Roadmap the bands map cleanly. Prompted and Piloted agents live in manual or plan mode. Governed agents earn acceptEdits or its equivalent with hooks underneath. Assured agents earn auto mode with a classifier and a nightly eval behind it. Autonomous is the band almost nobody has evidence for, and the maturity model spells out what that evidence would have to look like.

Advisory or enforcing?

The test I apply to every control component is simple. If the agent, or the developer sitting next to it, can change the setting, the control is advisory. A tier fails that test by default in both vendors’ tools. Shift+Tab cycles the mode. A settings file changes the default. A flag at launch overrides both.

It passes the test only when three things are true. The available tiers are set in managed settings the developer cannot edit. The ceiling is expressed as deny rules and sandbox limits that hold in every tier. The promotion rule reads evidence the agent does not produce about itself.

Anthropic’s own docs contain the sharpest version of this warning. A boundary you state in conversation, such as “don’t push until I review,” is honored by the auto-mode classifier, but it is not stored as a rule. It is re-read from the transcript on every check, and the docs say plainly that it can be lost if context compaction removes the message that stated it. For a hard guarantee, add a deny rule. That sentence is the entire difference between a grant and a band. I wrote about compaction yesterday; today’s post is why it matters for autonomy.

What breaks

Three failures, each one I have seen.

The grant that never comes back. A developer starts a session with bypass permissions on a laptop to get past a stubborn prompt, finishes the task, and leaves the setting in the user config. Every later session starts at the top tier. Nobody granted permanent autonomy. It was granted once and never revoked, because a grant has no expiry.

The demotion nobody sees. Auto mode drops back to prompting after repeated classifier blocks. In an interactive session someone notices. In a headless run with no prompt tool, the action simply does not execute and the agent keeps working around it. The tier changed. The log did not say so in a way anyone reads.

The band with no exit test. A team defines three tiers, assigns every agent to the middle one on day one, and has no written rule for promotion or demotion. Six months later every agent is still in the middle. The tiers exist. The band does not, because nothing ever moved.

What transfers to regulated loan origination

For the regulated loan origination, I would suggest three bands per agent, and the names matter less than the exit tests. Propose: the agent drafts the action and a human executes. Execute within limit: the agent acts on its own below a dollar and record-count threshold, with the threshold in a deny rule the agent cannot read or edit. Execute and settle: the agent acts and closes without review, and only the verifier agent and the nightly eval look at the result.

Promotion from one band to the next requires a run of clean nightly evals and a survival rate above a stated floor, both produced by the eval suite, not by the agent. Demotion is automatic on a single incident of a stated class and does not wait for a meeting. The current band is a field on the agent’s identity record, so any orchestrator can read it and any auditor can replay when it changed.

None of this is exotic. It is the vendors’ self-demoting auto mode with a promotion rule bolted on. The bolt is the part the vendors leave to you.

Roadmap diagnostic: can you name, for your most autonomous agent, the evidence that would move it down a tier this week, and who does not get a vote when it happens?

The bottom line

Instructions in, results out was IT. Intent in, outcomes out is agentic AI. The tier is how much of the outcome you let the agent own before you look. A grant decides that once. A band decides it every night, on evidence, with the ceiling held by something the agent cannot touch.

I wrote Intent In, Outcomes Out on the intent side of that sentence and Earned Autonomy on this side of it. The second book exists because the first question every program asks is how much to let the agent do, and the honest answer is: as much as it has earned, and not one action more.

Which of your agents holds a tier it never had to earn?

My books go deeper on both: Intent In, Outcomes Out and Earned Autonomy.

Go deeper

Agentic AI Architect: control design for enterprise agents.
Agentic AI Case Studies: deployment evidence, one teardown at a time.
Agentic AI P&L: cost, payback, and risk in a CFO’s voice.
Agentic AI Governance: who owns the harness.
Substack first access: agenticaiarch.substack.com/subscribe

Dr. Harish Kotadia, Ph.D., is an Enterprise AI Architect with 20+ years of IT consulting experience serving Fortune 100 clients, specializing in agentic AI systems built on Anthropic Claude, AWS Bedrock, and Google Vertex AI.

Disclaimer: This blog post is based on publicly available academic publications, vendor documentation, open standards, and news items from reputed media sources linked above. This post is intended for educational purposes, to help the enterprise agentic AI community build a shared vocabulary from public, authoritative sources.

Views and opinions expressed here are my own and do not represent those of any employer or client, past or present. The analysis presented is my independent interpretation of the published sources linked above and does not constitute legal, financial, or consulting advice of any kind.