Cursor adds team mode to Projects: colleagues' agents share context and tasks

If you have tried running several coding agents in parallel, you know what it looks like in practice. One person, one coordinator, a bunch of workers. Everything is fine as long as you work alone. As soon as a second engineer joins the task, each person ends up with their own set of chats, their own context, and their own version of what is actually going on. Cursor set out to solve exactly this problem: Projects has become "multiplayer."

What has changed

As a reminder, Projects is a mode in which an engineer drives a large task through a single coordinator, which distributes work among agents. Previously, this system served one person. Now you can invite colleagues into a Project, and the whole team works in one space together with all the agents.

The company highlights three things.

First, a shared task board. It shows who is working on what, what each participant's agents are doing, and which pull request stands behind each task. People and agents look at the same up-to-date picture instead of piecing it together from chats and threads.

Second, a shared context layer. Each participant still has a personal chat with a coordinator and workers with their own local context. On top of it sits a common base: requirements, diagrams, technical specifications, mockups. A decision made in one chat becomes available to all agents in the project. When a new person joins a Project, the context is already set up and current.

Third, agents communicating with each other. Colleagues' coordinators can see what their neighbors are doing and can negotiate without human involvement.

What it looks like in examples

Cursor gives several scenarios. The most down-to-earth one is on-call rotations. Several teams at the company run a rotation in a shared Project. When one engineer took over a shift from a colleague, their coordinator first checked that everything was correct, then continued from where the previous one left off. It already knew which tasks were in progress, which requests had gone unanswered, what needed to be handed over regarding incidents and notes, and which channels, Linear boards, and threads to watch. Unfinished work can be handed over directly: the new on-call engineer's agent simply picks it up.

Two other examples are about conflicts. An engineer is adding reviews to a product page while a designer is redesigning it at the same time. The coordinators spot the overlap in advance, and the reviews are built straight into the new design, with no refactoring later. Or your feature reads from the database while a colleague changes the schema: the agents agree on the order of work beforehand, and you don't have to untangle merge conflicts at the end.

The idea is clear and familiar: what used to be settled in a standup or in correspondence is shifted onto coordinators.

What to keep in mind

All of this is so far the vendor's own description. There are no numbers: not how much time the shared context saves, not how often agents actually catch overlaps, not how often they make mistakes. The examples with reviews and the database schema look like illustrations rather than measurement results. Only the on-call rotations are described as real practice, and even then inside the company itself.

Open questions remain too. Who verifies the shared context layer, and how, if an incorrect decision ends up there that all agents now see? How are access rights to documents and channels handled? What happens if the coordinators agree on an order but the people think differently? The blog doesn't answer these. The mode has also only just reached beta.

What to do in practice

If your team already uses Cursor, it makes sense to try a Project on one small but real task involving two or three people. Good candidates: on-call handoffs, a feature that overlaps with someone else's work, onboarding a new developer. You can create a Project in the left-hand menu, then invite colleagues.

Immediately ask yourself two questions. Has less time gone into explaining context to newcomers? Has the number of merge conflicts decreased? If the answers are positive, that's a signal the shared context layer works. If not, it's still a nice idea rather than a working tool. For product managers and team leads, the main takeaway is simple: competition among coding agents is shifting from "whose agent is smarter" to "whose system better organizes the work of several people and several agents together."