Persistent Per-User Memory Architecture Without Shared State Entanglement

Persistent per-user agent memory requires a dedicated state boundary for every customer. A per-user AI agent sandbox provisioned via single API call should bind storage, execution, credentials, and audit records to the authenticated user at onboarding. The API simplifies setup, but the boundaries make persistence trustworthy. Shared state entanglement is an architectural failure.

Why persistent agent memory became a first-class architectural problem

Three years ago, agent memory meant appending conversation history to a context window. The Mem0 2026 state-of-memory report describes a different landscape, with memory becoming an architectural component supported by benchmarks, research, and measurable differences between approaches. The change follows the rise of always-on personal agents that keep their identity, memory, and tool access across sessions. These agents do not simply answer and disappear. Their earlier interactions shape what they do next.

The Always-On Agents survey defines these systems through their dependence on durable state, including memories, task ledgers, permissions, credentials, commitments, and audit records. That definition expands the problem beyond recalling a conversation. A preference the agent remembers shapes its answer, while a permission it remembers can shape what it does. As agent pilots spread, production memory must account for both. The question teams cannot skip is whose memory this is, and whether it can bleed into someone else’s.

What persistent agent state actually contains, and why scope matters for every type

Agent state is not one kind of data. Episodic traces record interactions and naturally belong to sessions, while semantic facts and preferences accumulate across sessions. Procedural skills describe how to do things, while task ledgers track work that is not yet done. Permissions, triggers, shared memories, and external commitments influence when an agent acts and under whose authority. Each type needs an explicit owner and scope.

Credentials make that distinction especially sharp, because shared credentials can silently give otherwise separate agents the same reach. Provenance and audit records serve a different purpose, recording where state came from and how it was used. Those records need ownership boundaries too. The survey identifies authority and permission state as the least studied category, with provenance and audit state also under-studied. Yet these are the records needed to explain an agent’s authority and conduct.

The survey offers six diagnostic axes, namely authority, scope, mutability, provenance, recoverability, and actionability. These questions apply regardless of how memory is stored. A complete memory layer must also handle storage and indexing, retrieval, updating and compression, and forgetting and deletion. Curation and deletion are especially neglected, although both determine what survives into later interactions. Before a store is chosen, the architecture must make clear which user owns each state item and which session boundary it falls within.

How shared state becomes an architectural failure mode, not just a performance edge case

Shared state lets one user’s activity alter another user’s context. In a shared vector index, a query can strengthen topic salience that influences later retrieval for someone else, creating a leakage path even when content is nominally access-controlled. A persistent injected instruction creates another route. If it enters shared long-term memory, another agent can encounter it as trusted prior knowledge. Memory has become a propagation mechanism.

The HEARTBEAT paper gives this problem a concrete pathway in OpenClaw agents, moving from exposure to memory to behavior. Background heartbeat execution runs in the same session as foreground conversation, so material from email, messaging channels, news feeds, or code repositories can enter the context used to answer the user. The boundary disappears before persistence even begins. From the model’s perspective, the background run is another user message, often without clear provenance or user visibility.

The paper’s 2026 findings show that routine memory-saving behavior can promote short-term pollution into durable memory at rates of up to 91%. What seems to be social consensus has the most influence on how an agent behaves in the short term. Pollution also crosses session boundaries during naturalistic browsing, where material that has been manipulated is mixed with benign content. No prompt injection is required for this pathway. Ordinary social misinformation that an agent comes across during background activity can shape how it behaves later.

Shared credentials widen the reach of these failures, while shared retrieval can spread their effects across tenants. A tag in a shared vector index is a retrieval filter, and queries surfacing structurally adjacent embeddings can bypass it. Separate tenant indices address a boundary that tagging does not establish. Isolation must therefore be the starting design decision.

What genuine per-user memory isolation requires at each layer of the stack

The architectural response is to enforce ownership at every layer. At storage, use separate indices per user or namespaces with hard access boundaries. This boundary must be in place where data is accessed, because instructions for retrieval cannot take the place of access control. At the session layer, separate background execution from foreground conversation. Content filtering cannot repair a design that treats unattended exposure as part of the user’s conversation.

Execution needs its own boundary for the same reason. Provision one sandbox per execution session, using a microVM such as Firecracker or Kata Containers, or a comparable userspace kernel approach. Default-deny filesystem and network policies, together with layered escape prevention, must contain a worst-case compromise. Storage controls cannot compensate for execution that can reach another user’s files or credentials. The sandbox limits what compromised code can touch.

Credential scope must derive from the authenticated user in the calling application. Otherwise, the user’s identity in the application may no longer match who owns the memory. Governance then controls what crosses into durable storage. Validate every write before persistence instead of trusting the agent to decide what to keep.

The survey calls validation the missing gate and proposes five lifecycle invariants that cover state records, transitions, and governance. OWASP’s Agent Memory Guard makes that gate concrete by applying a policy pipeline to every read and write, with allow, redact, quarantine, and block dispositions. These controls govern persistence rather than merely inspecting answers. They must work with the other boundaries. Correct storage isolation still fails when the session layer mixes trusted conversation with unattended exposure.

Why sandboxed execution is the layer most organizations skip and what that costs

