How to reconstruct an AI agent's decision from the record

Begin with the action and work backwards through the record. Find the verdict linked to the action, restore the agent's brief, limits and certificate as they stood at that moment, retrieve the sources exactly as the agent saw them, and re-run the bounds check. A named investigator then records what happened, why it was allowed, and who approved.

What does reconstruction mean, and who owns it?

Reconstruction answers a question someone asks after the fact: a customer complaint, an auditor's sample, a regulator's enquiry, an incident review. Why did the agent do this? The aim is not to make the model produce the same words again, which it may not. The aim is to show what the agent knew, what it was permitted to do, which limit decided, and who, if anyone, approved.

The investigator owns the reconstruction: a risk analyst, an internal auditor, or the agent operations lead in an incident. The process owner confirms the business context. Whether it is possible at all depends on what was recorded at the time, which is why can you reconstruct why an AI agent took an action? is a design question, not only an investigation one.

What must the record contain?

For each action: the request or trigger; the agent's identity and the version of its brief; the capability invoked and its depth; the state of each bound and which one decided; the sources used, with their provenance and a fingerprint of their content; the model and its version; the proposed action; the verdict; the approver if held; and what executed. Without the sources as they were, you can only guess what the agent saw.

What are the steps?

1. Person, investigator: identifies the action from the business system, such as the payment, letter or record change, and its identifier.
2. Agent, depth 1: retrieves the linked verdict from the agent's record using that identifier.
3. Agent, depth 1: restores the limits as they stood: brief version, role scope, capability and depth, certificate status and customer limits on that date.
4. Agent, depth 1: retrieves the sources as seen, from the stored copies or fingerprinted versions, not from today's systems, where data may have changed.
5. Agent, depth 1: re-runs the bounds check against the restored limits and sources. The bounds check is rule-based, so it should give the same verdict; a different answer is itself a finding.
6. Agent, depth 2: drafts a reconstruction note in plain language: what was asked, what the agent knew, what it proposed, which bound decided and who approved.
7. Person, process owner: confirms the business context, such as whether the customer's limit was correct at the time.
8. Person, investigator: verifies record integrity for the entries used, then concludes and signs.

The retrieving agent should not be the agent under investigation, and it should have read-only access.

Which controls make reconstruction trustworthy?

An append-only record. Entries cannot be edited or deleted after filing; see append-only record: what it means for AI agents.

Tamper evidence. Each entry is chained or signed so any change is detectable. How do you make an AI agent's record tamper-evident? covers the methods.

Versioned limits. Briefs, scopes and depths are kept as dated versions, so you can restore what applied on any day.

Stored sources. The record keeps what the agent read, or a fingerprint plus a way to retrieve that exact version.

A named bound on every verdict. If the verdict says which bound decided, the reconstruction can confirm it directly. The argument for this is in why every agent decision needs a named bound.

Which signs show it is going wrong?

• The re-check gives a different verdict. The limits restored are not the ones that applied, or the bounds check was not enforced at the time.
• Sources cannot be found. The record holds references to documents that have since changed or been deleted.
• The approver is a shared account. You know the action was approved but not by whom.
• Reconstruction takes days. Engineers have to read raw logs, which means the record was built for debugging, not accountability.
• The note relies on the agent's explanation. An agent's own account of its reasoning is a claim, not evidence. Rely on sources, limits and verdicts.

What should you measure?

Time to reconstruct a decision, the number of reconstructions that could not be completed and why, re-checks that gave a different verdict, and integrity checks that failed. Run a few reconstructions every quarter on random actions, not only when something goes wrong.

Where does it usually go wrong?

The record was designed for engineers. It holds model inputs and outputs but not the limits that applied or the bound that decided.

Today's data is used. The investigator looks at the customer's current record and concludes the agent was wrong, when the data was different at the time.

Model reasoning is treated as the answer. Generated reasoning is useful context but is not proof of what drove the action. The bounds and sources are.

Where Pryme fits

In Pryme, each verdict is filed in an append-only record with the bound that decided and the provenance of every source, so reconstruction is retrieval rather than detective work. The five bounds every action meets are described in agent governance is a bound, not a model.