The order in which the work actually gets done.
If you are starting an agent governance program, the sequence below is the one I would follow. Each stage produces something the next stage needs, which is what keeps the process from becoming paperwork.
| Stage | Purpose | Output |
|---|---|---|
| Register | Know the agent and its owner | Agent record |
| AI-BOM | Know what is actually running | Composition record |
| Evaluate | Understand behavior and context | Evidence and findings |
| Comply | Connect obligations to controls | Control status |
| Govern | Apply policy and oversight | Decision criteria |
| Release | Decide whether it can operate | PASS, REVIEW or BLOCK |
| Assure | Keep the evidence current | Re-evaluation when needed |
Four of those stages deserve a little more explanation, because they are where programs usually go wrong.
Registration sounds clerical, and it is the stage that quietly determines whether anything later is possible. An agent record needs an identity and version, a business function, intended users, the tasks it may perform, the uses that are explicitly prohibited, and the names of the technical owner, the business owner, and the approver.
The reason to insist on it is practical. Most organizations do not know how many agents they have, which versions are live, what data those agents touch, or who owns them. When that information lives in scattered tickets and architecture diagrams, governance turns into archaeology performed after something breaks.
An AI bill of materials records what the agent is built from: model and version, prompts and their versions, tools and their declared side effects, data sources, memory configuration, orchestration, and the identities the agent can assume.
Its first purpose is reconstruction. Months after a release, you need to be able to say exactly what was running when you approved it. Its second purpose is change detection, since a change to any of those fields may invalidate the evidence behind the last decision.
The evaluation stage drives the agent through normal and adversarial trajectories and preserves what happened — the turns, the tool calls, the findings, and the configuration that produced them.
A score summarizes that body of evidence. It does not replace it, and a release conversation that only has the score has lost the ability to ask why.
The last stage is not a final step. Agents change behavior when nothing in your repository changes: a provider updates a model, a retrieval corpus shifts, a new attack pattern appears. Assurance watches for the changes that invalidate a decision and sends the agent back through the loop when they occur.
That is why the diagram has an arrow returning to evaluation. A release decision belongs to a specific version of a specific configuration, evaluated at a specific time.
With the sequence established, the rest of the guide follows it. The next part looks closely at the agent itself, because you cannot evaluate a system you cannot describe.
A release decision belongs to a version of an agent, not to the agent forever.
Map your current practice onto the seven stages to find where the sequence breaks. Most teams discover two or three stages that nobody performs, and one that everybody assumes somebody else does.