What is AI worker fleet orchestration?

AI worker fleet orchestration is one AI client splitting a task across purpose-built workers, then reading their results back to decide what happens next.

A worker fleet is usually described as something a person configures and then leaves alone. AI worker fleet orchestration is what happens when the thing driving it is not a person but another AI.

The client you already talk to connects to your fleet, sees every AI worker you have, and can run any of them with a prompt written for that one run. It reads each receipt back and decides what to do with what it found. A request too big for one agent becomes a plan across several, each step executed by a worker built for exactly that job, and each step's result choosing the one after it.

The chat agent alone, and the same agent orchestrating a fleet

	One agent, all the tools	An agent orchestrating a worker fleet
Holds the app access	Yes, the union of every job	No, each worker holds its own
Work happens	Inside one context window	Inside each worker's own run
Runs at the same time	One thing at a time	As many workers as you have
Knows a job's method	Whatever you paste in	Already in the worker's instruction
Evidence afterwards	A transcript	A receipt per run, per worker
Blast radius of a bad step	Everything it can reach	That one worker's grants

The second column is not a smaller version of the first. It is a different shape: the orchestrator holds the plan, and the workers hold the access.

The three verbs of fleet orchestration

Orchestration is smaller than it sounds. It reduces to three moves, repeated:

Read the fleet. What workers exist, what each one is for, which are ready, which are running right now.
Run one with a prompt. Not the worker's standing instruction, but what to do on this run: one account, one repository, one day, one question.
Read the receipt. Status, the report the worker wrote, what it touched, what it cost. Then decide the next move from that.

The third verb is where the pattern earns its name, because the next move is usually another run, with what the last one just found as its prompt.

Everything else, memory, schedules, instructions, starting and stopping, exists so the orchestrator can also leave the fleet in a better state than it found it.

Why the handoff needs an orchestrator

Workers deliberately share nothing. Each one has its own key, its own per-app grants and its own memory, which is exactly what stops a wrong fact or an over-broad permission from spreading across the fleet.

The cost of that isolation is that a finding cannot walk from one worker to the next on its own. The triage worker can conclude "these three are enterprise escalations" and the account researcher will never hear about it, because there is no channel between them and there should not be one.

An orchestrator is that channel, and it is a deliberately thin one: it reads a finished receipt and writes the next worker's prompt. Nothing is shared, no permission is pooled, and each worker still only ever sees the subject it was handed.

Why the prompt-per-run matters

A worker's standing instruction is its method: how to triage, how to research an account, what "done" means. That part is stable and was tested when the worker was built.

What changes is the subject. A per-run prompt supplies the subject without touching the method, so the same worker can be pointed at forty different things in an afternoon and each run still does the job the way it was written to. The orchestrator never has to explain how to do the work, only what to do it to.

This is the whole reason the pattern scales. The alternative, pasting a method into a general agent every time, means the quality of the work depends on how well the prompt was written that morning.

Use cases: one worker's result running the next

The shape worth learning is the chain. Run a worker, read what it found, and use that finding as the prompt for a different worker, one that holds different app access and knows a different job.

Triage, then research, then draft. The support triage worker runs over the last day's inbox and its report names three tickets that look like enterprise escalations. For each named account, the orchestrator runs the account research worker with that account as the subject, and it comes back with the renewal date, the open items and who owns the relationship. Those findings become the prompt for the drafting worker, which writes a reply that knows things the triage worker never had access to. Three workers, three permission sets, one line of work.

Step	Worker	Its input	What it hands on
1	Triage	"the last 24 hours"	Three accounts, named
2	Research	One account from step 1	Renewal date, open items, owner
3	Draft	Step 2's findings	A reply that cites them

Find the signal, then chase it. Engineering Pulse produces its digest and two pull requests in it have been stalled for a week. The orchestrator takes those two, with their owners, and runs the follow-up worker with them named in the prompt. The digest worker only reads GitHub; the follow-up worker is the one that can chase a person. Neither could have done both.

