The Agentic Operations Journey
Seven modes, M0 to M6. What changes across the ladder isn't how capable the model is — it's how much access, autonomy, action and accountability the enterprise has handed over, and what has to be true before it does.
Most AI governance still classifies by technology: which model, which vendor, which data. That tells you almost nothing about exposure. Two teams can run the same model and sit four rungs apart, because one drafts emails with it and the other lets it move money. The ladder classifies by delegation instead — and delegation is what the assurance floor has to be set against.
The modes · a ladder from M0 to M6
Where a use case sits on the ladder changes what readiness has to ask of it. The left half is a productivity story — the model helps people work. The right half is an operations story — the system does the work, and the enterprise carries the consequence. The curve is steep at the top because M5 and M6 add authority, not just capability: the same failure that produced a bad draft at M1 produces a committed, compounding action at M5. Select a rung to see what it demands.
Select a mode: click or ← → — or press play in the bar above
M3
Workflow agent
An agent executes a defined workflow — real tool calls, real writes, inside one bounded process.
Assurance floor
- Pre-deployment behaviour testing on the workflow itself
- Tool-call correctness verified, not assumed
- Brokered credentials — no standing access to systems of record
- Per-run approval trail that reconstructs the decision
Four A's posture
Looks like this in FSI
KYC document intake, dispute case assembly, control-evidence gathering. The first rung with real writes.
Fails like this
At the edges of the workflow definition — inputs nobody scoped, handled confidently.
Where assurance attaches
AI Range test sets mapped to TEVV and the Four A's; Evidence Pack from the first run.
Each mode, described
A mode is defined by what the enterprise has handed over, not by the model underneath it. The same model can operate at M1 in one workflow and M4 in another. Read each rung for three things: what it is, what newly leaves human hands, and who is left in the loop — the glyph on the right is the topology, not decoration.
Read the glyphs down the column rather than one at a time: people leave the loop before agents enter it, and by M5 the person is attached to the system by a dashed line — present, but no longer in the path of the work.
The ladder read through the Four A's
The rung is a summary; the Four A's are what it summarises. They escalate independently, which is why two systems on the same rung can need different controls. High Autonomy with low Action is a research agent — wrong answers, contained. Low Autonomy with high Action is a narrow agent wired to a payments rail — right answers until it isn't. Accountability is the dimension that gets skipped, because it is the only one nobody has to configure.
Place your own use case
Pick the line that best describes the system you have in mind on each of the four dimensions. The ladder places it for you — and the rung it lands on is the assurance floor it has to clear.
Answer the four questions above to place a real use case on the ladder.
What the harness actually does
Assurance isn't a review that happens beside the system. The harness is the controlled execution and evaluation layer wrapping the agent — every call brokered, every action gated, every run instrumented into evidence. It is not a policy document, not a model card, and not a review board: those describe intended behaviour, while the harness constrains actual behaviour at runtime. The distinction matters most from M3 up, where a prompt asking the agent to stay in scope is not a control and cannot be evidenced.
Products against the ladder
Continuous TEVV means the same discipline runs before deployment and after it. The products differ by where in the lifecycle they attach — and the sequence matters: you cannot test what you have not inventoried, and you cannot monitor drift without a pre-deployment baseline to drift from.
| Product | Attaches at | Job | Produces |
|---|---|---|---|
| Use Cases & Alignment | M0 – M6 | Registry of every AI use case, scored for compliance risk and placed on the ladder at the mode it actually operates at — not the one it was approved at. | Inventory, risk classification, mode assignment |
| AI Range | pre-deployment | Behaviour testing against adversarial and cohort personas: task success, tool-call correctness, multi-step hallucination, policy enforcement under pressure. | Test results, failure modes, go / no-go |
| Peregrine | post-deployment | Continuous monitoring of live agents with dynamic risk scoring — catching drift, scope creep and quiet promotion up the ladder that pre-deployment testing could not anticipate. | Live risk posture, drift and escalation alerts |
| Evidence Pack | throughout | Collects what each stage emits into a reproducible, regulator-legible record of what was tested, what was found, and what was decided. | Signed, replayable assurance evidence |
Terms as I use them
- Assurance harness
- The controlled execution and evaluation layer wrapping the agent. Distinct from the agent runtime — the runtime decides, the harness constrains and observes.
- TEVV
- Test, Evaluate, Verify, Validate. Evaluation here is agent-specific behaviour testing, not classic model-risk challenger testing.
- The Four A's
- Access, Autonomy, Action, Accountability. The dimensions along which delegation to an agent actually escalates.
- Evidence Pack
- The reproducible artefact set behind an assurance claim. Determinism is the requirement: same inputs, same trace, same conclusion.
- Alignment Readiness Score
- A single tracked measure of whether a system's demonstrated behaviour matches the authority it has been granted.
- Continuous TEVV
- Assurance as an operating loop rather than a launch gate — because an agent's behaviour is not fixed at deployment.
Using the ladder
The ladder is only useful if a real use case can be placed on it and the placement changes what happens next. Three steps, in order — each one depends on the one before it.
- 01Place the use case at the mode it actually runs at
Not the mode it was approved at, and not the mode the vendor describes. Ask what the system can reach, decide, and commit without a person. Where the answer surprises the owner, the placement has already earned its keep.
- 02Read the assurance floor for that mode
The floor is cumulative — everything below the rung applies too. Gaps against the floor are the work plan, in priority order, and they are stated as controls rather than intentions so each one can be tested.
- 03Prove it, then keep proving it
Test before deployment, monitor after, and collect both into the Evidence Pack. A use case that climbs a rung without re-clearing the floor is the failure mode the whole ladder exists to make visible.