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

Cursor 3 ships a thing called "Build in Parallel." The pitch is straightforward: instead of executing a plan step by step, Composer identifies which steps are independent and runs them as concurrent subagents.

It's a real shift. And it changes what a useful production template has to look like — because parallel agents punish vague conventions in a way single-threaded ones never did.

What changed

Cursor's May 2026 release notes describe it like this: Composer breaks a plan into a dependency graph, identifies branches with no shared writes, and dispatches them to async subagents. You watch a tree of tasks finish in roughly the time the longest single branch would have taken — not the sum.

It works. We tested it on a typical kit task ("add a new entity end-to-end: schema, API route, list page, detail page, types, prompts.md row"). Linear plan: 6 minutes 40 seconds. Parallel plan: 2 minutes 10 seconds. Three subagents writing three files at once, then a fourth subagent that wires the index export once they're done.

The interesting part isn't the speedup. It's what breaks when three model instances edit your codebase simultaneously.

Three things broke immediately

1. Shared barrel files. Every subagent wanted to append its new component to packages/ui/src/index.ts alphabetically. They didn't see each other's pending edits. Result: three near-simultaneous writes, two silently overwriting the third.

Fix: take the barrel out of the agent's path entirely. We now have one human-owned index.ts and a forbid-list in our CLAUDE.md:

## 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 react-colorful. Another, working on the same task, picked react-color. They both finished. Now your codebase has two color pickers.

Fix: lock libraries in .cursorrules before the 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)

3. Implicit file ordering. "Add the schema first, then the route" worked when one agent ran the plan top-to-bottom. With parallel execution the route gets written before the schema lands, the type import is undefined, the route file ships broken, and the next subagent that reads the route picks up the broken pattern.

Fix: make dependencies explicit in the plan template, not in the file order.

What "a template ships with" needs to change

Cursor 3's Meet the new Cursor announcement makes the same point in different words: the better the model gets at multi-tasking, the more your project's conventions have to live in machine-readable form. Parallel agents can't read between the lines.

For our kits, that meant a real audit:

• Every "do this then that" pattern got rewritten as a dependency graph. No more "after step 3, run step 4." Now: "step 4 requires step 3's output file at <path>." The model can build a DAG and dispatch correctly.
• Every locked library moved to .cursorrules and CLAUDE.md. Not buried in a deps section — in a top-of-file "Locked libraries" block.
• Every barrel/index/registry file is in 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 (ai/prompts/add-entity.md, add-screen.md) for steps that touch shared files. Composer respects it — if the prompt declares the task isn't parallelizable, the agent runs it linearly.

The Background Agents angle

Cursor 3's Background Agents compound this. A background agent finishes long after you've moved on. If it merges into a barrel file you just touched, your foreground state is wrong and you don't know it.

Our rule now: 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.

What it means for kit buyers

The kits ship with the forbid-list, the locked libraries, and the dependency-graph-style prompts already wired. When you pnpm dlx create-otf-app and open Cursor, Composer reads CLAUDE.md, sees the constraints, and dispatches parallel work that doesn't step on itself.

The point isn't "Cursor 3 is good." Cursor 3 is good — that's not the news. The news is that parallel agent execution makes convention-quality the bottleneck. Templates that don't ship machine-readable conventions are about to feel slow not because the model is slow, but because the human keeps having to clean up after it.

If you're building your own kits, write your .cursorrules and CLAUDE.md with three parallel subagents in mind. That's the bar now.