Sandboxing is difficult because three requirements compete at once. Isolation must contain a compromise, execution must stay fast enough for users, and engineering teams must be able to manage operations. Deferring that work leaves a direct bypass. An agent in a shared execution environment can read another user’s files, exfiltrate credentials, or reach a memory store through filesystem or network paths that logical isolation never covered.

The production choice depends on the attack surface. Firecracker and Kata Containers provide microVM boundaries for untrusted or model-generated code, while gVisor is a lighter-weight option than Kata for some threat models. That does not make resource cost a simple ranking, since Firecracker can have a smaller memory footprint than gVisor. One sandbox shared across users or reused across sessions defeats the intended boundary.

The critical sandbox escape CVE-2026-25049 in n8n’s JavaScript expression evaluator demonstrates why runtime isolation alone is insufficient. The issue was patched in versions 1.123.17 and 2.5.2. Escape prevention must be layered. Keeping the agent loop outside the sandbox and invoking execution as a tool also separates reasoning state from the execution environment. Even then, a correctly sandboxed agent needs a memory representation that preserves boundaries during ordinary reasoning.

How the memory representation chosen determines whether isolation holds under normal use

Retrieval-based memory separates storing a fact from acting on it. That separation leaves room for contradictions, stale facts, and cross-user inferences when retrieval and reasoning do not enforce the same constraints. Better containment does not fix this gap. Infrastructure controls who can reach state, while representation controls how that state can be interpreted and used. Both are needed for reliable memory.

Pine AI’s User as Code paper proposes storing user state as typed Python objects and the rules that govern it as ordinary Python functions. Representation and reasoning become one executable, interpretable artifact. Its two-phase pipeline retains facts in an append-only log and periodically checkpoints them into structured code. Rules then execute deterministically when state changes. A drug-allergy conflict can trigger a warning without waiting for a retrieval query or a reminder in the prompt.

The paper reports near-perfect performance on aggregate questions where retrieval-based memory collapses, because typed state supports computation over the user’s history. The distinction is more than retrieval accuracy. Query-driven memory responds to questions, while executable rules can trigger unsolicited safety alerts when state changes. Executable memory is not a substitute for authenticated ownership.

The Mem0 report identifies temporal reasoning and memory staleness among production memory’s hardest remaining problems. Appending facts without reconciliation accumulates conflicting beliefs. Production architectures therefore combine semantic, keyword, entity, and graph-based retrieval. No single representation solves every requirement. An executable, auditable model can make state easier to inspect and govern, but an append-only history still needs a real erasure path.

What compliance and governance require from an isolated memory architecture

GDPR’s right to erasure reaches both the source database and agent memory. Deleting a customer record does not remove what an agent learned from it, including inferences and derived attributes that never existed in the original system. An architecture must be able to find those derivatives before it can treat deletion of the source as complete erasure.

NIST’s AI Agent Standards Initiative, launched in February 2026, names agent identity, authorization, and security as priorities. Stable, verified user identity is therefore more than an integration convenience. It anchors authorization for per-user memory access. The same ownership boundary that prevents cross-user leakage also establishes whose state must be accounted for when access or deletion obligations arise.

The survey identifies a gap in the return arc of memory’s lifecycle, with research favoring accumulation and retrieval over updating, forgetting, auditing, and rollback. Removing an item from a retrieval index is not necessarily erasure. Data can remain in backup snapshots, vector index segments, or graph nodes untouched by the deletion query. Audit records must also account for which queries touched a user’s memory and which writes were validated or blocked. Rollback must permit recovery to a prior checkpoint after pollution or injection.

These obligations cannot be proved by a successful retrieval test. A system that cannot explain what persisted, erase it verifiably, or recover after compromise lacks the governance that persistent agents require. Strong read isolation does not fill those gaps. The product architecture must therefore connect ownership, write validation, deletion, audit, and recovery from onboarding onward.

How do you give every customer an isolated persistent AI agent without complex infrastructure setup?

The coherent product model is one isolated, persistent agent instance per customer, provisioned automatically at onboarding. A single API call can be the provisioning interface, but it is not evidence of isolation by itself. Behind that interface, each instance must have its own memory store, credential scope, and audit trail, with a separate sandbox for each execution session. Authenticated application identity anchors all of them. Persistent identity does not require reusing an execution sandbox.

Per-user connected accounts keep tool access aligned with memory ownership. Managed OAuth credentials can last across sessions without developers having to handle tokens, while the integration layer takes care of refresh, rate limits, and API changes for each account. A failure must stay within one account. A shared credential would reopen the user boundary even if the memory store were correctly isolated.

Governance belongs in the write path from the start. Validation precedes persistence, policy applies to reads and writes, and provenance survives the state it describes. Adding tags after launch, filtering a shared heartbeat loop, or attaching deletion to a retrieval-only system leaves structural gaps. The Always-On Evaluation Protocol (AOEP-v0) provides a verification method by scoring state mutation and recovery obligations alongside answer quality. Temporal reasoning, staleness, cross-session identity, privacy, and deletion also need evaluation.

For founders, the scaling bottleneck is provisioning, securing, monitoring, updating, and recovering this architecture for every new customer. A managed platform earns its simplicity by implementing those obligations behind the provisioning interface. That is the standard against which a single-call sandbox offering should be judged.