Your day probably looks like this: three Cursor windows open, manually assigning work to each AI, switching back and forth, then losing track of which task got to which step.
The point of Cursor’s new Projects isn’t that “the AI got smarter.” It’s that you stop being the person directing AI and become the person handing AI a goal.
So who’s in the middle, breaking down tasks, tracking progress, closing things out? Cursor’s answer: a coordinator agent.
On September 10, 2026, Cursor officially launched Projects (beta). The official line: it introduces a coordinator agent that dispatches thousands of sub-agents in parallel, taking on feature development, large-scale migrations, and full application builds.
Let me break this down by “what it actually solves,” “how the three pillars work,” and “which scenarios you can use today.”
1. Projects isn’t solving “AI can’t write code” — it’s solving “you can’t keep up”
Single-agent mode has a ceiling, and anyone who’s used it long enough knows it: fixing a small bug or writing a function is smooth. The moment it becomes a framework migration spanning hundreds of PRs, manually assigning work becomes the bottleneck itself.
You have to remember which branch is at which step, which PR is stuck in review, which subtask has already gone off the rails. The AI isn’t tired — you are.
Projects is aimed squarely at this: feature development, large-scale migration, full application builds — three categories of large work. The developer’s role shifts from “managing agents” to “directly commanding tasks.”
That sounds like marketing, but unpacked it has real substance: before, you wrote prompts, watched output, corrected drift. Now you give a goal, and the coordinator breaks it down, dispatches it, and closes it out.
This is the dividing line between “AI-assisted” and “AI-contracted.” Assisted means you do the main work and AI lends a hand. Contracted means you set the acceptance criteria and the process runs itself.
2. Three pillars — miss one and nothing runs
Projects has three architectural pieces. I’ll go in order of “which one is easiest to trip over.”
First: cloud by default, local testing on demand.
Each Project runs on its own cloud computer, and closing your laptop doesn’t interrupt it. This matters more than it sounds — running parallel tasks locally means your fans blow up and your machine chokes first. Cloud means you can hang dozens or hundreds of sub-agents off it, beyond local compute limits.
When local verification is needed, the coordinator automatically spins up local agents to handle it. That’s a pragmatic design: not every test can run in the cloud, and some depend on local environments.
Second: shared system context.
Each Project maintains a set of continuously synced files where agents deposit research findings, codebase understanding, and preference settings. The longer you use it, the better the coordinator understands your project.
This is the piece I care about most. The biggest pitfall in multi-agent setups isn’t compute — it’s inconsistent context: agent A changes an interface, agent B is still writing calls against the old signature. Shared context is essentially handing a group of agents the same “current state of the project.”
Third: intelligent subscription.
The coordinator can monitor Slack channels, run on a schedule, and track all PRs, taking action on its own when it detects a signal — no repeated prompting from you.
In plain terms: before, you asked “is it done yet?” Now it notices CI broke, a PR has a conflict, or someone dropped a new requirement in Slack, and acts on it.
Few products currently ship all three together. Copilot’s agent mode, Devin, and Claude Code each lean a different way, but “always-on cloud + shared context + event subscription” as a complete set is genuinely rare.
3. Three scenarios — what works now and what has to wait
The official material gives three deployment patterns, but they’re at different maturity levels. Don’t treat them as one bucket.
| Scenario | How it runs | My take |
|---|---|---|
| Feature development | Research builds context → coordinator sets plan → sub-agents implement and test in parallel → monitor logs and fix bugs after launch | Try it now |
| Code migration | Hundreds of PRs advanced step by step, strict human review early, hands off only once the approach matures | Humans must watch early |
| Gardening-style maintenance | Code quality monitoring, regression testing, e.g. auto-extracting design system components to generate rules | Most underrated |
Feature development is the smoothest category. The loop is clear: research first, then plan, then parallel implementation, then monitoring. Good for requirements with clear acceptance criteria.
Code migration is the cure for “easy to start, hard to finish.” Framework upgrades and style replacements are satisfying to kick off and brutal to close out. Projects’ approach is strict human review early, then let the coordinator run autonomously once the approach has matured. Note that this order can’t be reversed — hand it everything from the start and a few wrong patterns slip into hundreds of PRs, and cleanup costs more than writing it by hand.
Gardening-style maintenance is, I think, the most underrated. Code quality monitoring and regression testing — the “nobody wants to do it but it has to be done” work — is exactly what agents are good at: clear rules, high repetition, unambiguous acceptance criteria. Like auto-extracting design system components and generating rules on the fly.
My tradeoff advice: don’t throw a million-line migration at it on day one. Start with tasks that have clear acceptance criteria and controllable failure cost, get a feel for the coordinator’s temperament, then scale up.
4. The official numbers look good — read the fine print
Cursor says internal teams tested deeply for months, using it on migrations and feature releases involving hundreds of PRs.
The numbers: new users merged 30% more PRs; users who rely mainly on Projects merged 6x as many PRs.
To be clear: these are Cursor’s own figures, with no third-party verification. The “merged PR count” metric itself has room to inflate — split PRs finer and the count naturally rises. Fine for reading a trend, not for copying into a KPI.
A few information gaps worth flagging:
- Pricing, quotas, and the supported model list are all unannounced
- Whether “thousands of sub-agents” is a capability ceiling or a measured scale isn’t distinguished in the coverage
- Status is beta, rolling out gradually to all users — getting on now means being a test user
My own read: at beta stage, don’t hand over the lifeline of your production environment. Use it for internal tools, non-core modules, tech debt cleanup — scenarios where a crash isn’t fatal.
FAQ
How is Projects different from a normal Cursor conversation?
A normal conversation is single-agent, with you assigning work manually. Projects has a coordinator breaking down tasks and sub-agents executing in parallel — you give goals, not instructions.
Can I use it now?
It’s in beta, rolling out gradually to all users. Whether you get it depends on your account batch.
Is it good for small projects?
Not really. Small changes are faster with a single agent. Projects’ value shows up at the scale where one person can’t keep up.
Can code migration be fully automated?
The official design is strict human review early, hands off later. Going fully automatic in one step is high risk.
The bottom line
The real watershed here isn’t “AI can work in parallel now.” It’s that the coordinator layer got productized — you no longer have to be the scheduler yourself.
But beta is beta. Start by using it on the dirty work you’ve always wanted to do but never had time for. Once it runs smoothly, then talk about contracting out large-scale development.
What task do you have right now that’s “too much for one person to manage, but too risky to hand over entirely”? Drop it in the comments — I’ll pick a few typical scenarios and talk through how to break them down.