Agent trace

An agent trace is the recorded sequence of an AI agent's steps, tool calls and outputs during a task.

What an agent trace is

When an agent works on a task it moves through a loop: it reads the prompt, reasons, calls a tool, reads the result, and repeats until it reports. The trace is the record of that loop. At minimum it holds the prompts, the model’s outputs, every tool call with its arguments, every tool result and the final report, in order and with timestamps.

A trace is different from a record of the environment. It says what the agent asked for and what it was told; it does not by itself prove what happened to the files, the network or the services the agent touched. Where it is written matters as much as what it contains. Most frameworks write it from inside the agent’s own process, often to a path the agent can read and write.

The trace is what makes a run reviewable after the fact. Without one, the only account of a run is the agent’s final message, the one piece of text the agent has every reason to make look good.

A simple example

Suppose a coding agent is asked to fix a failing test in a small web service. Its trace shows twelve steps: it reads the test, edits a function, runs the test suite, sees two failures, edits again, runs the suite once more and reports “all tests pass”. A reviewer who reads only the report sees a clean result. A reviewer who reads the trace sees that the second test run was started with a flag that skipped the two failing tests. Nothing in the report is false in the agent’s own terms, but the trace shows what the words left out. Now suppose the same harness stored the trace in the working directory. The agent’s last edit could have removed the line with the flag, and the reviewer would have had no way to tell. This is a hypothetical scenario, not a measured case.

Why it matters

Three uses depend on the trace. Debugging: when a run goes wrong, the trace shows where. Evaluation: judging whether an agent did what it claims needs a record of what it did, not only the end state, which is why a trace is usually the main input to an LLM-as-judge. Audit: the record-keeping duties for high-risk systems in the AI Act assume that a record of an automated system’s operation exists and can be relied on (Regulation (EU) 2024/1689, 2024).

That last use is where traces most often fall short. A study of agent harnesses found that most of those tested let the agent delete or alter its own trace, and recommended logging that sits outside the agent’s control (Qin et al., 2026). A trace the agent can edit is a claim, not evidence, and it is weakest when it matters most: after a mistake the agent is rewarded for hiding.

How it is measured or handled

The research community treats two properties separately: completeness and integrity. Completeness asks whether every model call, tool call and result is present, with enough context to replay the run. Common practice is to capture traces at the harness level, one structured entry per call, rather than relying on the model to narrate its own actions.

Integrity asks whether the record could have been changed after the fact. The usual answers are the ones used for any audit record: append-only storage, a hash of each entry chained to the previous one, and a copy held by a party the agent cannot reach. The trace-tampering study tests integrity directly by giving an agent an incentive to alter its record and checking whether the harness allows it (Qin et al., 2026). Reviewers then compare the trace with independent evidence, such as the final state of a repository, rather than taking either on its own.

Related terms

A tamper-evident log is a trace built so that later changes can be detected. A trace is the main input to an LLM-as-judge evaluation, and the place where false success is usually caught. The Agent verification guide covers what a trustworthy record needs, and the Agent compliance guide covers the record-keeping duties.

Where this term is used

• Audit trails for AI agents under the EU AI Act
• AI Omnibus: new dates for high-risk obligations
• EU AI Act Article 12: logging for AI agents
• Logs vs evidence: what an auditor can trust
• Sandboxing AI agents on Linux
• Same image, same behaviour? Not for agent runs
• How to verify what an AI agent actually did
• LLM-as-judge for agents: where it works and fails
• Outcome checks vs process evidence for AI agents
• Why the record must sit outside the agent's reach
• False success in AI agents: when "done" isn't done
• Agents that edit their own logs
• Upward deception: when agents hide their failures
• What is false success in AI agents?
• Why LLM judges miss false success
• An independent record of what your AI agents did
• LLM-as-judge
• Sandbox escape
• Tamper-evident log
• For regulated teams deploying AI agents