What an orchestrator actually does
An orchestrator receives a task, chooses work units, gives each unit the context and tools it needs, then collects results. It must also decide whether to retry, stop, ask a person or pass the work to another specialist. A handoff is useful only when the receiving worker has a clear objective and the next step can verify its output.
A single agent is often enough. Add a specialist when it brings distinct tools, context or review responsibility. Splitting every step across agents increases messages, cost and opportunities for conflicting edits. The right design follows task dependencies, not the number of available models.
References: OpenAI — Orchestration and handoffsAnthropic — Create custom subagents
Draw the task graph before adding concurrency
Suppose a team needs a technical article and a code example. Source research and an existing-site audit can run independently. The article draft depends on verified sources; the code example depends on the API contract; final review depends on both. That graph shows where parallel work can save time and where a join must wait.
Give each worker an input contract: exact scope, data it may read, output format, deadline and acceptance check. Shared file writes need one owner or an explicit merge step. If two agents edit the same page without coordination, the extra concurrency creates rework instead of speed.
Where MCP fits
MCP lets a host application connect to servers that expose tools, resources and prompts. It can make a repository, search service or business system available to an agent. It does not decide which worker owns a task, whether a write is allowed or how a failed external call should be retried.
Keep credentials and authorization at the tool boundary. The orchestrator can request a read, but the server must still validate the acting identity and target record. A document returned by a tool is data, even when it contains text that looks like an instruction.
References: Model Context Protocol — architecture overview
Handle retries, review and evidence
External writes need an idempotency key or reconciliation path. A timeout may mean the destination accepted the write but the result did not return. Retrying blindly can create a second record. Store the requested action, confirmed result and unresolved status separately so a person can inspect what happened.
Place a human gate before consequential actions such as deployment, spending or messages to real recipients. The gate should show the exact proposed action and evidence, not only a model's summary. After execution, verify the destination state and record the outcome. Evaluate the complete workflow with representative tasks, including failures and interventions.