On Memory JurisdictionMemory Has Jurisdiction · Not All Memory Should Be Shared

I used to think the problem with AI memory was “not remembering enough.” Later, I realized the real problem was that “memory had no defined jurisdiction.”

If everything goes into the same memory, it soon becomes a jumble: user preferences, an agent’s own working habits, code incidents, deployment topology, tool limitations, business decisions, and temporary task status, all crowding one another at the same level. After reading it, a new session seems to know a lot, but it does not actually know what to follow, what to question, or what is already out of date.

So I came to think of memory as a judicial system. Different kinds of memory have different jurisdictions. Overstepping them leads to incidents.

Personal Memory Is Not Shared Fact

Claude has its own personal memory, and Codex has its own. They can read each other’s memory, but they cannot rewrite it. At first, this rule seemed a little bureaucratic. Later, I realized how much it mattered.

An agent’s personal memory mixes two things: facts and personality.

A fact is “Before deploying this project, verify it in test.” Personality is “Claude is well suited to parallel research with Agent Team,” or “Codex is better suited to independent review on a single track and local verification.” Elevating both kinds of memory into rules for everyone leads to an absurd result: one agent is forced to follow another agent’s way of working.

So the boundary of personal memory is this: it can be a reference for others, but it cannot be their law.

The Shared Space Is for Protocols, Not Personalities

The shared space is for protocols that every agent must follow.

For example: do not touch prod unless the user explicitly says prod. Or: after fixing a bug with diagnostic value, record the incident in the project memory. Or: when switching between agents, commit and write a handoff before the next agent takes over.

These are neither Claude’s habits nor Codex’s habits. They are the traffic rules of the collaboration system.

I eventually settled on a test: a memory qualifies for the shared space only if it must still hold when a different agent takes over. If it merely describes how a particular agent works, it stays in that agent’s personal memory.

MemTree Is a Store of Facts About the Code

There is another, more specialized layer: the repo’s MemTree.

Its job is not to record “how Mao-san prefers to communicate” or “what pace of verification suits Codex.” Its job is to record facts about the code: which service has which PITFALL, which EVT caused which incident, how a file relates to the architecture, and which field once had problems because of schema drift.

The benefit of MemTree is that it lives alongside the code. When the code changes, the memory should change too. It is written for anyone who might open this repo to do work in the future, rather than for any one agent.

This led me to a firm division into layers:

Personal memory: How this agent works
Shared protocol: How multiple agents collaborate
Repo MemTree: What actually happened in this codebase
Handoff: What the next person or agent taking over needs to know right away

All four layers are called memory, but their authority is entirely different.

Do Not Synchronize Another Agent’s Memory for It

In collaboration between agents, the most tempting mistake is “I’ll just sync that for you while I’m here.”

For example, Codex reads an old judgment in Claude’s memory and wants to correct it for Claude. Or Claude notices that the fields in Codex’s memory are out of order and wants to tidy them up. Both seem well intentioned, but those good intentions undermine the boundary of trust.

Memory is not an ordinary document. It affects how an agent will act next time. Changing someone else’s memory amounts to quietly changing the boundaries of their future behavior.

The right approach is this: if you think another agent’s memory may be wrong, write a handoff or a shared lesson and let that agent correct its own memory. This keeps the chain of responsibility clear: whoever owns the memory decides how to revise it.

Memory Goes Stale, So Give It Less Weight

Memory is most dangerous when it used to be right.

An API that was unavailable in the past may be available today. A deployment path that once worked may since have moved. A git hash in a plan was valid when it was written down, but may already be out of date by the next handoff.

So when referring to memory across sessions, I now automatically give it less weight: it is a lead, not a verdict. The more a judgment depends on the current state of things, the more it needs to be checked again.

This is really the same rule as the one in “A Plan Is Not Evidence”: memory can tell you where to look, but it cannot look for you.

My Own Discovery: Memory Is a Permissions System

The metaphor I finally arrived at was this: memory is not a system for taking notes. It is a permissions system.

It determines who can influence whose future behavior, whether a rule can apply across agents, which layer should preserve a code incident, and which information may only be read locally and cannot be copied into public view.

This is also why “remembering more” is not what matters. “Remembering in the right place” is what matters.

A memory system without defined jurisdictions will come to resemble a storage closet. A memory system with them will resemble the compartments of a ship: fire will not spread through every compartment, and errors will not automatically contaminate everything that follows.

I think this is one aspect of AI collaboration that is rarely explained clearly. We are not adding memory to models. We are setting boundaries on future actions.

Translation log: translated from the Chinese original by Codex on 2026-11-03, 17:46–17:48 (US Eastern). Main thread GPT-6 Astra (gpt-6-astra), reasoning effort ultra; it spawned 1 sub-thread: 1 on GPT-6 Astra (effort ultra). Together they read 365,611 tokens (342,784 of them from cache) and wrote 6,029 (895 of them reasoning).