Your agent's action is logged. Its reason is gone.
Agent audit trails record the tool call and drop everything the agent read before making it. The reason lived in a context window nobody kept.
Every agent framework ships an audit trail now. It records the tool calls — which function, which arguments, which timestamp, which run id. That is a genuinely useful record, and it is missing the one part anyone will ask about later.
When a person makes a decision that turns out to be wrong, the reason is recoverable. You can ask them. They remember the ticket, the thread, the person who said it was fine. The reason lives in a human who persists after the action.
When an agent makes the same decision, the reason lived in a context window that was assembled at request time and thrown away when the response returned. The action survives in your database. Everything the action was based on does not.
The context window is the decision
An agent has nothing between its inputs and its output. The retrieved documents, the tool results, the system prompt as it stood that morning, the earlier turns of the conversation — that assembly is the reasoning. Drop it and you have not lost supporting detail. You have lost the decision and kept only its consequence.
Six weeks later the run log says the support agent issued a refund on order 41‑8827 for the full amount. What it does not say is that the retrieval step returned a duplicate of an older order under a similar customer name, and that the policy document it read was the draft version somebody had left in the wiki for two days.
The instinct at that point is to replay the run. It rarely proves anything. The retrieval index has been reindexed, the wiki page has been fixed, the model has been through a point release, and the sampling was never deterministic to begin with. A replay produces an answer. It does not produce the answer, and it cannot tell you which of the two you are looking at.
The model version is part of the actor
invoice-agent is a name, not an actor. The same name spans a model upgrade, a prompt edit, a newly added tool, and a change in which documents the retriever is allowed to see. Behavior moves with every one of those, sometimes considerably.
So when someone asks whether an incident happened before or after the change, a name cannot answer. The actor recorded on the action needs to carry the model identifier, a hash of the prompt revision, and the version of the tool schema the agent was offered. Most deployments record a friendly name and a run id, which is roughly like logging every human action as employee.
The most useful evidence is the data you cannot keep
Here is the tension nobody gets to skip. The context is the sensitive part. It is customer records, HR files, whatever the retriever was pointed at. Storing the full context of every run means keeping a second copy of your most sensitive data inside a system built for logs, with looser access control and a longer retention period than the source. A privacy reviewer is right to refuse that, and a deletion request would have to reach into it.
The way through is to commit without storing. At request time, hash the canonical form of each item that entered the context and of the assembled whole, then seal that digest alongside the action record. What you retain is fixed-size and reveals nothing on its own.
It buys two things. If the source documents still exist, you can prove which version the agent actually saw rather than the version that exists now. If they have been deleted under policy, you can still prove that the set was fixed at decision time and not assembled afterward to fit the story. That second property is the one that matters in a dispute, and it costs a hash.
Five questions for your own deployment
Pick one action an agent took last week — ideally one with money or access attached — and try to answer these:
- Can you produce the exact set of documents and tool outputs it read, in the version it read them, rather than the current version?
- Does the actor on that record include the model identifier and prompt revision, or only a name someone chose?
- If a customer disputes the outcome, can you show what the decision rested on, or only that it happened?
- Can the service that writes the agent’s log also edit it? If yes, the log describes the past that survived, not the past that happened.
- When the source data ages out under your retention policy, does anything remain that ties the action to what it read?
The uncomfortable version of all five is that agents are being handed refunds, provisioning, and access decisions on the assumption that their actions are reviewable, while the review consists of a row that says the action occurred. That assumption is cheap to fix now and expensive to fix during the first argument about it.
Axowl seals agent and human actions as they are written, with the actor and the inputs committed at the moment of the decision rather than reconstructed later. How it works.