Running a fleet of long-lived AI agents: independent memory, and surviving a reboot

A year ago the normal way to use an AI coding agent was one terminal, one conversation, one task. That’s no longer where the leverage is. People now run several at once: one agent refactoring auth in a git worktree, a second triaging the issue tracker, a background job summarizing yesterday’s session logs, a scheduled agent that opens a PR every morning. The shift from one chat to a fleet is the single biggest change in how the tool is used in 2026.

And the moment you cross from one agent to several, two failure modes appear that nobody warns you about:

1. Their memory bleeds together. Every session in a project reads the same CLAUDE.md and the same rules. That’s exactly what you want for shared standards — and exactly wrong when each agent is supposed to be a specialist with its own accumulated knowledge.
2. A reboot wipes the lot. You’ve got six agents mid-task, you restart the machine, and you’re staring at six empty terminals with no idea which conversation was which.

Both are solvable, and you don’t need a framework to solve them. The primitives ship with Claude Code today. This is a field guide to wiring them together: give every agent its own memory, and make the fleet survive a reboot.

Part 1 — Give every agent its own memory

The default memory model is shared by design. Every session you start in a project loads the same memory hierarchy: ~/.claude/CLAUDE.md (your personal rules), the project’s CLAUDE.md, CLAUDE.local.md, and any managed policy files. That’s correct for standards — the test command, the lint rule, the thing Claude is never allowed to ship. You want every agent to read those, every turn.

It’s wrong for specialization. If your code-reviewer agent has learned, over fifty PRs, that this codebase always forgets to null-check the webhook payload — that’s not a standard for everyone, it’s that agent’s accumulated knowledge. Dumping it into the shared CLAUDE.md taxes every other agent’s context window with a note they’ll never use. (On why that tax is real, see how big your CLAUDE.md can get before it hurts performance.)

Claude Code gives you three layers to keep these separate.

Subagents run in their own context window. A subagent — defined as a markdown file under .claude/agents/ (project) or ~/.claude/agents/ (all your projects) — works in a context window separate from the main conversation, with its own system prompt, its own tool allowlist, and its own permissions. The whole point is isolation: a subagent does its work and returns only a summary, so its search results and dead ends never pollute the coordinator’s context. Subagents do not share memory with the coordinator or with each other. That isolation is the feature.

The memory: field gives an agent a persistent directory that survives across conversations. This is the part most people miss. Add one frontmatter line to a subagent definition and it gets a folder it can accumulate knowledge into — codebase patterns, recurring bugs, architectural decisions — that persists from one session to the next. The scope picks where the folder lives:

memory: scope	Directory	Use when
user	~/.claude/agent-memory/<agent-name>/	the agent should remember across all your projects
project	.claude/agent-memory/<agent-name>/	the knowledge is project-specific and shareable (check it into git)
local	.claude/agent-memory-local/<agent-name>/	project-specific but private (do not commit)

When memory is enabled, Claude Code automatically injects the first 200 lines (or 25 KB, whichever comes first) of that folder’s MEMORY.md into the agent’s system prompt, and turns on Read/Write/Edit so the agent can curate its own notes. So a reviewer agent reads its hard-won list of this-codebase gotchas at the start of every run — without any of it touching the shared CLAUDE.md that the other nine agents pay for.

The boundary that actually matters. The single most common mistake in a multi-agent setup is putting the wrong thing in the wrong layer:

• Shared standards → CLAUDE.md. Loaded by everyone, every turn. Keep it tight.
• One agent’s accumulated knowledge → its memory: directory. Loaded only by that agent.

Get that split right and each agent stays a specialist without inflating everyone else’s token bill. Get it wrong — specialist knowledge leaking up into the shared file — and you’ve recreated the exact bloat problem that breaks CLAUDE.md in teams of five or more, except now it’s agents instead of people.

For sustained parallelism beyond a single session, two newer primitives extend the same model: background agents let you run many independent sessions at once and monitor them from one place, and agent teams (still behind CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1) give each worker its own independent context and let them message each other. Both inherit the same rule — isolated context per worker, shared standards from CLAUDE.md.

Part 2 — Make the fleet survive a reboot

Here’s the good news the panic hides: a reboot does not delete your sessions. Claude Code saves every conversation continuously to a local transcript on disk, as JSONL, at:

~/.claude/projects/<project>/<session-id>.jsonl