Look it up, then answer with it. A support reply needs the real policy, not a remembered one. The orchestrator runs Company Knowledge Concierge with the question, gets an answer with citations out of the document store, and passes that answer into the worker that writes the reply. The reply quotes the source because the source came from the previous run, not from the model's memory.

Narrow with a cheap worker, then spend on the survivors. A fast, shallow worker scans a wide surface and returns the fifteen items worth a closer look. Only those fifteen go to the careful worker on the stronger model. The chain is the cost control: the expensive step only ever sees a filtered list, which is usually the difference between a sweep you can afford daily and one you run once.

Check before you commit. The research worker proposes a set of CRM updates and writes them into its report rather than applying them, because it holds Read on the CRM and nothing more. The orchestrator shows you the proposal, and only what you approve gets handed to the worker that holds Write. The gate between "decided" and "done" is a different worker with different grants, which is a far stronger boundary than an instruction asking a single worker to be careful.

Prep a day, meeting by meeting. The briefing worker returns today's meetings. Each one becomes a run of Meeting Prep Assistant with that meeting's attendees as the subject, and the prep sheets come back one per meeting. Here the first run does not just start the chain, it decides how many links it has.

Catching up after an outage. A provider was down and three workers skipped their windows. The orchestrator reads the run history to find the gap, replays the missed subjects one run at a time with the dates named in each prompt, and each replayed run's outcome decides whether the next one is still needed.

Chaining is not the only shape. When steps do not depend on each other, the same three verbs fan out instead: one worker run fifty times over fifty accounts, all at once, with the orchestrator writing the summary at the end. The rule is simply whether the next prompt needs the last result. If it does, chain. If it does not, run them together.

What the orchestrator is not allowed to do

This is the part that makes the pattern safe enough to leave connected.

The credential an orchestrator holds is a fleet credential. It can list, run, schedule and configure workers. It cannot reach your connected apps. There is no tool on it for reading a mailbox or writing to a CRM, and no way to borrow a worker's access for its own purposes.

So when an orchestrated worker touches an app, it does so under its own rules, unchanged:

Still enforced during an orchestrated run	Decides
App firewall	Which apps, at Off, Read or Write
Contact rules	Which people it may see and reach
Redaction	What must never leave
Daily caps and usage windows	Whether the run happens at all

A prompt cannot widen any of them. "Also email the customer" reaching a worker with Read on email produces a run that could not do it, not a sent email. The restraint lives with the worker, so it holds no matter who is asking.

How to set up AI worker fleet orchestration

The connection is a remote MCP server, mcp.workerkit.ai. Full detail is on the WorkerKit MCP server page; the short version, in the order you do it:

Add the workers endpoint to your client. In any MCP client that supports remote servers, add https://mcp.workerkit.ai/workers as a connector. In Claude Code that is one line:

claude mcp add --transport http workerkit https://mcp.workerkit.ai/workers

Authenticate from the client. Prefer this over pasting a key. The client discovers the OAuth flow and sends you to the consent page at workerkit.ai/mcpauth, where you sign in, choose or mint an access key, and approve. The client stores the result and you never handle a raw credential. Only an account admin can complete this step.

Choose the reach on that page. The key you approve with carries a set of scopes, and the client's reach is exactly those scopes. Start with readWorkers and readRuns so the first session can only look, then add runWorkers, and the manage scopes only when you want the orchestrator to change things.

Say what you want in plain language. Ask the client what workers you have before asking it to do anything with them. The first useful sentence is usually "list my workers and tell me what each one is for".

Add the public catalog endpoint too if you want the client to be able to search for kits. It needs no key and no sign-in:

claude mcp add --transport http workerkit-directory https://mcp.workerkit.ai/directory

What an orchestration session actually looks like

Read the fleet, run the first worker, then let its report choose the next one. This is the triage chain above, in the calls the client actually makes:

