Context Bleed: Why Long-Running Agents Need Per-Project Memory Isolation

The agent that helped you ship project A is now working on project B, and it just suggested you use the logging convention from A - the one that does not exist in B, was never adopted there, and now sits in a pull request as if it were house style. Or worse: it recalled a staging endpoint from a client engagement that ended in March and dropped it into an unrelated codebase. This is context bleed, and it is the predictable result of giving one agent one global pile of memory and pointing it at many projects. The memory was supposed to make the agent smarter. Without boundaries, it makes the agent leak.

The fix is not less memory. It is scoped memory. A theme in the 2026 agent-operating-system tooling - the crop of "agent OS" projects that organize long-running work into per-project workspaces - is that they isolate files, memory, and skills per project precisely to stop this bleed. One open-source agent OS making the rounds pitches its workspaces as a way to run agents across projects "with less context bleed by isolating files, memory, and skills per project." That instinct is correct and underbuilt almost everywhere else. This piece is about why a single global memory is the wrong default for any agent that touches more than one context, what bleed actually costs, and how to scope memory so the agent stays sharp per project while still reusing what is genuinely general.

What context bleed actually is

Context bleed is memory surfacing in a scope it does not belong to. It is distinct from recalling the wrong thing within one project - that is a relevance problem we cover in why AI memory layers recall the wrong thing - and distinct from multiple agents sharing one store, which is its own design space in multi-agent memory patterns. Bleed is one agent, many projects, one undifferentiated memory, and a recall query that cannot tell which project a memory came from because nothing recorded it. It shows up in a few recognizable shapes:

• Convention leakage. A naming scheme, a framework choice, or a workflow the agent learned in one project gets applied in another where it was never adopted, because to a similarity search "how we do X" looks relevant everywhere.
• Stale-context resurrection. A value that was true for a finished project - an endpoint, a schema, a deadline - resurfaces in a new one. The memory never expired because nothing scoped it to the engagement it belonged to.
• Cross-tenant contamination. The dangerous one. An agent serving multiple clients or users recalls one tenant's facts while acting for another. Here bleed is not just sloppy, it is a data isolation failure, and it overlaps directly with security - an attacker who can write to a shared memory can plant something that surfaces in another scope, the persistence problem we cover in memory poisoning that survives restart.
• Noise dilution. Even when nothing wrong surfaces, a global memory means every recall competes against memories from every project. The relevant fact for the current task has to win against a larger, mostly-irrelevant field, so recall quality drops simply because the haystack got bigger.

A global memory treats "everything the agent has ever learned" as one corpus. But the agent does not work in one corpus. It works in projects, for tenants, on tasks - and the boundaries between those are real even when the embedding space does not know they exist.

Why "just one big memory" is the wrong default

The reason teams reach for a single global store is the same reason they reach for a single vector index for everything: it is the path of least resistance, and it appears to work until the second project shows up. The defaults conspire against isolation. Similarity search has no concept of a boundary - cosine distance between "our deploy process" in project A and a deploy question in project B is small, so A's answer surfaces in B and looks confident doing it. And memory written without scope cannot be filtered by scope later; if the write did not record which project, no query can restrict to it. The boundary has to exist at write time or it does not exist at all.

There is a real tension here, which is why "just isolate everything" is also too blunt. Some of what the agent learns genuinely is general - your personal style preferences, a hard-won lesson about a library's quirk, a fact about the world. You do not want to relearn those per project. The goal is not maximal isolation, it is correct isolation: project-specific knowledge stays in its project, genuinely shared knowledge is promoted to a shared scope deliberately, and nothing crosses a boundary by accident. That is a design, not a default, and the default of "one pile" gets it wrong in the direction that leaks.

Scoping memory the right way

A memory layer that prevents bleed treats scope as a first-class property of every memory, set on write and enforced on read. The shape that holds up:

