Memory scope is a schema axis, not a namespace prefix

Memory scope is a schema axis, not a namespace prefix. Adding tenant_id or user_id to a vector-store key may prevent an obvious cross-customer lookup, but it does not answer who owns a belief, who may update it, how long it survives, or whether it can be reused in another task. Scope changes the meaning and lifecycle of a memory record. It belongs in the model and its policies, not only in the storage address.

I distinguish at least five scopes: run, task, agent, user, and organization. A run checkpoint exists so one execution can resume and should usually expire quickly. Task memory may outlive a process but end when the case closes. Agent memory describes operational learning tied to a particular role. User memory carries preferences or facts whose consent and correction rights follow the person. Organizational memory represents shared policy or domain knowledge and needs provenance strong enough for many agents to rely on it. Calling all five “memory” and separating them with prefixes preserves storage convenience by spending semantic clarity.

Ownership is where the shortcut first breaks. A user preference can be corrected by the user and may need to follow them across devices. An inferred organizational rule should not be overwritten because one conversation contradicted it. An episode is usually append-only evidence; a profile is a versioned interpretation of evidence. The personalization research makes this separation explicit through profile and episodic submodules, confidence scores, preference drift, and right-to-be-forgotten controls. Those are schema behaviors. A namespace cannot tell the write path whether to append, merge, challenge, or delete.

Retrieval has the same problem in reverse. The query planner should know which scopes are eligible for the current decision and in what order. Run state may be freshest but least durable. A user preference can shape response format but should not override an organizational compliance rule. Team memory may be useful only when the acting agent has inherited the team’s authority. If retrieval merely concatenates nearest neighbours across permitted prefixes, semantic similarity silently becomes policy precedence.

Multi-tenancy raises the stakes. Tenant context must propagate through the full stack — API identity, dispatcher, cache keys, vector collections, audit events, and tool calls — because one missing hop can contaminate another customer’s context. Yet hard isolation is only the floor. Within a tenant, project, role, and purpose boundaries still matter. “Same organization” does not make every memory appropriate for every agent, especially when personal data, regulated cases, or delegated authority are involved.

There is a limited case where a prefix is enough. For an ephemeral prototype with one memory type, one writer, no cross-session reuse, and no regulated data, namespacing can honestly represent the entire ownership model. The mistake is allowing that storage convention to survive after user profiles, shared knowledge, delegation, and retention policies arrive. Complexity has already entered the domain; hiding it in key construction does not remove it.

I would therefore make scope an explicit field with an enforced contract: owner type and identifier, purpose, eligible readers and writers, retention rule, provenance, confidence, and precedence. The memory API should require those values on write and use them to construct the read plan. That turns isolation from an accidental property of key formatting into a reviewable part of agent behavior. Once memory can affect action, where a belief is allowed to live is as important as what the belief says.