Seniority Ladder
Not what the agent is called. What kind of agent it is, and what governance that kind actually requires.
The published agent card carries a field that reads <1-5; see Seniority Ladder>. Until now the reference resolved to nothing a reader could open.
It always resolved to something. The ladder has been written, canonical, and in use in assessment work since before this wiki existed. It was defined in one repository and named in another, which is a publication failure rather than a missing framework.
This page is the publication. Nothing here is new work.
Autonomy increases as the level number increases. Level 1 is the most constrained. Level 5 is the least.
That has to be stated out loud, because the opposite convention is in circulation: there are credible sources that number a ladder by human involvement, where a higher rung means more mandatory review. Two teams reading two documents will both say we are at level three and mean opposite governance postures. One of them will be wrong in the direction that costs money.
The convention on this page is the one already published in the agent card, and it is the one the card's readers have been assuming.
| Level | What the agent does | Risk profile | Governance it needs | The signal you are actually here |
|---|---|---|---|---|
| 1 · Task automation | Completes a defined, bounded task on a fixed input and output contract. No branching, no tool use, no writes to external systems | Low. A human reads the output before anything happens | A model card, an accuracy threshold, a human in the loop for anything consequential | The client can state exactly what goes in and what comes out, with no ambiguity |
| 2 · Supervised autonomy | Takes actions that reach real systems, but a human approves before execution or inside a short window | Medium. Errors are catchable, and only if the review step was designed | A written human-in-the-loop policy, a defined escalation path, edge case handling, an audit trail of the human decisions | The client has designed the review step, rather than assuming review will happen |
| 3 · Governed autonomy | Acts without per-transaction approval, inside a policy envelope. Exceptions escalate | Medium to high. Errors may not surface until something downstream is already wrong | Policy governance, monitoring, drift detection, escalation SLAs, compliance sign-off on the envelope itself | The client can articulate the policy envelope and the escalation triggers, with specificity |
| 4 · Autonomous orchestration | Decomposes goals, selects tools, drives other agents, adapts on intermediate results. Minimal per-task oversight | High. Errors cascade across hops and amplify before anyone sees them | An orchestration policy, a trust model between agents, human override at any point, full observability, an incident playbook for agentic failure | The client has mapped the multi-agent topology and defined the trust model between the agents |
| 5 · Strategic autonomy | Sets its own sub-goals against high-level objectives, over long horizons, with no human in the tactical loop | Very high. The scope and the error surface are hard to bound | Research grade. Not yet codifiable in standard enterprise governance | Almost always a misclassification. Nearly everyone claiming level 5 is describing level 3 or 4 |
Level 5 is not recommended in an enterprise context without a dedicated research team and sustained red-teaming. It is on the ladder because the ladder has to have a top, not because it is a target.
The governance column above is the requirement. This is what it means in practice, and it is where most estimates are wrong by a factor.
| Level | What it needs before it runs | What it needs while it runs |
|---|---|---|
| 1 | Labelled examples of the task, a clean and consistent input format | Sampled accuracy against the threshold |
| 2 | Task examples carrying approval and rejection signals, integration with the system of record | The audit log of human decisions, which is also the training signal |
| 3 | The policy rules codified and tested, an edge case library that defines what escalates | A full trail of agent decisions and their rationale, plus drift detection |
| 4 | Tool APIs with real contracts, observability infrastructure, adversarial testing of agent-to-agent handoffs, a failure mode catalogue | Monitoring across hops, and an override that works at any point rather than only at the end |
| 5 | An extensive world model, an evaluation harness that works over long horizons | Not solved. That is the honest answer |
One useful reading of that table: the work does not scale with the level, it changes shape. At level 1 the work is data. At level 3 it is policy. At level 4 it is infrastructure. A team that is good at the first is not automatically ready for the third.
The four-rung human-involvement convention mentioned above is not wrong about the world. It is only counting from the other end. Its content survives as the governance requirement at each level of this ladder, which is where it belongs.
| Level | The human posture that goes with it |
|---|---|
| 1 | Log and read. The output is a suggestion until a person acts on it |
| 2 | Approve. Nothing reaches a system of record without a named person releasing it |
| 3 | Review by exception. Routine transactions run; the escalation triggers decide what a human sees |
| 4 | Supervise the fleet, not the transaction. Humans handle exceptions and read the aggregate |
| 5 | Set standards for work nobody will individually inspect |
The asymmetry is the whole point. As you move up the ladder, autonomy transfers and responsibility does not. The further you delegate, the more of the job becomes deciding what correct means in advance, because you will not be in the room when it is decided.
A level is a description of a system. A promotion is a decision to let a specific agent operate at one, and it needs a criterion that was written before the promotion was wanted.
| Moving to | What should earn it |
|---|---|
| Level 2 | A sustained period at high acceptance on real inputs, with zero critical errors |
| Level 3 | A sustained period inside a defined error rate, at real volume, with the policy envelope written and tested rather than described |
| Level 4 | Demonstrated recovery from a failed handoff, not just demonstrated success on a good day |
| Level 5 | Nothing yet. Treat a request for it as a level 3 or 4 request that has been described ambitiously |
The source documents state specific durations and thresholds for the first two. Those are deliberately given as bands here, because the right duration depends on volume: thirty days at low volume proves nothing, and a week at high volume can prove more.
Three properties of a promotion process that is actually working:
The criterion is written before the level is occupied. A criterion invented at promotion time is a rationalisation with a number attached.
Demotion exists. A ladder with no way down is a ratchet, and a ratchet is how an agent ends up at level 4 after an incident nobody logged.
The level is on the card. If autonomy is not a recorded field, it is a belief, and beliefs vary by who you ask.
The level describes what the system does. It says nothing about what governs it, and the two are set by different people at different times.
The failure mode this ladder exists to catch. An organisation deploys at level N and has designed governance for level N minus 2 or lower.
The common form: a level 3 or level 4 workflow running on level 2 governance, which is to say a human-in-the-loop design and nothing else, or on no governance at all.
What it costs when something goes wrong: no defined accountability owner, no escalation path, and no audit trail. The system is operationally fragile and compliance-exposed at the same time, and the first anyone hears of it is the incident.
The question that finds it:
If this agent takes an incorrect action on its own, what is the process for detecting it, reversing it, and understanding why it happened?
Three answers and you are fine. A pause and a look at the ceiling is the finding.
One. Ask: walk me through what the AI does from input to output. Who or what triggers it, what actions does it take, and who sees the result before anything downstream happens?
Two. Map the answer to the table above. Map what was described, not what it was called.
Three. Ask: who designed the governance for that level of autonomy?
Four. If the claimed level and the governance maturity do not match, that is seniority overshoot, and it is the finding of the meeting.
The first question is doing most of the work. It is deliberately not what level are you at, because that question returns the answer the client has already decided on.
They are different questions and both are needed.
| Asks | Scale | Changes when | |
|---|---|---|---|
| Seniority ladder (this page) | What kind of agent is this, and what governance does that kind require? | Five levels | The system's design changes |
| Trust ladder | How far has this particular agent earned its way? | Four rungs | The evidence changes |
A level 3 system can and should sit at rung 1 while it earns its way up. Those are not contradictory statements, and a governance conversation that cannot hold both at once will keep confusing capability with permission.
There is a second ladder in circulation, used to teach how capable a tool in front of you is: Reflex, Recommendation, Bounded Decisions, Autonomous Orchestrator, Adaptive.
It is referred to by rung name only, and it carries no numbers, because two ladders cannot collide on numbers if only one of them uses numbers.
| Teaching rung, by name | This ladder | Note |
|---|---|---|
| Reflex (autocomplete, a reversible suggestion a human accepts or ignores) | Below level 1 | Deliberately has no level. It is pre-agentic. You do not govern autocomplete |
| Recommendation (presents options, a human selects) | Level 1 | Bounded, no writes, reviewed before action |
| Bounded decisions (decides inside explicit rules and thresholds, logs overrides) | Level 2 or level 3 | Level 2 if a human approves each action, level 3 if it acts inside policy and only exceptions escalate. The rung spans both, and the split is exactly where governance changes |
| Autonomous orchestrator (multi-step planning and execution) | Level 4 | |
| Adaptive | Level 5 | Experimental, with the caution above |
The off-by-one runs in the dangerous direction. Someone who learned the teaching sequence and then reads level 3 in a governance artifact believes they are looking at governed autonomy when they are looking at orchestration.
The rule: in any governance, assessment or client artifact, level N means this page. Teaching rungs appear by name, with the mapping visible.
The seniority ladder, seniority overshoot and the teaching-ladder mapping are from the practice canon. The promotion criteria are adapted from the AI CoE and Agent Factory Playbook, based on The Augmented Enterprise framework. The governance posture per level is the author's own.
Back to Home · The framework spine · NORTH and the trust ladder