1. Namespace every memory. Each memory carries the scope it belongs to - a project, a tenant, a session, or an explicit "shared" scope. This is recorded at write time as part of provenance, which is one more reason provenance is not optional; see lineage and provenance in agent memory. A memory with no scope is a future leak.
2. Default recall to the current scope. When the agent recalls for a task in project B, the query is bounded to project B plus the shared scope. It does not see project A at all unless something was explicitly promoted. The boundary is enforced by the store, not by hoping the ranker prefers the right neighbors.
3. Promote shared knowledge deliberately. When a memory is genuinely general, it gets promoted to the shared scope as an explicit action, ideally with a record of why. This keeps reuse possible while making cross-project visibility a decision rather than an accident. The bar for promotion is "this is true regardless of project," and most project facts do not clear it.
4. Make tenant isolation a hard wall. Project scopes are a quality boundary; tenant scopes are a security boundary. Cross-tenant recall should be impossible by construction, not merely unlikely by ranking. Treat the tenant namespace like a row-level security predicate that the memory layer always applies, never an optional filter the agent can forget.
5. Expire by scope lifecycle. When a project ends, its scope can be archived as a unit - retained for audit, removed from active recall. This is cleaner than per-memory expiry and it solves stale-context resurrection at the boundary instead of fact by fact, complementing the broader garbage-collection strategy.

Isolation versus the value of shared memory

The objection to strict scoping is that it throws away the upside of an agent that learns once and applies everywhere, and that objection is half right. An agent that genuinely cannot carry a lesson across projects is back to being amnesiac at every boundary. The resolution is that sharing should be a graduation, not a default. A memory starts scoped to where it was learned. If it proves general - it keeps being relevant across projects, or the user marks it as a standing preference - it earns promotion to shared. This is the same instinct as salience in the consolidation loop: the memory layer should be opinionated about what graduates from local to global, rather than treating every fact as globally visible the instant it is written.

Done well, this is invisible. The agent feels like it has perfect recall within a project and clean instincts that carry across them, and it never embarrasses you by importing one client's architecture into another's repo. Done with one global pile, the agent feels uncanny in the bad way - knowledgeable and leaky at once - and the failure is hard to debug because the bleed looks like a confident, plausible suggestion rather than an error.

How to test for bleed

Context bleed is easy to miss in a demo with one project and obvious the moment you have two. Test for it on purpose:

• Plant a project-specific fact, then query from a sibling. Teach the agent a convention in project A, switch to project B, and ask a question where A's convention would be a tempting but wrong answer. It should not surface.
• Run a cross-tenant probe. Write a fact under tenant 1 and attempt to recall it while scoped to tenant 2. Any leakage is a security finding, not a quality nit.
• Check promotion actually works. Mark a fact as shared and confirm it surfaces across projects - isolation that also blocks legitimate sharing is over-corrected and will get disabled in frustration.
• Archive a scope and re-query. End a project, archive its scope, and confirm its facts stop surfacing in active recall while remaining auditable. This is the test for stale-context resurrection.

The takeaway

The agent-OS tools are right that long-running, multi-project agents need their memory scoped, not pooled. A single global memory is the default that leaks: conventions cross into projects that never adopted them, finished engagements resurface, and in a multi-tenant setting bleed becomes a data-isolation failure. The fix is to make scope a first-class property of every memory - namespaced on write, enforced on recall, promoted to shared only on purpose, and walled hard at the tenant boundary. That gives you an agent that is sharp within each project and clean across them, which is the whole point of memory that was supposed to help rather than leak.

memnode is built for exactly this. Memories are recorded with provenance and scope, recall is bounded to the current context by default rather than dredging one global pile, and sharing across scopes is an explicit promotion with a record of why - sitting inside the same record, recall, lineage, correction loop the rest of the layer runs on. It speaks MCP so your agent can carry a per-project memory as a tool, and it ships hosted when you do not want to operate the store. Give a multi-project agent boundaries, and the bleed stops being your problem.