Run the fleet.

Four of the major coding agents shipped variants of the same shape in the past two weeks, and they line up too neatly to ignore. Cursor 3's new Build in Parallel mode reads the plan a developer just approved, identifies which steps are independent, and dispatches them as async sub-agents that run in their own contexts. Anthropic's Claude Code sub-agents — versioned in a project's .claude/agents/ directory and team-shareable — let a manager agent delegate to specialised workers with their own model and tool permissions. Codex sub-agents ship the same pattern for the OpenAI side. Gemini CLI added parallel sub-agents earlier in the spring. VS Code's multi-agent dev mode rounds the set out.

What changed at the surface.

Until very recently the standard agentic web-build session looked like a chat: one developer, one agent, one queue of turns. The agent picked up a ticket and worked through it in series — read the file, edit the file, run the test, fix the regression, ship the patch. That shape is dissolving. The agent that gets the ticket now reads it, writes a plan, and hands the leaves of that plan to a small team of cheaper, narrower agents that run at the same time. The five-page-site demo making the rounds this week — a marketing site with hero, pricing, FAQ, blog index, and contact, stood up by three sub-agents in roughly the time a single agent took to ship two pages — is the most legible example, but it is one of many.

Why this is showing up everywhere at once.

Two pre-conditions had to land first, and both did in April. The first is that model providers cut session-startup time hard enough that spinning up a second or third agent is no longer a tax — Anthropic's late-April release made sub-agent and MCP initialisation parallel by default, so a manager agent that fans out to three workers no longer pays a thirty-second penalty before any of them start. The second is that a community-driven convention for shared project memory stabilised. The AGENTS.md file — read natively by Claude Code, Codex, Cursor, Aider, Devin, Copilot, Gemini CLI, Windsurf, and Amazon Q — gives a fleet of agents the same code book, so the boats actually understand each other's signals.

Put those together and the cost of the second agent fell below the cost of waiting for the first. That is the moment a fleet becomes the rational default.

The technique under the parallel-agents pattern is older than the model. Any system that splits work between distributed actors has to answer three questions: how does the manager split the work, how does each worker signal progress, and how does the manager gather the results back into one piece of artifact. The teams shipping cleanly this week are doing those three things explicitly — not letting the agent improvise them.

Split: by surface, not by stack.

The temptation, the first time a team runs parallel agents on a web build, is to split the work the way a back-end team would: one agent on the data layer, one on the API, one on the UI. It almost never works. The reason is coupling — every UI decision needs the API to be there first, so the UI agent stalls while the API agent finishes. The split that does work is by surface. Page A to one agent, Page B to another, Page C to a third. Each agent owns a self-contained slice of the artifact end-to-end. The seams between agents end up at page boundaries, which is the same place the design team has always drawn them.

Signal: short, public, machine-readable.

A sub-agent that fans out for five minutes and comes back with a paragraph of prose is worse than no agent at all. The format that works is the format navies have been using since the eighteenth century — short, hoisted, public. A sub-agent should write a one-line status line every minute or two — "Hero shipped, pricing in progress, FAQ blocked on tokens" — into a place the manager can read without context-switching. In Claude Code, the convention is a status.md at the project root. In Cursor 3, it's the parallel-agents panel. Either way, the principle is the same: a hoist is a banner, not a letter.

Gather: one merge, one set of eyes.

The single biggest failure mode is the manager that lets three workers merge their own PRs in sequence. Every team that tried it in the past month reported the same thing: by the time the third worker rebases on top of the second, the assumptions the second made about shared components have drifted out from under it. The pattern that holds is to make every sub-agent open a draft PR, let the manager review them all together as one batch, resolve conflicts in a single integration pass, and merge as a unit. The fleet returns to harbour together or not at all.

The shape that's emerging in design studios shipping with parallel sub-agents this month looks more like a watch rotation than a sprint. A small product team — a designer, an engineer, a brand lead — sit at the bridge. The fleet sits in the harbour. The work moves through three watches of roughly an hour each, and the humans hand off between watches rather than working through them.

