A log tells you that something happened. An audit trail for an AI agent should tell you why. For every action, the record should show what was asked, which bound decided the verdict, what evidence the agent relied on, and who acted next. Without those four things, a list of events cannot defend a decision to anyone.
What is the difference between logging an event and explaining a decision?
Most systems already log. A request arrives, a record changes, a timestamp is written. That is enough to rebuild the sequence of events, and for deterministic software it is often enough to rebuild the reason too, because the code path is fixed and anyone can read it.
An agent is different. The same request on two days can produce two different actions, because the agent weighs its sources, its instructions and the case in front of it. A line that says "refund issued, 14:02" tells you the outcome. It does not tell you whether the refund was inside the agent's authority, which limit was checked, or whether anyone looked at it. If you want the general definition first, our explainer on what an audit trail is covers it; the argument here is about what an agent's trail must add.
A logging trail lets you say what happened. An explaining trail lets you say whether it should have happened, which is what an auditor or a complaining customer will ask.
What should each entry in an agent's audit trail contain?
Think of each entry as a short, structured answer to a question someone will ask later. The fields below are the minimum we would expect for any action an agent proposes, whether it ends up allowed, held, refused or withheld.
| Field | What it answers |
|---|---|
| The request | What was the agent asked to do, by whom or by what trigger? |
| The proposed action | What did the agent decide to do, in concrete terms? |
| The sources relied on | Which facts did it use, and where did each one come from? |
| The bounds checked | Which limits applied: role scope, certificate, sources, the customer's own limits, platform guardrails? |
| The deciding bound | Which of those limits produced the verdict? |
| The verdict | Allowed, held, refused or withheld. |
| The next actor | Who approved, rejected, edited or picked up the work, and when? |
The first three fields describe the agent's reasoning in terms a person can check. The middle three describe the governance. The last one closes the loop. Remove any of them and the entry stops being an explanation and goes back to being a log line.
Why does naming the deciding bound matter so much?
Every action an agent takes meets several limits at once. The agent's role may allow refunds. Its certificate may allow them only up to a set depth. The customer may have set a ceiling of 500. The platform may forbid refunds to an account that changed its details yesterday. The lowest of these wins, and the record should say which one it was.
It is the most useful field in the record. If a refund of 800 was held, "held" alone tells a reviewer nothing about what to fix. "Held: customer limit of 500" tells them the agent behaved correctly and the question is whether the limit is right. "Held: source was external, not signed" tells them something quite different, that the agent was being asked to act on an unverified email.
Naming the bound also makes patterns visible. If most held items cite the same customer limit, the limit may be set too low for the work. If refusals cluster on role scope, the agent may be receiving work it was never meant to do. A trail that only says "held" or "refused" hides all of this.
How does the record show who acted next?
An agent's verdict is rarely the end of the story. A held action waits for a named person. A refused action may be rerouted to a team. An allowed action may be reversed later by someone who spotted a problem. The trail has to follow the work until it settles.
That means recording the person, not the team. "Approved by payments operations" is not an answer an auditor will accept. "Approved by the named approver for refunds over 500, after editing the amount" is. It also means recording what the person changed. If approvers routinely edit the agent's drafts before sending them, that is evidence about the agent's quality that a plain approval count would hide.
Can the same record explain a decision to a customer?
It should be able to. A customer who asks why their refund was declined deserves a specific reason, not a general statement that a system was involved. If the record names the request, the sources and the deciding bound, a person can turn that into a plain answer: the refund was above the amount we allow without review, and a colleague declined it because the item had been used.
If the record does not hold those facts, someone has to reconstruct them from memory and guesswork, and the explanation may not match what happened. Our guide on explaining an AI agent's decision to a customer goes into how to phrase it; the precondition is a record that holds the reason in the first place.
What does an explaining record cost, and is it worth it?
The trade-off is real. Each action has to carry structured fields, the bound check has to report its result in a form the record can store, and the record has to be append-only so nobody can tidy it afterwards. Storage grows, and so does the effort of deciding what each field should contain.
The alternative costs more, but later. Without an explaining trail, every audit becomes a reconstruction exercise, every complaint needs an investigation, and every incident starts with weeks of reading raw logs to work out what the agent thought it was doing. Preparing for an audit is far easier when the evidence already exists, which is the core point of our guide on how to prepare AI agents for an audit.
There is also a design benefit. Teams that cannot fill in the "deciding bound" field usually discover they never set bounds clearly enough to check.
How do you tell whether your trail explains or only logs?
Pick ten actions an agent took last week, at random. For each one, try to answer five questions from the record alone, without asking anyone: what was asked, what the agent proposed, what it relied on, which bound decided, and who acted next. If you need to open another system, read a chat thread or ask a colleague, the trail is logging, not explaining.
Then repeat with ten held or refused items. If the record goes quiet once the agent hands over, the gap sits exactly where accountability does. Our article on how to audit what an AI agent did sets out a fuller test, and the wider principle sits in our guide to agent governance as a bound, not a model.
Where Pryme fits
In Pryme, every verdict is filed in an append-only record that names the request, the sources and their provenance class, each of the five bounds checked, the bound that decided, and the person who acted next. Held items carry the named approver and any edit they made. The record is built for reconstruction, so an auditor or a support lead can answer the five questions above without leaving it.
Questions people ask
Does an explaining audit trail need to store the agent's full reasoning text?
Not necessarily. Free-text reasoning is hard to search. Structured fields for the request, sources, bounds and verdict carry most of the explanatory value, and a short reasoning summary can sit alongside them for context.
How long should an agent's audit trail be kept?
Keep it at least as long as you keep the records of the underlying business activity, and longer where a regulator or your own policy requires it. The trail is evidence about decisions, so it should outlive the period in which those decisions could be questioned.
Who should be able to read the trail?
The process owner, the people who approve held items, internal audit and, through a person, the customer it concerns. Write access should belong to no one: entries are added by the system as decisions happen and are never edited afterwards.