Shared Memory for AI Agents
Shared memory for AI agents is durable organizational state that more than one agent can read and update across sessions. It is different from one agent’s chat history, local files, or a vector index that only retrieves documents.
The core requirement is simple: when Claude, ChatGPT, Codex, a background behavior, and a custom agent all work with the same customer or project, they should not each maintain a separate version of the truth. They need a shared record with evidence, permissions, and a history of how it changed.
What shared agent memory needs
Section titled “What shared agent memory needs”A useful shared-memory layer has five properties:
- Durability. Important facts survive chat resets, sandbox restarts, and agent changes.
- Shared identity. Different agents resolve the same customer, project, person, or decision to the same organizational object.
- Provenance. A fact can be traced back to the event, source, or human that produced it.
- Permission-aware reads. Sharing memory does not mean every agent gets every fact. Access still follows user and source permissions.
- Controlled writes. Agents can consolidate or correct state without silently overwriting the evidence that came before it.
This is why a folder of memory files works well for a personal assistant but starts to fail for a company. Files are excellent working memory. They are a poor coordination primitive when many agents need to converge on the same changing state.
Scratch space and organizational memory are different layers
Section titled “Scratch space and organizational memory are different layers”Agents need both.
| Layer | Best for | Lifetime | Scope |
|---|---|---|---|
| Filesystem / sandbox | downloads, scripts, intermediate CSVs, temporary notes | task or agent workspace | one agent or run |
| Shared entity memory | customer facts, decisions, project state, recurring knowledge | durable | authorized agents and people |
| Event history | evidence, changes, observations, actions, approvals | append-only | authorized agents and operators |
A useful mental model is the data-team split between a notebook and a warehouse. The notebook is where one worker explores. The warehouse is where durable results become available to the rest of the organization.
Lobu uses the same separation. See the deeper Memory model and Filesystem vs database for agent memory.
Why a vector database is not enough
Section titled “Why a vector database is not enough”Vector retrieval solves an important problem: finding semantically relevant text. It does not by itself define:
- which Acme record two agents should update
- whether a fact is current or superseded
- which source supplied it
- who is allowed to see it
- whether an agent may take an action based on it
- how a human corrects the shared state
For shared company memory, retrieval is one capability inside a larger state model. Typed entities and append-only events make the state addressable and auditable; semantic search then helps agents find the relevant pieces.
An example: three agents, one customer
Section titled “An example: three agents, one customer”Imagine three agents working with Company:Acme:
- a support agent learns that the customer’s CTO left
- an engineering behavior observes a production incident
- a renewal agent sees that the contract renews next month
With per-agent memory, those facts live in three separate places. The next agent has to rediscover them.
With shared memory, the observations attach to the same company entity while their source events remain available as evidence. An authorized agent asking “what is going on with Acme?” can see the combined current context without copying one agent’s private scratchpad into another.
How Lobu implements shared memory
Section titled “How Lobu implements shared memory”Lobu’s memory model is entity-based and event-sourced:
- events preserve observations and outputs as durable evidence
- entities give agents shared organizational objects such as companies, projects, and members
- memory attaches durable facts and summaries to those entities
- behaviors continuously consolidate relevant signals into shared state
- permissions scope what a given user or agent can read and do
- MCP lets external agents use the same company context without moving them into a new harness
That means ChatGPT, Claude, Codex, and custom agents can work from the same organizational memory while keeping their own local working directories and conversation state. See Lobu MCP for the cross-agent access path.
Shared memory vs conversation memory
Section titled “Shared memory vs conversation memory”Conversation memory answers: “what did this agent and user discuss before?”
Shared organizational memory answers: “what does the company currently know about this entity, where did that knowledge come from, and which agents are allowed to use it?”
A production AI teammate usually needs both. Conversation history helps preserve local continuity. Shared organizational memory lets separate agents coordinate around customers, projects, decisions, and changing company state.
When shared agent memory is worth the extra structure
Section titled “When shared agent memory is worth the extra structure”Use a shared memory layer when:
- multiple agents need to read or update the same facts
- context must survive individual conversations and sandboxes
- knowledge arrives continuously from tools such as Slack, Jira, email, CRM, or databases
- humans need to inspect and correct agent memory
- permissions differ by user, source, customer, or workspace
- you need evidence for why an agent believed something
If you are building a single personal agent with no shared company state, local files or a simpler memory service can be the better choice.
Measure memory, do not assume it works
Section titled “Measure memory, do not assume it works”Retrieval quality and answer quality should be tested separately. Lobu publishes its methodology and reproducible results on agent memory benchmarks so changes to ingestion, retrieval, and answering can be evaluated instead of judged from demos.