First watch — Plan.

The bridge writes the plan with one manager agent, in the chat. No code yet. The output is an AGENTS.md update: roster, scope of authority for each role, success criteria. The designer at the bridge is the one in the seat, because shape-of-the-thing decisions — how many pages, what each page is for, what success looks like per page — are design decisions, not engineering ones. The agent helps map the territory; it does not pick the destination.

Second watch — Dispatch.

The bridge hands the plan to the manager agent and steps back. The manager dispatches three or four sub-agents — one per page, one inspector — and watches their hoists. The humans glance at the parallel-agents panel every few minutes and answer questions, but they are not in the loop on every keystroke. The right number of sub-agents in this watch is small. Most teams reporting this week top out around three to five — beyond that, the coordination overhead starts to eat the parallelism gain.

Third watch — Gather.

The bridge takes over again. The inspector sub-agent's report goes up first, with screenshots of every page in light and dark. The bridge reads it, accepts or rejects, and walks the producer's PR through merge. The site is up at the end of the watch. The roster stands down.

The prompt below is a lightly generalised version of one a small studio in Brooklyn is running as the manager agent in a three-sub-agent web-build pipeline. They feed it the AGENTS.md, the sprint ticket, and a list of available worker agents with their roles and model choices. The bones are the part to copy; the names of the roles and the model picks are the part to swap for your own.

You are the manager agent on a fleet of three sub-agents. You do not
write production code yourself. Your job is to read the ticket, plan
the work, dispatch it, and gather it back. Treat each sub-agent like
a colleague on a different ship who can hear your signals but not
read your mind.

For every ticket, produce four things — in this order:

1.  ROSTER. List every sub-agent you intend to use, their callsign,
    their scope of authority, and the model they should run on. Read
    AGENTS.md first; do not invent roles that are not in the code book.

2.  PLAN. Break the ticket into independent surfaces — one per
    sub-agent. If a surface depends on another, name the dependency
    explicitly and order the dispatch. Refuse to dispatch in parallel
    surfaces that share state.

3.  HOIST. For each sub-agent, write a one-screen brief: what they
    own, what they cannot touch, what "done" looks like, the
    success criteria the inspector will check against.

4.  WATCH. Once dispatched, check sub-agent status every two minutes.
    Read their hoists. Answer their questions. Do not edit their work.
    Do not let them edit each other's.

When all sub-agents have filed their drafts, run the inspector against
the bundle. Merge as a unit or send the whole batch back.

You speak in hoists, not paragraphs. Be specific about who, what, and
done. The fleet returns to harbour together or not at all.

The clause that does the heaviest lifting is the second one — refuse to dispatch in parallel surfaces that share state. Without it the manager will happily fan three sub-agents into the same component file, then spend an hour reconciling their conflicting rewrites. With it, the plan reshapes itself into surfaces that can actually be built in parallel — which is the whole point of having a fleet.

1. Cursor 3 — Build in Parallel with async sub-agents and the new Agents Window Cursor
2. Cursor in Microsoft Teams — @Cursor delegation from chat, agents that file PRs back Cursor · 11 May 2026
3. Claude Code sub-agents — isolated context, per-agent model selection, version-controlled roles Anthropic
4. Claude Code agent teams — five-page website built with three parallel sub-agents MindStudio
5. Codex sub-agents — OpenAI's parallel-worker pattern for the Codex CLI OpenAI
6. Subagents have arrived in Gemini CLI — Google's take on parallel worker fanout Google Developers
7. Multi-agent development in VS Code — your home for running agents in parallel Visual Studio Code
8. AGENTS.md — the open code book for agentic coding tools Open spec
9. Code with Claude 2026 — dreaming, outcomes, multi-agent orchestration Anthropic
10. Claude Code agent teams — parallel workflows and the three-to-five-agent ceiling MindStudio
11. Vibe coding and agentic engineering are getting closer than I'd like Simon Willison · 6 May 2026
12. Claude Agent SDK credits — programmatic usage on a separate meter from June 15 Anthropic · 13 May 2026