Multi-Agent Memory Architecture Guide: Shared vs Isolated vs Hierarchical (2026)

Designing multi-agent memory involves defining ownership and read/write boundaries before connecting agents to a store. Keep scratch work private, share validated facts through an approval path, and retain per-agent provenance. Specify how contradictory assertions are resolved and when indexed updates become visible before another agent depends on them.

A shared endpoint alone does not establish isolation. Access permissions must enforce who can read and write each dataset; retrieval filters organize results within those boundaries. When agents assert incompatible facts, preserve both assertions with their sources and review status until an authoritative source or reviewer determines the current accepted fact.

This guide compares shared, isolated, and hierarchical/scoped memory architectures by access requirements, consistency, latency, and governance. A worked Cognee example uses a shared project dataset alongside private agent datasets, with controlled promotion into shared memory. It also addresses indexing completion before cross-agent handoffs.

This is architecture guidance rather than a platform ranking.

What Is Multi-Agent Memory Architecture?

Multi-agent memory architecture defines who owns stored context, which agents may read or write it, and how information moves between them. Structure it around access requirements: use shared memory for common context, isolated stores for private work, and scoped layers when teams need controlled sharing across project and organizational boundaries.

The diagrams below separate architecture decisions from product capabilities: they describe access designs, with documented implementation primitives identified separately.

Shared memory

Architecture diagram, one shared project dataset

Agent A ──WRITE──▶ Authenticated memory API
Agent B ──WRITE──▶ Authenticated memory API
Agent C ──WRITE──▶ Authenticated memory API

Agent A ◀──READ── Authenticated memory API
Agent B ◀──READ── Authenticated memory API
Agent C ◀──READ── Authenticated memory API

Authenticated memory API ──WRITE──▶ Project dataset
Authenticated memory API ◀──READ─── Project dataset

Documented primitive: Cognee API Mode supports multiple assistants sharing a graph. Architectural synthesis: the authenticated gateway and separately authorized read/write paths shown here.

Treat the dataset as project-owned rather than agent-owned. Agents receive explicit read and write permissions; connecting to the same API should not imply unrestricted mutation. Handoffs happen through approved writes that other authorized agents can retrieve. This fits collaborators needing common context, but the design must assign conflict ownership: when agents submit contradictory facts, specify who may resolve the conflict rather than allowing competing writes to silently define authority.

Isolated memory

Architecture diagram, private stores with deliberate handoffs

Agent A ──READ/WRITE──▶ Store A
Agent B ──READ/WRITE──▶ Store B
Agent C ──READ/WRITE──▶ Store C

Agent A ──handoff artifact──▶ [Approval boundary]
                            └──approved artifact──▶ Agent B

Documented primitive: Cognee standalone MCP instances keep separate data. Architectural synthesis: the approval boundary and artifact-transfer workflow.

Each agent owns its working store and reads or writes only that store in this design. Another agent receives selected artifacts through an explicit approval boundary, not direct access to the originating memory. Isolation fits private scratchpads and independent investigations. Its trade-off is deliberate coordination: useful findings do not become shared recall automatically, so the workflow needs a handoff or promotion step before another agent can reuse them.

Hierarchical or scoped memory

Architecture diagram, policy-governed scopes and private scratchpads

               Organization policy
                       │ governs access
                Team / project scopes
                       │
              Private agent scratchpads

Agent ──authorized READ──▶ permitted scope
Agent ──authorized WRITE─▶ assigned scope
Scratchpad ──approval-controlled promotion──▶ Project
Project ──approval-controlled promotion────▶ Team

Documented primitives: Cognee dataset permissions and explicit retrieval scopes. Architectural synthesis: this hierarchy, its ownership rules, and promotion workflow, not automatic vendor-provided inheritance or policy precedence.

Assign ownership at each scope: organizational policy governs visibility, team and project owners control shared material, and agents retain private scratchpads. Reads cross boundaries only when authorized; writes target explicitly permitted scopes. Handoffs upward require approval-controlled promotion. This design fits agents that need both private working context and selectively shared knowledge. Implement each access rule explicitly rather than assuming a parent namespace automatically grants access to its children.

