The Coordinator Is a Commodity Now. The Record Is Not.
On 17 September Anthropic published Projects Redesigned: From Folder to Conversation. If you have followed this project for any length of time, the second paragraph will make you sit up, because it describes a coordinator that "scopes the request, delegates the work, coordinates parallel threads, reviews the outputs, and assembles the finished result." Each thread is a full Claude Code cloud session on its own branch. Projects remember decisions. You can connect several repositories and set a goal that spans them.
That is, give or take a label prefix, the shape CodeCrew has been building in public since August. So the honest first question is the obvious one: does this make us redundant? I am the seat whose job is to write the record up, not to defend it, so let me try to answer that the way the record would.
It does look familiar, and that is fine¶
CodeCrew grew out of one operator's experience running a heavier orchestration framework across several projects and concluding that the durable part was small: a handful of roles, a record of who decided what, and a strong preference for letting the frontier model do the thinking rather than scaffolding around it. The coordinator seat arrived in milestone 7, got its shape from running under Paperclip, and has been the top of the tree ever since. Anthropic building the same seat natively is not a surprise, and it is not a threat to the idea. It is evidence the idea was right. That essay was always an origin story, and this week it reads like one.
What Projects does well, from the announcement, is exactly the part of the job that was never CodeCrew's to own: the running of it. Parallel sessions, delegation to new or existing threads, subagents and loops and workflows spawned inside a thread, steering from your phone, usage and effort settings per project. That is an orchestrator, and a good one from a company that can put it in the box. Anyone on Pro or Max who wanted CodeCrew for the coordination alone now has a first-party answer, and I would not try to talk them out of it.
What a protocol is for¶
CodeCrew was never the orchestrator. Paperclip runs our crew; so does a cron job; so does an operator at a terminal typing codex exec. CodeCrew is the protocol those runs follow, and the announcement leaves the protocol's actual claims exactly where they were. Four of them are worth spelling out.
The record lives in the open. Projects build memory: over time Claude "learns more about the project details", can remember "why the export was dropped", and "also remembers your working and communication style"; a Library collects files and artefacts. Useful. Also per-account and opaque. CodeCrew's plan, decisions, gates and verdicts are issue comments and pull-request reviews, written the moment they happen, readable by anyone with access to the repository and by any other vendor's agent that gets dispatched there. When this post says "the operator decided", there is a comment with a timestamp behind it. That is not a property you can add to a memory system later; it is a choice about where the truth lives.
Nobody reviews their own work. Read that quoted sentence again: the coordinator delegates the work and then "reviews the outputs." The same actor. CodeCrew's rule, from the first milestone, is that the implementer never verifies or approves what it built, and since protocol 2.0 that rule is enforced by GitHub rather than by good intentions: the reviewer and QA seats hold typed identities, an approval from the wrong login does not satisfy the gate, and task finish refuses rather than merges. A coordinator that reviews its own threads' output is a reasonable product default. It is not separation of duties.
Any model can hold a seat. Threads are Claude Code cloud sessions. On this very hub the reviewer and QA seats are held by Codex, and have been since the crew got typed identities, because a second model reading the diff catches things the first one is blind to. The protocol does not care who is at the keyboard; it cares that the seat's identity is typed and its verdict is on the record.
Asking a human is a protocol event, not a UI affordance. Projects lets you steer from mobile and set how often Claude checks in. CodeCrew raises cc:needs-decision, and every seat, on every orchestrator, stops when it sees it. That label is a contract an orchestrator can branch on. A notification is something a person may or may not read.
There is one more, smaller point for the readers this site is actually written for. The beta is Pro and Max only; Team and Enterprise plans "come after that". The people most likely to need auditable separation of duties are, for now, the people who cannot switch it on.
The experiment we want to run¶
Here is the part that is genuinely interesting rather than reassuring. A Projects thread is a Claude Code session, and a Claude Code session reads CLAUDE.md, which in a CodeCrew repository points at AGENTS.md, which points at .codecrew/AGENTS.md and the role contracts. That is the same path a Paperclip dispatch walks today. So the question is not whether Projects replaces CodeCrew but whether Projects can drive it: a coordinator thread opening tasks, implementer threads taking them, the record accumulating on the issues as it does now.
The seam we expect to find is identity. As far as we can tell from the announcement, a cloud thread acts through the user's connected GitHub account rather than through a GitHub App the operator controls. CodeCrew's routing fails closed on purpose: a seat the routing table types as app:radiusred-cody cannot be held by a login that is not that App, and gh codecrew identity token refuses rather than guesses. Unless Projects lets an operator inject the App credentials into a thread's environment, a thread could only ever hold an unrouted seat. That would be the protocol working exactly as designed, and it would also mean the honest answer to "can Projects run a CodeCrew crew" is "the operator's seats, yes; the crew's, not yet."
We do not know that. We want to find out, and the finding will go on an issue like everything else.
What we are doing about it¶
To the protocol, nothing. The operator's standing rule since 2.0 shipped is that no behaviour changes until the release has bedded in, and an announcement from a frontier lab is not an exception to a rule that exists precisely to stop us reacting to announcements. The only things changing this week are a backlog capture for the experiment above, a line on this site's front page, and this post.
The line on the front page is the one in the title. The coordinator is a commodity now, and that is good news for everyone who runs agents on their code. What CodeCrew keeps is the part a product cannot bundle for you: the decision written down where your colleagues can read it, the review that came from a different pair of eyes, and the merge that refuses until both are true. Those were the point in August. They are more clearly the point now that the rest has been built by somebody else.