A developer working on five projects has knowledge that applies to all of them — their preferred code style, their understanding of their own technical constraints, their working hours and communication preferences. This knowledge doesn't belong to any single project. It belongs to the person.
A global memory tier stores this cross-project knowledge. It sits above the project-scoped tiers and injects its facts into every session regardless of which project is active. Done right, it makes the AI a persistent collaborator across the entire body of work. Done wrong, it bleeds project-specific context across confidentiality boundaries — or it floods every session with irrelevant facts from unrelated domains.
The decision of what goes in the global tier is a governance question, not just an engineering one. It involves data minimization, confidentiality, and the question of what you actually want an AI to know about you across all your work.
A consultant works with three clients simultaneously. Each client has a separate project context in their AI system: separate memory stores, separate knowledge graphs, separate injection specs. The boundaries are intentional — client A should never see client B's architectural decisions.
But some knowledge applies across all three clients. The consultant's preferences for how to structure project documentation are the same everywhere. Their understanding of certain technologies that all three clients use — a shared authentication service, a common analytics platform — is relevant in every client session. The way they communicate with stakeholders is consistent.
The consultant builds a global memory tier to hold this cross-cutting knowledge. The first version includes: personal working style, technology expertise, general communication preferences, scheduling constraints. Sessions immediately improve — the AI stops asking questions it already knows the answers to.
Then edge cases emerge. A decision made for client A — "always recommend Redis for caching" — bleeds into client B's session, where the recommendation is wrong for their infrastructure. A preference note about "aggressive cost-cutting" from a client that needed that approach surfaces in a session with a client who specifically didn't want that framing. A security consideration from one project's architecture leaks into another session where it's confidential.
The global tier is too broad. But narrowing it raises the opposite problem: the AI loses the context that makes it useful across projects. There's a boundary here, and it requires a deliberate policy to draw it correctly.
A well-designed memory system has three tiers. Each tier has a defined scope, a defined injection rule, and a defined ownership model. Mixing content between tiers is the source of most global memory problems.
Facts that are true regardless of which project is active. Strictly scoped to: personal identity facts (role, expertise, communication style), universal constraints (availability, tools used across all projects), and cross-project skills (technologies used in every context). The test: if this fact would be wrong or misleading in any single project context, it does not belong here.
Facts that are true for this project specifically. Architectural decisions, team preferences, conventions, history, open questions. Injected only in sessions for this project. Never crosses into other projects' sessions.
Facts that emerged in this session and haven't been promoted to a higher tier. Not persisted by default. Relevant only within the current conversation window.
Moving a fact from Tier 2 to Tier 1 is a governance decision. The question is: is this truly universal, or does it just feel like it is right now? A technology preference formed because client A uses that technology is not universal — it's project-context-specific knowledge that looks universal from inside that project's context. Promotion should be deliberate and auditable.
NIST's GOVERN function requires organizational policies for AI system accountability. A global memory tier is an organizational decision: who decides what crosses project boundaries? Is there a review process for global tier additions? Is there an audit log of what's in the global tier and why? Without these, the global tier grows by accident rather than by policy.
NIST MAP asks you to identify what can go wrong in context. Cross-project memory has specific failure modes: confidentiality leakage (project A's details surfacing in project B's session), context poisoning (a project-specific preference incorrectly treated as universal), and recommendation drift (advice shaped by one client's context being applied to another). Map these risks before deciding on global tier scope.
The debate covers three scenarios that test the global tier boundary in different ways. Each one has a genuine case for both global and isolated memory. Your job is to take a position and defend it.
A developer works on three projects that all use the same backend framework. Their deep expertise with that framework is relevant in every session. Argument for global: it would need to be injected identically into all three project tiers — why not centralize it? Argument against: the version of the framework, the specific use patterns, and the context for recommendations are all project-specific. What's your position?
The developer prefers concise responses, dislikes theoretical explanations without examples, and works in 90-minute focused blocks. None of this is project-specific. Argument for global: this should apply universally. Argument against: some projects may require different communication styles — a client that wants thorough documentation shouldn't receive the same brevity preference. What's your position?
A security requirement on one project — "all API calls must be logged for compliance" — was elevated to the global tier because it seemed like good general practice. Now it's surfacing in sessions for projects that have no such compliance requirement and where the overhead is not appropriate. What went wrong, and who should have caught it?
You'll defend your position on each scenario under challenge. You can evolve your view if your reasoning changes — what matters is that you can explain why.