You've split a task across several subagents so they can work in parallel — one exploring the codebase, one drafting a migration, one running tests — and the orchestrating agent pulls their output back together to decide what happens next. In one reported case, running three tasks concurrently brought wall-clock time down to about twelve minutes from something closer to twenty-five, so the setup feels justified.
Speed isn't the part that matters most, though. Rahul Garg, in a piece on Martin Fowler's site, argues that the orchestrator's context is a scarce resource rather than a container: anything loaded into it has to be held alongside everything else the agent is trying to reason about. Read that way, a subagent earns its place by absorbing work whose detail never has to come back - which is a different measure of value from how much time it saves. Treat a subagent as a way of protecting the orchestrator's working memory, and design delegation around that rather than around parallelism.
Why flooding the orchestrator's context is the actual failure mode
If a subagent reports back everything it did — every file it opened, every dead end it explored, every intermediate draft — the orchestrator now has to hold all of that alongside the original task, the accepted decisions about the increment, and whatever else is already in play. None of it disappears just because it arrived from a subagent instead of being generated directly. It still occupies space that competes with the information the orchestrator actually needs to reason well about what to do next.
This is easy to miss because the payoff of using subagents (faster completion) is visible immediately, while the cost (a degraded orchestrator) shows up later, as decisions that seem to lose track of constraints established earlier in the same session, or as the orchestrator restating work a subagent already did because the relevant fact got buried under exploration noise. The site's article on keeping context between AI sessions covers the equivalent problem across sessions — what to write down so a project survives a break. The subagent version of the same problem happens inside a single session: what should be allowed back into the orchestrator's context at all.
Give the orchestrator ground rules, not just tasks
Garg's argument, as described in the Fowler piece, is that this only works well if the orchestrator has explicit ground rules for when and how to delegate. In PDAID terms, that's a Context & Constraints question. Delegation without a boundary on what a subagent is allowed to hand back is delegation without a constraint, and the result is that the orchestrator absorbs whatever the subagent decided to include.
Some practical consequences follow directly from that framing:
- Decide what a subagent returns, not just what it does. A subagent tasked with "investigate why this test is failing" can come back with a full transcript of its investigation or with a short statement of the cause and the evidence for it. The task looks identical from the outside; the effect on the orchestrator's context is not.
- Treat a subagent's output as something to accept or reject, not absorb wholesale. This mirrors the division of responsibility in PDAID more generally: AI can propose, but accepted decisions are what should persist. A subagent's raw exploration is a proposal, not an accepted fact, and doesn't need to sit permanently in the orchestrator's context just because it arrived.
- Split subagent work along the same lines you'd split any increment. The site's piece on the smallest useful increment argues for units of work that are useful, understandable and testable on their own. The same test is useful for deciding what to hand a subagent: a task with a clear, checkable outcome produces a report the orchestrator can accept or reject in one pass. A vague or sprawling one produces a sprawling report, which is exactly what floods the context.
- Don't parallelise for its own sake. If two subagents are cheaper to run in parallel but their combined output is harder for the orchestrator to reason about than doing the work sequentially, the parallelism has cost more than it saved.
What this doesn't solve
None of this removes the orchestrator's own responsibility for deciding what "done" looks like — that's covered in Agents Still Need Someone to Decide What "Done" Means, and it applies whether the orchestrator is working alone or coordinating subagents. Protecting the orchestrator's context makes it more likely that its judgement is sound when that decision gets made; it doesn't replace the need to check the result. The source here is a short piece making one argument, not a study of multi-agent systems in production, so treat "ground rules for delegation" as a design principle to apply deliberately rather than a fixed procedure — what counts as too much context, and what a subagent should be trusted to summarise versus report in full, will depend on the task in front of you.
If you're building a multi-agent workflow, the question worth asking before you split work across subagents isn't "how much faster will this be" but "what is this subagent allowed to bring back, and what should it filter out before it does."