Error Propagation
PatternsDefinition
The risk in multi-agent systems where an error or incorrect output from one subagent contaminates downstream agents, amplifying the mistake. Mitigated by validating subagent outputs before passing them forward and designing subagents to return structured error types rather than silent failures.
Example Usage
Validate that the data extraction subagent returned a valid schema before passing its output to the analysis subagent.
Why It Matters for the CCA-F Exam
Error propagation questions typically present a multi-agent pipeline design and ask candidates to identify either (a) where in the pipeline contamination risk is highest, or (b) which mitigation is missing. The key insight the exam tests: validation must happen at handoff points, not just at pipeline endpoints — catching contamination early limits its blast radius.
In Depth
The Pipeline Contamination Problem
Error propagation is the mechanism by which a bad output from one agent silently becomes the input to the next, multiplying the damage across a pipeline. It is distinct from a hard failure: the subagent does not crash — it returns *something*, but that something is wrong or incomplete. Because the coordinator does not validate the output, it passes it forward, and each downstream agent builds on a corrupt foundation.
The insidious quality of error propagation is that the final output can look plausible. No exception was thrown. No error flag was set. The pipeline completed. Only when the output is scrutinized — or causes a downstream real-world error — does the contamination become visible.
Why Multi-Agent Systems Are Especially Vulnerable
In a single-agent system, errors are local. In a multi-agent pipeline, the agent's output is another agent's input. Each handoff is an opportunity for contamination to widen:
- Amplification: A data extraction agent returns 95% of records correctly and silently drops 5%. The analysis agent computes statistics on incomplete data and produces figures that appear accurate to two decimal places.
- Type confusion: A structured-output agent returns a string where a number was expected. The coordinator passes it forward; the calculation agent coerces it in an unpredictable way.
- Confidence laundering: A subagent returns low-confidence output without flagging it. The orchestrator, seeing no error signal, treats it as reliable and routes it to a high-stakes decision agent.
Mitigation Strategies
| Strategy | How It Works | When to Apply |
|---|---|---|
| Schema validation at handoff | Coordinator validates subagent JSON against expected schema before routing | Every structured-output boundary |
| Explicit error types in subagent contracts | Subagent returns {"status": "error", "error_type": "missing_required_field"} rather than partial data | Any subagent that may partially fail |
| Confidence tagging | Each claim or field carries a confidence score; coordinator refuses to forward sub-threshold values | High-stakes pipelines |
| Assertion gates | Coordinator checks invariants (e.g., record count matches input) before proceeding | Data transformation steps |
| Isolated subagent contexts | Subagents do not share state; contamination cannot flow sideways | Parallel pipeline branches |
The Structural Error Trap
One exam-critical failure mode is the silent partial return: the subagent encounters a parsing error mid-output, truncates its response, and returns valid JSON for the fields it processed. The coordinator sees valid JSON, passes schema validation, and the missing fields propagate as nulls or defaults. Defensive design adds a completion_status: "partial" | "complete" field to every subagent contract so truncation is always detectable.
See graceful-degradation for how to handle detected propagation failures, and Orchestrator Pattern for where validation gates fit in coordinator design. The concept guide Error Propagation in Multi-Agent Systems maps the full cascade taxonomy.
How It Compares
| Failure Mode | Visible to Coordinator? | Propagates? | Mitigation |
|---|---|---|---|
| Hard exception (exception raised) | Yes — exception surfaces immediately | No — pipeline halts | Standard try/catch |
| Silent partial return (valid JSON, missing fields) | No — JSON is valid | Yes — nulls flow forward | completion_status field + field-presence assertion |
| Type mismatch (string vs. number) | Sometimes — depends on downstream coercion | Yes — corrupts calculation | Schema validation at handoff |
| Confidence laundering (low-confidence unmarked) | No — no error signal | Yes — treated as reliable | Mandatory confidence tagging in contract |
| Wrong but plausible value | No | Yes — most dangerous; undetectable | Cross-agent verification or human spot-check |
Example
Validation gate applied by the coordinator before forwarding extraction output to the analysis subagent.
import jsonschema
from typing import Any
# Schema the extraction subagent must return
EXTRACTION_SCHEMA = {
"type": "object",
"required": ["records", "record_count", "completion_status"],
"properties": {
"records": {"type": "array"},
"record_count": {"type": "integer", "minimum": 0},
"completion_status": {"type": "string", "enum": ["complete", "partial"]},
"confidence": {"type": "number", "minimum": 0, "maximum": 1}
}
}
def validate_before_forward(subagent_output: Any, expected_count: int) -> dict:
"""Validation gate between extraction and analysis subagents."""
# 1. Schema check
jsonschema.validate(subagent_output, EXTRACTION_SCHEMA)
# 2. Completeness assertion
if subagent_output["record_count"] != expected_count:
raise ValueError(
f"Record count mismatch: expected {expected_count}, "
f"got {subagent_output['record_count']}"
)
# 3. Partial-return gate
if subagent_output["completion_status"] == "partial":
raise ValueError("Subagent returned partial output — escalate before forwarding")
# 4. Confidence gate (if present)
conf = subagent_output.get("confidence")
if conf is not None and conf < 0.7:
raise ValueError(f"Confidence {conf:.2f} below threshold — escalate")
return subagent_outputFrequently Asked Questions
Is error propagation only a risk in multi-agent systems, or can it happen in single-agent pipelines?
It can happen anywhere there is a chain of dependent operations, including tool-use sequences within a single agent. If a tool returns malformed data and the agent uses that data in a subsequent tool call without validating it, that is error propagation. Multi-agent systems amplify the risk because each subagent boundary is an opportunity for contamination to hide inside a structurally valid response.
How do you design a subagent contract to prevent silent partial returns?
Every subagent that processes variable-length input should include a `completion_status` field (`complete` or `partial`) and a count of items processed versus items expected. This makes truncation visible at the contract level rather than requiring the coordinator to infer it from missing data. Combine this with a `confidence` score and explicit `error_type` field for cases where the subagent encountered but recovered from a parsing issue. See [Structured Error Response Design](/glossary/error-response-design) for the full contract pattern.