Automater
Upgrade to ProDownload Lite free

When Not to Use an AI Agent Coordinator

An AI agent coordinator copies its first mistake N times. The decision rule, a sixty-second self-test, and four brakes for sensitive or air-gapped work.

Portrait of Russell Winslow
12 min read
All articles
Fan-out motif for when not to use an AI agent coordinator: one plan feeding six pull requests tagged wrong, against one agent producing one diff tagged caught once
One plan, six faithful copies of its mistake. One agent, one diff, one human who reads it.
THE FIELD GUIDE

Go deeper. Build your own.

A coordinator does not make your agents smarter. It makes your first mistake arrive N times, in N pull requests, each consistent with the others and therefore convincing. That property never appears in launch copy, and it is the one an AI agent coordinator should be judged on before any of the others.

Cursor Projects arrived on Sep 10, 2026 with a coordinator that “is never blocked,” and OpenAI’s Agents API went to public beta the same day with subagents of its own. The pitch on both is the same: hand the plan to one agent and let it run the others. For a bounded migration with a test suite, that is a fine trade. For three shapes of work it is the wrong tool, and this is the piece that draws the line the vendors will not.

By Tuesday you should have a decision rule you can say in one sentence, a sixty-second self-test you run before opening a coordinator on any task, and four brakes for the times you use one anyway.

The pitch, once: never blocked, and you review less

Cursor’s “Introducing Projects” post by Alexi Robbins and Fredrika Lindh, dated Sep 10, 2026, is the cleanest statement of the coordinator shape on the market, so it is the one to read closely (Cursor blog; Cursor changelog). “The coordinator agent in a project doesn’t write code itself; it plans the work, delegates it to agents that implement it, and brings the finished work back to you to check.” It runs “as many in parallel as the work needs,” and “because it delegates rather than executes, it is never blocked and is always responsive to direction.”

Cursor blog post Introducing Projects, Sep 10, 2026, with a table of contents listing Direct thousands of agents through one coordinator, Migrations, and Gardening Screenshot: Cursor blog, “Introducing Projects” (Sep 10, 2026), captured Sep 13, 2026.

The review model is the part to underline. “Early on, you review each PR closely. As the fixes hold up, you review less, and the coordinator keeps working through the migration on its own.” Cursor reports using it for “migrations of a few hundred PRs” and says “users who primarily use Projects merge six times as many” PRs, a vendor number about vendor-selected work.

The same day, OpenAI’s Agents API entered public beta with subagents, automatic context compaction, and hosted sandboxes (OpenAI). InfoWorld’s Sep 11, 2026 coverage called it “a crowded category” alongside Claude Managed Agents and Amazon Bedrock AgentCore, and led with lock-in: when one vendor provides “the model, context management, tools, orchestration, and execution environment, moving to another platform becomes harder” (InfoWorld). The coordinator is now the default shape being sold. The news ends here.

An AI agent coordinator does not average out mistakes; it copies them

Fan-out is sold as parallelism, and parallelism is where the intuition goes wrong. Ten humans working from a bad spec produce ten different wrong things, and the disagreement is the signal that the spec is bad. Ten subagents working from one coordinator’s plan can produce ten versions of the same wrong thing, because they were briefed by the same planner with the same context files. The plan is a shared point of failure, and the architecture can replicate it on purpose.

Acting agents make this expensive rather than embarrassing. A chatbot’s wrong plan is a paragraph you delete. A coordinator’s wrong plan is N branches, N CI runs, N pull requests, and, under “you review less,” some number of merges. The unit of damage stops being the mistake. It becomes the mistake, times the fan-out, times the fraction you stopped reading.

Three task shapes that stay single-agent plus a human

Single-task work: nothing to parallelize, everything to coordinate

A one-file bug fix. A failing test with a known cause. A config change with one right answer. A coordinator adds a planning step, a delegation step, an environment per worker, and a hand-back, and gets one diff for its trouble. Environments are where the cost lands: GitTaskBench attributes 65.04% of task failures to environment setup and dependencies (arXiv 2508.18993), and a coordinator that gives every worker a fresh environment pays that failure rate per worker. For single-task work, run one agent in the repo you already have set up and read its diff.

High-sensitivity changes: the pen stays in a human hand

