§1What Projects actually shipped
On 17 September Anthropic launched Claude Code Projects in beta. The design is clean. A project is one long-running conversation that acts as a coordinator. Instead of doing the work itself, that top conversation breaks a goal into separate threads, hands each one to a full Claude Code cloud session with its own branch and repository copy, and reviews what comes back. Context persists across the threads: a deadline, a technical decision, who owns approval, the fact that the release moved to Friday. The threads keep running after you close the laptop, and you can steer them from a phone.
It is a good design, and if you have been juggling terminal tabs and losing the thread every time your session ends, it will feel like a real upgrade. This Note is not a complaint about it. It is the opposite. It is what we learned from running that exact shape by hand, long enough to know which part is hard.
§2We have run this shape by hand for months
Our own setup is not a product, it is a rig we built because we needed it. A coordinator agent takes a goal and decides what to spin out. Specialist agents pick up the pieces. A task board tracks what is in flight and forces every item to exit as shipped, blocked or killed. A shared memory store holds the decisions and context that outlive any single run, so the next agent starts where the last one left off. It runs across days. Work continues while nobody is watching.
That is the same skeleton Projects just packaged: a coordinator, parallel isolated workers, persistent shared context. So here is the useful admission. The orchestration was a weekend of plumbing. Spawning parallel work, giving each unit its own branch so they do not tread on each other, collecting the results, is not where the difficulty lives. It is a queue, a fan-out, and some care about isolation. Any competent team can build it, and now you do not even have to.
The hard part was never getting ten agents to run at once. The hard part was getting the shared thing they all read to stay true.
§3The shared memory is what rots
Persistent shared memory is the feature everyone wants and the one that quietly turns on you. The problem is simple to state and hard to fix: it is easy to persist a fact, and very hard to know that the fact is still true. We hit three failure modes, over and over.
Stale decisions. Anthropic's own example is the tell. "The release moved to Friday" is exactly the kind of fact you want the coordinator to remember. But what happens when it moves again, to the following Tuesday, and only one thread was told? Now the shared context holds two answers and no clock. A coordinator that persists a decision does not, by default, know the decision has been reversed. Persistence records what was true when it was written. It does not track what is true now.
Confident wrong recall. A memory that names a file, a flag or a function is a liability the moment that file is renamed. The store happily returns the old note, it reads as plausible, and the agent acts on something that no longer exists. Recall gives you a lead, not a fact. We learned to treat everything a recalled note points at as unverified until checked against the live system.
Unbounded growth. Left alone, the store gets big, and big means noisy. Recall starts returning the loosely relevant alongside the load-bearing, and the coordinator makes decisions on the wrong context without any error ever firing. Nothing crashes. The fleet just quietly gets less right.
§4Cheap parallelism multiplies a bad memory
Here is why the shared-memory problem gets worse, not better, the moment orchestration is free. When spinning up ten parallel threads is one sentence, the bottleneck moves entirely onto the quality of the context they share. Ten threads reading the same stale fact do not average it out. They each act on it, in parallel, on ten separate branches, while you are asleep.
Parallelism does not dilute a bad input. It multiplies it. One wrong entry in shared memory used to cost you one confused run that you noticed and corrected. Fan it out across a coordinator that keeps working after you close the laptop, and it costs you ten, discovered later, spread across ten branches you now have to inspect. The blast radius of a stale fact scales with exactly the thing Projects makes effortless.
So the investment does not go where the demo points. It goes into the freshness and the provenance of what the coordinator hands down.
§5What to actually do
Adopt the orchestration. Do not rebuild what Anthropic, or anyone else, will now give you for free. Spend the time you save on the memory discipline the coordinator will not bring with it.
- Date every fact. A memory without a timestamp cannot be reasoned about. With one, a reader can at least ask whether it is old enough to distrust.
- Treat recall as a lead, not a truth. Before an agent acts on a recalled note that names a file, a flag or a number, it verifies that thing still exists in the live system. Plausible and current are not the same property.
- Prune on a schedule. Something has to go through the store and retire what is wrong or superseded. If nothing ever removes memory, recall degrades in a way that no amount of better retrieval fixes.
- Log what each thread was told. When a thread goes wrong offline, you want to see which context it trusted, not guess. The record of what was handed down is as important as the record of what came back.
None of that is exotic. It is the unglamorous half that a coordinator UI does not do for you, because it cannot know your world well enough to know which of its own memories has gone off.
§6What Projects does not solve
The honest limits first. It is a beta, currently Claude Code only, on select Pro and Max plans, with team, enterprise and local execution still to come. Many parallel cloud threads burn usage quickly, so the thing that makes it powerful is also the thing that empties your allowance. Worth knowing before you fan out twenty threads on a whim.
But the deeper gap is the one this Note is about, and it is not a criticism of the product, because nobody has solved it. Shared memory persistence is a storage feature. Truth is not a storage feature. Writing a decision down is easy. Knowing it is still the current decision, that the file it names still exists, that it has not been quietly reversed in another thread, is the actual work, and it stays yours whether you hand-roll the coordinator or rent it.
That is the good news, really. If the orchestration is now a commodity, you get to stop spending your best hours on plumbing and spend them on the part that was always the difference between a fleet that compounds and one that confidently drifts. The coordinator was the easy part. It is a fine time to stop treating it like the whole job.