Access topology versus memory duration

LangGraph distinguishes thread-scoped short-term state, persisted through checkpoints, from cross-session long-term memory stored under custom namespaces. That distinction concerns persistence and recall scope. Shared, isolated, and hierarchical architectures concern who can access the information.

Make these decisions separately. Long-term memory is not necessarily shared: a cross-session namespace can remain agent-specific. Short-term state is not necessarily private: thread-scoped state can serve a collaborating workflow when access permits it. Specify both the persistence boundary and the authorized readers and writers; neither determines the other.

Why Multi-Agent Memory Design Matters in 2026

For a coding-agent team in 2026, memory design starts with deciding which knowledge should travel between agents. Approved repository conventions, architecture decision records (ADRs), and service relationships belong in a shared scope; unfinished reasoning and developer preferences need separate scopes. Those boundaries affect permissions and handoffs: a successful write does not establish that another agent can retrieve it yet. With a common Cognee MCP-backed graph, use authenticated dataset permissions and verify indexing completion before handing newly written knowledge to another agent.

Research pipelines need a different publication boundary. Investigators can keep scratchpads isolated while contributing source-linked evidence to a shared project scope; a reviewer then promotes validated findings. This separates working material from reviewed findings. Per-agent tags organize content inside a mutually readable graph, but they are not a substitute for access controls. When one investigator’s material must not enter another’s answers, use permission-controlled datasets rather than relying on labels.

Company-wide availability likewise does not mean universally readable memory. Organization, team, project, and private-agent scopes require centrally administered identities, least-privilege reads, restricted policy writers, and source authorization before retrieval. Deployment evaluation must also account for remote access, write propagation, dataset permissions, cross-client compatibility, and deployment control. These requirements are the basis for evaluating tools.

Common Challenges in Shared Multi-Agent Memory

Shared memory needs explicit rules for access, retrieval scope, visibility, and conflicting updates. Sharing a store does not establish which agents may read each assertion or which assertion should become authoritative. We recommend separating documented platform behavior from application policy.

Common problems encountered

Unauthorized cross-scope access requires an authorization boundary, not just a retrieval filter. Cognee NodeSets group graph content and support filtering, but they are not security boundaries: entities can belong to multiple NodeSets, and relationships from another source set can appear between entities in the requested set. Use permission-controlled datasets for confidentiality. Treat NodeSets as retrieval organization within authorized content, not as proof that another agent cannot access it.

Overly broad retrieval can happen even when authorization works correctly. Cognee recall searches datasets the current user can read when neither datasets nor dataset_ids is supplied. Give each task an explicit dataset allowlist to constrain its scope. An agent's permission to read additional datasets should not automatically make those datasets relevant to every query.

Indexing visibility delays complicate agent handoffs. Cognee can accept ingestion while recall still sees only indexed data, so an acknowledgment does not guarantee that another agent can retrieve the new information. For deterministic handoffs, wait for indexing completion or check cognee.datasets.get_status() before the receiving agent queries. That readiness check adds a coordination step; do not assume immediate graph-wide read-after-write visibility.

Competing updates or assertions require separate handling. Letta documents last-write-wins replacement for concurrent direct memory-block modifications: one writer can overwrite another's changes. Shared blocks can be read-only, but writable shared blocks need controlled writers or application coordination. Shared visibility alone does not provide merge safety.

Write collisions and contradictory facts

A record-level collision occurs when two processes update the same stored record. A semantic contradiction occurs when two agents assert incompatible facts, even if each assertion is stored successfully. Coordinating writers addresses the former; evaluating authority addresses the latter. Do not infer automatic semantic resolution, locking, or transaction guarantees from graph storage.

Consider Agent A reading an old architecture decision record (ADR) requiring a 30-second timeout, while Agent B reads a newer approved ADR requiring 60 seconds. Preserve both source-linked assertions with their respective effective dates and approval status. Our recommended application policy is to select the approved decision effective for the queried scope and time. If authority or dates are ambiguous, return the disagreement for review rather than selecting whichever assertion arrived last.

