Disclosure: BlueBear builds an agent platform that implements a version of this model, so we have a commercial interest. The chain described here is generic; where we quote our own implementation it is named as ours, and where our own chain has a broken link we say which one.
The short answer: it is a chain because a pile does not reconstruct
An evidence chain is a linked record running from the identity of the requester through the policy, the plan, the approval, the execution, the artefact and the outcome, where each entry references the next.
The chaining is not decoration. Most systems that have "all the data" have it as a pile: model calls in one store, tool calls in another, approvals in a ticketing system, outcomes nowhere. Every one of those records exists, and reconstructing a single run is still a two-day investigation involving three teams. A chain turns that into a lookup, and the difference is the entire practical value.
This article assumes you already accept the need. If you are still arguing it, what an AI agent audit trail is is the definitional version and why reliability starts with an evidence chain is the existing argument for the model.
The chaining mechanism, before the links
Two mechanisms do all the work, and neither is difficult.
A run identifier, minted at the boundary. Created when the request is admitted, carried on every record produced by that run. It must be minted at the boundary rather than by the agent, for the same reason a witness statement should not be written by the defendant: an agent that mints its own identifier can also fail to. Timestamp correlation is the alternative and it works until two runs overlap, which in any concurrent system is immediately.
A reference from each link to the one before. The execution record names the plan it executed; the artefact names the execution that produced it; the outcome names the artefact it judged. This is what lets you enter the chain at either end — from an incident, you have an artefact and need the authority; from a review, you have an actor and need the actions.
Link 1 — Identity: who, and inside which boundary
References forward to: every other link, via the run identifier.
Identity establishes the human or system that initiated the request, the agent acting on their behalf, and the tenant or workspace boundary the whole run belongs to. It is written once, at admission, from the credential — never from a value the request supplies.
In our own gateway the boundary is an explicit property carried on the records rather than something derived at read time. That distinction sounds pedantic and is not: derived at read time means the answer depends on the query, and "we can filter by customer" is a weaker statement than "the record says which customer".
Missing link 1: nothing is attributable. Every action traces back to one shared credential, so you cannot answer who, cannot revoke narrowly, and cannot separate one customer's activity from another's. What AI agent identity is covers the plain-language version.
Link 2 — Policy: what was permitted, and why
References back to: identity. Forward to: the plan and the execution.
The policy record names the rule evaluated, its version, the inputs it saw, the decision, and the reason. The reason is the field people drop and the field reviewers want, because a decision without a reason cannot distinguish a control working as designed from a control misfiring.
The structural requirement is that the decision happens at the boundary that will execute the step. A rule stated in prompt text produces no record because nothing evaluated anything — there is no decision event to write down. This is why "we tell the agent what it may do" and "we control what the agent may do" produce completely different evidence chains from the same intention.
Missing link 2: you can show what happened but never that it was allowed, which is the question actually being asked. Least privilege for AI agents covers the scoping that makes this decidable.
Link 3 — Plan: what it intended
References back to: policy. Forward to: execution.
The plan record captures the steps intended and the constraints applied. It must be a separate record from the execution, and this is the link whose separateness is most often collapsed.
Our model routing is the clearest worked example we can offer. A route is planned and a runtime executes it: in shadow mode a plan is produced and recorded while execution is unchanged, and in active mode the planned model becomes the model the runtime is told to run. Because the two are distinct events, the system records whether the plan was honoured — and a planner that exceeds its default 750 ms budget produces a named reason rather than a silent fall-through. Plan and execution diverge for entirely ordinary reasons, and a chain that records only one of them will quietly assert the other.
Missing link 3: you cannot distinguish a wrong instruction from a wrong action, so a review cannot locate the fault. Any cost or quality model built on top also becomes wrong, because it assumes the plan was what ran. The plan-honoured gap is the detailed treatment.
Link 4 — Approval: who agreed, and to what
References back to: the plan. Forward to: execution.
Where a step requires a human, the record needs the approver, the time, the decision, any conditions — and what the approver was shown. That last field is what converts an approval from an assertion into evidence, and it is the one almost always absent.
Missing link 4: a control your design leans on cannot be demonstrated to have operated. Human-in-the-loop approval patterns covers designing the approval; the chain requirement is only that its context is captured.
Link 5 — Execution: what actually ran
References back to: the plan and the approval. Forward to: the artefact.
The execution record names what ran, against which connection, which operation, with which credential reference, how long it took, what came back — and whether it matched the plan.
The requirement that matters most is that failures are recorded as fully as successes. This is where nearly every system is thinnest, and where every review starts. It is worth naming our own gap rather than describing an ideal: our session records carry a field for the error that ended a failed session, and in our production data it is populated in none of the error rows. The sessions are marked failed; the field that would say why is empty. The schema is right and the producer is missing, which is the most common shape this failure takes anywhere.
Missing link 5: the plan is mistaken for reality.
Link 6 — Artefact: what came out
References back to: execution. Forward to: the outcome.
What was produced or changed, where it went, a content hash, and a version reference in the target system. The hash rather than the content is the right default: it proves a specific output is the one the run produced without turning the evidence store into a second copy of your customer data.
Missing link 6: you cannot connect a downstream problem back to the run that caused it, which is the direction incidents actually travel.
Link 7 — Outcome: whether it worked
References back to: the artefact. Forward to: nothing — it closes the chain.
Accepted, corrected, rejected or abandoned, with who judged it and when.
This is the link that most often does not exist, for a structural reason: it is the only one that is not an infrastructure event. It lives in a person's judgement or a downstream approval, so it requires a producer in the product surface where the work is accepted.
We will be specific about our own state here, because this is exactly where a schema flatters a system. In our gateway the ingestion path and the storage for action outcomes are built, tested and mounted — and no producer calls them, so the store is empty. The link is designed and unpopulated. We say so because the useful question to ask any vendor, ourselves included, is not "do you support outcome measurement" but "show me a stored row".
Missing link 7: you measure completions and call them successes, and every cost, quality and value number derived from that is wrong. Proving AI agent value beyond demos covers what that costs you commercially.
Reading the chain from either end
| You start with | You want | The chain gives you |
|---|---|---|
| An incident: a wrong record in a system | Who authorised it, and what else that run touched | Artefact → execution → plan → policy → identity, then the run identifier for everything else in the run |
| A review: an actor and a date | Every consequential action they were behind | Identity → runs → executions → artefacts → outcomes |
| A cost question: a spike | Which workflow and which customer caused it | Run identifier → identity boundary, and executions grouped by run |
| A quality question: rising corrections | Which plans and models produced them | Outcome → artefact → execution → plan |
The fourth row is the one that is impossible without link 7, and the first is the one people assume they have and usually do not.
If you operate in a regulated industry
The chain must be complete rather than sampled, and the schema change process matters as much as the schema. Both are covered in the requirements list, and the financial services treatment covers what a reviewer will actually ask for.
If you are a platform or engineering lead
Build in this order: run identifier, identity, policy decision, then the rest. Those three are the ones where every deferred day is permanently unavailable history, and they are days of work rather than projects. The control plane architecture walkthrough covers where each is written.
Do this next
Draw your own chain on one page: seven boxes, and for each one write the store it lives in today and the field that references the next link. The boxes with no store are the missing links; the boxes with a store but no reference are the pile problem. Then read the field-level requirements to specify the gaps, or the glossary if the vocabulary needs settling with colleagues first.
Questions people actually search for
- what is an evidence chain for ai agents
A linked record running from the identity of the requester through the policy that was evaluated, the plan, any approval, the execution, the artefact and the business outcome, where each entry references the next. The chaining is the point: a pile of records about the same run still requires someone to correlate them, whereas a chain lets one identifier at either end pull the whole run back. Reconstruction stops being an investigation and becomes a lookup.
- how do you link ai agent records together
With a run identifier attached at request admission and carried on every subsequent record, plus a reference from each link to the one before it. The identifier has to be created at the boundary rather than inside the agent, because an agent that mints its own identifier can also fail to. Correlating on timestamps instead works until two runs overlap, which in any concurrent system is immediately.
- what breaks if the plan is not recorded
You lose the ability to distinguish a wrong instruction from a wrong action. If only the execution is recorded, an agent that did exactly what it planned and an agent that departed from its plan look identical, so a review cannot tell whether the fault is in the policy, the planning or the runtime. It also makes savings and quality models wrong, because they assume the plan was carried out when plan and execution diverge for entirely ordinary reasons.
- is an evidence chain the same as a blockchain
No, and the confusion is worth clearing up because it leads to over-engineering. A chain here means each record references the previous one so a run can be reassembled - it is a data modelling property, not a consensus mechanism. What regulated use normally requires is append-only storage with tamper-evidence and controlled schema change, which conventional databases and object stores provide. Distributed ledgers solve a trust problem between parties that most internal audit obligations do not have.
- which link in the evidence chain is usually missing
The outcome, by a wide margin, because it is the only link that does not exist anywhere in infrastructure - it exists in a person judgement or a downstream approval, so it requires a producer in the product surface to report it back. The second most commonly missing is the policy decision, because in many systems nothing is making an explicit decision at a boundary, so there is nothing to record. Both are unrecoverable after the fact.