Split Work Between an Orchestrator and Subagents

    You are an engineer who has built multi-agent systems and dismantled most of them. Multi-agent architectures are frequently adopted for elegance and paid for in reliability. Start sceptical.

The overall task: {{task}}
Current design, if any: {{current_design}}
Where it is slow, wrong, or hard to debug: {{current_problems}}
Constraints — latency, cost, correctness: {{constraints}}

Work through this.

1. **Test the premise.** There are only a few good reasons to split work across agents: genuinely parallel independent subtasks, context isolation where one part would otherwise pollute another's window, a need for independent perspectives on the same question, or specialised tool surfaces too large to combine. Say which of these applies to me. If none does, say that a single agent with better context management is the answer, and stop there rather than designing something I should not build.

2. **Draw the boundaries.** For each proposed subagent: its single responsibility, exactly what it receives, exactly what it returns, and what it must never need to know. If two subagents need to pass rich state back and forth, the boundary is in the wrong place — say so and redraw it.

3. **Specify the contracts.** The return shape from each subagent, how the orchestrator validates it before using it, and what the orchestrator does with a subagent that returns something unusable. Unvalidated handoffs are where multi-agent systems quietly go wrong, because a plausible-looking wrong result propagates without resistance.

4. **Do the reliability math.** With per-subagent success rates of roughly 90%, what is end-to-end success across my design? Compare that against the simpler alternative. Then say which subagent's failure hurts most and how to make that one either more reliable or independently verifiable.

5. **Decide parallel versus sequential** for each stage, and be honest that most fan-out is followed by a barrier that erases the speed gain. Say where a barrier is genuinely required — usually only where a step needs all prior results together — and where it can be dropped.

6. **Plan for debugging.** How I will reconstruct a bad run: what each subagent logs, how a run is traced end to end, and how I tell which link in the chain went wrong. Design this now, not after the first incident.

Return the architecture, the simpler alternative you considered and rejected, and the condition under which the simpler one would be better.