Lay out a code audit across 24 services as subagents, one serial run or a mix, with the brief, the return schema and the token count.
designmediumExercise · 3 min · 64 of 77
On this page
An audit across many services looks like the textbook case for subagents until one shared library turns independent reads into dependent ones. The design has to find that dependency before it splits the work.
A security review is in 30 hours. The platform team must show that no service logs a full card number: every handler that touches card data must mask the number before any log call. There are 24 services, each with about 30k tokens of relevant code: handlers, logging setup and the payment client. Six of them log through a shared wrapper library, auditlog, about 10k tokens, which is supposed to do the masking for them; nobody has checked that it does. The reviewers want, per service, a verdict, the files read, and each violation with file, line and the offending code.
Assume a 200k-token window, P_in = $3 and P_out = $15 per million tokens, and that an agent reading 30k tokens of code over its own turns consumes about 80k input tokens and writes about 2k.
Serial in one context fails on size: 24 × 30k = 720k, more than three windows, and early findings would be compacted under no schema.
The reads are independent except for auditlog, on which six verdicts depend. So two waves, orchestrated by code:
A code step confirms from imports which six services use auditlog. One subagent audits the wrapper and returns whether it masks, quoting the masking function.
24 subagents in parallel, one per service. The six wrapper users get the wave-1 verdict in their brief.
The brief, about 700 tokens: the rule in one sentence, the service's exact paths, what counts as a violation (a log call whose arguments can carry an unmasked card number), read-only tools, and the return schema:
Capped at 600 tokens, validated on return, retried once if malformed. not_read keeps "no violation" apart from "not checked".
Tokens: 25 subagents × 80k = 2M input and 50k output, about $6 + $0.75. Code merges the 24 objects, and one call over 24 × 600 ≈ 14k tokens writes the summary. Two waves of a few minutes each leave most of the 30 hours for a person to confirm every reported violation and spot-check two passes.
What would change it: card numbers flowing between services. If service A hands a raw number to service B, which logs it, no per-service read sees the path, and the design needs a third step over the cross-service call graph. And if the wrapper masks only some fields, the six briefs must name the gap exactly.
"One agent, service by service, compacting as it goes." It fits only by summarising early findings with no schema, so a violation found in service 3 can be gone by service 20, and 24 services in series spend hours of a fixed deadline.
"24 subagents in parallel with one brief." It treats the six wrapper users as independent, so each either audits auditlog itself, six times with possibly six answers, or assumes it masks. The shared dependency is the point of the exercise, and this answer never finds it.
"Each subagent returns a summary paragraph." Twenty-four paragraphs in different shapes cannot be merged by code, and "no issues found" cannot be told apart from "never opened the logging config".
