How do you handle unavailable agents in a multi-agent system?

When an agent is unavailable, the multi-agent orchestrator should detect the problem, preserve the task, and choose a safe alternative: wait, retry, reassign, degrade gracefully, or escalate. Unavailability is not the same as an incorrect answer; it means the specialist cannot currently accept or complete the work.

Beginner-friendly example: API test generation

Suppose a supervisor delegates authorization-test generation to a security specialist. The registry shows the specialist as healthy, but its worker becomes unreachable before returning a result.

A safe sequence is:

Dispatch task → Detect timeout → Check task status → Find eligible replacement → Reassign or wait → Validate final output

The system does not immediately assume the original attempt did nothing. A timeout might occur after the worker wrote test cases but before its acknowledgment arrived.

Imagine a task must finish within 60 seconds. The first specialist is unreachable after 15 seconds. A second qualified agent is available and estimated to need 20 seconds. The orchestrator can reassign the task if the previous operation is reconciled, the replacement has the necessary permissions, and enough time remains. Otherwise it should report a blocked or partial result.

How do you detect unavailability?

• Health checks and heartbeats: Identify workers that have stopped responding.
• Request timeouts: Avoid waiting indefinitely for a response.
• Queue and capacity signals: Distinguish an overloaded agent from one that is offline.
• Registry freshness: Treat stale availability metadata as uncertain.
• Execution status: Inspect the task or workflow record before claiming failure.

A health check is only a signal; an apparently healthy agent may still fail on a particular task.

What recovery options are available?

1. Short, bounded retry: Useful for transient network failures when replay is safe.
2. Wait or queue: Appropriate when a required specialist is temporarily busy.
3. Fallback agent: Select another capable, authorized specialist with compatible contracts.
4. Partial completion: Continue independent branches and mark missing work explicitly.
5. Human escalation or termination: Necessary when no safe alternative exists or a deadline is exceeded.

Do not route sensitive data to a less-trusted agent merely to keep the workflow moving.

Preventing duplicate execution

Store a stable task or operation ID, record dispatch attempts, and use leases or atomic task claims when multiple workers may compete. Before reassigning, check whether the original worker already completed external side effects. Make writes idempotent where possible.

Be careful: a lease expiring does not prove the original worker stopped. Fencing tokens or downstream checks may be required for operations that cannot safely run concurrently.

LangGraph and Celery considerations

In LangGraph, a routing or recovery node can inspect structured failures and choose a permitted fallback. With Celery, task timeouts, worker loss, redelivery, and retries have distinct behavior depending on broker and task configuration. Coordinate the task's execution status with the graph's checkpointed state instead of treating a missing response as definitive failure.

Monitor fallback rate, time to recovery, queue delays, and deadline misses to see whether the system is robust or simply masking capacity problems.

In short

Reliable multi-agent systems treat unavailable agents as a recoverable coordination problem when safe, while preserving task identity, permissions, and truthful completion status.