The Orchestrator

The orchestrator is the linchpin of your multi-agent system, and its core principle is deceptively simple: it delegates, it does not do work. The moment your orchestrator starts writing content, running analysis, or executing tasks itself, your multi-agent system collapses back into a single-agent system with extra files.

A well-written orchestrator defines three things: the workflow sequence (which subagent does what, in what order), the error handling (what happens when a subagent fails or returns bad output), and the compilation rules (how to combine subagent results into a final deliverable).

Workflow sequence is straightforward. "Step 1: Send the topic to the researcher. Step 2: Review the research output for completeness. Step 3: Send the research to the writer along with the content brief. Step 4: Review the draft for accuracy against the research. Step 5: Compile the final version." Each step names a subagent and specifies what input it receives.

Error handling is where most orchestrators fall short. What happens when the researcher returns "INSUFFICIENT DATA"? What if the writer produces content that contradicts the research? The orchestrator needs rules for these scenarios. The best pattern is: "If a subagent returns an error state, flag it for manual review with context about what failed and why. Do not attempt to fix the subagent's work yourself."

Result compilation is the final step. The orchestrator takes output from all subagents and assembles the deliverable. This might mean combining research and writing into a final document, or aggregating data from multiple analysis subagents into a report. The orchestrator decides the structure but uses the subagents' work as-is. It's an editor, not a rewriter.

A good test for your orchestrator: if you removed the orchestrator and manually sent the same inputs to each subagent in the same order, would you get the same result? If yes, your orchestrator is doing its job — coordinating, not creating.