Cursor Projects multiplayer: team agents share a board

What Cursor shipped on November 10

On November 10, 2026, Aryaman Khandelwal published Cursor Projects is now multiplayer ↗. September's Projects let one engineer direct a coordinator, which directs worker agents on Cloud Agents. The blog says multi-agent systems have so far served one person. This upgrade invites teammates in.

@cursor_ai ↗ posted at 23:20 UTC: "Your agents can now coordinate with your teammates’ agents." The next post ↗ says: "Agents share plans before they start, flag conflicts while they work, and unblock each other’s tasks across the team. Launching in beta today."

The blog says it is "rolling out in beta to all users in Cursor starting today." The docs ↗, fetched November 12, add limits. Sharing needs a team account and Cursor 3.26.13 or later. A teammate needs access to the repository. Joining is unavailable with Privacy Mode (Legacy), on a self-hosted Project, or on an archived Project. Invites stay inside one Cursor team. The owner can Reset Share Link.

Projects themselves need a plan with Cloud Agents: Premium and higher, Teams, Enterprise, and legacy paid plans. The docs exclude Free, Plus, and the legacy Hobby plan. The blog's "all users" and the docs' plan rules are both published. Read the docs before you send an invite.

What is shared, and what bills as you

Each person gets their own chat, coordinator, and workers. That chat runs and bills as them. Two things are shared. The task board shows the same tasks, who is on them, and the pull request behind each task. Shared context (Context in the app) is one store every member's agents read and write. The blog says it holds requirements, diagrams, specs, and mockups, and that a decision in one chat is accessible to every agent in the Project.

A personal store stays on your account. The docs say teammates' agents do not see it. Preferences and skills live there, and copying one into the Project rules takes your approval.

Coordinators message each other. Cursor labels the text as agent input and tells the receiver it is untrusted. It lands in a side chat, "Chat with {name}'s agent." You can read, stop, or archive that chat. The docs say you cannot message it. It answers from what your chat knows, never shares secrets, credentials, or tokens, can read the task board, and cannot change the board, ask questions, request access, connect source control, or manage routines.

Cursor's on-call example is its own teams: a coordinator taking a rotation already knew which work was in flight. The blog also describes two people whose agents order the work and avoid a merge conflict. That is a scenario in the post. The launch posts include no measurement of conflicts avoided.

Who it is for

Use it on a Cursor team that already runs Cloud Agents, with two or more people in one repo. On-call handoff is the case Cursor describes. Parallel feature work is the other: two coordinators, one task list, a pull request on each task.

September's version already served a team of one. Google's /swarm in Antigravity, covered in our Gemini 4 Carbon post, turns one prompt into "a coordinated team of agents," with Carbon planning and lighter models doing the parallel work. That fleet has one user. Perplexity Teammates, from the company's November 4, 2026 launch as reported in that piece, are Max-plan agents that hand work to other teammates and message coworkers in Slack. That product lives on the web. Cursor's board lives on the repository.

Our Copilot vs Cursor and Claude Code reviews cover the single-assistant products. This post does not retest them for a shared project board. Cursor's line that Projects is "the first workspace where software teams work side by side with all of their agents" is Cursor's claim. Build Live Apps (November 5) is how a cloud agent publishes an app. Single-assistant rankings are in the 2026 coding guide.

What people are saying

• "Astute observers will note: Cursor launched a slack, Google Docs, notion & linear/JIRA competitor." wrote Nick Dobos ↗.

• "I expect multiplayer Projects to produce more merge conflicts before it produces less work." wrote @Aureus_xyz ↗.

• "Biggest gripe is that it is cloud only and viewing design work on a cloud machine is very low quality compared to viewing it locally." wrote John Intrater ↗.

• "a decision made in one chat reaches every agent. So does a wrong one." wrote @RogerThat_ ↗.

• "Most indie iOS devs I know are a team of one though lol." wrote @realjoeginley ↗.

Reddit was not reachable for this story.

Our take

Send the invite when the team is already on Cursor Teams, Cloud Agents are on, and at least two people share the repo. The board plus the pull request is what a human can check. On-call is where the shared store pays for itself: the next person starts from notes already in the Project. Skip it on Privacy Mode (Legacy) and on self-hosted Projects. The docs exclude both. Update to 3.26.13 before the invite works.

Treat shared context as a system prompt. Side-chat messages are untrusted, and that chat cannot change the board or reveal secrets. The store is the other path. A wrong requirement, or a spec someone pasted, becomes every agent's instruction. Read Context before the next invite. Usage bills to the member whose chat ran.

Plan on a heavier review queue. @Aureus_xyz expects more merge conflicts first. Cursor's schema story hopes the agents order the work. Each worker still opens a pull request. John Intrater's limit is real for design work: the Project runs in the cloud, and a local agent starts when a test has to run on your machine.

Skip the invite if you work alone. September's Projects and Google's /swarm already parallelize one person's tasks. For a single assistant, start with the coding guide.