One agent can be trusted to read a whole customer file, draft a reply for a person to send, update an address alone and do nothing with payments. A single autonomy level applied alike to every action cannot express that. The agent is certified to one depth, meaning how far it may act, and each action needs a depth of its own.
What is depth, and why does each action need its own?
Depth describes how far an agent may go. At depth 1 it reads. At depth 2 it drafts and a person sends. At depth 3 it executes routine work within bounds. At depth 4 it moves money or takes actions that are hard to undo. Depth 5 is reserved for orchestrators that coordinate other agents. Our glossary entry on what depth means for AI agents gives the full definition.
The reason each action needs its own depth is that the risk of each capability varies. Reading a file harms no one if the agent misreads it, as long as nothing follows. Drafting a reply harms no one if a person checks it. Updating a postal address could misdirect a letter. Issuing a refund sends money out of the business. These are different risks, and an agent that handles all four should not be treated as if they were one.
Why do single autonomy levels appeal, and where do they fall short?
They are simple to explain. "This is a level 3 agent" fits on a slide and gives a board one number to approve. Several published frameworks describe agent autonomy in levels; the Cloud Security Alliance, for example, has published autonomy levels for AI agents from 0 to 5. These are useful for describing the general character of a system.
As a control, a single level applied alike to every action has two problems. Set it high enough for the agent's most trusted capability and you hand that trust to every other capability, including ones it has never been tested on. Set it low enough for the riskiest capability and you throw away the value of the safe ones, sending routine work back to people. Either way, the setting does not match reality for most of what the agent does.
There is also an evidence problem. An agent tested thoroughly on drafting complaint replies has proven nothing about issuing refunds. So the agent's depth is only ever the highest depth its own cases proved.
What does this look like for a real agent?
Take a customer service agent at a mid-sized lender. It handles inbound messages, and over time it has been given several capabilities.
| Capability | Depth | Why |
|---|---|---|
| Read account history and correspondence | 1, read | Needed for every task; no action follows from reading alone |
| Answer questions about product terms | 3, execute within bounds | Tested in the agent's cases; answers grounded in the policy library |
| Draft complaint responses | 2, draft | Complaints carry regulatory and conduct risk; a person sends |
| Update contact details | 2, draft | Changes to contact details precede many frauds |
| Waive a late fee | 3, execute within bounds | Up to the customer's limit; above it, a person decides |
| Change repayment schedule | Not granted | Outside its role scope; stays with people |
One level applied alike to all of this would be wrong on almost every row. The depth each action needs lets each row reflect its own risk, against the agent's one certified depth. A capability and depth matrix template lays this out in a form owners can review and sign.
How is depth earned?
On evidence, from the agent's own cases. The agent's role sets a ceiling on how deep it may go. Evidence from testing the agent against real cases from the business's own operation sets the depth it has actually earned. The lower of the two wins. Configuring a depth without evidence behind it is not earning it.
This is why certification has to be specific too. The agent is certified as a whole, on cases that test what it does, for that customer. The argument that certification is per customer, not per vendor follows from the same logic: evidence from one customer's operation does not transfer to another's.
Does this make governance harder?
It makes it more detailed, which is not the same thing. A board or committee does not need to review every cell of every agent's matrix. It needs to approve the ceilings, see which capabilities need depth 3 or 4, and know who owns each of those. The detail lives with the capability owners, where it can be managed.
It also makes some things much easier. When a capability goes wrong, you can narrow its limits without touching the others. When evidence supports widening, you can widen one capability without arguing about the whole agent. And when an auditor asks what the agent may do, you can answer row by row, against the agent's certified depth. Third-party standards are starting to reflect this; our piece on how AIUC-1, autonomy levels and certification fit together looks at how they relate.
What is the trade-off?
More decisions, more evidence and more records. Each capability needs its own test cases, a place in the agent's certification and its own owner. Adding a capability to an agent is a real piece of work rather than a configuration change.
That friction is deliberate. It stops authority spreading across capabilities without anyone deciding it should. Teams used to giving an agent a role and moving on will find it slower. They will also find that when something goes wrong, the damage is confined to one capability, and the fix is to narrow one capability rather than switch off the agent. List each live agent's capabilities in rows, put the depth each needs beside the depth the agent holds, and note the gaps. Our guide on how to set permissions for an AI agent walks through the first pass, and the wider framework is in our guide to agent governance as a bound, not a model.
Where Pryme fits
Pryme certifies depth per agent, per customer. The agent's role sets a ceiling, Attest sets the depth the agent has earned on the customer's own cases, and the lower wins. A run that clears no depth drops the agent to depth 1 the same day, and every verdict records the capability and depth it was decided against.
Questions people ask
Can an agent act on one capability and not at all on another?
Yes, and that is common. An agent might execute routine account updates within limits while having no grant at all to touch payments. Capabilities with no grant are refused.
How many capabilities should one agent have?
As few as its job needs. Each capability adds testing, ownership and more for the agent's certification to cover. If an agent accumulates many unrelated capabilities, consider splitting it into narrower agents with clearer roles.
Is depth the same as a permission level in an access system?
Related but not the same. Access permissions control what an identity can technically reach. Depth controls how far the agent may act with a capability, including whether a person must send or approve. Both need to agree, and depth is usually the tighter of the two.