Every line is one message, tool call, or metadata entry. There’s a global index at ~/.claude/history.jsonl too. So after a restart the full state is right there — the problem is purely that nothing relaunches it. The fix is three habits.

1. Name your sessions. An unnamed session is findable only by digging through a picker. A named one is addressable. Name it at startup with claude -n auth-refactor, or rename a running one with /rename auth-refactor. (Accepting a plan in plan mode auto-names the session from the plan, which is a free way to get names you didn’t have to think about.)

2. Know the resume verbs. After a reboot you bring sessions back with:

Command	What it resumes
claude --continue (-c)	the most recent session in the current directory — zero IDs to remember
claude --resume <name>	a specific named session, even across worktrees
claude --resume <session-id>	any session by ID — including headless claude -p sessions that don’t show in the picker
claude --from-pr <number>	the session that created a given pull request

One gotcha worth internalizing: in non-interactive mode, --continue may spin up a new session instead of resuming. For anything scripted, resume by explicit name or session ID, never by -c.

3. Wire a supervisor to relaunch on boot. This is the layer the docs hand you the pieces for but don’t assemble — because it’s your OS’s job, not the agent’s. Two shapes, depending on whether the agent is interactive or unattended:

• Interactive sessions you babysit: put each claude --resume <name> in a tmux (or screen) window, and have a login script recreate the tmux session on boot. After a restart you tmux attach and every agent is exactly where it was. This is the lowest-ceremony option and the one most people should start with.
• Unattended, long-running agents: run them headless (claude -p "<instruction>" --resume <session-id>) under a process supervisor — launchd on macOS (a LaunchAgent plist with RunAtLoad + KeepAlive), systemd on Linux (a user service with Restart=always). The supervisor relaunches the agent on boot and restarts it if it dies.

Two cautions before you automate anything unattended:

• An agent running with no human at the keyboard needs --dangerously-skip-permissions to avoid blocking on every prompt — which is exactly as dangerous as the name says. Only point it at a sandboxed checkout, scoped credentials, and a repo where the blast radius of a bad command is bounded. Never run a reboot-persistent unattended agent against production credentials.
• Transcripts are auto-deleted after 30 days by default (cleanupPeriodDays). For a long-lived fleet, raise that, or your “resumable” sessions silently expire. And don’t reach for --no-session-persistence here — that flag exists to suppress the very transcripts your reboot recovery depends on.

Part 3 — See what the fleet is actually remembering

Once you’re running, say, eight agents, each with its own agent-memory/<name>/MEMORY.md and its own JSONL transcript stream, a new problem shows up that has nothing to do with reboots: you lose the plot. Which agent learned what? Is your reviewer’s memory file 40 KB of stale notes silently truncated at the 25 KB injection limit? Did yesterday’s background agent actually write anything useful to disk, or just burn tokens? You can’t manage a fleet’s memory you can’t see.

This is the exact problem we built AI Memory Reader to solve (disclosure: we make this). It’s a free, open-source macOS app that auto-discovers every memory and transcript directory your agents write to — CLAUDE.md files, the agent-memory/ folders, the JSONL session logs under ~/.claude/projects/ — and lets you read them in one place, with live file-watching so you see an agent’s memory update as it works. When you’re running a fleet, “what does each agent actually know right now” stops being a question you have to grep for.

The minimal fleet, on an index card

You don’t need any of this to be elaborate. The whole setup fits in a few lines:

1. Shared standards live in CLAUDE.md. Tight. Loaded by every agent, every turn.
2. Each specialist is a subagent under .claude/agents/ with a memory: scope, so its accumulated knowledge stays in its own folder.
3. Name every long-lived session (-n / /rename) so it’s addressable after a restart.
4. Resume on boot — tmux + claude --resume <name> for interactive, launchd/systemd + headless --resume <id> for unattended.
5. Raise cleanupPeriodDays so a long-lived fleet’s transcripts don’t expire under you.
6. Watch what they remember so the memory doesn’t rot unseen.

Companion reading

• How big can your CLAUDE.md get before it hurts performance — why leaking specialist knowledge into the shared file taxes every agent.
• The CLAUDE.md problem in teams of 5+ — the same shared-vs-private failure, one layer up.
• What AI coding agents actually write to your disk — the full map of the directories a fleet leaves behind.

Sources: Manage sessions and Create custom subagents, Claude Code documentation (resume flags, JSONL transcript path, the memory: field and its three scope directories, MEMORY.md injection limit, 30-day cleanup); background agents and agent teams per the same docs. Verified June 2026.