Shared memory for Claude Code subagents and agent teams

Last updated October 30, 2026

Claude Code subagents and agent-team teammates each run in their own context window, so what one learns doesn't reach the others unless it is written down somewhere they all read. To give them a shared memory, connect Memlo once with --scope project or --scope user, keep the work's notes in one shared space, use log_experience as a handoff log, and change notes with edit_memory, which refuses a write that would overwrite someone else's change. This makes collisions visible and recoverable. It doesn't divide the work for you.

What Anthropic's documentation says

These limits come from Claude Code's own documentation, read on October 30, 2026:

• Subagents: "Each subagent runs in its own context window with a custom system prompt, specific tool access, and independent permissions." The main conversation's auto memory isn't loaded into a subagent. A subagent can have a memory directory of its own, which persists across conversations, but it belongs to that subagent.
• Agent teams: "Agent teams are experimental and disabled by default." You turn them on with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. "Each teammate has its own context window," and "The lead's conversation history does not carry over."
• Shared files: "Two teammates editing the same file leads to overwrites. Break the work so each teammate owns a different set of files."

Anthropic's write-up of its own multi-agent research system describes the same problem: early versions had subagents that "performed the exact same searches as other agents."

Why one shared memory helps

Parallel agents lose work in three ways:

• They repeat each other. Two agents look up the same thing, or one makes a mistake another already fixed.
• Handoffs get lost. The lead's history doesn't carry over, so a teammate starts without knowing what was decided.
• Writes collide. Two agents change the same note, and one change silently replaces the other.

A memory server that every agent reads and writes addresses the first two, if agents search it before they act and write to it when they learn something. The third needs writes that check what they are replacing.

The pattern

1. Connect one memory for the whole team

Subagents inherit the MCP tools of the main conversation, unless their tools list leaves them out. Each teammate loads the project's MCP servers, like a regular session. So add Memlo once, for the project, and every session in the repository has it. Each person signs in with their own account:

claude mcp add --transport http --scope project memlo https://memlo.ai/mcp

That writes a .mcp.json file to commit. Use --scope user instead to have Memlo in every project on your computer.

2. Use one shared space

Keep the work's notes in one space, so every agent searches the same place. Make a space for the project in the Memlo app, or use your personal space when you work alone. To include teammates, share the space with them by email as Editors, or with a team. Each agent then passes space with the space's name on every tool call. list_spaces shows the names.

Put the space's rules in its prime_memory (its start-here page), so get_prime_directive hands them to every agent at the start.

3. Log handoffs with log_experience

log_experience writes a work-diary entry: a subject, what was done, and optionally the context, the outcome, a project and a status (pending, in progress, completed or blocked). list_experiences reads entries back, newest first, and can filter by project. It reads every space you can read, so teammates' entries show up too.

Have every agent log when it starts and finishes a piece of work, with the same project, and put its own name at the start of the subject:

log_experience(
  subject="tests-agent: payments webhook tests",
  action="Wrote tests for retry backoff; two fail on the 3rd retry",
  outcome="Bug is in retry_delay(); left a note in memory payments_retry_backoff",
  project="payments-retries",
  status="blocked",
  space="payments-team"
)

The next agent calls list_experiences(project="payments-retries") before it starts, and sees what is done, what is blocked and where the notes are.

list_experiences also has an agent filter, but entries written through the MCP server today aren't labeled with the app that wrote them, so the filter can't tell your agents apart yet. Put the agent's name in the subject, as above.

4. Edit notes so a stale write is refused

Have agents change notes with edit_memory, which replaces exact text. It reads the note's current version first and writes only over that version. If another agent changed the note in between, Memlo refuses the write with a 409 conflict, nothing is written, and the reply tells the agent to read the note again and retry. The agent then reads the new version, reapplies its change on top, and tries again.

update_memory replaces a note's whole text and doesn't make that check, so keep it for notes only one agent writes.

To save something new, use smart_add_memory. It checks for notes that already say the same thing and lists them, so an agent can merge into an existing note instead of adding a second one.

5. Check who changed what

Every write is a new version, and versions are never rewritten. memory_history lists a note's versions, with when each was written and by whom: the person, and the connected app or agent they used. memory_history with diff_against shows what changed, and restore_memory brings back an earlier version, as a new version, so a restore can be undone too.

A prompt for the lead

Paste this when you start a team or hand work to subagents:

We are working in the memlo space "payments-team", project "payments-retries".
Tell every teammate or subagent you start to do the same:
1. Before starting, call list_experiences(project="payments-retries") and search_memories in that space for the files and topics you will touch.
2. When you start and when you finish, call log_experience with that project, your role name at the start of the subject, and the status.
3. Save what you learn with smart_add_memory. Change an existing note only with edit_memory. If edit_memory reports that the note changed, read it again, reapply your change and retry.
4. Give each teammate a different set of files to change.

What this does not do

• It doesn't split the work. There is no claim or lease tool: nothing stops two agents from starting the same task. The handoff log shows that they did. Splitting the work is still the lead's job.
• It doesn't merge code. Conflict checks cover notes in Memlo, not files in your repository. Anthropic's advice to give each teammate different files still applies.
• It doesn't capture by itself. Agents save and log only when told to, so put the rules in the lead's prompt and the space's prime_memory.

Frequently asked questions

Do Claude Code subagents share memory?

Not by default. Each subagent runs in its own context window, and the main conversation's auto memory isn't loaded into it. A subagent can have its own persistent memory directory. To share notes between subagents, connect them to the same memory server and space.

Do agent-team teammates share context?

No. Each teammate has its own context window, and the lead's conversation history doesn't carry over. Teammates can message each other, but anything they need later has to be written down.

What happens when two agents edit the same memory?

With edit_memory, the second write is refused with a 409 conflict and nothing is written. The agent reads the note again and retries. Every version is kept, so you can see both changes in memory_history.

Does this work with Codex or other agents in the same team?

Yes. Any agent connected to Memlo with the same account, or with access to the shared space, reads and writes the same notes, including Codex and ChatGPT.

Sources

Checked on October 30, 2026:

• Create custom subagents, Claude Code docs
• Orchestrate teams of Claude Code sessions, Claude Code docs
• How we built our multi-agent research system, Anthropic
• Memlo: the setup page and its list of tools