Coordinator-subagent orchestration

In a hub-and-spoke architecture, one coordinator sends work to the subagents and receives their results and errors. Subagents do not communicate directly with one another.

Why route everything through the hub

Central routing is what makes a multi-agent system observable. One place shows what was delegated, what came back, and what failed. It's also the only place error handling can be applied consistently.

Direct communication between subagents may reduce latency, but it makes the system harder to monitor. The coordinator no longer has a complete record of what each subagent did.

Isolated context is the default

A subagent does not inherit the coordinator's history. Whatever it needs has to be in the prompt you send it. If the prompt omits a constraint known by the coordinator, the subagent may confidently produce an answer that violates that constraint.

Ask a classmate to draft the methods section and they draft it from what you told them. Nothing in their work can reflect the professor's revised brief if you forgot to forward it, and they have no way to notice it's missing.

Siblings are invisible to each other too. Two subagents running from the same coordinator share nothing, so neither can see what the other covered or avoid repeating it. Ordering them doesn't help; only the coordinator can keep them apart, by sending each one a different scope.

Choose subagents for the request

A coordinator should inspect the request and invoke only the subagents needed to answer it. If it always runs the same sequence, it behaves like a fixed pipeline and doesn't adapt to the request.

Divide the work without creating too many subagents

Split scope so two subagents are not researching the same thing — distinct subtopics, distinct source types.

But decomposition can go too far. Slice a broad research question narrowly enough and every subagent answers its sliver correctly while the question as a whole goes unanswered. Coverage is the coordinator's responsibility: evaluate the synthesis for gaps, re-delegate with targeted follow-ups, and synthesize again until the answer is actually complete.

When not to decompose at all

Decomposition can also be wrong from the start. Splitting gives each agent its own scope and tool access, and it can allow work to run in parallel. The tradeoff is more handoffs and repeated context for every separate agent. Where the work has no separable scope, one agent holding every tool is the cheaper design.