Blog · Guide · 28 October 2026
A traceability checklist for AI agents in production: what to log, what to sign, what to show the reviewer
Disclosure: 100monkeys.ai builds AEGIS, an open-source agent orchestrator, and maintains the awesome-agent-traceability list cited below. This checklist is vendor-neutral: every item can be met with open tools, and none requires our products. It was drafted by one of our AI agents and reviewed by the company.
When an AI agent acts on a real system, someone will later ask what it did and why. This checklist is the work to do before that question arrives: what to log on every run, what to sign so the log can be trusted, and what to put in front of the person who reviews it. Each item names an open standard or tool from the awesome-agent-traceability list.
The frame comes from our paper Red levers: traceable, deterministic agents in production, which defines an agent system as safe in production when a person can see every decision it made, why it made it, and stop it. Logging serves the first, the recorded reason serves the second, and the review step serves the third.
Part 1. What to log
Step 1. Give every run an identity
Assign each run an id at the start and carry it through every model call, tool call and side effect. Without it, a log is a pile of events nobody can group. Use trace and span ids from the OpenTelemetry semantic conventions for generative AI, which define shared names for model calls, agent steps and tool invocations, so traces from different frameworks read the same way. The conventions for agent spans cover creating and invoking agents.
Step 2. Record the request and the intent, in words
Log what the agent was asked, by whom, and the reason it was given. Then, at every consequential act, log the agent's own one-line statement of why. A reason written at the moment of the act is evidence; a reason reconstructed afterwards is a story.
Step 3. Record the model and its settings
For each model call: provider, model name and version, the parameters that change output (temperature, maximum tokens, tools offered) and token counts. A behaviour you cannot tie to a model version cannot be reproduced after the provider updates it.
Step 4. Record every tool call with its inputs and outputs
Name the tool, the arguments, the result, and the time. Redact personal data before storage rather than after; Presidio is one open option. A tool call that wrote somewhere should also record what it changed: the diff, the record id, the message id.
Step 5. Record each policy decision
If a policy engine allowed or refused a call, log the decision and the rule that made it. Open Policy Agent keeps decision logs for exactly this. A refusal is as important to keep as an allow: it shows the limit held.
Step 6. Record identity and reach
Log which credential or token the run used and what that credential could reach, not its secret value. The reviewer's question is often "could it have done worse", and the answer is the scope it held.
Step 7. Make the run replayable
Store enough to re-run the work: inputs, the state at each step, and the order of events. Durable execution engines such as Temporal keep a workflow event history that lets a workflow be replayed deterministically.
Part 2. What to sign
Step 8. Make the log append-only and chained
A record that can be rewritten after the fact proves nothing. Write events to an append-only store and chain each entry to the one before it by hash, so a removed or edited entry breaks the chain. The IETF SCITT working group defines signed statements registered in append-only transparency services, a ready-made shape for this.
Step 9. Sign what the agent produced
When a run produces an artifact (a build, a report, a released file), attach a signed statement of how it was made. The in-toto Attestation Framework carries such statements, and SLSA defines levels of build provenance. For media, the C2PA specification attaches signed provenance manifests, including for content produced or edited by AI.
Step 10. Sign the approval
If a person approved an act, record who approved it, when, and exactly what they saw. Bind the approval to the content: if the act changes after the approval, the approval no longer counts.
Part 3. What to show the reviewer
Step 11. Show the act, not a summary
The reviewer should see the email, the diff or the command that will run, rendered from the run's own output. A summary written by the same model that wants approval is not a review surface.
Step 12. Show the reason beside the act
Put the agent's recorded intent next to the change it made. "Why is this line here" should be answered by the sentence written when the line landed.
Step 13. Show the limits it ran under
Show the policy and credential scope next to the run. A reviewer who sees that the agent could only write to one branch reads the run differently from one who has to assume it could reach everything.
Step 14. Give the reviewer a stop
Every review screen needs a way to refuse, and the refusal must hold. Article 14 of the EU AI Act, as quoted in Red levers, asks that people overseeing high-risk systems can "intervene in the operation of the high-risk AI system or interrupt the system". Citing it here is about the shape of the control, not a claim of compliance.
Checking yourself
Pick one run from last week and try to answer, from records alone: who asked, what the agent called, what it changed, under which policy, who approved, and whether the record could have been edited since. Each question you cannot answer maps to a step above.
How we apply it
We build tools for parts of this list. AEGIS by 100monkeys.ai, in beta, is a self-hosted orchestrator that runs agents in isolated, policy-enforced runtimes with durable state; How to give an orchestrator an approval step shows its approval gate as a worked example, and this install guide gets it running on a server. Carbon Forge keeps code and prose in one record where blame shows the intent written at landing.