What belongs in an agent decision log
When an AI agent acts on your organisation's behalf, someone will eventually ask why it did what it did. What a decision log needs to capture for that question to have an answer, and what a register entry alone cannot tell you.
What should an AI agent's decision log record?
A decision log records what an agent actually did, as distinct from the register entry that records what it is allowed to do. For each consequential action it should capture the action itself and what it changed, the tool calls made, the inputs and context the agent was working from, the goal or task it was pursuing, whether a human approved the step or the agent acted within its autonomy, and the time. The test is whether a person who was not there can reconstruct why the agent did what it did, months later, from the log alone. A register entry answers what the agent may do. The decision log answers what it did, and the distance between the two is where every difficult question about an agent lives.
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 register entry records 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, and the distance between the two is where every difficult agent question lives. 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, since 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 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 token and intermediate step, belongs to engineering observability, 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 demonstrate that the log is complete and unaltered, because the demonstration cannot be built retroactively. This is the same property that matters for governance evidence generally, covered in what makes AI evidence independently verifiable.
Where Aicura fits
In Aicura, agents live in the AI Register alongside the systems they sit on, each with its tools, runtime identity, autonomy and owner on the record, and runtime constraints enforced through the gateway. Agent decision logs are part of the Enterprise tier, connected to the agent’s register entry so what the agent did sits beside what it was allowed to do, and captured into the evidence layer, so the record’s integrity is something you can demonstrate rather than assert.
Aicura provides guidance, not legal advice, and does not certify, audit or issue a compliance verdict. What your agents are permitted to do, and what counts as consequential for each, are decisions their owners make.
Common questions
Isn’t the application log enough? Application logs record what happened to the software. A decision log records what the agent did as an actor, meaning actions, tool calls, context and authorisation, organised so a governance question can be answered. You can sometimes reconstruct the second from the first, at great cost, once, under pressure. A decision log is that reconstruction done continuously and in advance.
Should we log every step or only consequential ones? Log at the level of actions that change something or commit the organisation to something. Full traces of every internal step have their place in engineering observability, but a decision log serves people answering accountability questions, and drowning them in tokens defeats it. The threshold worth writing down is which actions your organisation considers consequential for each agent.
How long should decision logs be kept? As long as questions about the agent’s conduct could reasonably arise, which for agents acting on decisions that affect people is usually years, not months. Align retention with your record-keeping obligations for the underlying business process, since the agent was performing that process.
Who should be able to read a decision log? The agent’s owner, the people overseeing agents generally and anyone your organisation decides answers for the outcomes, plus an external party when a dispute or review makes it necessary. Which is why it helps for the log to be organised for reading, and for its integrity to be demonstrable rather than asserted.
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.
Related guides
- What to record about an AI agent — The register entry the decision log sits beside.
- Governing AI agents
- The AI incident evidence trail
Decision logs in Aicura
Aicura holds agents in the AI Register with their tools, runtime identities and constraints, and keeps agent decision logs as part of the Enterprise tier, connected to the register entry so what the agent did sits beside what it was allowed to do.