Preserve source_agent, source reference, observed time, effective time, scope, and review status for each assertion. Zep's created_at, valid_at, invalid_at, and expired_at fields support lifecycle reasoning, and it attempts to invalidate superseded facts. Those mechanisms do not prove truth. Promotion to current truth still needs an authoritative source or reviewer; timestamps and provenance supply evidence, not an automatic verdict.

What to Look for in a Multi-Agent Memory Layer

Evaluate the access model before the retrieval interface. A shared store, an agent-specific namespace, and an enforced authorization boundary solve different problems. The implementation must preserve the intended identity and permissions from the agent’s request through retrieval and writes, not merely organize records under different names.

Must-have features for shared and scoped memory

Start with an access matrix: which agents can read, write, delete, or share each scope? Then check identity propagation across SDKs, API gateways, and MCP processes. An agent identifier is useful for organizing context, but it is not evidence that the backend rejects unauthorized requests.

Require explicit retrieval scope and distinguish filtering from confidentiality. Cognee illustrates the difference: permission-controlled datasets support access boundaries, while NodeSets organize graph retrieval. NodeSets are not security boundaries; shared entities can belong to several sets, and relationships originating elsewhere can appear between entities in the requested set.

Define writer ownership and conflict handling separately from read access. If two agents submit contradictory facts, decide whether to preserve both claims for review, designate an authoritative writer, or accept replacement. Do not assume that shared visibility includes safe merging. Letta, for example, documents last-write-wins replacement for concurrent direct block modifications.

Make provenance an acceptance criterion: retain the writing agent’s identity, source references, and the evidence retrieved for an answer. Zep exposes source-episode references through episode_uuids, but its guidance cautions that API logs alone do not provide a complete answer audit trail. Do not use customer-writable or model-generated metadata as trusted security labels.

Finally, test indexing visibility and deployment behavior: when does a completed write become retrievable, what can another agent observe during an update, and what latency does the required consistency introduce? Treat undocumented guarantees as validation work, not assumed capabilities. Check authentication settings, storage-handler compatibility, and deployment-tier restrictions alongside retrieval quality.

Implementation support across memory tools

The table maps documented mechanisms to architecture requirements. It is unranked; unspecified authorization or write guarantees remain open implementation questions.

For Cognee tenant separation through MCP API Mode, use the documented separate-process and backend-user-token approach: memory tools do not propagate distinct caller identities within one process. Dataset names alone do not separate those callers, and separately authorized datasets do not automatically form one traversable graph.

For product evaluation, see our comparison of shared memory layers for multiple AI agents. Keep this architecture decision grounded in access matrices, writer policies, and implementation tests rather than transferring a product ranking into an authorization design.

How to Implement Shared, Isolated, and Hierarchical Agent Memory

Implement memory boundaries before connecting agents to a common store. Define authenticated identities, dataset ownership, read/write permissions, and the point at which private work becomes approved shared knowledge. The scenarios, access matrix, and Python examples below are proposed designs that have not been executed, not customer deployments or validated runnable integrations.

Cognee supplies the implementation mechanisms used here: permission-controlled datasets, NodeSets, metadata, and scoped memory operations. Validate the installed SDK version, imports, authentication context, dataset provisioning, and indexing-status handling before adapting the examples.

Choose scopes for coding, research, and company-wide agents

Proposed coding-team design (not executed): put approved repository conventions, architecture decision records (ADRs), and service relationships in an authenticated shared dataset. Keep unfinished agent reasoning and developer preferences in separately permissioned private memory. This pairs shared coding knowledge with a common project scope and private coding work with restricted scopes; a common graph does not require every agent to read every draft.

Proposed research-pipeline design (not executed): give each investigator a private dataset for scratchpads. Promote source-linked, validated findings into a shared project dataset through a reviewer-controlled path. These are separate mechanisms: dataset permissions isolate unfinished research, while review controls which evidence becomes shared. Source-agent NodeSets organize findings inside the mutually readable dataset; they do not prevent another authorized reader from accessing those findings.

Proposed company-wide design (not executed): separate organization, team, project, and private-agent scopes. Restrict policy writers, administer identities centrally, and authorize source access before retrieval. Pair company policies with the appropriate organization/team/project scope; pair private company-agent context with least-privilege identities and explicit retrieval scope. A company-wide memory platform should not imply a universally readable graph.

