Walls Without Doors

Anthropic's assistant keeps a separate memory for each project. What Claude learns while you work on one project does not carry into the next one, and the reasoning is stated plainly in their own documentation: the boundary keeps client work separate from product planning, and confidential discussions separate from general operations. Cowork follows the same rule.

That is the correct default, and it deserves saying before anything else: memory that quietly follows you between contexts is a leak with a friendly name. Anyone who has watched an assistant volunteer one client's roadmap while drafting a proposal for another understands why the wall is there.

But a wall is a decision with two sides. It protects what should stay put, and it strands what should travel. This post is about the second side — the knowledge that ought to cross, and what it takes to let it cross safely. It's the Memory and Trust pillars of our framework for operating LLMs safely, applied to a boundary rather than a store.

A room with no door is a safe design and an unfinished one. Everything inside it has exactly one setting: private, forever, by default and by architecture.

The two taxes of a wall with no door

In the Claude apps, sharing runs person-to-project, not project-to-project. Team and Enterprise members can be granted "Can view" or "Can edit" on a project, which shares that project's knowledge base with those people. What there is no supported mechanism for is a single knowledge base that several projects draw on. Two costs follow from that, and they compound quietly.

The duplication tax

Your architecture conventions, your house style, the decision to stop using a particular library — these are not project knowledge. They are organizational knowledge that happens to be needed in every project. With no shared store to point at, the only route is to upload a copy into each project's knowledge base. And since a document in a knowledge base cannot be updated in place — the documented path is to remove it and upload the new version — every revision is a manual fan-out across every copy you remember to visit.

Six copies, revised at six different times, is not six times the knowledge. It is one piece of knowledge plus five pieces of misinformation, with nothing in the system able to tell you which is which.

The relearning tax

The subtler cost is that a lesson learned in one room cannot be spent in another. Whatever the assistant worked out with you last month — the reason a migration was done a particular way, the constraint that makes an obvious refactor a bad idea — is available in exactly one project and structurally invisible everywhere else. The organization pays for that insight once per room.

You can watch the same shape appear in the tooling ecosystem. An open issue on claude-context, a code-indexing MCP server, asks for a global knowledge base across projects because retrieval is scoped to one project directory at a time. A team in the thread describes running roughly 94 indexed repositories across 103 collections, where questions that span repositories — who writes to this Kafka topic? where is this class defined? — force an agent to iterate over every project one at a time until it hits its limits.

Worth being precise about the strength of that signal: as of this writing the issue has drawn two substantive comments and a couple of reactions in about three months, with no maintainer response. It is a well-documented account of the problem's shape from a real deployment, not evidence about how many teams hit it. We cite it because it is specific, not because it is a groundswell.

The wall is right. The permanence is the problem.

It would be easy, and wrong, to conclude that isolation is the mistake. Conversations should be isolated. Draft thinking, client specifics, half-formed positions — those belong in a room with a wall around them, and a product that made them ambient by default would be worse, not better.

The problem is not that a boundary exists. It is that the boundary has no promotion path. An organization needs somewhere to keep things private, and it also needs a way for something to stop being private — deliberately, on the record, when a person decides it should. Without that second mechanism, per-project memory offers a single setting for everything it will ever hold.

So the design question isn't "walls or no walls." It's: what does a door need before you're willing to put one in?

What a door needs

Five properties, in the order they matter. These are the controls we built MemBrain's share gate around, and each maps to a pillar.

None of these is exotic. Together they're just the observation that crossing a boundary is an event worth governing — the same way a code review governs the boundary between a branch and main.

Doors only open onto rooms in the same building

There's a second axis that a promotion path inside any one vendor's product cannot reach.

Per-project memory forgets across projects. Every vendor's memory forgets across vendors. What the assistant learned in one product is not available to the editor, the CLI, the local model, or the script you run in CI — not because anyone decided it shouldn't be, but because there is no shared place for it to live. A door built into one application can only ever connect rooms in that application.

This is why we put the door at the gateway seam instead of inside a client. When knowledge lives in the proxy that every tool already talks through, the promotion path is provider-independent by construction: a lesson captured while working in one tool is available, subject to the same five gates, in the next tool — and the tool after that, including ones that don't exist yet.

Coverage. One knowledge layer behind Anthropic, OpenAI, Ollama, and 100+ models via LiteLLM, reached through an application proxy or transparently at the network layer.

What per-project memory does better

Three things, and pretending otherwise would be dishonest.

• It requires no operations. You create a project. We ask you to run a gateway, a Postgres, and a Redis. That is a real difference for a team without an appetite for infrastructure, and no amount of architecture argument makes it go away.
• Curated beats observed, for precision. Retrieval over a document set a human deliberately assembled is more precise than distillation from traffic nobody curated. Our answer is the review queue, but a well-tended knowledge base is a strong baseline.
• It's already paid for. Project memory is included with the plans teams are on. Marginal cost shapes adoption more than most feature comparisons admit.

And one more point of intellectual honesty: Anthropic does ship shared, scoped memory — memory stores that span multiple agents with different access scopes, an org-wide store readable by many, audit logs, programmatic control. It lives on the platform side, in Managed Agents, rather than in the apps most teams use day to day. The pattern is not one we're arguing for against its designers; they built it. The gap is where it's available, and the fact that the app-side boundary isn't something a team can configure.

The trade in one sentence

Keep the wall — it's doing real work. Add a door that stays locked by default, opens only when the person who owns what's behind it turns the key, rescans whatever passes through, writes down who walked it, and can be walked back.

Isolation is a good answer to the question "how do I stop knowledge from leaking?" It is not an answer to "how does my organization learn?" Those need two mechanisms, and most teams currently have one.