How do you identify which agent caused a failure in a multi-agent workflow?

Identify the agent responsible for a multi-agent workflow failure by tracing where the first incorrect or invalid state appeared, not simply which agent reported the final error. A reviewer might detect a problem that actually began in requirements extraction, an upstream tool, or a stale artifact.

Beginner-friendly example: API test generation

A workflow has three specialists:

• Requirements agent: Extracts the payment API's authentication rules.
• Test-generation agent: Creates test cases from the extracted requirements.
• Coverage reviewer: Checks those cases against the original specification.

The reviewer reports that OAuth authorization tests are missing. It is tempting to blame the reviewer or generator. But a comparison of intermediate artifacts reveals that the requirements agent mistakenly recorded the endpoint as requiring only an API key. The generator faithfully followed the wrong input.

Find failed acceptance check → Trace the output backward → Compare each handoff with its contract and source → Locate first divergence → Reproduce and validate cause

Numerical example

Suppose a test suite requires 20 independently verified checks, but only 16 pass.

• The reviewer identifies 4 missing authorization cases.
• The generator's input artifact contains 0 authorization requirements.
• The original source specification contains 4 authorization requirements.

This evidence points toward a requirements-extraction or input-selection failure—not necessarily a test-generation failure. The next step is to reproduce extraction with the same source version and confirm whether it omitted those requirements.

A 16/20 score tells us *how much* failed. Intermediate artifact comparison helps explain *where* the defect originated.

A practical root-cause investigation

1. Start with an objective failure: Define the violated requirement, invalid schema, missed deadline, or incorrect final result.
2. Recover the complete execution record: Use workflow and task IDs to collect agent spans, retries, artifact versions, and validation results.
3. Follow data lineage: Map which input artifact and source version each agent consumed, and what output it produced.
4. Find the earliest incorrect transition: Compare the output of each stage to its expected contract and the authoritative evidence.
5. Distinguish error types: Separate incorrect reasoning from missing context, stale inputs, bad routing, tool failure, or policy rejection.
6. Reproduce under controlled conditions: Replay the failing input with fixed versions and compare against a known-good case when possible.
7. Confirm the cause: Change the suspected factor and check whether the failure disappears without breaking other tasks.
8. Assign corrective ownership: Fix the appropriate extraction, validation, routing, or infrastructure component; record uncertainty if evidence is incomplete.

Why the last failing agent may not be responsible

Consider another example: the security agent receives a correct specification but the model API times out. That is a dependency failure. If the supervisor suppresses the error and marks the suite approved, a supervisor status-handling defect is also present.

A single incident can have several contributing causes. Distinguish the originating defect, propagation path, detection point, and missing safeguard rather than forcing every failure onto one agent.

What should you log?

Capture a compact audit trail:

• Workflow ID, task ID, agent identity, attempt number, and timestamp.
• Input artifact references and immutable versions.
• Output artifact references, schema-validation results, and quality checks.
• Model/tool version, retrieval source references, and routing decision.
• Structured error codes, retry reason, and downstream decision.

Protect tenant boundaries and sensitive requirements. Use access-controlled artifact references or redacted evidence rather than indiscriminately storing full prompts, documents, or secrets in logs.

LangGraph and Celery implementation

In LangGraph, instrument graph nodes and handoff edges with source/output artifact IDs, version metadata, and validation results. Checkpoints make execution resumable, but they must be correlated with external model/tool operations to establish a reliable history.

With Celery, link task IDs and retry attempts to the workflow ID. Separate queue failures, broker redelivery, model-provider errors, and application-level output validation failures. A task's successful process exit does not prove its semantic output was correct.

Difference from distributed tracing

Distributed tracing shows *where execution traveled and how long each operation took*. Root-cause attribution uses trace evidence alongside ground truth, contracts, versions, and controlled reproduction to explain *why* a failure happened.

In short

Trace backward from the failed outcome to the first demonstrably incorrect state, then reproduce the suspected cause. Attribute failures to evidence, including shared dependencies and missing safeguards, rather than blaming whichever agent raised the final error.