A memory store shared by every agent is a shared mutable state. Production systems need ownership, scope, provenance, conflict handling, and a clear boundary between agent memory and business truth.
Multi-agent systems usually begin with a clean division of labor. One agent researches, another plans, a third executes, and a fourth verifies the result. Then the agents need to share what they know.
The obvious solution is a common memory store: write observations into a database, retrieve the relevant entries for each agent, and let the workflow continue. That approach works in a demonstration. In production, it becomes a state management problem.
Two agents may update the same fact at the same time. One may retrieve a stale decision. A summary may lose a critical qualifier. Sensitive context collected for one task may leak into another. An agent may treat another agent's inference as if it came from the system of record.
The hard part is deciding what memory means, who can change it, how long it remains valid, and what happens when agents disagree. Shared memory is an operating model you design.
Start by separating state according to purpose
Teams get into trouble when every piece of context is placed in one searchable pool. A production design should separate state by purpose.
Working state
Working state is the short-lived scratchpad for one workflow run: the active objective, completed steps, intermediate outputs, open questions, and execution status.
It should be scoped to a run or thread, checkpointed so the workflow can resume, and discarded or archived according to a defined retention rule. Frameworks such as LangGraph explicitly distinguish thread-scoped short-term state from long-term memory shared across sessions. That distinction is architectural.
Conversation state
Conversation state preserves the messages and decisions required to continue a user interaction. It may span several agent runs, but it still belongs to a specific conversation, case, or task.
The OpenAI Agents SDK session model is one example: sessions maintain history across runs and can use different persistence backends. The design choice that matters is the session boundary. A support ticket, an account review, and a personal assistant conversation should not become one memory space.
Durable memory
Durable memory contains information that may be useful in future sessions: an approved user preference, a learned operating procedure, a validated account fact, or a lesson from an earlier run.
This memory needs stronger controls because it can influence decisions long after the original context is gone. It should include provenance, timestamps, ownership, sensitivity, and an expiration or review policy.
Business truth
Business truth is not agent memory at all. It lives in the CRM, ticketing platform, product database, identity system, contract repository, or another authoritative source.
An agent may remember that a customer prefers email. The customer record remains authoritative. An agent may summarize that a renewal was approved. The contract or approval system determines whether it actually was. A memory store that silently becomes a shadow system of record will eventually drive decisions from stale, ungoverned data.
Share governed records
A memory entry should not be an anonymous block of text. It should be a record with enough structure to evaluate whether another agent may trust and use it.
At minimum, a durable record should answer:
- What is it: a fact, user preference, observation, decision, hypothesis, task result, or summary?
- Where did it come from: a user statement, document, API response, tool result, or another agent's inference?
- Who wrote it: the agent, workflow, model, and version responsible for the entry?
- What is its scope: the user, tenant, account, case, workflow, or project to which it belongs?
- How reliable is it: verified, unverified, inferred, disputed, or superseded?
- When does it expire: a fixed time-to-live, an event-based invalidation rule, or a scheduled review date?
- Who may read or change it: permissions based on role, workflow, data class, and purpose?
That metadata turns retrieval into a policy decision instead of a similarity search. The nearest vector match is rarely the correct memory. A semantically relevant entry may belong to another customer, reflect an outdated policy, or contain a conclusion that was later reversed. Relevance is only one requirement. Scope, freshness, authority, and permission matter just as much.
Define ownership before allowing writes
Shared mutable state creates coordination failures even in deterministic systems. Agents add another layer of uncertainty because they may interpret the same context differently.
The safest default is single-writer ownership for important fields. One agent or service owns the canonical workflow plan. One component owns task status transitions. One verification step can mark an outcome confirmed. Other agents contribute proposed updates, evidence, or events rather than overwriting the current value directly.
When multiple writers are necessary, use ordinary distributed-systems controls:
- Version numbers or optimistic concurrency checks
- Idempotency keys for repeatable operations
- Append-only events for decisions and actions
- Explicit merge functions for fields that can be combined safely
- Leases or locks for work that must have one active owner
- Conflict states that trigger review instead of silently choosing a winner
An LLM should not improvise the merge rule for production state. If a research agent says an account has 500 employees and a sales agent says 1,200, the memory layer should preserve both claims, their sources, and their timestamps. A deterministic policy or human reviewer decides which value becomes trusted.
Treat summaries as lossy indexes
Long-running workflows create more state than a model can consume efficiently. Summarization and context compression are necessary, but summaries should not replace the underlying evidence.
A useful pattern is to store three layers: the original event or source reference, a structured record of the important fields, and a compact summary optimized for retrieval and model context. The agent usually reads the summary first. It can retrieve the structured record or original evidence when the decision requires more confidence.
This is a safer form of progressive disclosure. It limits context cost while preserving a path back to the source. It also makes corrections possible. When the underlying record changes, the system can identify and regenerate dependent summaries. Without lineage, stale summaries remain searchable and continue influencing future runs.
Memory permissions should follow the action boundary
Multi-agent systems are often designed around specialized roles, but a common memory store can quietly erase that separation. A research agent may need to read public account information but not customer contracts. A support agent may need the current case history but not unrelated conversations. A verifier may need read access to execution evidence without permission to rewrite it.
Memory access should be scoped as deliberately as tool access:
- Separate namespaces by tenant, user, workflow, and data classification
- Grant agents the minimum read and write permissions their role requires
- Filter retrieval before content reaches the model
- Encrypt sensitive state and define retention limits
- Log reads, writes, corrections, and deletions
- Prevent untrusted retrieved content from becoming instructions
Persistent memory can carry prompt injection across sessions. If an agent stores an untrusted instruction from a document and another agent later retrieves it as trusted context, the attack has become durable. Memory records need a clear distinction between data and instructions, plus provenance that survives summarization and retrieval.
A practical architecture for shared agent state
For most production workflows, a reliable design does not require one universal memory engine. It requires clear interfaces between a few different stores:
- A checkpoint store for run-level workflow state
- A session store for conversation continuity
- A durable memory service for scoped, governed records across sessions
- An event log for actions, decisions, and state transitions
- Direct access to systems of record for authoritative business facts
Place a policy layer in front of durable memory. That layer should validate scope, enforce permissions, attach provenance, apply expiration rules, and control which records are eligible for retrieval.
Framework memory interfaces can sit behind that boundary. Microsoft AutoGen, for example, defines memory as a protocol whose implementations may use different storage and retrieval mechanisms to update model context. That flexibility is useful, but the application still owns the rules that determine what should be stored and trusted. The database does not supply the operating model.
Test memory as a system, not a prompt
A memory design should be tested against the failures it will encounter in production. Ask what happens when:
- Two agents update the same record concurrently
- An agent retries after a timeout
- A workflow resumes from an old checkpoint
- A source document changes after a summary is created
- An entry crosses its expiration time
- One tenant's content is semantically similar to another's
- An agent writes an unsupported inference as a fact
- A deletion request must propagate through summaries and indexes
- A malicious instruction is stored inside retrieved content
Then measure more than retrieval accuracy. Track stale-memory incidents, conflict rates, unauthorized retrieval attempts, correction propagation time, duplicate writes, unsupported claims, and the percentage of consequential decisions tied back to authoritative evidence.
The measure that matters is whether the agent used the right state, from the right scope, with the right authority, at the right time.
Coordination comes from rules
Shared memory can make a multi-agent workflow faster and more capable. It can also turn a collection of specialized agents into a system where every component inherits every other component's mistakes. The difference is governance.
Agents coordinate reliably when the state between them has rules. Without those rules, shared memory is just shared risk.
Design the state boundary before you scale the agent workflow. If you are moving a multi-agent prototype toward production, PRESHai can help you build the governed architecture around it.
