Engineering · July 11, 2026 · 6 min read

Claude Agent SDK: giving your agents shared memory

The Claude Agent SDK gives you one strong agent — tools, a loop, subagents. What it doesn't give you is a way for those agents to share what they learn. Here's how to add that in a few lines.

One agent is easy. The second is where memory breaks.

The Claude Agent SDK makes a single capable agent almost trivial: define some tools, let it run its loop, spawn a subagent when the work fans out. What it deliberately doesn't decide for you is where the agents' memory lives. Each agent — each run, each subagent — starts from its own context.

That's fine until there's more than one of them. The researcher subagent uncovers "Auth flow moved to v2 — PR #42 merged"; the writer subagent, a step later, documents v1. Nothing crashed. The two agents just never shared a reality. It's the most common way multi-agent systems fail (see the MAST taxonomy), and no bigger model fixes it (here's why).

The shared-memory shape is an MCP server

You could bolt a database onto each agent and hope they converge. The cleaner seam is the one the SDK already speaks: MCP. Lore ships as a Model Context Protocol server, and the Claude Agent SDK connects to MCP servers natively through options.mcpServers. So you don't wrap Lore in glue code — you point the agent at it, and write and pack show up as tools the agent (and every subagent) can call.

Wiring it up

import { query } from "@anthropic-ai/claude-agent-sdk";

const run = query({
  prompt: "Summarize where the auth work stands, then keep building it.",
  options: {
    mcpServers: {
      lore: { type: "stdio", command: "lore", args: ["mcp", "--scope", "team:platform"] },
    },
    // read-your-writes + access control are enforced server-side
    allowedTools: ["mcp__lore__write", "mcp__lore__pack"],
  },
});

for await (const msg of run) {
  if (msg.type === "assistant") console.log(msg.message.content);
}

Two things to notice. The tools are named mcp__lore__write and mcp__lore__pack — the Claude Agent SDK's mcp__<server>__<tool> convention — and you allow-list exactly what the fleet may use. And because Lore is a real server, the guarantees don't live in the prompt: read-your-writes and per-agent access control are enforced server-side, where a stray token can't loosen them.

What every agent gets

• Read-your-writes across runs and subagents. When one agent's write returns a sequence number, the next agent's pack is guaranteed to contain it — the handoff stops depending on timing. (The whole idea, in plain terms: read-your-writes for agents.)
• Governed by construction. Agents run tools, so a compromised or over-eager agent is a real risk. Access control, provenance, and quarantine live in the server — a new or untrusted agent can't read or poison beyond its scope no matter what its prompt says.
• A smaller token bill. Instead of re-feeding the whole transcript to every agent, each one pulls a budget-fit, deterministic pack. Prompt-cache hits compound; the bill goes down as the fleet grows.

Why MCP is the right seam

Wiring memory through MCP instead of a bespoke Claude-Agent-SDK adapter buys you neutrality. The same Lore server that backs your Claude Agent SDK agents also backs your LangGraph graph, your CrewAI crew, and any MCP client like Cursor or Claude Code — one shared memory, many clients, no lock-in. No framework shares memory with a competitor's agent; a neutral layer does.

The one-line version

The Claude Agent SDK is great at building an agent. Give that agent — and every subagent and run beside it — Lore's MCP server, and they stop working in parallel universes.

Runnable reference: the Claude Agent SDK integration. The idea behind it: coordination memory and read-your-writes. Repo on GitHub.