11. Shared Memory in Multi-Agent Systems — Many minds, one notebook¶

~17 min read. The moment several agents collaborate, memory becomes a coordination problem, not only a storage problem.

Built on the ELI5 in 00-eli5.md. The filing-cabinet — now shared by many workers — needs rules so one agent does not overwrite what another just learned.

1) Why shared memory is hard¶

See the picture.

planner agent ──┐
research agent ─┼──→ shared memory ──→ executor agent
critic agent ───┘

This looks efficient.

It also creates conflicts. Different agents may write at the same time.

They may disagree. They may use different abstractions.

They may even duplicate work. If shared memory has no rules,

quality collapses. One agent's summary-card may erase another agent's caveat.

One diary-page may record an event too early. One profile update may be based on weak evidence.

So what to do? Treat shared memory like a database with workflow.

Not like a magical common mind. Simple, no?

2) Patterns for shared memory¶

Common patterns include these.

A. Shared scratchpad¶

All agents append notes.

Good for transparency. Bad for noise.

B. Role-specific stores¶

Planner writes plans. Researcher writes evidence.

Executor writes outcomes. Better separation.

C. Mediated memory¶

Agents propose updates. A memory manager validates and commits them.

This is strong for important systems.

agent proposal ──→ validation ──→ committed memory
                     │
                     ├── schema check
                     ├── source check
                     └── conflict check

The mediated pattern is often worth it.

Yes, it adds latency. But it reduces chaos.

3) Conflict resolution¶

Shared memory needs rules for collisions. Examples:

last-write-wins
confidence-weighted merge
role priority
human approval for high-risk fields

Look at one simple flow.

new write arrives
      │
      ├── same key, same value ─────→ merge source refs
      ├── same key, newer evidence ─→ update value
      ├── same key, conflict ───────→ mark dispute
      └── new key ──────────────────→ insert

Last-write-wins is easy.

It is often too crude. Confidence-weighted merge can be better.

But it still needs scope and source tracking. See.

Shared memory becomes manageable when writes are explicit, versioned, and attributable.

Anonymous shared state is a debugging nightmare.¶

4) Worked example: planner versus executor¶

Suppose three agents collaborate on a release.

Planner writes: - next step = run staging tests

Researcher writes: - known risk = currency rounding regression on EUR flows

Executor writes later: - staging tests passed except EUR rounding case

If the executor overwrites the plan blindly, shared memory may now say,

"staging tests passed" and lose the exception.

Bad. A mediated memory manager would commit instead:

plan_status = partially complete
risk = EUR rounding regression remains open
latest event = staging pass except EUR rounding case Now every agent reads the same truth.

The filing-cabinet stays coherent. The diary-page stores the latest event.

The summary-card can mention the open risk. That is shared memory done properly.

5) Operational guardrails¶

Use schemas. Use version numbers.

Use source references. Use actor ids.

Log rejected writes. Partition memory by tenant and task.

Consider locks for high-contention updates. But do not over-lock everything.

That kills throughput. So what to do?

Choose strictness by memory type. A shared scratchpad can be append-only.

An address-book field may need mediated updates. A sensitive permission change may need human approval.

Look. Multi-agent memory is one place where boring systems design wins hard.

Where this lives in the wild¶

LangGraph multi-agent workflows — AI engineer often need shared state so planner, researcher, and executor can coordinate across steps.
Customer support orchestration bots — support ops may split triage, policy lookup, and drafting into agents that share case memory.
Software release copilots — platform engineer can use specialized agents for risk analysis, test execution, and changelog drafting over shared run memory.
Autonomous research assistants — analyst often use separate browse, summarize, and critique agents that must share evidence without corrupting it.
Warehouse automation supervisors — operator may coordinate scheduling, routing, and exception-handling agents through shared operational state.

Pause and recall¶

Why does shared memory turn into a coordination problem?
What is the difference between a shared scratchpad and mediated memory?
In the worked example, what detail was lost by blind overwrite?
Why are source references especially important in multi-agent systems?

Interview Q&A¶

Q: Why not let every agent write freely into one shared memory object? A: Free writes maximize noise and conflicts. Shared memory needs schema, ownership, and conflict handling to remain trustworthy.

Common wrong answer to avoid: "Because agents are slower than databases" — the real issue is semantic conflict and traceability.

Q: Why can append-only scratchpads still be insufficient? A: They preserve everything, but force later agents to interpret noisy, conflicting notes. You often still need validated committed memory.

Common wrong answer to avoid: "Because append-only is expensive" — cost matters less than interpretability and precision.

Q: Why attach actor ids and version numbers to memory writes? A: They support attribution, debugging, and safe merging. Without them, conflicting updates are hard to resolve.

Common wrong answer to avoid: "Only for analytics" — they are core to correctness and conflict resolution.

Q: Why might high-risk memory writes need mediation or approval? A: Some fields affect permissions, policy, or user trust directly. Bad writes there are more dangerous than missing writes.

Common wrong answer to avoid: "Because humans are more accurate" — the deeper reason is risk containment and accountability.¶

Apply now (5 min)¶

Exercise: Imagine three agents working on one task. Define one shared scratchpad field, one committed fact field, and one event field. Then write one conflict rule for each. Sketch from memory: Draw planner, researcher, and executor feeding a mediated memory manager before updates reach shared memory.

Bridge. Shared memory gives us power, yes. But how do we know any of this actually improves the product rather than just adding complexity? → 12-memory-evaluation.md