I expected a multi-agent production pipeline to have one obvious efficiency story: divide work, finish sooner, spend less. One observed episode broke that story. It reached its first complete review candidate in 6:09:31, compared with 13:56 for an earlier preserved case. At the same time, total input including cached input rose from 197,682,422 to 246,251,458, and uncached input rose from 5,406,198 to 5,674,946.
That is a 55.8% shorter elapsed path to the first candidate, alongside 24.6% more total input and 5.0% more uncached input. These are token counts, not currency or a bill estimate. The episodes also had different subject matter and development work, so this is an operational comparison, not a controlled causal experiment. But it was enough to retire the convenient claim that parallelism had made the work cheaper.
The first candidate arrived sooner. The logs do not isolate how much of that difference came from overlap among production, diagnosis, review, and implementation work. The successor candidate, after feedback, still arrived in 9:53:46, 29.0% faster than the older case.
The second clock was less flattering. By the successor endpoint, total input including cached input was 387,745,989 and uncached input 10,635,589: 96.1% and 96.7% above the comparison case. Output also rose. The system reached a review candidate sooner without reducing the work measured across all paths.
That distinction matters outside AI agents. A build farm can improve time to a green artifact while spending more compute. A larger incident rotation can reduce customer wait time while creating more handoffs. Neither result is automatically bad. They answer different questions. The mistake is naming one of them “efficiency” and allowing it to stand in for both.
The later endpoint recorded 37 routes: 22 production routes, 15 development routes, and 17 blocked terminal events. Seven owners avoided simultaneous writes, but that protection did not prevent a single episode from being repeatedly divided, re-briefed, and resumed. Each blocked path created a fresh diagnosis, a new brief, and context transfer to another participant.
It would be too strong to say that parallelism caused the increase. The observation contains confounders: pipeline defects were fixed during production, an external consultation timed out, and the comparison episode was not the same job. What it does support is a more useful hypothesis: route fragmentation, blocked-path recovery, and long-lived coordinator context are candidate costs worth measuring separately.
The stage ledger added another warning. It recorded 1,327.702 seconds of active stage time, about 3.7% of the successor wall time. That is ledger coverage, not the process's true active percentage: model inference, qualification, external consultation, coordination, and waiting were outside that ledger. A partial ledger cannot settle where the rest of the time went; it can only show that the ledger is not yet an accounting system for the whole workflow.
The remediation did not try to outlaw agents or make every task serial. It made a small set of limits explicit: one logical episode job, at most two production stages, one development batch, two blocked terminations, two full renders, and no compaction for the target path. It also records session usage deltas at attach and finish instead of assuming a route's nominal model represents its cost.
Those are not universal thresholds. They are an experiment design. A route that crosses its limit should trigger a scope decision or a batched development fix, instead of quietly becoming another re-briefing cycle. More importantly, the metric must join the cost of the work with the work that made it necessary. Render-only timing, or an account-wide utilization percentage, cannot do that.
The next newly produced episode is the immediate qualification. The improvement claim fails if it misses a 90-minute first-review wall time, 1,621,859 uncached-input cap, 198,609 output cap, one job, at most two production stages, one development batch, two blocked terminations, two full renders, or zero compactions. Repeating that measurement on later episodes is necessary before treating one qualification as a stable improvement. Passing supports this particular control-plane design, not a general proof that AI agent systems are cheaper.
The useful dashboard therefore has at least two lines: time to a reviewable result, and total work consumed to get there. When those lines move in opposite directions, do not average them into a success story. Decide which trade-off the product can actually afford, then make the handoffs observable enough to change it.
Measure wall time, uncached input, output, route count, blocked terminations, and context compactions. These describe different operational costs.
No. Different jobs can have different development work, and token counts are not currency. A shorter elapsed path can coexist with more total work.
Trigger a scope decision or batch a development fix instead of creating another unbounded re-briefing cycle.