What belongs in an agent decision log

Every organisation that deploys an agent eventually meets the same question. Why did it do that? Sometimes the question arrives gently, from a curious owner. Sometimes it arrives in an incident review, a customer dispute or a regulator’s information request, with a date months in the past attached. Whether the question has an answer is decided long before it is asked, by what the agent’s decision log captured while nobody was worrying.

The register says may, the log says did

An agent’s record in the AI register says what the agent is, meaning its purpose, its permitted tools, its autonomy and its owner. That answers what the agent may do. It cannot answer what the agent did on the afternoon of 14 March. An agent can hold entirely appropriate permissions and still have done something that needs explaining, and an agent that acted correctly still needs the record to show it. The decision log is the “did” side of the pair, and it only exists if it was being written at the time.

What to capture

The action and its effect. What the agent did and what changed as a result, whether that is the record updated, the message sent or the transaction submitted. Effects are the part someone will ask about, so the log should name them rather than leaving them implied by a tool name.

The tool calls. Which tools the agent invoked, with what, and what came back. Tool calls are where an agent touches the world, and they are also where the register’s permissions meet reality. A tool call the register would not predict is the first thing an investigation looks for.

The working context. What the agent knew when it acted, meaning the inputs, the retrieved material and the state it was reasoning over. Most surprising agent behaviour is unsurprising once you see what the agent was looking at, and without the context the log records conduct while explaining nothing.

The task. The goal or instruction the agent was pursuing, and who or what set it. Actions that look wrong in isolation are often correct against the task, and the reverse is also true.

The authorisation. Whether a person approved the step or the agent acted within its autonomy, and if a person approved, who. This line carries more accountability weight than any other, because it locates each action on the boundary between human and delegated decision.

The outcome. Whether the action completed, failed, was blocked by a control or was escalated to a person. A blocked action is as informative as a completed one, because it shows the boundary working.

The time. Every entry, precisely, because sequence is often the entire question.

The test for sufficiency is reconstruction. Could a person who was not there, reading the log months later, work out what the agent did and why? If the answer needs a developer, a database export and an afternoon, the log is not doing its job.

Consequential, not exhaustive

An agent’s full internal trace, meaning every piece of text the model reads and writes and every intermediate step, belongs to engineering monitoring, and burying a governance reader in it defeats the log’s purpose. The decision log operates at the level of actions that change something or commit the organisation to something. The useful discipline is to decide, per agent, which actions count as consequential, write that down and log at that grain. The decision itself is governance, because it is your organisation saying what it considers worth answering for.

A log that can be doubted is half a log

Decision logs get read in exactly the situations where someone benefits from doubting them. A log whose integrity rests on “our database says so” invites the response that databases can be edited, and in a genuine dispute that response will be made. It is worth knowing, before the dispute, how you would show that the log is complete and unaltered, because that cannot be built retroactively. The same property matters for governance evidence generally, covered in what makes AI evidence independently verifiable.

What the frameworks say

ISO/IEC 42001 expects the operation of AI systems to be documented and records to be kept and controlled. The NIST AI Risk Management Framework asks for mechanisms to track and document how deployed systems behave. Where an agent falls within a high-risk use under the EU AI Act, the Act requires high-risk systems to support automatic logging of events and deployers, the organisations using them, to keep those logs for an appropriate period. None of these prescribes an agent log format, which is why the fields above are worth settling for yourself.

Where Aicura fits

Aicura keeps the “may” and the “did” on the same agent. At Pro, decision records sent from your environment, through a small Aicura service that runs there, land on the agent’s monitoring page, each with the decision, its outcome, the tool called and whether the gateway allowed or blocked it. A tool missing from the agent’s declared list carries a “Not declared” flag, and the share of undeclared tool calls is a figure you can set an alert on. Batches of decision records are also kept as sealed snapshots in the Evidence Vault as they arrive.

What your agents may do, and what counts as consequential for each, are decisions their owners make.

A note on this page

This guide describes what makes an agent decision log useful when it is needed. Retention, access and what to log are decisions with legal and workplace dimensions in your context, so take your own advice on those. It is general information, not legal advice.