3 posts tagged with "agent-orchestration"

A planner agent receives a task, decomposes it, and spawns a researcher subagent to handle one of the branches. The orchestration framework propagates the parent's full context to the child because that is the easiest default to ship. The researcher now holds the planner's complete system prompt — the policy text, the names of internal tools, the credentials the parent was scoped to use, the few-shot examples that hint at how your billing pipeline is structured. The researcher's job was to read three documents. The blast radius of the call is the entire authority of the parent.

This is not a hypothetical. It is the default behavior of most multi-agent frameworks shipping in production today. A recent audit found that 93% of agentic projects use unscoped API keys, and that when one agent calls another, the child agent either inherits the parent's full credentials or receives its own independent key — with no project implementing scope narrowing, depth limits, or cascade revocation for delegated access. The framework treats "share parent state" as a convenience and "scope down the child" as opt-in. The opt-in step is the one nobody writes.

Your planner agent passes its eval suite at 94%. Your researcher agent scores even higher. Your synthesizer agent nails every benchmark you throw at it. You compose them into a pipeline, deploy to production, and watch it produce confidently wrong answers that no individual agent would ever generate on its own.

This is the composition testing gap — the systematic blind spot where individually validated agents fail in ways that no single-agent analysis can predict. Research on multi-agent LLM systems shows that 67% of production failures stem from inter-agent interactions rather than individual agent defects. You're testing the atoms but shipping the molecule, and molecular behavior is not the sum of atomic properties.

Most multi-agent systems start as a chain. Agent A calls Agent B, B calls C, C calls D. It works fine in demos, and it works fine with five agents on toy tasks. Then you add a sixth agent, a seventh, and the pipeline that once ran in eight seconds starts taking forty. You add a retry on step three, and now failures on step three silently cascade into corrupted state at step six. You try to add a parallel branch and discover your framework was never designed for that.

The problem is not the number of agents. The problem is the execution model. Linear chains serialize inherently parallel work, propagate failures in only one direction, and make partial recovery structurally impossible. The fix is not adding more infrastructure on top — it is rebuilding the execution model around a directed acyclic graph from the start.