Memory Is Not State

Most agent-memory problems begin with a reasonable shortcut.

An agent learned something useful. Put it somewhere persistent. Load it next time. Problem solved.

That model works until the agent is no longer alone.

A second profile appears. A different channel resumes the work. A background worker takes over. A customer-facing assistant enters the system. The question is no longer whether something was remembered. It is what was remembered, for whom, by which runtime, and with what authority.

The shortcut confused memory with state.

State belongs to the runtime

Runtime state has a narrow and useful job. It carries a request through a handler, holds a session while a user is active, stores a retry counter, or keeps temporary tool output available while a task is in progress.

It may be local. It may be disposable. It may disappear when the process restarts.

Memory has a different lifecycle. It is information that should survive the runtime that happened to observe it: a project decision, a user's working preference, or the history needed to avoid repeating a known mistake.

Putting that information inside an agent profile feels natural because the conversation happened there. But the profile is the reader of the information. It is not automatically the owner.

Ownership is the missing question.

Sharing is a trust decision

A multi-tenant SaaS would not keep tenant data on whichever application server handled the last request. The server is replaceable; the data must survive it. But the system also would not place every tenant into one undifferentiated bucket merely because a shared store is convenient.

The useful model is a durable service with scoped access.

Agent memory needs the same distinction. An instance can be replaced. A channel can disappear. A worker can restart. None of those events should decide whether a user's preferences survive. But neither should the availability of a shared bank grant another project or customer access to them.

So “should agents share memory?” is too broad a question.

The sharper questions are:

• What subject is this information about?
• Which runtimes may retrieve it?
• Who may correct or delete it?
• What evidence gave it authority?
• What happens when the remembered context conflicts with the source?

A single global memory bank is not a mature answer. It is the removal of a boundary.

Four things hidden in one word

“Memory” often collapses several lifecycles that should remain distinct.

Runtime state is current execution: the request, temporary output, retry status, or unfinished operation. It should usually expire with the work.

Operational continuity helps the next worker pick up a task: what changed, what remains blocked, and which action is next. It can survive a session without becoming durable knowledge.

Decision history records why an option was rejected, which trade-off was accepted, or what evidence changed a team's mind. It needs provenance because it can shape future work.

Durable knowledge contains rules, architecture decisions, and source-backed facts that a team has chosen to treat as true until revised. It belongs in visible, reviewable artifacts.

A retrieval provider may help find information across these layers. It should not silently merge them. Otherwise a temporary observation can become a preference, a remembered discussion can look like an approved decision, and a retrieval result can acquire the authority of a source document.

Retrieval is a lead, not verification.

The boundary changes with the system

An embedded store can be entirely reasonable for one focused agent, one owner, and one narrow workflow. It keeps operational cost low and makes the ownership boundary obvious.

The mistake is treating that starting point as a permanent architecture.

The boundary changes when one person moves between agents, when several workers handle one project, when a system serves multiple customers, or when retained context can influence a consequential decision. At that point, sharing is not a configuration detail. It is an architectural decision about scope and authority.

This is also where orchestration cost appears. More runtimes do not automatically produce more understanding. If each one retrieves a slightly different memory and treats it as settled truth, the system gains coordination work while losing a stable account of intent.

The answer is not to make every agent read everything. It is to make the right context available to the right runtime and keep the ownership rule visible.

The model's limit

Calling memory a service layer does not solve memory governance by itself. A remote store can still be opaque, stale, over-scoped, or wrong. A durable record can still preserve a bad decision.

The model simply puts the questions in the right place. The service needs explicit scope, provenance, review, correction, and a source of truth outside the runtime. Human judgment still decides what deserves to become durable and when an old decision should be revised.

Memory is not state attached to an agent instance. It is context with an owner, a lifecycle, and an access boundary.

The useful system is not the one that remembers the most. It is the one that can say whose context it is, why it is available here, and which inspectable artifact wins when memory and evidence disagree.