Anything that touches a credential, a production infrastructure module, a payment or retention path, a lockfile, or a CI workflow. The property that matters here is approvers per change, and a coordinator drives it toward zero: N workers make N changes before the first approver has read one. The vendor answer is “review closely early on,” which is a human policy the product cannot enforce for you. Use one agent under a permission mode that asks before it writes. Claude Code’s default mode and explicit allow, ask, and deny rules are one documented shape (Claude Code docs). Keep one approver and one change at a time. Agents are privileged users, and a coordinator is a privileged user that hires.

Air-gapped, regulated, or untrusted work: the coordinator’s shape is the leak

Projects runs on its own cloud computer by default. Cursor’s Sep 2, 2026 self-hosted-machines changelog says local tool execution can stay inside your network, but the cited Projects launch pages do not establish a fully air-gapped coordinator path. If data cannot leave the room, require a documented end-to-end boundary before using the coordinator; otherwise keep the work on one local agent and one controlled host.

Untrusted intake is the sharper case. Manifold Security’s GitSpawn research (Sep 1, 2026) showed that a repository’s .git/config can name a program that git runs during startup operations before an agent’s trust prompt (Manifold Security). Manifold’s mitigation is to inspect .git/config before opening the directory with an agent because program-naming settings can execute. Do that once in quarantine before any coordinator is allowed to copy or delegate work from the repository.

Novee’s Black Hat 2026 findings (Aug 5–6, 2026) add the harness angle: deployment-visible trust controls were missing, and one demonstrated child process could read secrets from its parent process (Novee). A harness flaw in one worker is a harness flaw in every worker. For this shape: one agent, a quarantined clone, a machine with nothing on it worth taking, and a human who reads .git/config first. The repo intake checklist and the sandbox piece carry the details.

The decision rule: fan out only where the plan can be wrong cheaply

Say it in one sentence and put it on the wall. Use a coordinator only when the task decomposes into independent units, each unit has a mechanical pass/fail, and the worst unit’s merge can be reversed without waking anyone. Three tests, all three required.

Test Passes Fails
Decomposable One migration pattern across 300 files; a rename with a codemod; a dependency bump per service A feature whose parts must agree on an interface not yet written; anything where worker 3’s output changes worker 7’s task
Verifiable by a machine Tests per package; a type checker; contract tests; CI green as the gate Untested code; UI judged by eye; “make it cleaner”; an LLM judge as the only gate
Reversible cheaply Code-only PRs behind branch protection; one git revert per unit Schema migrations; credential rotations; anything that sends email or money; changes to CI itself

Illustrative heat table of blast radius by task shape, single agent plus human versus an AI agent coordinator with N workers, with verdicts per row Illustrative, an operator model rather than measured data. Darker cells are more to unwind when the plan is wrong; the red-outlined verdicts are the three shapes that never fan out.

If any test fails, the answer is single agent plus a human, not a coordinator with more review. Review is the resource the coordinator is built to consume less of, and a task that needs more of it is a task the coordinator is shaped against.

The sixty-second AI agent coordinator self-test

Eight questions, yes or no. Answer them before you open the coordinator, not after the first PR lands.

  1. Can I write the plan myself, in under ten lines, as a list of units that do not depend on each other?
  2. Does each unit have a pass/fail that a machine decides?
  3. If every unit is wrong in the same way, can I revert all of them with one command in under ten minutes?
  4. Does any unit touch a credential, a production infra module, a lockfile, a CI workflow, or a payment or retention path?
  5. Does the code or data carry a “does not leave” rule?
  6. Did this repository arrive as a clone from a source I control, rather than a zip, a shared drive, a sync folder, or a USB stick?
  7. Have I named the human who reads the first ten PRs in full, and the count after which “review less” is allowed?
  8. Is there a written cap on workers and a daily budget, with a stop I have tested?

Scoring. A no on 1, 2, or 3: single agent. A yes on 4 or 5: single agent plus a human approver, whatever the rest says. A no on 6: no agent of any kind opens it until intake is done. A no on 7 or 8: a coordinator only after the brakes below exist, not before.

If you use one anyway: four brakes on amplification

Brake 1: make the plan a reviewable artifact before fan-out

The plan is where the mistake is born, so it is the thing to read. No worker starts until a human has signed the plan file. Illustrative shape, checked into the repo the coordinator works on:

# coordinator-brakes.yaml: illustrative
plan:
  review: required # a human signs the plan before any worker starts
  max_units: 40
fan_out:
  max_workers: 8 # raise after ten clean PRs, not before
  environment: golden-image # one prebuilt image, not a fresh install per worker
unit_gate:
  tests: required
  max_diff_lines: 400
  paths_denied: ['infra/**', '**/*.lock', 'secrets/**', '.github/workflows/**']