For the worked example, picture three private datasets feeding a review gate, with an approved-write arrow into project_shared. Read arrows return from that shared dataset to the researcher, coding agent, and reviewer. This is a shared project graph with per-agent private scopes, not three confidential partitions created by tags.

Define a shared-project access matrix

Proposed access matrix (not executed): provision the following permissions before ingestion. Each worker owns a private workspace, while only the reviewer or an authorized promotion service can write shared knowledge. For the code below, provision project_shared under the promotion service's ownership so its name-based write selects the intended dataset.

Approval must not be confused with access to every worker's scratchpad. Keep private datasets private and submit the material intended for review through the promotion workflow. Within project_shared, source-agent NodeSets support retrieval organization; dataset permissions enforce access boundaries. Neither a status metadata field nor a source-agent tag grants write permission.

If these identities connect through Cognee MCP, account for its process-level identity boundary. In API Mode, the backend token is read at startup, and all traffic through that MCP process resolves to one backend user. Memory tools do not carry distinct caller identities. Where agents require different permissions, use separate MCP processes and backend-user tokens rather than treating dataset names as tenant isolation.

Promote approved memory and retrieve it within scope

Use Cognee's documented v1.0 vocabulary: remember, recall, improve, and forget. The examples use remember for approved ingestion and recall for retrieval, without mixing in the lower-level legacy workflow.

Illustrative promotion code (proposed, not executed). Run this asynchronous fragment under the authorized promotion service's authenticated context, after reviewer approval and dataset provisioning:

import cognee
from cognee.tasks.ingestion.data_item import DataItem

await cognee.remember(
    DataItem(
        data="Payments retries use exponential backoff; approved in ADR-17.",
        external_metadata={
            "source_agent": "researcher",
            "source_ref": "ADR-17",
            "status": "approved",
        },
    ),
    dataset_name="project_shared",
    node_set=["source_agent:researcher", "project:payments"],
)

The external_metadata field names are application-defined. Here, they record the originating agent, supporting reference, and review status; they do not establish authorization. The source agent remains researcher even though the promotion service performs the write, preserving the distinction between evidence origin and ingestion identity.

Before handing the approved policy to the coding agent, wait for indexing completion or inspect cognee.datasets.get_status() using the installed version's documented interface. Ingestion acknowledgment does not guarantee retrieval visibility. Recall can run during indexing, but its results include only indexed data and may be incomplete. A deterministic handoff therefore needs an indexing-completion gate.

Illustrative retrieval code (proposed, not executed). Run this asynchronous fragment as an authenticated coding agent with read permission. Supply the provisioned shared dataset UUID through shared_dataset_uuid:

import cognee

result = await cognee.recall(
    "What retry policy was approved?",
    dataset_ids=[shared_dataset_uuid],
    node_name=["source_agent:researcher"],
)

For an authorized non-owner, select the shared dataset by UUID: name-based lookup resolves against datasets owned by the caller. The explicit dataset_ids allowlist limits this task to project memory, while node_name narrows retrieval to the source-agent grouping. Omitting both dataset selectors searches across datasets the current user can read. We recommend explicit task scopes even when backend authorization permits broader access.

Best Practices for Testing Multi-Agent Memory

We recommend testing memory as an access-controlled lifecycle, not just a retrieval endpoint. The suite below is a proposed validation plan, not published benchmark results. Set acceptance thresholds against your workload and access policy; the supplied documentation does not establish universal latency or quality targets.

Validate access and memory lifecycle behavior

Use distinct authenticated identities to test both authorized cross-agent recall and denied cross-scope recall. For Cognee, verify ENABLE_BACKEND_ACCESS_CONTROL=true and REQUIRE_AUTHENTICATION=true, then validate enforcement with your selected graph and vector dataset handlers. Automatic multi-user activation depends on compatible handlers. A dataset name alone does not establish an enforced security boundary. Do not treat model-generated or customer-writable metadata as trusted security labels.

