An orchestrator dispatches five subagents to process five independent modules of a codebase in parallel. Four subagents complete within 10 minutes and report results. The fifth subagent stalls due to an internal deadlock but never reports failure — it remains running indefinitely. The orchestrator waits indefinitely for the fifth result, blocking the entire workflow from completing. What mechanism was missing?
Select an answer to reveal the explanation.
Short Explanation and Infographic
An orchestrator that waits forever for a subagent is like a manager sitting outside a meeting room that went silent an hour ago, still waiting politely for someone to come out. Heartbeats change the dynamic: if no signal arrives in N seconds, the orchestrator assumes the worst, marks the subagent as failed, and triggers recovery — rather than waiting forever.
Full explanation below image
Full Explanation
Stall detection via heartbeat and timeout is the standard pattern for making orchestrated multi-agent workflows resilient to subagent failures that don't surface as explicit errors. A deadlocked or indefinitely-blocked process does not raise an exception — it simply stops making progress while remaining alive. Without a detection mechanism, the orchestrator cannot distinguish a slow subagent from a stalled one.
The heartbeat pattern works as follows: - Each subagent emits a 'still-alive' signal (heartbeat) at regular intervals (e.g., every 30 seconds) - The orchestrator tracks the last heartbeat timestamp for each subagent - If a subagent's heartbeat is not received within a timeout window (e.g., 2 minutes), the orchestrator declares it stalled - The orchestrator invokes a recovery action: kill the stalled subagent, re-queue the task, assign it to a new subagent, or escalate to a human
This ensures that a stalled subagent causes a bounded delay, not an infinite block.
Option A (larger compute allocation) addresses resource contention, not logical deadlocks. A deadlock caused by two processes waiting on each other's locks will not resolve with more CPU or memory.
Option C (sequential processing) eliminates the stall-blocking problem by removing parallelism, but at the cost of all efficiency gains from parallel execution. Sacrificing throughput to avoid a resolvable coordination problem is the wrong trade-off.
Option D (give the fifth subagent a different task) is not a generalizable solution — any subagent could deadlock, and pre-emptively avoiding specific tasks based on suspected deadlock likelihood is not feasible at scale.