Three different things are called Projects

Claude has Projects. ChatGPT has Projects. Cursor launched Projects in September 2026. The word is doing very different work in each case, and the differences matter more than the similarity.

What the chat assistants mean by it

In the chat products, a Project is essentially a container with memory attached.

You create one for a body of work, give it standing instructions, and attach reference files. Conversations started inside it inherit both. The practical effect is that you stop re-explaining your context at the beginning of every session — which, if you use these tools daily, is a surprisingly large share of the time you spend on them.

Shared project context reduces repeated setup, but it does not tell you how work executes. ChatGPT projects can contain Chat and Work conversations. Claude’s memory documentation also distinguishes project context from how chat and cloud Cowork use memory. Check the mode and connected tools, not just the Project label.

What Cursor means by it

Cursor’s Projects, launched on 10 September 2026, is a different category of thing. The coordinator agent and how it delegates work is worth reading separately.

The centerpiece is a coordinator agent that plans a body of work — a feature, a migration, an entire application — and delegates it to other agents that implement it. The coordinator explicitly does not write code itself. It creates and manages agents on your behalf, running as many in parallel as the work needs, and subagents can run on their own virtual machines with isolated copies of the project.

Cursor’s announcement also describes shared context across agent machines and subscriptions that trigger work from events or schedules. These are coordination features to inspect, not proof that every other product lacks comparable capabilities.

The useful distinction is between stored context and permission to act. A product can provide both. Record each separately when comparing a workflow.

The distinction that actually matters

Strip away the feature lists and there are two questions, and they have different answers.

“I keep re-explaining the same background.” That is a context problem. A project can help, provided its files are current and available to the right people. Uploaded documents, shared access and retention settings still need deliberate choices.

“I want work to progress while I am not watching.” That is a delegation problem. Inspect the actual execution mode, permissions, approval rules, logs and recovery behavior. A folder name does not answer those questions, and even a conversational tool can gain authority through connected tools.

Teams get into trouble by answering the second question with a tool built for the first, or — more expensively — by adopting a tool built for the second while thinking they are solving the first.

Where the chat version quietly fails

Two failure modes worth knowing, because both are gradual.

Instruction rot. Standing instructions are written once, when you set the Project up, and then apply invisibly to every conversation for months. When the work changes, the instructions frequently do not, and you get subtly wrong framing for weeks without noticing — because nothing surfaces them. Re-read them occasionally; it takes two minutes and is almost never done.

Reference drift. Attached files are a snapshot. The version of the policy you uploaded in March is the version the model is using in September. There is no warning, because from the model’s perspective nothing has changed. Anything that gets revised needs a habit for re-uploading it, or it will confidently answer from a superseded document.

Where the Cursor version needs care

Cursor introduced Projects as a beta in September 2026. Whatever the current release label, begin with work whose failure you can detect and reverse.

Review becomes the bottleneck. Parallel agents produce parallel diffs. A coordinator working well can generate more code than one person can meaningfully read, and approving without reading is not a capacity gain — it is removing a control while keeping the paperwork.

Shared context needs review. A wrong note about a service can influence later tasks until someone corrects it. Keep a way to inspect, edit and remove stale material, and check the context when a failure appears to repeat.

Subscriptions are a governance change. An agent that acts on a Slack message without a prompt is a system with an external trigger. Decide what it may do unattended before enabling it, not after.

Which to reach for

A reasonable sequence, and it is a sequence rather than a choice.

If you are re-explaining yourself constantly, try a project with a small set of approved reference files. Confirm who can access it, review its memory settings, and check one answer against the source before adding sensitive material or more integrations.

If you are running agents on real code daily and the work decomposes into independent pieces, a coordinator is worth an experiment — on one contained migration, with a test suite you trust, where you would be annoyed rather than damaged if it went sideways.

If nobody on your team can say which repeated task is worth automating, neither tool is your bottleneck, and adopting either will feel productive without changing anything. That is a different exercise, it requires no new software, and it is almost always the higher-value afternoon.

What both approaches share

One thing is useful across all three products: a maintained description of the work, its sources and its boundaries. Some context is authored by people; some is generated from conversations or agent activity. Both need an owner who can correct them.

Review standing instructions, uploaded references and generated notes together. Record who owns each source and how a correction reaches later work. A useful initial setup can become misleading when the project changes and nobody updates its context.

It is worth treating that description as a real document with a real owner. What the project is for. What conventions apply. What is out of scope. What the tool should do when it is unsure. Twenty minutes of care there outperforms any amount of cleverness in individual requests, and it is the one investment that carries across all three tools and survives the next renaming.

A caution about persistent memory

Persistent context creates a risk that is easy to miss: a wrong statement can keep influencing work until it is noticed and corrected. Inspect the product’s controls for editing, removing and limiting that context.

A standing instruction written for a situation that has since changed. A reference document that was superseded in June. An agent’s note about how a service works, recorded confidently and incorrectly. None of these announce themselves, all of them are applied silently to future work, and the failures they cause look like model failures rather than what they are.

The mitigation is unglamorous and takes minutes: put a recurring reminder somewhere to re-read the persistent material. Once a quarter is enough for most teams. What you are checking is not whether the tool is working — it is whether the things you told it months ago are still true.

The naming problem is going to get worse

Worth saying plainly, because it will keep costing people time: the vocabulary in this category is not settled. Projects, agents, skills, modes, memory, workspaces — each of these means materially different things at different vendors, and the overlap in words is not evidence of overlap in function.

When comparing tools, ignore the feature names entirely and ask three questions: what does it remember, what can it do without me, and what happens when it is wrong. Those three answers distinguish these products cleanly, and they will keep working as a comparison method long after this particular set of names has been replaced.

Comparison reviewed 10 October 2026 against Cursor’s September launch note, ChatGPT Projects documentation and Claude’s memory documentation. Product modes, account settings and plan access change. Compare the actual workflow you can use; this is not an exhaustive feature comparison.

Try this

Write down the outcome you want, then compare the actual modes available in each candidate tool. Record what context persists, which connected actions it can take, what needs approval and how you can correct or stop it. Test one bounded task before deciding which workflow fits.