Claude Projects for team knowledge: where they work and break
Espen Oddvik · Founder
There's a pattern I keep meeting in small teams that run on Claude: a founder who runs the whole consultancy out of Claude Projects. One project per client engagement, each loaded with that engagement's documents, goals and agreed tone. It's usually the best-organized knowledge setup in the company. Then you open the instructions of three projects in a row, and the same four paragraphs describing the company sit at the top of each one. Three copies. Two of them out of date.
Stated plainly: Claude Projects work well for knowledge that belongs to one piece of work, like a client engagement or a product launch. They break when company facts such as product names, pricing rules and tone get copied into every project, because each copy drifts on its own. Company Brain holds company facts in one reviewed place and delivers them through MCP to Claude, ChatGPT, Copilot and Cursor.
I'll come back to those four paragraphs. First the praise, because it's earned.
What Claude Projects genuinely do well
A Claude Project is a workspace inside Claude: custom instructions, uploaded documents, and every chat started inside it shares that context. For a defined piece of work this is exactly the right shape. The client engagement gets its contract, its meeting notes and the tone this particular client expects. The product launch gets the plan and the messaging document. The quarterly report gets last quarter's report. Every chat inside the project starts informed, and nobody pastes the same background twice within that workstream.
Projects also make work legible in a way loose chats never do. Conversations about the launch live with the launch. Six months later you reopen the project and the reasoning is still there, attached to the documents that shaped it.
For a solo operator whose work divides neatly into projects and who does everything in Claude, this can genuinely be the whole knowledge system. I mean that without reservation. Build the projects and enjoy them.
Where Claude Projects break for team knowledge
The break is structural, so no amount of careful setup avoids it. It comes from scope.
A project's knowledge lives inside that one project. That is the whole design, and for engagement documents it's a feature; the client's contract has no business appearing anywhere else. Company facts have the opposite shape. Your product names, your pricing rules, your tone of voice, your positioning belong in every project at once, and Projects have no layer for knowledge like that. So the facts get pasted into each project's instructions, one reasonable copy at a time, and every paste starts aging on its own schedule.
That's how those four paragraphs go stale. The positioning gets sharpened in the spring. The two projects in daily use get the new wording, because that's where the founder is when the change happens. An older engagement's project keeps the old wording, and a deliverable drafted inside it describes the company the way it looked a year earlier. In every version of this story I've been told, it gets caught just before the client notices. Barely.
Two more walls stand behind that one. First, projects live inside Claude, per person or shared project by project. A shared project helps the people invited into it, and it helps them only inside Claude. The colleague who prefers ChatGPT inherits nothing. The developer in Cursor inherits nothing. A new hire inherits whatever projects someone remembers to share. Second, project instructions have no review step. Whatever got pasted in is now, functionally, what your company says about itself, with no record of who wrote it, when, or whether anyone checked it.
Claude behaves exactly as designed here. A feature built to hold one project's context is being asked to act as a company's memory, and the boundaries show.
A quick test for sorting the two kinds of knowledge
Take any sentence you're about to paste into a project's instructions and ask: would this sentence be true in every project we have?
"This client wants British English and hates exclamation marks" fails the test. It belongs to one engagement, so it belongs in that project. "Our product is called X and we never promise same-day support" passes the test. It's true everywhere, which means it belongs to no project in particular, which means every copy of it inside a project is a small debt with a due date you don't get to pick.
Keep Projects for project material, move company facts underneath
Project material belongs in the Project. Company facts belong somewhere every project reads.
That second place is the job we built Company Brain for. Company facts live in one reviewed home: changes arrive as proposals, get checked against what's already approved, and carry a recorded approver on every fact, so there is always an answer to who approved this wording and when. The whole team connects through one shared MCP address for the company. A chat inside any Claude Project then starts with both the project's context and the company's, and the same approved facts reach ChatGPT, Copilot and Cursor, so the walls above stop mattering.
On Company Brain's free plan you get 50 company facts and one curator, the whole team connects over MCP, and it stays free for good. If you want the two approaches side by side, our comparison of Claude Projects and Company Brain walks through where each one wins, including when Projects alone are enough. The setup itself takes a few minutes; how Company Brain connects to Claude covers the steps. And if part of your team lives in ChatGPT, the same pattern plays out there, which we traced in where Custom GPTs work for team knowledge, and where they break.
The fix keeps every project. Delete the four company paragraphs from all of them, move those facts into one reviewed place, and let each project go back to holding what it was always good at.
The projects get lighter, and the company describes itself the same way in every chat, in every tool. Both at once. That's the trade you want.