Cursor's Projects Goes Multiplayer So Coding Agents Coordinate Before Conflicts Hit
Cursor Projects now lets entire teams and their coding agents share one workspace, with cross-teammate agent coordination to prevent conflicts.
- Cursor Projects is now multiplayer, letting teammates and their agents share one workspace in beta.
- Shared context layer holds docs, diagrams, plans, memory, and task assignments across the whole team.
- Each user keeps a private coordinator and worker agents on top of the shared layer.
- Coordinators from different teammates communicate to flag conflicts and sequence work before merge issues happen.
- On-call handoffs cited as early use case: incoming engineer's agent picks up in-flight work automatically.
- Rolling out in beta to all Cursor users; create a Project from the left nav to start.
Cursor has added team collaboration to Projects, its workspace for coordinating coding agents. The multiplayer update lets teammates’ coordinator agents exchange plans, identify overlapping work, and flag dependencies before code reaches a pull request. Cursor says the beta is rolling out to all users.
Projects debuted in September as a way for one engineer to direct several worker agents through a coordinator. Multiplayer extends that model with project-wide context, tasks, and agent communication. For development teams, the change could reduce duplicated setup and expose collisions earlier in the implementation cycle.
A shared control plane
Each teammate retains a private conversation with their coordinator and separate local context for worker agents. The Project adds a shared task board that records assignments, agent activity, and the pull request associated with each task, giving the team a current view of work in progress.
Projects uses two context layers, separating each person’s active agent sessions from information that the wider team needs:
| Layer | Access | Contents |
|---|---|---|
| Local context | One teammate and their agents | Coordinator chats, worker-agent context, and active task details |
| Shared context | Project members and their agents | Requirements, technical specifications, diagrams, mockups, files, notes, plans, memory, chat history, and assignments |
Cursor says decisions made during one teammate’s work can become available to every agent in the Project. That shared layer gives coordinators enough information to compare plans and account for work already underway.
Less context to rebuild
Teams using coding agents often duplicate the same background across personal .cursorrules files, scratchpads, prompts, and architectural notes. New teammates must reconstruct that context before their agents can work effectively. A Project packages the team’s existing documents, memory, and assignments so an invited member can start with the current state.
Cursor illustrates the handoff with an on-call rotation. When one engineer takes over, their coordinator can already know which incidents remain open, what work is in progress, and which Linear boards require attention. The incoming engineer can also assign unfinished work to their own agents without recreating the task from a separate handoff.
Coordinators compare plans
Coordinator agents can announce intended work before execution and warn one another when plans overlap. Cursor gives two examples of how that coordination could affect day-to-day development:
- Overlapping product work: An engineer adds reviews to a product page while a designer revises the same interface. Their coordinators identify the overlap and align the implementation with the new design.
- Schema dependencies: One feature reads from a database while another teammate changes its schema. The coordinators agree on sequencing before either set of changes reaches a pull request.
The coordination runs inside Cursor Projects. Cursor’s announcement does not describe an external API, an open agent-to-agent protocol, or interoperability with coordinators from other products.
The beta’s open questions
Cursor has not published benchmarks, failure rates, or detailed controls for multiplayer coordination. Teams evaluating the beta will need to test several unresolved areas:
- Conflict resolution: How coordinators proceed when they recommend incompatible plans.
- Context boundaries: Which chat decisions enter shared memory and which remain local.
- Access control: How permissions apply to documents, tasks, conversations, and agent-generated changes.
- Memory maintenance: How stale decisions are corrected, summarized, or removed as a Project grows.
- Reliability: How often agents detect dependencies, miss them, or raise unnecessary warnings.
Teams can create a Project from Cursor’s left navigation and invite colleagues. The beta is most relevant to organizations already running several coding agents across shared repositories, where duplicated context and concurrent changes create recurring coordination costs.
Comments
