Orchestrator vs Worker

One agent that plans, routes, and synthesizes. Other agents that execute. This simple split is what turned a chaotic pile of AI conversations into a system that could actually scale — and the reasons it works are more practical than they first appear.

The Problem a Single Agent Can't Solve

When you are working with one AI session doing everything — planning, writing, deploying, checking, reporting — you hit a wall fast. The wall is not intelligence. The AI can handle all those tasks individually. The wall is context and role conflict.

An agent that is simultaneously deciding what to do next and executing the current task makes inconsistent decisions. It gets pulled by whatever it just touched. It loses track of the larger plan. And critically: if it is also the one committing changes and deploying code, there is no second set of eyes on its own work. Every error it makes, it ships.

The fix we landed on is the same division of labor that works in human teams: separate the thinking from the doing. One role plans and routes. Other roles execute. The planner never loses sight of the whole; the executors go deep on their piece without needing to hold the whole in mind.

What an Orchestrator Actually Does

The orchestrator is not a supervisor sitting idle while workers toil. It is the most active role in the system — it just acts at a different level.

Concretely, the orchestrator:

• Reads the plan and current state at the start of every session, so it always knows what is in flight and what comes next.
• Routes tasks to workers with explicit briefs — concrete scope, concrete inputs, and a concrete description of what to return. "Go figure something out" is not a brief. "Read these three files, find any URLs that are missing from the sitemap, and return a list" is a brief.
• Synthesizes what workers return into a single coherent direction, rather than forwarding three separate outputs to a human and making them do the integration.
• Is the one that commits and deploys. Workers produce; the orchestrator verifies and ships. This single constraint prevents most race conditions and keeps a clean audit trail.
• Updates the shared memory — state, decisions, lessons, handoffs — so the next session picks up cleanly regardless of which agent runs it.

What a Worker Actually Does

Workers are briefed like a smart colleague who just walked into the room knowing nothing about the project. That framing is useful because it tells you exactly what the brief needs to contain: context, specific inputs, and a clear statement of what you want back.

Workers do the execution work: reading files, running audits, generating content, checking live URLs, extracting data. They go deep on a bounded task and return a structured result.

The most important constraint on workers is this: workers are read-only by default. They gather, analyze, and produce. They do not commit to version control. They do not deploy. They do not update the shared memory files. All of that stays with the orchestrator.

This constraint sounds limiting. In practice it is liberating, because it means you can run a worker on almost anything without fear that it will accidentally clobber something. The blast radius of a worker going wrong is bounded: it produces a bad output, the orchestrator catches it in review, nothing ships. That is a recoverable situation. A worker that has deploy authority going wrong is much harder to recover from.

Why This Prevents Race Conditions

A race condition in this context means two agents editing the same file at the same time, with one silently overwriting the other. It happens faster than you expect once you have more than one agent active.

The orchestrator-as-sole-committer pattern addresses the race condition at its root: there is only one agent with commit authority, so there is no race. Workers queue their outputs; the orchestrator integrates them one at a time before any of it touches production.

For cases where you do have multiple orchestrators running in parallel — which becomes relevant when the system grows — the answer is a claim-before-you-change lock: an agent declares it is working on a specific file or path before it touches it, and a second agent seeing that claim waits or picks a different task. We cover this in detail in Part 7. For now, the single-orchestrator pattern is enough to get most of the benefit.

How to Write a Worker Brief That Actually Works

The brief is where most orchestrator-worker setups fail. A vague brief produces a vague output, and the orchestrator then has to do the work the brief should have done. Here is the structure that works:

TASK: [one sentence, active verb — what you want done]
INPUTS: [specific files, URLs, or data the worker should read]
SCOPE: [what is in bounds; what is explicitly out of bounds]
OUTPUT FORMAT: [exactly what you want back — a list, a JSON object, a markdown table]
DO NOT: [the one or two things most likely to go wrong — head them off explicitly]

The DO NOT line is underrated. When you have run a few workers, you will notice the predictable failure modes: a worker that was asked to find broken links also "helpfully" rewrites the prose around them. A worker asked to audit a sitemap also generates a new one. Explicit scope-limiting prevents half the errors before they happen.

The Audit Trail as a Feature

When the orchestrator is the sole committer, every change in version control traces back to a decision the orchestrator made — which in turn traces back to a worker output, a human direction, or a rule in the operating constitution. This chain is not just good governance. It is practically useful: when something breaks, you can walk backward through the commit history and find exactly what changed and why.

Compare this to a system where any agent can commit at any time. The history becomes noise — many commits, unclear provenance, no way to tell which ones were deliberate decisions and which were opportunistic side effects of a task aimed at something else.

One orchestrator, one commit stream, one audit trail. The discipline is worth it.

Synthesizing Worker Output: The Orchestrator's Most Underrated Job

When three workers return their results, the temptation is to forward all three to the human and say "here is what I found." That is not synthesis. That is delegation of the integration problem.

The orchestrator's job is to read all three outputs, identify the single coherent direction they point to, and act on that direction — or surface the conflict if they genuinely disagree and a human call is needed. The human should receive one clear brief, not a pile of raw AI output to sort through themselves.

This is harder than it sounds. Worker outputs often partially overlap, contradict in small ways, or use different formats. The synthesis step requires the orchestrator to hold the full picture and make a judgment call. It is also where the orchestrator earns its keep: a system that produces three separate reports and asks the human to combine them has not actually saved the human any cognitive work.

Starting With One Agent Wearing Both Hats

You do not need two agents on day one. The orchestrator-worker split is a pattern you can practice with a single agent by being deliberate about which mode it is in at any given moment.

Run a session in two explicit phases. In the planning phase, the agent reads the state files, decides what work to do, and writes a task list — it does nothing else. In the execution phase, it works through the task list one item at a time. In the commit phase, it reviews its own output before pushing anything.

The discipline of the three phases — plan, execute, review — is the underlying pattern. A second agent eventually makes each phase cleaner and faster, but the pattern works with one. Once you feel the benefit of the separation, adding a second agent for the execution phase is a natural next step rather than a leap of faith.

What to Do Right Now

Before you add any agent beyond your first, establish two things:

1. Decide who commits. Pick one role — it can be you or your primary AI session — and make it the only entity that pushes changes to production. Everything else produces and proposes; this one role reviews and ships.
2. Write your first worker brief template. Fill in the structure above for the most common task you would want to delegate. The act of filling it in will immediately reveal where your current process is vague, and vagueness is where errors hide.