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
No heartbeat for 45 minutes means the agent's stuck, crashed, or looping in silence — and all three need the same response: declare it stalled and act. You don't wait indefinitely; you cancel the stalled task and get a replacement or escalate to a human.
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.
The correct response is to classify the subagent as stalled based on the absence of heartbeat signals, cancel the subagent's task, and either retry with a fresh subagent or escalate to a human for investigation.
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: - The option that says to wait an additional 2 hours before taking any action 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. - The option that says to trigger a second subagent to begin the same task in parallel with the first, 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. - The option that says to reduce the scope of the refactoring task and re-assign the simplified version to the same subagent 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.