merge:
  human_reviews_first_n: 10
  review_less_after: 10 # consecutive clean PRs, then sampling, never zero
abort:
  stop: coordinator_and_workers # both, or you have orphans
  partial_branches: keep_unmerged_and_name
budget:
  per_day_usd: 40
  on_exceed: pause_and_page

Brake 2: gate every unit mechanically, and deny paths rather than intentions

Tests required. A diff-size cap. A path denylist for infra, lockfiles, workflows, and secrets, enforced by branch protection and required reviews on the repository rather than by the coordinator’s good manners (GitHub Docs). AWS’s Sep 8, 2026 post on automated agent evaluation makes the general point in six words, “Without automated evaluation, agent quality is subjective,” and its pattern (fixed prompts, built-in evaluators, thresholds, block the PR on regression) is what a unit gate looks like at the agent level (AWS). If you cannot evaluate one agent’s output mechanically, you cannot evaluate N of them; the coordinator only makes the subjectivity parallel. The evals piece covers the harness side.

Brake 3: stagger merges, and give “review less” a number

“You review less” is a policy with a number in it, and you pick the number before PR one. Ten full reviews, then sampling at a rate you wrote down, never zero. Track two signals per PR: approve latency, and the share of approvals where the reviewer opened no file. When the second number climbs, the coordinator has started reviewing itself.

Brake 4: define abort before you need it

Stop means the coordinator and every worker, or you have orphans running CI on a plan you cancelled. Partial branches stay unmerged and get named. The interruptible coordinators playbook covers what pause, redirect, and abort must mean across CLIs, and metering fan-out covers the orphan sweep and the budget alarm.

Amplification path diagram: a spec with one wrong assumption becomes one coordinator plan, N faithful implementations, N consistent wrong PRs, a reviewer who reads less, and N merges, against a single-agent lane where one human catches it once The plan is the single point of failure; the fan-out replicates it on purpose. The dashed lane is the same spec routed to one agent.

What breaks, and how you’ll know

Consistency mistaken for correctness. Signal: N PRs with near-identical diffs and near-identical descriptions, and reviewers approving the second faster than the first. Fix: diff PR two against PR one, find the line they share, and ask what in the plan produced it. Then read the plan.

Environment failure, times N. Signal: workers failing in setup rather than in code, the same missing dependency across the fleet, tokens burned before the first edit. Fix: one golden environment before fan-out, never a fresh install per worker. The 65.04% figure above is the reason.

Orphaned workers after an abort. Signal: CI runs and usage continuing after you pressed stop. Fix: brake 4, tested on a throwaway branch before it matters.

The plan that was never written down. Signal: nobody can say, in ten lines, what the coordinator decided to do. Fix: brake 1. A coordinator that “is never blocked” is also never waiting for you to read anything, unless you make it.

A multiplier needs an operating layer around it

A coordinator is a multiplier. Multipliers are operating-layer infrastructure, not a smarter prompt, and they belong inside a layer that can count what they spent, stop what they started, and replay what they did. Vendor-hosted coordinators, Cursor’s and OpenAI’s alike, offer the multiplication and leave the layer to you. That is a fair deal, as long as you know it is the deal.

The desk-level version of that layer, one place that sees every agent on the machine, is the argument in the command center piece, and subagent orchestration covers how fan-out behaves inside a single CLI. The sibling on Cursor Projects and the tray has the ownership table for the days you say yes. The rule here is for the days you say no, which should be most of them.

FAQ: when an AI agent coordinator is the wrong tool

When should you not use an AI agent coordinator?

When the task is a single unit of work, when a change touches credentials, production infrastructure, or payment paths, or when the code or data cannot leave a controlled machine. In each case the coordinator adds environments, latency, and copies of any planning mistake while removing the one human read that would have caught it.

Do AI agent coordinators make mistakes worse?

Yes, by design. The coordinator writes one plan and delegates it to N workers who implement it faithfully, so a wrong assumption in the plan becomes N consistent wrong pull requests. Consistency across PRs then reads as correctness to a reviewer told to review less. Brakes: plan review, mechanical gates, a numbered review policy.

Is a coordinator safe for production changes?

Not for changes that touch credentials, infrastructure modules, lockfiles, CI workflows, or anything irreversible. Those need one agent, one approver, and one change at a time under a permission mode that asks before writing. Coordinators suit code-only units with tests, behind branch protection, where any single merge is one revert away from undone.

Sources

YOUR NEXT READ

Stay in the loop.

Explore all Intel ↗