An orchestrator agent triggered a subagent 45 minutes ago to refactor a complex service module. The subagent's assigned GitHub Issue has not been updated, no commits have been pushed to its branch, and the orchestrator has received no status messages. The subagent appears to be completely unresponsive. What should the orchestrator do?
Select an answer to reveal the explanation.
Short Explanation and Infographic
No heartbeat for 45 minutes means the agent is either stuck, crashed, or looping in silence — and all three need the same response: declare it stalled and act. Think of it like a contractor who hasn't checked in, hasn't submitted any work, and isn't answering calls. You don't wait indefinitely — you cancel the contract and get a replacement or call the supervisor.
Full explanation below image
Full Explanation
Stall detection is a critical orchestrator responsibility. Healthy agents in a multi-agent system should emit regular progress signals: GitHub Issue updates, heartbeat messages, incremental commits, or log entries. The complete absence of any such signal for 45 minutes — particularly on a task expected to produce observable progress — is a reliable indicator of a stall condition.
An orchestrator should have a defined stall detection policy: - A maximum inactivity timeout (e.g., 30 minutes without a progress signal is a stall) - A classification step: is this a timeout, a crash, an infinite loop, or a blocked dependency? - A response strategy: cancel the stalled subagent and either retry with a fresh instance or escalate to human review
The orchestrator should not wait indefinitely. Waiting multiplies pipeline delay by the remaining stall duration and may cause downstream agents to also stall waiting for the stalled agent's output.
Why the other options fail: - Option A (wait 2 more hours) compounds the problem. Without a stall detection policy, a stalled agent could block the pipeline for its entire maximum timeout. Stall detection exists precisely to bound this wait time. - Option C (trigger a parallel second agent) without canceling the first creates two agents working on the same task simultaneously. If the first agent is stuck but eventually produces output, both outputs will conflict. The first stalled agent must be canceled before a replacement is spawned. - Option D (simplify the task and re-assign to the same agent) assumes the stall was caused by task complexity. The orchestrator has no evidence of this — the stall could be an infrastructure failure, a dependency issue, or an agent loop. Sending more work to a potentially broken agent is not the correct response.
Stall detection requires a timeout policy, a classification process, and a defined response — not indefinite waiting.