Attributing Failures in Orchestrator-Workers Systems

When the failure has no single obvious location

A single-call failure has one place to look. An orchestrator-workers system, where an orchestrator decomposes a task, dispatches subagents, and synthesizes their results, spreads the failure surface across many components and the boundaries between them. The symptom often appears at synthesis, but the cause can be anywhere upstream, and the traces that would tell you are fragmented across agents. This analyse-level knowledge point is about attributing a multi-agent failure to its true root cause by tracing across the boundaries rather than blaming the place the symptom surfaced.

Blurred boundaries and fragmented traces

The defining difficulty is that the failure boundaries blur. When the orchestrator and its subagents each do part of the work, it is not always clear which component owns a given failure: an incomplete result could be an orchestrator that planned the decomposition wrong, a subagent that did its slice badly, or a handoff that lost information between them. And the evidence is scattered, each agent logs its own activity, so the trace of a single end-to-end request fragments into disconnected pieces unless something ties them together. Diagnosis in this setting is inherently about crossing boundaries, not inspecting a single call.

The silent drop at synthesis

The most treacherous multi-agent failure is a subagent that drops or fails silently and is not noticed at synthesis. If the synthesis step simply combines whatever results it received, a missing subagent contribution produces a result that looks complete, coherent and confident, while quietly missing coverage. Nothing errored; a piece of the work just never arrived, and the synthesis stitched together the pieces that did.

The guard against this is reconciliation: the synthesis step must check the results it received against the coverage it expected, results should equal the units of work submitted, and flag the gap when they do not. Without that reconciliation, a dropped subagent is invisible, and the coverage failure surfaces only later, in production, as an answer that was subtly incomplete. Crucially, the gap that appears at synthesis usually did not originate there, so treating synthesis as the culprit misattributes the failure.

Recoverable vs unrecoverable, and the shared trace ID

Attribution also requires classifying the failure's severity relative to where it can be handled. A recoverable subagent failure, a transient timeout, a rate limit, a retryable error, can and should be handled locally: the subagent retries or flags, and the failure never needs to reach the orchestrator. An unrecoverable failure, one the subagent cannot resolve on its own, must propagate up to the orchestrator so it can decide how to proceed rather than pretending the work completed. Getting this classification right is what prevents both extremes: silently swallowing a fatal failure, and needlessly escalating a transient one that local recovery would have absorbed.

Underpinning all of this is a shared trace ID carried across every agent. Because traces fragment, the only way to reconstruct the path of a single request from orchestrator through each subagent and back to synthesis is a common identifier that stitches the fragments into one story. Without it, you cannot follow a synthesis-stage symptom back to the subagent or orchestrator decision that actually caused it.

What the exam trips candidates on

The first trap is assuming a synthesis-stage gap in coverage always originates at the synthesis agent, rather than tracing back through the subagent and orchestrator boundaries. A scenario will show incomplete output at synthesis and blame the synthesizer; the credited reading traces the gap upstream, often to a silently dropped subagent or an orchestrator decomposition error, and adds reconciliation plus a shared trace ID.

The second trap is treating every subagent failure as something that must propagate to the orchestrator, instead of allowing local recovery for transient, recoverable failures. A scenario will escalate a retryable timeout all the way up; the correct answer distinguishes recoverable failures (handled locally by retry or flag) from unrecoverable ones (which must propagate), and applies the right level to each.

Common misreadings to avoid

How this shows up on the exam

Domain 4 questions on this knowledge point present a multi-agent system with a coverage or synthesis gap and ask you to attribute it. The reliable approach traces the symptom back across the orchestrator-subagent boundaries rather than blaming where it appeared, adds reconciliation to catch silent drops, classifies failures as recoverable or unrecoverable, and relies on a shared trace ID.

This is the multi-agent class from the core failure taxonomy, distinct from the single-call classes in prompt failure vs hallucination. The shared trace ID and coverage reconciliation depend on logging the four categories, the recoverable-versus-unrecoverable distinction connects to layered reliability controls, and multi-agent attribution feeds forward into change attribution when a monitored metric moves.