Error Handling and Retry Logic Between Agents

Why Multi-Agent Systems Need Different Error Handling

Here's the thing, when a single agent fails, you retry the call. When a multi-agent system fails, you need to figure out which agent failed, whether the failure is transient, and whether the downstream agents can still proceed. From what I've seen in production, 93% of multi-agent failures happen at the handoff between agents, not inside them.

The failure modes are specific: data gaps (29% of cases, the planner didn't pass enough context), referential drift (27%, executor misinterprets what "the user" or "the order" refers to), signal corruption (37%, the output schema wasn't followed), and capability mismatches (7%, planner asked an executor to do something it can't). Retries alone won't fix these, you need validation at every edge.

The pattern that works: classify errors by transience, implement retries with exponential backoff for recoverable failures, and use circuit breakers or re-routing for persistent dependency issues. Think of it as defensive handoff design. You're not just catching exceptions; you're building in the assumption that agents will misunderstand each other, that APIs will flake, and that state will occasionally get weird.

Check your understanding

Your travel booking planner hands off a hotel search to an executor, which returns "No results found." The planner retries three times, getting the same response, then logs an error. What's the most likely root cause?

Transient vs. Persistent Failures: When to Retry and When to Reroute

Not all failures should trigger a retry. Transient failures, rate limits, network timeouts, 503 server errors, benefit from exponential backoff (sleep 1s, then 2s, then 4s, then 8s). Persistent failures, 401 authentication errors, 400 bad requests, context overflow, or a downstream dependency that's actually down, won't resolve with retries. You're just burning tokens and time.

The rule I use: retry on 429 (rate limit), 500/503 (server errors), and network timeouts. Don't retry on 400, 401, 404, or when the agent explicitly returns "I can't do this." When a dependency is down (e.g., the payment API returns 500 three times in a row), that's when you need a circuit breaker, temporarily mark it as unavailable and reroute the task to a fallback or escalate to a human.

In the payment processing example from the research bundle, Agent A times out waiting for Agent B's payment response and retries. But Agent B already processed the payment, it just responded slowly due to API latency. The fix? Idempotency tokens. Agent A includes a unique hash (like run_id + step_id) with every payment request, so Agent B can detect duplicates and return "already processed" instead of double-charging.

Don't Retry Your Way Out of Bad Architecture

Check your understanding

Validation at Handoff: Catching Errors Before They Propagate

Let's get real, most multi-agent failures don't happen because an agent crashed. They happen because one agent passes garbage to the next, and the next agent tries to make sense of it. The planner says "book the hotel," but doesn't say which one. The executor returns a list when the planner expected a single object. The downstream agent interprets "the user" as the wrong person.

The fix is edge-level validation, structured schemas at every handoff that both sides agree on. In LangGraph and modern frameworks, you use TypedDict or Pydantic models to define what each agent expects and produces. The planner validates its own output before sending it; the executor validates the input before acting. If validation fails, you raise an error immediately instead of letting the corruption cascade three agents down the chain.

Harrison Chase's LangGraph team built this into the framework with typed state and checkpointing. When an executor receives a handoff message, it can access only the fields explicitly passed in the typed state, not the entire conversation history. This reduces referential drift, the executor can't accidentally reference something from ten messages ago that the planner didn't intend to share. Limiting scope keeps context windows clean and reasoning simpler.

93% of Failures Happen at the Edge

Check your understanding

You're building a customer support planner-executor system. The planner identifies that a user needs billing info and troubleshooting, then hands off to two executor agents. What specific validation steps should you implement at the handoff to prevent the most common failure modes?

Replanning and Task Re-Routing When Plans Fail

Even with perfect handoffs and smart retries, sometimes the plan itself is wrong. The user asked for a flight to Paris, but there are no direct flights, do you fail, or do you replan with a layover? The diagnostics executor discovers the issue isn't a deployment problem, it's a database corruption, do you keep executing the original incident response plan, or pivot?

This is where replanning loops come in. In the SRE incident response example from the research bundle, the manager agent creates an initial diagnostic plan, dispatches executor agents, and when their findings contradict the initial assumptions, the manager dynamically refines the plan and dispatches a new round of tasks. The key is continuous progress reporting, executors signal not just "done" or "failed," but "done, and here's what I learned that might invalidate your assumptions."

The implementation pattern: the planner monitors executor status (via state checkpoints or event streams). When an executor returns an unexpected result or signals a capability gap, the planner has three options: (1) re-route the subtask to a different executor, (2) decompose the subtask further, or (3) escalate to a human. The worst move is to blindly continue executing a plan that no longer makes sense. Shunyu Yao's ReAct work showed that reasoning loops, where agents reflect on outcomes and adjust, dramatically outperform fixed execution sequences.

Start Simple, Add Replanning When You See the Pattern

Key takeaways

• 93% of multi-agent failures happen at handoffs through data gaps, referential drift, signal corruption, and capability mismatches, validate at every edge.
• Retry only on transient failures (rate limits, timeouts, 500/503 errors); don't retry authentication, bad requests, or persistent dependency outages.
• Use idempotency tokens (hash of run_id + step_id) to prevent duplicate operations when retries cause the same request to be processed twice.
• Implement typed schemas at handoffs so both planner and executor agree on what's expected and produced, catching corruption before it propagates.
• When executor results invalidate the planner's assumptions, trigger replanning or re-routing instead of blindly continuing a broken plan.

Your product check-in

Apply “Error Handling and Retry Logic Between Agents” to a product or workflow you know. What would you try, what could go wrong, and what evidence would help you decide?