Governed autonomy explained: the operating model in seven stages
Published 2026-08-05 · Last updated 2026-08-05
Governed autonomy runs in seven observable stages: a trigger arrives, context is gathered, policy is evaluated, the agent executes what it is permitted to do, a person decides what carries consequence, the system of record is updated and the complete history is retained. Every stage has a visible control.
Why seven stages rather than a general description
Autonomy claims become assessable when they are broken into stages that can each be demonstrated. General descriptions of intelligent procurement cannot be verified; a stage that either happens or does not can be.
The seven stages below are the sequence to ask any vendor to show you, using one of your own workflows.
Stage 1 — Trigger
Work begins with a defined event: a request, a supplier response, a due date, a quality event, an exception or a data condition.
The control at this stage is that the trigger enters a governed record immediately, rather than existing only as an email that someone may or may not action.
Stage 2 — Context
The agent assembles what it needs: category, entity, value, supplier history, contract position, quality standing and any missing information it must request.
The control is that context comes from connected data and recorded requests, so the basis of the subsequent decision is visible.
Stage 3 — Policy
Applicable policies, permissions, thresholds and entity rules are evaluated before any action is taken.
The control is that the rule which fired is recorded against the transaction, which is what allows a routing decision to be explained months later.
Stage 4 — Agent action
The agent performs the actions it is authorised to perform: preparing an event, inviting eligible suppliers, chasing responses, routing approvals, normalising a comparison or drafting from an approved template.
The control is the permission set. Each action is attributed to the agent and to the authority that permitted it.
Stage 5 — Human decision
Consequential decisions reach a named person: commercial awards, contractual acceptance, supplier status, high-value purchases and any out-of-policy situation.
The control is that checkpoints cannot be bypassed by an agent, and the escalation arrives with the context needed to decide rather than to investigate.
Stage 6 — System update
Once approved, the outcome is written back to the relevant system of record — typically a requisition, purchase order or supplier record in the ERP.
The control is that only approved outcomes are written back, and that write-back success and failure are both monitored.
Stage 7 — Audit history
The observation, the applied rules, every agent action, each approval, any exception and any override are retained together.
The control is retrievability. If the complete history of a single transaction cannot be produced on request, the preceding six stages cannot be verified.
Four points. Easy to skim, easy to misread.
What the sequence is actually claiming.
The stages are observable, not conceptual
Each one produces something you can point at during a demonstration: a record, a rule reference, an escalation, a system update. If a vendor cannot show the artefact, the stage is a description.
Stage five is the product
The point where execution stops and a person decides is not a limitation of the automation. It is the property that makes the rest of it authorisable.
The rule reference matters as much as the action
Knowing an agent routed a request is of limited use. Knowing which rule selected the route, and that the rule is retained with the transaction, is what makes policy adherence evidenceable.
Stage seven is retained, not generated
The history is assembled as the work happens rather than compiled on request. That difference is the whole of audit readiness.
Six checks. Run the sequence on any vendor.
Including us. Especially us.
- Make them run one of your workflows through all seven stages, not a prepared scenario.
- At stage three, ask to see the stored rule reference.
- At stage four, ask what happened without a person.
- At stage five, try to bypass the checkpoint.
- At stage six, ask what happens when write-back fails.
- At stage seven, request the record as an auditor would.
The questions we get asked. Answered straight.
The ones that come up when a shortlist is being narrowed.
The sequence is consistent, though the detail differs. A catalogue purchase may pass through policy and human approval quickly, while a sourcing event spends most of its life in stages 3 and 4. The stages that are always present are policy, human decision and audit history.
Stage 3 is a rule being applied by software. Stage 5 is a person exercising judgement. Confusing the two is how organisations end up believing they have governance when they only have routing.
Only where your policy says it should — routine, low-value, in-policy work is exactly what agents are for. What matters is that the threshold deciding this is explicit and configured, not implicit.
Bring one real workflow and ask to see all seven stages executed on it, including a blocked action and an escalation. A demonstration that only shows the happy path has not shown you the governance.
That is common, and the encoding exercise usually exposes it quickly. Most organisations find the ambiguity is concentrated in a small number of thresholds and exception routes, which is a manageable thing to resolve.
Seven: a trigger arrives, context is gathered, policy is evaluated, the agent executes what it is permitted to do, a person decides what carries consequence, the system of record is updated, and the complete history is retained. Each stage produces an observable artefact.
Because certain decisions carry commercial, legal, quality or safety accountability — supplier award, contractual acceptance, supplier status change, quality containment. Delegating those to software transfers the action but not the accountability, which is why they remain human checkpoints.
It escalates to a named person with the context attached rather than stopping silently or attempting the action anyway. The escalation path is part of the agent definition, not a fallback behaviour.