What belongs in an agent's audit trail

Something will go wrong. An agent will send the wrong message, file the wrong record, or make a decision that a person would not have made. When that happens, the first question anyone asks is "what happened?" The second is "why?" And the third, from whoever is responsible for the business, is "how do we make sure it does not happen again?"

An audit trail is the thing that lets you answer all three. Most agents do not have one worth the name. They have logs, which is not the same thing. Here is the difference, and what to record.

Logs tell you that. Trails tell you why.

A log says the agent ran at 09:14 and returned status two hundred. A trail says the agent received this input, retrieved these three documents, decided the request was a refund, checked the customer's history, found the order, and issued the refund because the policy rule about orders under a threshold matched.

The trail is a narrative of decisions, not a list of events. It is the difference between knowing the agent did something and knowing what it was thinking when it did.

The six things to record

For every run, capture these, in a form a person can read without an engineer sitting beside them.

The input, exactly as received. Not a summary. The actual message, document, or event that started the run. Half of all incidents turn out to be input nobody expected.

The context the agent used. Which records it retrieved, which documents it read, which tool results it saw. When an agent is wrong, it is often because it was reasoning correctly from something it should not have been looking at.

Each decision, with the reason. At every branch, what the agent chose and the rationale it produced. This is the part most systems skip, and it is the part that answers "why."

Each action taken, with the parameters. What tool was called, with what arguments, and what came back. If a message was sent, the message. If a record changed, the before and after.

Every gate and its outcome. Where a person was asked, what they were shown, and what they decided. Where the agent asked a question instead of guessing, the question and the answer.

Cost and timing. Tokens, calls, seconds. Not for the incident review, but because the trail is also where you see decay start.

Make it readable by the person who will need it

The audit trail's reader is not a developer. It is the operations manager at nine in the morning after a complaint, or the compliance lead answering a question from a regulator, or the owner deciding whether to trust the agent with more.

So the trail should render as a story, in order, in plain language, with the technical detail available but not in the way. A screen that shows "run 4471: input, context, decisions, actions, gates, cost" as a readable timeline is worth more than a terabyte of structured logs that need a query to interpret.

Keep it as long as the consequence lasts

How long to retain trails depends on what the agent does. An agent drafting internal notes can keep a few weeks. An agent touching financial records or customer communications should keep trails as long as those records matter, which may be years. Decide this at design time and write it down, because it is also a data-protection decision.

The trail is the governance

People ask what governance looks like for agents and expect a policy document. The policy matters, but the trail is what makes the policy real. A guardrail you cannot audit is a suggestion. A human gate with no record of who approved what is a formality. The trail is how you prove the controls exist and worked, and it is how you learn where they did not.

If your agents have logs but no trail, that is the next thing to build. It is cheaper before the incident than after.