Cursor 3's parallel agents change what a template ships with

Parallel subagents punish vague conventions in a way single-threaded agents never did. When three model instances edit your codebase at the same time, every implicit rule you never wrote down becomes a merge conflict, a duplicated dependency, or a broken import. Templates have to ship machine-readable conventions now — forbid-lists, locked libraries, and dependency-graph prompts — or the human spends the speedup on cleanup.

Cursor's changelog is the canonical record of this direction: async subagents, cloud agents running on your own sandboxes and infrastructure, and dynamic pool scheduling that scales workers with demand. The through-line is unmistakable — the editor is becoming an agent platform, and the project's conventions have to live in files the agent actually reads.

What parallel execution breaksCopy Anchor Link

We tested parallel plan execution on a typical kit task: add a new entity end-to-end (schema, API route, list page, detail page, types, prompts log row). Run linearly, one agent working top to bottom, it took about six minutes forty seconds in our testing. Dispatched as parallel branches with a solo wiring step at the end, it took about two minutes ten seconds. Three subagents writing three files at once, then a fourth pass that wires the exports once they land.

Those timings are from our own testing, not vendor benchmarks — your numbers will differ by task and model. The interesting part is not the speedup anyway. It is what breaks when three model instances edit your codebase simultaneously, and three things broke immediately.

1. Shared barrel files. Every subagent wanted to append its new component to the shared UI barrel file alphabetically. None of them could see each other's pending edits. Result: near-simultaneous writes, with two silently overwriting the third. The file looked fine until the missing export surfaced at build time.

The fix is to take the barrel out of the agent's path entirely. We keep one human-owned barrel file and a forbid-list in our agent instructions:

## Forbidden files (agents must NEVER edit)
- `packages/ui/src/index.ts` — barrel, hand-curated, edited solo
- `apps/landing/data/component-registry.ts` — gallery wiring
- `package.json` — only the lead engineer adds deps

2. Convention drift across parallel branches. One subagent picked one color-picker library. Another, working a different branch of the same task, picked a competing one. Both finished. Now the codebase ships two color pickers that do the same job. This is the failure mode unique to parallelism: each choice was reasonable in isolation, and no single agent ever saw both.

The fix is to lock libraries in your agent rule files before any plan is generated, not as a code-review pass after:

## Locked libraries (use these, NEVER alternatives)
- color picker → react-colorful (NOT react-color)
- markdown → @tiptap/react (NOT remirror, NOT slate)
- forms → react-hook-form (NOT formik)

If your conventions live only in a maintainer's head or a wiki page, parallel agents will route around them. If they live in .cursorrules and CLAUDE.md, every branch inherits them. Our guide to writing rule files agents actually respect covers the full format — file tree, import layout, anti-patterns — that turns agents from guessers into extenders.

3. Implicit file ordering. "Add the schema first, then the route" works when one agent runs the plan top to bottom. With parallel execution, the route gets written before the schema lands, the type import resolves to nothing, the route file ships broken, and the next subagent that reads the route picks up the broken pattern and propagates it. Ordering assumptions are the silent killer of parallel plans.

The fix is to make dependencies explicit in the plan template, not in file order. Every step declares the output files it requires from other steps. The dispatcher — human or model — can then build a real dependency graph instead of trusting sequence.

What a template has to ship nowCopy Anchor Link

The better models get at multi-tasking, the more project conventions have to live in machine-readable form. Parallel agents cannot read between the lines, so a template that ships vibes instead of constraints is a template that generates cleanup work. For our kits, that meant a real audit with three outcomes.

First, every "do this then that" pattern got rewritten as a dependency graph. No more "after step 3, run step 4." Now each step names the output file it depends on. The model can dispatch branches that share no writes concurrently and serialize the ones that do.

Second, every locked library moved into .cursorrules and CLAUDE.md in a top-of-file block, not buried in a dependencies section. Placement matters: instructions at the top of the context window survive long plans better than instructions in the middle. A well-structured agent-readable repository makes this inheritance automatic — each directory's conventions travel with the files being edited.

Third, every barrel, index, and registry file went into a forbid-list. Parallel agents that need to register a component now emit a follow-up "wire this up" task that runs solo against a single agent, never in parallel. We also added a parallel: false flag on a handful of tasks in our prompt library for steps that touch shared files. When a prompt declares a task is not parallelizable, the run stays linear for that step.

The background-agent angleCopy Anchor Link

Background agents compound all of this. A background agent finishes long after you have moved on to something else. If it merges into a barrel file you just touched, your foreground state is wrong and you do not know it until the build breaks or, worse, until production tells you.

Our rule is simple: background agents are scoped to one feature directory and forbidden from touching anything outside it. The same forbid-list does the work — the rule fires whether the agent is foreground or background. Scope plus forbid-list covers both execution modes with one mechanism, which is exactly the kind of consolidation that keeps rule files short enough that agents actually follow them.

What it means for kit buyersCopy Anchor Link

The kits ship with the forbid-list, the locked libraries, and dependency-graph-style prompts already wired. When you scaffold a project and open it in Cursor, the agent reads the rule files, sees the constraints, and dispatches parallel work that does not step on itself. The shared-architecture approach — one component API across web and mobile — further shrinks the surface where drift can hide, because there is one convention to follow instead of three.

The point is not that any single release is good, though the async and cloud-agent direction documented in Cursor's changelog genuinely is. The point is that parallel execution makes convention quality the bottleneck. Templates that do not ship machine-readable conventions are about to feel slow — not because the model is slow, but because the human keeps cleaning up after it.

If you are building your own kits, write your rule files with three parallel subagents in mind. Locked libraries up top. Barrels forbidden. Dependencies explicit. That is the bar now.

Ready to start from conventions that already survive parallelism? Browse the OTF kits →

SourcesCopy Anchor Link

• Cursor changelog (canonical release record; confirms async subagents, cloud agents on self-hosted infrastructure, dynamic pool scheduling) — https://cursor.com/changelog
• Cursor changelog: self-hosted machines (agent execution on your own infrastructure) — https://cursor.com/changelog/self-hosted-machines