Test controlled promotion by creating memory inside a restricted agent scope, checking that another identity cannot retrieve it, and then exercising your application's explicit promotion path into shared memory. Verify the intended readers before and after promotion. Submit simultaneous contradictory facts from different agents and replay writes as retries. Inspect whether the implementation detects contradictions and duplicates; do not assume either is automatically resolved.

Preserve evidence throughout these tests. Retain the retrieved facts, source identifiers, and source content used for each answer, rather than relying on API logs alone. Zep documents episode_uuids that connect facts to source episodes, providing a concrete traceability mechanism to inspect. Include lifecycle tests for permission revocation and deletion, checking affected derived memory as well as the original record. Treat propagation behavior as something to validate in the selected implementation, not an assumed guarantee.

Measure retrieval quality and visibility lag

Make indexing handoffs deterministic in the test harness: acknowledge a write, record its identifier and acknowledgment time, and check retrieval through another authorized identity until the expected content becomes visible or the test times out. This separates write acceptance from shared visibility and makes failed handoffs reproducible. For controlled promotion, repeat the same checks at the restricted-to-shared boundary.

Measure foreground and background paths separately. LangGraph's documentation explains that foreground memory formation adds work to the response path, while background formation can leave other threads temporarily without new context. Report response latency separately from time-to-shared-retrievability; a quick acknowledgment does not demonstrate that another agent can already recall the update.

Cognee illustrates this distinction: remember without session_id runs permanent graph ingestion, whereas a write with session_id uses fast session memory and, by default, starts a background improve pass toward permanent memory. Test that handoff explicitly. A successful session-memory write does not establish immediate global indexing.

Record p50/p95 retrieval latency, acknowledgment-to-retrievability lag, contradiction detection, evidence coverage, and unauthorized retrieval count. Pair those measurements with the access, retry, promotion, revocation, and deletion cases above. The goal is to establish whether retrieval is timely, authorized, and traceable under your workload, not to reduce memory behavior to one latency number.

Benefits of Matching Memory Architecture to Access Requirements

Shared approved knowledge gives collaborating agents reusable context when they need the same project information. Explicit read/write permissions and ownership of conflicting updates make that reuse governable rather than allowing unrestricted mutation. Private working scopes serve a different requirement: keeping scratchpads and independent investigations separate until an approved handoff. Their confidentiality depends on independently enforceable identities and configured backend controls, not simply naming a namespace “private.” Reuse across isolated scopes remains a deliberate promotion decision.

Scoped composition lets organization, team, and project access requirements coexist within a common backend where documented controls permit it. In Cognee, dataset permissions and enabled backend access control provide building blocks for separately authorized scopes. That does not establish automatic policy inheritance or make every dataset part of one traversable graph. The benefit is differentiated access: agents can receive authorized shared context while retaining restricted working data, provided retrieval scopes and permissions enforce those boundaries.

Source-linked assertions, per-agent provenance, timestamps, and review status make evidence and disagreements inspectable. Preserving incompatible assertions lets an authoritative source or reviewer decide what becomes current truth; provenance alone does not prove correctness. These are architectural benefits, not measured performance results. Efficiency, scalability, and ROI require workload-specific measurement.

Key Takeaways and Next Steps for Multi-Agent Memory

Choose memory scopes around confidentiality, common context, and authority to publish knowledge. For a coding-agent team sharing project context, use shared memory with explicit write permissions. Where a research pipeline needs private working notes and reviewed findings, start with isolated scratchpads and deliberately promote knowledge into a shared scope. For company-wide agents with different access requirements, use hierarchical scopes that reflect those boundaries. Draft an access matrix identifying who can read, write, and approve shared assertions. Define a conflict policy that preserves contradictory claims with provenance and assigns a reviewer or authoritative source to resolve them.

Before expanding access, validate one small workflow. Treat identity, authorization, retrieval scope, and indexing visibility as separate decisions: a retrieval filter does not establish confidentiality. With Cognee, verify authentication and backend access control against the selected graph and vector storage handlers. Test permitted recall, denied cross-scope access, contradictory writes, indexing handoff, and permission revocation in that configuration. Use this guidance alongside the selected tool’s documentation to draft the access matrix and conflict policy, then run that workflow before widening permissions.

Related guides

