Your Agent Made a Call. Can You Prove Why?

Here is a question worth asking your team about any agent you are close to shipping. Three months from now, a customer disputes something the agent did. What do you put in front of them?

The usual first answer is "we have logs." Sometimes that is enough. Frequently it is not, and the gap between the two is worth understanding before you need it rather than during.

Application logs are built for engineers debugging a system. They record what the software did — this endpoint was called, this returned a 200, this took 340 milliseconds. They are structured around execution, they are usually sampled, and they typically age out after thirty or ninety days because nobody budgeted to keep them longer.

An audit trail answers a different question. Not what the software did, but why this outcome was reached, on what information, under whose authority. That is a business record. It has to survive far longer than a log, it has to be readable by someone who is not an engineer, and it has to be complete rather than sampled.

You can sometimes reconstruct a rough version from logs. What you cannot reconstruct is the context the agent actually had at the time — which documents it retrieved, what the record looked like before someone edited it last week, which version of the instructions was live. That information is gone unless you deliberately captured it, and "we think it probably saw the current version" is not a defence.

The practical list is shorter than people expect. For each consequential action, record what triggered it and who or what initiated the request. Record which tools the agent invoked and what each returned — the actual values, not just that a call happened. Record the retrieved context that fed the decision, or a stable reference to it that will still resolve in two years. Record the version of the model, the instructions and the tool definitions in effect. Record the action taken, and if a human approved it, who and when.

Two details matter more than the list. It has to be written as part of the action, not afterwards by a process that might fail independently — otherwise you will eventually have actions with no record and no way to tell which. And references have to stay resolvable: pointing at a document that has since been edited in place tells you nothing about what the agent read.

Not in the same place as your debug logs, and not somewhere it can be edited without a trace. This is business record retention, so it inherits whatever retention rules already apply to the process the agent is participating in. If the underlying decision has a seven-year retention requirement, so does the record of the agent making it.

A useful sanity check: could you produce a complete, readable account of one specific decision without engineering involvement? If producing it requires somebody to write a query and interpret the output, you have logs. If someone in operations or compliance can pull it themselves, you have an audit trail.

Pick a decision your agent made last week. Not a dramatic one — an ordinary one. Try to produce the complete account: inputs, context, tools called, action taken, authority. Time how long it takes and note what you cannot recover.

Almost everyone finds something missing on the first attempt, and it is much better to find it in a dry run than in response to a complaint or a request from a regulator. The fix is nearly always cheap at this stage and nearly always expensive later, because it means changing what the agent writes at the moment it acts — and by then it has been acting for months.

If you want help designing what to capture before an agent goes live, that is the sort of thing we do. It is a much shorter conversation than the one that starts after something has gone wrong.