Detailed Analysis
A Reddit post from a Claude Code practitioner running multi-agent workflows against Azure AI Foundry models offers a granular, practitioner-level case study in the limits of agentic orchestration. The author built a nine-stage "intelligence brief" pipeline—scouts, curator, writer, editor, multi-model review gate, renderer, and QA—using a fleet of 22 parallel agents. Two consecutive full runs burned through nearly 3 million subagent tokens and multiple hours of wall-clock time before both failed. The failure pattern was not random: it consistently occurred at steps requiring an LLM to produce a large, uniform, mechanical artifact (merging 117 items into JSON, deduplicating entries, formatting hundreds of records) rather than steps requiring genuine reasoning or judgment. Once those specific stages were replaced with roughly 200 lines of deterministic Python, the pipeline completed end to end without further failures.
The finding matters because it cuts against a common assumption in the current wave of agentic AI enthusiasm: that adding more agents, more parallelism, and more model-driven steps uniformly improves pipeline capability. Instead, this case suggests a much more specific division of labor. LLM agents excelled at tasks requiring interpretation, creativity, and adversarial scrutiny—nine parallel authors successfully implemented pipeline components from a written spec, and adversarial reviewer agents caught real defects, including a bug that would have leaked a secret into logs. But agents performed poorly, and expensively, on bulk, repetitive, structurally uniform work where there was "no real decision to make." This is consistent with a broader engineering principle long understood in traditional software design—use the right tool for the job—now being rediscovered in the context of LLM-based orchestration, where the temptation is to route everything through a model simply because the model *can* do it.
The architectural conclusions drawn—treating stage boundaries as files on disk, using exit codes as gates, and never letting an agent validate its own output—reflect a maturing discipline around agentic system design that mirrors classic distributed-systems and pipeline-engineering practices. Rather than anthropomorphizing every step of a workflow, the author advocates a hybrid model: deterministic scripts for bulk, mechanical transformation; LLM agents reserved for judgment-heavy tasks like implementation-from-spec and adversarial review; and multi-agent orchestration scoped narrowly to where it demonstrably adds value rather than applied uniformly across an entire pipeline. This "shrinking scope" of agentic involvement is a notable data point in the ongoing industry conversation about agentic reliability, cost, and failure modes—particularly relevant as tools like Claude Code, Anthropic's coding-agent platform, are increasingly used not just for single-shot code generation but for orchestrating complex, multi-stage, multi-agent production systems.
This kind of empirical, cost-and-failure-driven post-mortem is emblematic of a broader trend in the AI development community: practitioners moving past benchmark-driven hype toward pragmatic, token-cost-aware engineering discipline. As agentic frameworks proliferate and organizations experiment with increasingly elaborate multi-agent architectures (scouts, curators, reviewers, QA gates, and so on), stories like this serve as a counterweight, emphasizing that agent orchestration is not free—it carries real token costs, latency risk, and failure modes tied to task structure. The implicit lesson for the Claude Code ecosystem and similar agentic tooling is that reliability and efficiency gains will likely come not from maximizing the number of agents in a pipeline, but from carefully identifying which subtasks genuinely benefit from model-based reasoning versus which are better served by conventional, deterministic code—a distinction that is likely to become a standard design heuristic as agentic systems move from novelty demonstrations into production-grade reliability.
Read original article →