If you only logged one thing about an AI agent, it should be its tool calls. A model generating text is, in the worst case, producing words. A tool call is the agent reaching out and changing something: writing a record, sending a message, moving money, altering a system. Tool calls are the actions. Everything else an agent does is preamble to an action or commentary on it. So the record of tool calls is, quite literally, the record of what your AI did in the world, and that record is the difference between an incident you can explain and one you cannot.
The fields that matter
A useful tool-call log captures the full shape of the call, not just that it happened. Five things deserve to be recorded every time.
The identity behind the call: both the human ultimately responsible and the agent that acted on their behalf. Without this, you have an action with no actor, which is useless for investigation and worthless for accountability.
The tool and its arguments: which tool was invoked and with exactly what parameters. The arguments are where the real meaning lives. "Called the database tool" tells you little. "Called the database tool requesting all records modified in the last year" tells you whether something went wrong.
The policy decision: what the policy engine decided and on what basis. Recording that the call was allowed, and why, is what proves the control was working. Recording that a call was denied or required approval is just as important, because denials are evidence that the boundary held.
The result: what the tool returned or what effect the call had. The action's outcome closes the loop between intent and consequence, and it is what you reconstruct events from.
The reason: the rationale tying the decision to the policy and the purpose. A log that says "allowed" is far weaker than one that says "allowed because this agent, acting for this user in this role, was permitted to perform this action for this purpose." Reasons are what turn a log into an explanation.
Why denials and approvals belong in the log
Teams instinctively log successful actions and forget the ones that did not happen. That is backwards for governance. The most valuable entries are often the denials and the approvals. A denial recorded with its reason proves that the system stopped something it was supposed to stop, which is exactly what a security reviewer or auditor wants to see. An approval recorded with its context and its approver shows that a human made a deliberate decision at a high-stakes moment, rather than an agent acting unchecked. Logging only the allowed actions leaves you able to show what happened but unable to show what was prevented, and proving prevention is half the point of governance.
From a tool log to an audit trail
A tool-call log on its own is valuable, but its real power shows up when it is part of a larger, structured record. The same interaction that produced a tool call also involved data retrieval, a policy decision, perhaps a model call and a memory operation. Capturing the tool call in isolation tells part of the story. Capturing it as one event in a complete trace of the interaction tells the whole story, and lets you reconstruct not just what the tool did but everything that led to it.
This is why tool-call logging is best understood as a feeder into the broader AI audit trail, rather than a separate log file. The principles, structured events, decision reasons, complete attribution, are the same ones that govern the audit trail as a whole, which we cover in the complete guide to the AI audit trail.
The habit worth keeping
The simplest rule is this: never let an agent take an action in the world that leaves no trace of who, what, why, and with what result. Tool calls are actions. Actions need accountability. A complete tool-call record is what makes agent autonomy something you can stand behind rather than something you hope goes well. The controls that decide which calls are allowed in the first place are covered in the complete guide to MCP governance and in scoped credentials.