State Management and Agent Handoffs

Why state and handoffs matter in multi-agent systems

Here's the thing, when you run a single-agent workflow, all the context lives in one place. But the moment you split a task between a planner and an executor, or across multiple specialists, you need shared state that persists and structured handoffs that don't lose information. From what I've seen in production, this is where most multi-agent systems break.

Research from Harrison Chase's LangGraph team shows that 93% of multi-agent failures manifest at the edge, the handoff between agents. Data gaps, referential drift, signal corruption, and capability mismatches all happen when one agent passes work to another without validation. Without durable state, a server restart or pod eviction wipes your entire workflow context and you start from scratch.

The good news? Modern frameworks like LangGraph now provide persistent checkpointing and typed state schemas that make this manageable. You're no longer juggling ephemeral memory and hoping nothing crashes mid-workflow.

Check your understanding

Match each handoff failure mode to its definition:

Persistent state with checkpointing

Before LangGraph 1.0, state was ephemeral, if your workflow crashed mid-execution, you lost everything. Modern multi-agent systems use durable execution with automatic checkpointing so workflows survive restarts, network timeouts, and pod evictions without losing context.

In practice, you define your state as a TypedDict schema, something like {'plan': list[str], 'current_step': int, 'results': dict}, and the framework writes snapshots to persistent storage (PostgresSaver, AsyncSqliteSaver, or equivalent) after every state transition. If an executor agent finishes a subtask and the system crashes before the planner gets the result, the checkpoint lets you resume exactly where you left off.

The key insight: state isn't just memory, it's the contract between agents. Both planner and executor read from and write to the same typed structure. LangGraph's DeltaChannel even supports incremental updates so agents can append results without rewriting the entire state object every time.

State is the contract, not just memory

Structured handoff protocols

A handoff is more than just passing data, it's a structured transition where one agent explicitly signals completion and the next agent acknowledges receipt. In LangGraph, this often looks like an edge with a conditional function that validates the state before the transition. If the planner writes {'next_agent': 'executor', 'task': 'query_database'}, the orchestration layer checks that the executor has the query_database tool before routing.

From what I've observed, the most robust patterns include explicit handoff declarations in the state schema. Instead of implicit routing based on heuristics, the planner writes 'handoff_to': 'executor_billing' and the framework enforces that only valid transitions are allowed. Andrew Ng's design patterns emphasize this separation: the planner reasons about what to do next, and the handoff protocol ensures the right agent gets the right context.

When diagnostics reveal an unexpected root cause, like a database issue instead of a deployment problem, the planner can trigger replanning by writing a new plan to state. The executor picks up the updated instructions on the next cycle. This dynamic replanning is what makes multi-agent systems resilient to surprises.

Check your understanding

You're building a planner-executor system where the planner sometimes assigns tasks that require tools the executor doesn't have. What's the most effective place to catch this mismatch?

Error handling and retry logic

Not all failures are worth retrying. Exponential backoff works beautifully for transient errors, rate limits, network timeouts, server 500s, but retrying an authentication failure or a bad request just wastes time and money. The pattern: retry on 429 (rate limit), 503 (service unavailable), and network errors; don't retry on 400 (bad request), 401 (auth failure), or context overflow.

For duplicate prevention, use idempotency tokens, a hash of run_id + step_id, so if Agent A times out waiting for Agent B's payment processing and retries, the payment API deduplicates and doesn't double-charge. This is especially critical in financial workflows where retries are common but side effects must happen exactly once.

When a dependency is actually down, implement a circuit breaker: after N consecutive failures, stop retrying for a cooldown period and route the task to an alternative agent or escalate to human review. Production systems report a 15× token cost multiplier when coordination overhead isn't managed, you can't afford to retry indefinitely.

Don't retry everything

Check your understanding

Key takeaways

• 93% of multi-agent failures happen at handoffs, data gaps, referential drift, signal corruption, and capability mismatches all manifest at the edge between agents.
• Persistent state with checkpointing (TypedDict schemas + PostgresSaver or AsyncSqliteSaver) lets workflows survive restarts and pod evictions without losing context.
• Structured handoff protocols with edge-level validation catch capability mismatches before they waste tokens and create downstream failures.
• Only retry transient errors (rate limits, network timeouts); use idempotency tokens to prevent duplicate side effects and circuit breakers when dependencies are down.
• Executor agents should receive planner-generated instructions only, not the original global task, to reduce reasoning complexity and keep context windows clean.

Your product check-in

Apply “State Management and Agent Handoffs” to a product or workflow you know. What would you try, what could go wrong, and what evidence would help you decide?