An architect is designing a multi-agent system where a Claude orchestrator decomposes complex research tasks into subtasks delegated to specialized Claude subagents. If any subagent fails, the orchestrator must retry with a modified approach rather than propagating the failure. Where should retry logic be implemented?
Select an answer to reveal the explanation.
Short Explanation
You put retry logic in the orchestrator because it has the full task context. It can decide whether to retry with a new prompt, swap in another subagent, or break the failed subtask down differently.
Full Explanation
In a multi-agent system, strategic retry and failure handling belongs in the orchestrator, not individual subagents. The orchestrator has the full task context needed to make intelligent decisions: it knows which subtask failed, what the overall research goal is, and can choose to retry with a different prompt, substitute an alternative subagent, or decompose the failed subtask differently. The subagent-self-retry approach creates local retry loops without task context — a web search agent retrying the same failed search query gains nothing without the orchestrator's context about why the search was needed. The API-layer exponential-backoff approach handles transient infrastructure failures such as 5xx errors but cannot handle semantic failures such as wrong output or insufficient information that require prompt-level correction. The equal-orchestrator-and-subagent approach creates conflicting retry logic and can cause retry storms when both layers retry simultaneously.