workers_list                                  -> triager #4, researcher #7, drafter #9
worker_run   tokenId=4  prompt="last 24h"     -> receipt: Running, runId A
run_events   runId=A    afterSeq=0            -> poll every 3-5s until settled
run_get      runId=A                          -> report: 3 escalations, accounts named

   (the client reads A's report and writes the next prompt from it)

worker_run   tokenId=7  prompt="<account 1>"  -> runId B
run_get      runId=B                          -> report: renewal in 3 weeks, 2 open items

worker_run   tokenId=9  prompt="<B's report>" -> runId C, the drafted reply

Nothing about worker 7 or worker 9 was decided in advance. The fleet was read, the first run happened, and everything after it was chosen from a receipt.

Two manners to teach the client once, because they are the difference between a session that works and one that gets throttled:

Wait between polls. A run advances at the speed of a model taking turns, so poll its events every 3 to 5 seconds, not in a tight loop.
A skipped run is an answer, not an error. A cap, a usage window or a missing app connection comes back as a normal receipt with a reason on it. The right response is to report the reason, not to retry the run.

The reasonable objection

"This is a coordination layer over things that already run on their own. Why not give one agent every tool and let it do the work directly?"

Because the two answers differ on everything except the first afternoon.

The single agent has to hold the method for every job in whatever context you give it, hold the access for every job at once, do one thing at a time, and leave a transcript rather than a record. It is also only as good as the last prompt somebody wrote.

Fleet orchestration puts the method inside each worker, where it was tested; keeps the access split, so a wrong step is contained; runs jobs at the same time rather than in sequence; and leaves a receipt per run that can be read months later. The orchestrator supplies the one thing a fleet genuinely lacks, which is a plan for today.

When not to orchestrate

One worker does it. If the job fits inside a single worker's instruction, run the worker. A coordinator over one thing is a hop.
The job should be scheduled. Something needed every morning wants a schedule, not a person asking a client to trigger it.
You have no workers yet. Orchestration is a multiplier on a fleet. Build the first two workers, then connect a client.
The steps must be exact. A plan that must run identically every time is code, not a model deciding what to run next.

FAQ

What is AI worker fleet orchestration?

AI worker fleet orchestration is one AI client breaking a large task into smaller jobs, handing each to a purpose-built AI worker in a fleet, and reading the results back to decide what happens next. The client holds the plan; each worker holds its own app access, its own tested instruction and its own receipt.

How does an AI client like Claude orchestrate my worker fleet?

Through the WorkerKit MCP server at mcp.workerkit.ai. The client connects to the workers endpoint, authenticates over OAuth, and gets tools for listing workers, triggering a run with a prompt written for that run, watching it, and reading the report it produced.

Can an orchestrating client read my email or write to my CRM?

No. The credential it holds manages workers and grants no access to any connected app. When a worker acts during an orchestrated run it uses its own permissions, and the app firewall, contact rules and redaction apply exactly as they do on a scheduled run. A prompt cannot widen them.

Can one AI worker's result be used to run another worker?

Yes, and that is the most common shape. The client reads the finished receipt from the first run and writes the next worker's prompt out of what it found, so a triage worker's list of accounts becomes the research worker's subject, and the research worker's findings become the drafting worker's input. Workers share no memory and no permissions with each other, so the orchestrator carrying a result across is what makes the handoff possible at all.

Can I run several AI workers at once?

Yes, and that is most of the point. Each run happens inside its own worker rather than in the client's context, so a sweep across many subjects runs in parallel instead of one after another. Runs draw on the account's normal allowances, and run triggers are limited to 30 a minute per account.

Do orchestrated runs cost more than scheduled ones?

No. A run triggered by a client is metered like any other run: its tool calls count against the daily allowance and its model tokens are billed at provider list price with no markup. What changes is how many runs you choose to trigger.

Do I need to write code to orchestrate a worker fleet?

No. The orchestration happens in the conversation: you describe the outcome, and the client decides which workers to run, with what prompt, in what order. Code is an option, not a requirement.