How do you handle timeouts between communicating agents?

A timeout between communicating agents occurs when a requesting agent does not receive an expected response before a defined deadline. It helps workflows avoid waiting forever, but a timeout does not prove that the receiving agent failed or stopped working.

Beginner-friendly numerical example

An API test-generation supervisor asks a security agent to produce authentication test cases.

• Request sent: 10:00:00
• Response timeout: 20 seconds
• Deadline: 10:00:20
• Actual security-agent completion: 10:00:25

At 10:00:20, the supervisor marks the request timed out. The security agent might still finish five seconds later. If the supervisor blindly resends the work to another agent, both agents could publish duplicate suites.

A safe process is:

Send request with ID → Wait until deadline → Check status → Retry, cancel, reassign, or escalate → Reconcile late responses

Which timeouts matter?

• Connection timeout: Maximum time allowed to establish a connection to another service.
• Response timeout: Maximum time waiting for a response after sending the request.
• Queue-wait timeout: Maximum time a task may remain queued before it becomes stale.
• End-to-end deadline: Total time available for the full task, including retries and handoffs.

These timers protect different stages. A 10-second request timeout repeated five times can still exceed a 30-second user deadline unless retries share one overall time budget.

How do you handle a timeout safely?

1. Attach a correlation ID: Identify the exact request, originating run, target agent, and attempt.
2. Set realistic deadlines: Use measured latency distributions and the task's remaining time budget.
3. Record an uncertain outcome: Distinguish a timeout from an explicit failure response.
4. Query task status when possible: Check whether the receiving agent is running, completed, or failed.
5. Retry only when safe: Use bounded attempts, backoff, and the same logical operation ID.
6. Handle late replies: Ignore stale results or reconcile them against current task state; do not let them overwrite a newer accepted result.
7. Escalate or fail clearly: Report incomplete work when no safe completion path remains.

Example retry budget

Suppose the full workflow has 30 seconds remaining. A request times out after 10 seconds. Retrying for another 10 seconds after a 2-second delay would consume 22 seconds total, leaving only 8 seconds for final validation. The orchestrator should consider whether that is sufficient before retrying.

LangGraph and Celery considerations

In LangGraph, store request IDs, deadlines, and status in workflow state and route timed-out operations through an explicit recovery branch. Persistent checkpoints help preserve that decision across restarts.

In Celery, broker delivery, worker execution limits, acknowledgment behavior, and task-result waiting are separate concerns. Calling get(timeout=...) limits how long the caller waits; it does not necessarily terminate the task on the worker. Celery soft or hard time limits have different effects and must be configured with care.

For remote tool calls, configure network timeouts independently of Celery task limits. Never assume cancelling a request rolls back an API call or database write already performed by another agent.

In short

Treat inter-agent timeouts as uncertain outcomes, enforce end-to-end deadlines, and reconcile task state before retrying or switching agents. This keeps multi-agent workflows responsive without creating duplicate work or false success reports.