Cursor Projects Keeps Context for Months — Nothing Reaches the Next Agent Unless a File Carries It (2026)

The launch entry is specific about scope. Projects, Cursor writes, "lets you take on larger bodies of work, such as a feature, a migration, or a full app. It maintains context over months of work, delegates tasks to thousands of subagents, and performs recurring work without being prompted."

The coordinator is deliberately not a coder: "The coordinator agent in a project doesn't write code itself; it plans the work, delegates it to agents that implement it, and brings the finished work back to you to check." It also runs somewhere you are not — "A Project runs on its own computer in the cloud, so closing your laptop doesn't stop it" — and it can start work on its own, watching a Slack channel, a schedule, or a set of pull requests.

The section that matters most for context is the one Cursor titled, in the announcement itself, "Shared context":

"Each Project maintains a set of files that sync across every cloud and local machine its agents use. Agents add research and artifacts, along with what they learn about the codebase and how you prefer work to be done."

And then the example that reveals the mechanism: "If one agent figures out how to test a service, for example, every future agent can use those instructions. The shared context grows with the Project, making the coordinator more effective over time."

Read that example closely. The benefit is real, and it is conditional. Every future agent can use those instructions because an agent wrote them into a file. The knowledge did not travel because the agents were connected. It travelled because it was written down.

Cursor's subagent documentation says the other half out loud:

"Subagents start with a clean context. The parent agent includes relevant information in the prompt since subagents don't have access to prior conversation history."

That is the whole model in two sentences. A subagent gets a prompt and a checkout. It does not get the history. The parent decides what to include, and the Project's synced file set is what survives the parent.

It does not change how much a single agent can hold. Cursor's own reason for isolating subagents is budget: "Each subagent has its own context window. Long research or exploration tasks don't consume space in your main conversation." The three built-in subagents — for codebase exploration, shell commands, and browser control — exist because those operations are noisy, and Cursor's stated rationale is that "Intermediate output stays in the subagent. The parent only sees the final summary."

So the thing that reaches the next step is a summary, by design. Anyone who has watched an agent confidently re-derive a decision it already made three hours ago has met the consequence of that design. Our earlier piece on what coding agents actually read walks through the same boundary from the single-agent side; Projects multiplies it by the number of workers.

It also does not make the shared file set a full record. Cursor is careful here too. In the August 19 release, a separate entry — not part of the Projects launch — introduced subagents on their own machines: "Subagents can now run on their own virtual machines. Each gets an isolated copy of the project with clean context in its own cloud environment." And the subagent docs warn about the default: "Subagents share the parent agent's checkout by default. When several subagents edit files at once, they can overwrite each other's changes."

What it does change is where the durable part of your project lives. Before Projects, a long-running effort lived in a chat you kept open and a set of instruction files you maintained by hand. After Projects, the chat is gone as a carrier — there are hundreds of chats, each starting clean — and the file set is promoted to the only channel. That is a better architecture. It also means the quality of your project's memory is now exactly the quality of what somebody bothered to write.

This is not a Cursor observation. It is where the category landed. Kiro's Crew documentation describes subagents that "run in parallel with isolated context." Factory defines custom droids as subagents "with their own system prompt, model, and tool policy that Droid delegates focused tasks to in a fresh context window." Zencoder's subagent pipelines "spawn isolated sub-processes with different models, contexts, and skills for parallel execution and clean context isolation." Warp takes the opposite tack on portability and says its "Rules, Skills, MCP servers, and Codebase Context apply the same way in the app, the CLI, and the cloud" — same conclusion from the other direction: the durable layer is the declared one, not the conversational one. That is not a criticism of any of them. It is four teams independently deciding that fresh context beats inherited context, and all four leaving you to supply the part that has to persist.

"The coordinator remembers, so I don't have to write things down." The coordinator maintains a file set. It does not maintain an oral history. Anything a subagent learned and summarised away is gone at the end of that subagent's run unless it landed in the files.

"Thousands of subagents means thousands of perspectives on my codebase." It means thousands of clean starts. Breadth comes from parallelism; continuity comes from the written layer. Our piece on why long context isn't memory makes the same distinction at the model level.

"This is the same problem as Claude Code's subagents." Close, but not the same object, and worth separating. Claude Code's subagents not sharing memory is about a single session fanning out and back. A Cursor Project is scoped to a body of work — "a feature, a migration, or a full app" — that runs for months across machines you never see. The blast radius is different, and so is the fix. Likewise, Cursor's cloud agents forgetting context covers a single remote run; this is about the layer that outlives every run.

