Concepts · July 9, 2026

Multi-agent memory: why your agents live in parallel universes

Everyone says “agent memory,” but they don’t mean the same thing. One product means remembering a user. Another means knowing what’s true now. Your multi-agent system needs a third thing — and most stacks don’t have a name for it yet.

The parallel-universes problem

Put three agents on one task and a strange thing happens: each one starts from zero. The researcher discovers that the auth flow moved to v2. The writer never sees it and documents v1. The reviewer approves against a third version that no longer exists. Nobody is wrong, exactly — they’re each correct inside their own copy of reality.

This isn’t a reasoning failure. A recent taxonomy of multi-agent failures found that 36.9% of them come down to agents disagreeing about shared state — inconsistency, not incapability. And the tax you pay for it is measured in tokens: roughly 40% of compute in these systems is burned re-establishing context that another agent already had.

Three shapes of the same problem show up again and again:

• The invisible handoff. Agent A learns something; agent B never sees it and redoes the work.
• Stale truth. Two agents update the same fact. Which value is your system serving right now? If you can’t answer, neither can your agents.
• Debugging in the dark. “Why did the agent do that?” shouldn’t take an afternoon. Without provenance, every incident is archaeology.

“Memory” means at least three different things

The reason this is confusing is that the memory tools you’ve heard of were built for different questions. It helps to line them up:

• Personalization memory answers “who is my user?” — durable preferences and facts about a person, ranked at read time. Great for a single assistant getting to know you.
• Temporal memory answers “what is true now?” — every fact carries a validity window, and stale knowledge is superseded rather than confusing retrieval. Great for one assistant over changing facts.
• Coordination memory answers “is my team of agents working from the same reality?” — and that’s the one a multi-agent system is missing.

The first two are real and good at what they do. But remembering a user perfectly doesn’t stop two agents from writing two different truths about the same task, and knowing which fact is current doesn’t guarantee that agent B’s next context window actually contains agent A’s latest write.

What coordination memory actually is

Coordination memory is a shared memory system for a team of agents. The loop is simple to say and load-bearing to get right:

• Write. Agents stream events as they work. Nothing blocks — the write path never waits on an LLM.
• Consolidate. Events become versioned claims. When two agents write the same fact, the conflict is resolved at write time, by a policy you choose — not by luck at read time. The losing value is versioned, not erased.
• Pack. Any agent asks for one budget-fit, provenance-tagged block of context — deterministic and cache-friendly — instead of replaying the whole history.

The difference from “personalization” and “temporal” isn’t the storage. It’s where correctness is established. Coordination memory constrains and adjudicates at the moment of writing, so the shared state is already consistent before anyone reads it.

Read-your-writes, for agents

The primitive that makes this real is a consistency contract borrowed from databases. When an agent writes, the API returns a sequence number:

const { seq } = await lore.write({
  runId, agentId: "researcher",
  content: "Auth flow moved to v2 — PR #42 merged",
}); // seq: 1042

const pack = await lore.pack({
  query: "current state of auth work",
  minSeq: 1042,        // read-your-writes
  tokenBudget: 2000,
});
pack.coveredSeq  // ≥ 1042 → the write is in there, guaranteed

If agent A wrote it, agent B’s next pack contains it — extracted, or included as a raw tail until extraction lands. The pack tells you its coveredSeq, and the response carries freshness_lag_ms so “how current is this?” is a number, not a vibe. That’s the whole game: session guarantees for agent teams, as an API contract instead of a blog promise.

Coordination is also a governance problem

Once several agents — some of them freshly spun up, some of them handling untrusted input — write to the same memory, “who can write what” stops being optional. Coordination memory treats governance as first-class: per-agent access control compiled to SQL predicates, new agents that start quarantined until trusted, and mandatory provenance so every claim traces back to the run and event that produced it. Untrusted writes never reach your prompts.

When you don’t need this

If you’re building a single assistant that remembers one user’s preferences, you want personalization memory. If you’re building one assistant over facts that change and get queried historically, you want temporal memory. Coordination memory earns its keep the moment you have more than one agent writing shared, fast-changing state — and it becomes non-negotiable when those agents disagreeing is a bug your users can see.

The one-line version

Personalization remembers your user. Temporal memory knows what’s true now. Coordination memory keeps your agent team in sync — with consistency guarantees, access control, and a token bill that goes down. That last one is the category we’re building, in the open.

Lore is an open-source coordination memory layer. The repo is live on GitHub; see how the pieces fit on Features, or how it compares on Compare.