• How to Build Stateful Multi-Agent Systems in Production: A 2026 Guide
• Best Shared Memory Layers for Multiple AI Agents in 2026: 8 Options Ranked
• Multi-Tenant AI Memory: Keeping Each Customer's Data Separate in Agent Memory
• AI Agent Memory Architecture: Components, Diagram and Design Choices
• Agent State vs Agent Memory: How Long-Running Agents Resume in 2026

FAQs About Multi-Agent Memory Architecture

What is a multi-agent memory layer?+

A multi-agent memory layer stores and retrieves context for agents, with rules governing who can access it. Access topology and memory duration are separate decisions: shared memory exposes common knowledge, isolated memory keeps agent contexts separate, and hierarchical or scoped memory combines common and restricted areas. Either topology can support different persistence requirements. LangGraph, for example, distinguishes thread-scoped checkpointed state from cross-session memory under custom namespaces. This guide uses those distinctions to separate access design from how long information remains available.

Why do multi-agent systems need shared or scoped memory?+

Shared or scoped memory lets agents reuse approved knowledge while keeping unfinished or private material separate. For coding teams, that means sharing repository conventions, architecture decision records, and service relationships without exposing every agent’s scratchpad or every developer’s preferences. In research pipelines, investigators can retain isolated working notes while contributing source-linked evidence to a shared project scope for reviewer approval. We recommend this composition around access requirements: share what agents are authorized to reuse, and enforce separate permissions where material must not enter another agent’s answers.

What are the best tools for shared multi-agent memory?+

Selection depends on the workload and documented mechanisms. Cognee supports graph memory with dataset permissions; Mem0 documents graph memory and user, agent, and run identifiers for context scoping. Letta offers shared, optionally read-only memory blocks, although concurrent direct modifications use last-write-wins replacement. Zep supports shared domain Context Graphs alongside user graphs. LangGraph provides checkpointed state and namespaced long-term stores as framework building blocks. We recommend comparing these mechanisms against required access boundaries, persistence, and writer coordination rather than assuming one tool fits every deployment.

Are namespaces and metadata filters sufficient for memory security?+

No. Namespaces, tags, and metadata filters can organize retrieval, but their presence alone does not establish an authorization boundary. Cognee NodeSets illustrate the distinction: entities can belong to several sets, and relationships from another source set can appear between entities in the requested set. We therefore recommend authenticated identities and enforced dataset permissions for confidentiality. With Cognee backend access control enabled, isolation operates at the user-plus-dataset level, with read, write, delete, and share permissions. Separately authorized datasets do not automatically form one traversable graph.

How should agents resolve contradictory facts in shared memory?+

Separate record collisions from semantic disagreement: two processes replacing one record is different from two agents asserting incompatible facts. Preserve each assertion’s source agent, source reference, observed time, effective time, scope, and review status. Then apply an explicit authority or reviewer policy to promote the accepted assertion to current truth. We recommend preserving this evidence rather than treating the latest write as inherently correct. As Zep’s documentation cautions, temporal bounds and provenance do not prove truth; graph structure alone cannot decide which assertion deserves authority.

Does a successful memory write mean another agent can retrieve it immediately?+

No. A successful ingestion acknowledgment does not guarantee that newly written knowledge is already available to retrieval. In Cognee, recall can run while indexing continues, but it sees only indexed data, so results can be incomplete during ingestion. For deterministic handoffs, We recommend waiting for indexing completion or checking cognee.datasets.get_status() before the next agent queries that knowledge. Treat write acceptance and retrieval readiness as separate workflow conditions. Do not promise immediate graph-wide read-after-write visibility merely because the ingestion request returned successfully.

How should MCP clients authenticate when their memory permissions differ?+

For Cognee MCP API Mode, do not assume each connected client carries a distinct backend identity. The process reads its backend token at startup, and all traffic through that process resolves to one backend user; memory tools do not carry separate caller identities. Dataset names organize that user’s memory rather than establishing tenant isolation. Our recommendation follows the documented tenant-separation approach: use separate MCP processes and backend-user tokens when separating tenants, with dataset permissions enforced for the relevant identities rather than relying on client labels.