Concepts · July 3, 2026 · 5 min read

What is coordination memory? A working definition

“Agent memory” is one phrase doing three jobs. Two of them are well known. The third — the one a team of agents actually needs — barely has a name yet. Here's a precise definition of coordination memory, and the line that separates it from just sharing a store.

One word, three jobs

When people say "agent memory," they mean one of three things, depending on the problem in front of them:

• Personalization memory answers "who is my user?" — durable facts and preferences about a person.
• Temporal memory answers "what is true now?" — every fact carries a validity window, so stale knowledge is superseded.
• Coordination memory answers "is my team of agents working from the same reality?" — and that's the one most multi-agent systems are missing.

The definition

The load-bearing phrase is "at write time." Personalization memory settles correctness at read time (rank the right record higher). Temporal memory settles it after the write (invalidate the old fact). Coordination memory constrains and adjudicates as the write lands — so by the time another agent reads, there's already a single, agreed answer.

Sharing a store is not coordination memory

Here's the distinction that matters, because it's the one most stacks get wrong. You can hand the same memory object to five agents and call it "shared memory." That's sharing a pointer. It is not a coordination contract. To be coordination memory, sharing has to come with guarantees:

• A consistency contract. When agent A writes, agent B can guarantee it sees that write in its next context — read-your-writes, with a sequence token and a freshness number, not a hope.
• Conflict resolution at write time. Two agents write the same fact; the system detects the conflict with a constraint and adjudicates it by a policy you choose. The losing value is versioned, not lost.
• Per-agent access control. Who can read and write what is enforced structurally, so an untrusted write can't silently reach a trusted agent's prompt.
• Provenance. Every claim traces to the agent, run, and event that produced it — so "why did the agent do that?" has an answer.

Take those away and you're back to five agents sharing one pointer and hoping. Under load, hope loses — which is exactly how coordination failures happen.

When you have a coordination problem

You don't always need this. If you're building a single assistant that remembers one user, 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

Coordination memory is shared memory for a team of agents, with the contract that makes "shared" actually mean "in sync": write-time correctness, read-your-writes, access control, and provenance. It's not better personalization or better temporal truth — it's a different question, answered with guarantees.

This is the category Lore is building, in the open. Start with the pillar, see the write → consolidate → pack loop, or read how it stacks up on Compare. Repo on GitHub.