"A Project is where my team's knowledge should live." Some of it, yes. But a Project is scoped to a Project. The conventions your team argued about for two weeks — why you rejected the other database, which service owns the migration, what "done" means for a release — are not per-feature facts. They outlive the Project that surfaced them, and they need to be readable by the next Project and by whatever tool the person next to you uses.

The goal is not to fight the architecture. It is to stop asking a per-Project file set to hold cross-project reasoning.

Step 1: Split the work's artifacts from the project's decisions

Go through what a Project accumulates and sort each item by one question: would this still be true after the feature ships? "How to spin up the payments service for tests" is an artifact of this work and belongs exactly where Cursor puts it. "We do not add a dependency without an owner" is a decision, and it will be just as true in the next Project, in your editor, and in the code review three months from now.

Artifacts go in the Project. Decisions go in a layer the Project reads from.

Step 2: Capture the reason, not just the rule

A coordinator that reads "use the repository pattern here" will follow it and will not know why. A coordinator that reads "we use the repository pattern here because the legacy adapter leaks connections under load, and we hit that in production" can tell when the rule stops applying. This is the difference between an instruction file and a decision record, and it is what makes the record worth carrying between Projects rather than rewriting each time.

Step 3: Give the record one address every surface can reach

Cursor syncs its Project files "across every cloud and local machine its agents use," which solves portability inside a Project. It does not solve portability across Projects, or across the other tools on your team. Put the decision record somewhere addressable, keep the Project file set pointed at it, and you stop maintaining the same paragraph in four places. Our note on turning project docs into AI memory covers the sorting pass in more detail.

A shared decision layer is what MemoryLake is for: one place the reasoning lives, readable by the coordinator, by the local agent, and by the next Project that has never seen any of this.

Step 1: Create an API key

Sign in, open your workspace settings, and generate an API key. This is the credential your agents and editors use to read the same layer, so create it once and keep it available to every surface you work from.

Step 2: Upload your first memories

Start with the decisions you have already explained more than twice: the architectural call and its reason, the conventions that have survived a review cycle, the constraints that are not obvious from the code. Keep each entry short enough that a coordinator can act on it without loading a document.

Step 3: Connect your AI & agents

Connect the tools you actually use — the editor, the terminal agent, the cloud runs — so the same reasoning arrives in each one. A subagent still starts clean. It just starts clean with the project's decisions already in front of it.

The first difference shows up when a Project ends. Instead of a file set that slowly goes stale in a closed Project, the reasoning is already somewhere the next Project reads, and the artifacts stay where they belong.

The second shows up when a coordinator delegates. Cursor's model has the parent decide what to put in the prompt. When the durable facts live in a layer the parent can quote from, that decision gets easier and more consistent, and you stop seeing subagents arrive at three different answers to a question you settled in May.

The third shows up on your worst day. A Project running unprompted against a bug-report channel will eventually take an action you would not have taken. The useful question afterwards is what it was working from — and that is answerable when the standing decisions are written and versioned rather than reconstructed from a summary. Auditing what your AI remembers is the practice that makes that answerable.

Write for a reader with no history. Every subagent is that reader. Entries that begin "as discussed" are entries that will be misread.

Keep the always-true separate from the currently-true. Sprint state belongs in the Project. Standing decisions belong in the layer underneath it. Mixing them means the layer decays the moment the sprint ends.

Record the rejected option. The cheapest way to stop an agent from re-proposing something is to have the refusal and its reason written down once.

Re-read what an agent wrote about your codebase. Cursor says agents add "what they learn about the codebase and how you prefer work to be done." That is a genuinely useful mechanism and it is also an inference. Treat the first few entries as drafts and correct them, the same way you would correct a new teammate's onboarding notes.

Assume the handoff is lossy and make it cheap. You cannot widen the channel between agents. You can make sure the thing travelling through it is the conclusion rather than the transcript.

Cursor Projects is a serious piece of engineering and its context model is the honest one: subagents start clean, the parent supplies what they need, and the Project's synced files are what survives. The consequence is simple to state and easy to miss. In an architecture where every worker starts from nothing, the written layer is not a nice-to-have. It is the entire bandwidth between everything that happens today and everything that happens next month.

Projects are in beta and rolling out to all users. If you are about to point a coordinator at months of work, the highest-leverage hour you will spend is not on the prompt. It is on writing down the decisions you would otherwise expect it to remember.