Building Multi-Agent Systems with Shared Memory Guide

Multi-agent memory sounds simple until you try to build it. One agent learns something useful. Another agent should benefit from it. A third agent should probably not see it. By the time you add users, teams, tools, and environments, “shared memory” stops being a feature checkbox and turns into an architecture problem.

That is why most multi-agent systems either over-share or under-share. In one direction, everything lands in one noisy pool and recall gets messy. In the other, each agent has its own silo and nothing compounds. The right answer is a deliberate shared agent context model, one built around bank boundaries, retention discipline, and retrieval that can handle cross-session work.

This guide walks through the patterns that hold up in practice, including per-team memory, per-user isolation, project-scoped banks, and hybrid layouts where some knowledge is shared and some stays local. If you want the underlying mechanics while you read, keep the docs home, the quickstart guide, Hindsight's retain API, and Hindsight's recall API nearby.

The core idea

A multi-agent system needs memory boundaries that match the real collaboration boundary.

That usually means deciding what should be shared at each of these levels:

• user
• project
• team
• environment
• tool or agent role

If those boundaries are wrong, the memory layer will feel wrong too.

What shared memory is actually for

Shared memory is most valuable when agents are doing different parts of the same larger job.

Examples:

• a research agent gathers material, a writing agent turns it into a draft
• a support agent captures user issues, a follow-up agent handles escalations
• one coding agent investigates, another implements, another reviews
• a Hermes assistant and an OpenClaw workflow operate on the same user or project context

In all of these cases, the value comes from compounding knowledge across sessions and roles.

The shared-memory pattern is described from a user perspective in One Memory for Every AI Tool I Use. This guide focuses on the architecture behind it.

The first design decision: what is the bank boundary?

This is the most important choice you make.

Option 1: one bank per user

Use this when:

• several agents serve the same person
• each user should have continuity across tools
• cross-user leakage must never happen

Good fit for:

• personal assistants
• customer-facing support systems
• multi-tool personal workflows

Option 2: one bank per project

Use this when:

• several agents collaborate on the same project
• project conventions and decisions should carry across roles
• users are less important than the workstream

Good fit for:

• coding teams
• research workflows
• long-running internal initiatives

Option 3: one bank per team

Use this when:

• the whole team should benefit from shared operational knowledge
• there is one common domain and one trust boundary
• cross-project leakage is acceptable

Good fit for:

• internal support agents
• platform engineering teams
• common playbooks and runbooks

Option 4: hybrid

This is often the real answer.

Example:

• user-specific bank for personal context
• project bank for work context
• optional shared team bank for general practices

That gives you both personalization and cross-agent leverage.

Common isolation patterns

Here are the patterns that usually work best.

Pattern	Share within	Isolate across	Best for
Per-user	all agents serving one user	users	assistants, support
Per-project	all agents on one project	projects	software, research
Per-team	all agents in one team	teams	internal ops
Per-user-per-project	one user's work on one project	users and projects	consulting, client work
Hybrid shared + local	shared project knowledge plus role-local memory	depends on design	complex multi-agent systems

A useful mental model is simple: share by default only across actors that should genuinely learn from one another.

A practical architecture

A clean shared-memory setup often looks like this:

                ┌──────────────────────────────┐
                │         Hindsight            │
                │   bank: project-acme-api     │
                └──────────────┬───────────────┘
                               │
        ┌──────────────────────┼──────────────────────┐
        │                      │                      │
┌───────▼───────┐      ┌───────▼───────┐      ┌───────▼───────┐
│ Research Agent│      │ Builder Agent │      │ Review Agent  │
└───────────────┘      └───────────────┘      └───────────────┘

All three agents share the same bank because they are contributing to one project.

A more advanced layout might look like:

user:alice          project:acme-api        team:platform
    │                     │                     │
    └──── local agent ────┼──── shared agents ─┘

In that design, an agent can retain into more than one conceptual layer depending on what kind of knowledge it is producing.

What should be shared

Good candidates for shared memory:

• architecture decisions
• accepted conventions
• recurring failure modes
• deployment lessons
• project milestones
• user preferences that all relevant agents should honor

Bad candidates for broad sharing:

• noisy intermediate reasoning
• one-off drafts that no one will reuse
• sensitive personal details outside the intended boundary
• agent-local scratch work

Shared memory gets stronger when retention is selective, not maximal.

How Hindsight helps here

Hindsight is useful for shared multi-agent memory because it is not limited to semantic similarity over chunks. It retains structured facts and retrieves with multiple strategies, which matters when different agents ask differently shaped questions.

One agent might search semantically. Another might ask for an exact term. Another might need a time-bounded chain of events. The same shared bank can support all of those because recall combines:

• semantic retrieval
• BM25 keyword retrieval
• graph traversal
• temporal retrieval
• reranking over the merged result set

That retrieval model is explained in the recall architecture guide.

Real-world examples

Support team with specialist agents

A triage agent identifies the issue. A billing agent handles account state. A follow-up agent sends summaries and next steps.

A per-user bank works well here. Each specialist can benefit from the others' retained context without mixing customers together.

Coding workflow with role-based agents

A research agent explores options, a coding agent implements, and a review agent checks the final changes.

A per-project bank is usually right. The point is to compound project knowledge, not personal identity.

Hermes plus other tool surfaces

If a Hermes assistant and another agent surface are both working for the same user, a per-user shared bank can make sense. If they are collaborating on one engineering effort, a per-project bank is often cleaner.

Decision tree

Use this quick rule set.

Question	If yes	If no
Should different agents remember the same user's preferences?	Start with per-user memory	Keep user context local
Are several agents collaborating on the same artifact or project?	Add a per-project bank	Separate by role
Would a mistake be costly if another team saw this memory?	Tighten isolation	Shared bank may be acceptable
Do agents need the same operational playbook?	Add a team-level bank	Skip broad sharing
Is memory quality getting noisy?	Narrow the bank boundary	Keep the current scope

Common mistakes

One giant global bank

This feels efficient at first and becomes noisy fast.

No retention discipline

If every turn is retained as equally important, the bank fills with low-value clutter.

Sharing without a trust model

If you cannot explain who should see what, the bank design is not ready.

Treating retrieval problems as storage problems

A bank can contain the right knowledge and still feel broken if recall is weak or badly scoped.

A good starter pattern

If you are unsure where to begin, start here:

• one bank per project for team workflows
• one bank per user for assistant workflows
• avoid team-wide sharing until you know you need it
• keep retention focused on reusable context

That gets most systems to a stable first version without overcomplicating the layout.

Bottom line

Shared memory does not mean one giant memory.

It means the right agents can build on one another's work without polluting contexts that should stay separate. If you choose the bank boundary well, retain selectively, and use retrieval that supports more than semantic similarity, multi-agent memory becomes a real advantage instead of a source of noise.

Next steps

• Start with Hindsight Cloud if you want shared memory without running your own infrastructure
• Read the full Hindsight docs
• Follow the quickstart guide
• Review Hindsight's recall API
• Review Hindsight's retain API
• See the user-facing pattern in One Memory for Every AI Tool I Use