How to Share Memory and State Between Claude Code Agent Sessions?

Mar 20, 2026

Problem

I was running multiple Claude Code sessions to process a large batch of blog posts. One session planned the content, another wrote drafts, and a third reviewed them. But each session started fresh with no memory of what the previous sessions had done.

I thought I needed a database. Or maybe a shared memory system. Something to persist state between sessions so agents could coordinate. I started designing a PostgreSQL schema for tracking session state.

Then I found out I was overengineering the whole thing.

What Happened?

I discovered a Reddit thread by DevMoses titled “From Zero to Fleet: The Claude Code Progression Ladder.” In it, someone asked the same question I had:

"I never thought that level five would be possible without a persistent memory system between agents in a fleet but thanks for proving me wrong."

The response surprised me. You do not need a persistent memory system. State is shared through files:

"I use opus to draft specs and then pick them up with Sonnet or Codex, and each session starts with 'get up to speed' and ends with 'log this' (prompting them to read memory and later write to memory)."

The answer was simple: each session reads files at startup and writes files at completion. No database needed. No complex state management. Just predictable file locations.

The Solution

I learned to use file-based protocols for sharing state between sessions. Here is how it works.

Pattern 1: Session Boundary Protocol

Every session follows the same structure:

Session Start -> "Get up to speed" -> Read existing files
Execute       -> Perform assigned task
Session End   -> "Log this"        -> Write output files

At the start of each session, I tell Claude: “Get up to speed by reading the plan files.” Claude reads the relevant files and understands the context.

At the end of each session, I tell Claude: “Log this to the review directory.” Claude writes the output file.

This creates a chain of sessions that can pick up where the previous one left off:

Get up to speed:
1. Read plan/task-001.md to understand the current task
2. Read review/completed.md to see what is already done
3. Read urls_todo.md to find pending work

Log this:
1. Write your findings to review/findings-001.md
2. Update urls_done.md with completed items
3. Update urls_todo.md to remove finished items

Pattern 2: Directory-Based State

State lives in predictable file locations. I created a simple directory structure:

project/
├── plan/
│   ├── task-001.md      # Task definition
│   ├── task-002.md      # Next task
│   └── ...
├── review/
│   ├── draft-001.mdx    # Completed drafts
│   ├── draft-002.mdx
│   └── ...
├── urls_todo.md         # Pending work queue
└── urls_done.md         # Completed work history

Each file has a specific purpose:

# Pending URLs
- https://example.com/article-1
- https://example.com/article-2
- https://example.com/article-3

# Completed URLs
- https://example.com/article-0 (completed 2026-03-19)

When a session starts, it reads urls_todo.md to find work. When it finishes, it moves the URL from urls_todo.md to urls_done.md.

Pattern 3: Discovery Relay for Multi-Wave Orchestration

For more complex workflows, I use a discovery relay pattern. Multiple “waves” of agents pass information through files:

Wave 1: Discovery agents
  -> Read urls_todo.md
  -> Write findings to discovery/wave-1/

Wave 2: Execution agents
  -> Read discovery/wave-1/
  -> Execute with that context
  -> Write findings to discovery/wave-2/

Wave 3: Review agents
  -> Read discovery/wave-1/ and discovery/wave-2/
  -> Review and finalize
  -> Write to review/

Each wave reads the outputs of previous waves. This creates a pipeline without any shared memory system.

The Reddit thread showed this at scale:

198 agents, 109 waves, 27 documented postmortems.
This is where one developer operates at institutional scale.

Pattern 4: Institutional Memory via Postmortems

The thread mentioned “27 documented postmortems.” These serve as institutional memory. When something goes wrong, I write a postmortem:

# Postmortem: Failed API Integration

**Date**: 2026-03-15
**Issue**: Claude tried to use deprecated API endpoint

## What Went Wrong
The API documentation was outdated. Claude used an endpoint that no longer exists.

## How It Was Fixed
Added a note to project CLAUDE.md about the correct endpoint.

## Prevention
Always verify API endpoints against current documentation before implementing.

New sessions read these postmortems to avoid repeating mistakes. This is how one developer operates at “institutional scale.”

Common Mistakes

I made several mistakes before understanding this approach.

Mistake 1: Over-Engineering Memory Systems

I started designing a PostgreSQL database with tables for sessions, states, and transitions. This was unnecessary:

session_states table
├── session_id (PK)
├── agent_type
├── current_state
├── context_json
└── created_at

+ REST API to query/update state
+ Redis cache for performance

plan/task-001.md     # Current task
review/draft-001.mdx # Output
urls_todo.md         # Queue

Files are simpler. Files are readable by humans. Files work without any infrastructure.

Mistake 2: Inconsistent File Locations

At first, I put files in random locations:

/tmp/plan-abc123.md
~/Downloads/task-001.md
./output/review-xyz.mdx

Claude could not find them reliably. Now I use consistent paths:

project/
├── plan/      # All plans here
├── review/    # All outputs here
└── *.md       # State files at root

Mistake 3: Missing Session Boundaries

Sometimes I forgot to include “get up to speed” at the start or “log this” at the end. The session would start without context or end without saving.

I added this to my project’s CLAUDE.md:

## Session Protocol
At session start:
- Read plan/*.md to get current task
- Read urls_todo.md to find pending work

At session end:
- Write output to review/
- Update urls_done.md
- Update urls_todo.md

Mistake 4: Ignoring Failure Logs

When a session failed, I would just restart it. But I was not capturing what went wrong. Now I always create a postmortem for failures:

# Postmortem: [Issue Title]

**Date**: YYYY-MM-DD
**Session ID**: [if applicable]

## What Went Wrong
[Description of the issue]

## How It Was Fixed
[Steps taken to resolve]

## Prevention
[How to avoid this in the future]

How I Applied This

I restructured my workflow to use file-based protocols:

For Single Session Work:

1. Create plan/task.md with the goal
2. Start session: "Get up to speed by reading plan/task.md"
3. Do the work
4. End session: "Log this to review/output.mdx"

For Multi-Session Pipeline:

Session 1 (Planner):
  -> Start: Read urls_todo.md
  -> Execute: Create plans for each URL
  -> End: Write to plan/

Session 2 (Writer):
  -> Start: Read plan/*.md
  -> Execute: Write drafts
  -> End: Write to review/

Session 3 (Reviewer):
  -> Start: Read review/*.mdx
  -> Execute: Review and edit
  -> End: Write final versions

Each session is independent. Each session reads and writes files. No coordination needed beyond the files themselves.

Summary

In this post, I explained how to share memory and state between Claude Code agent sessions without building a complex memory system.

Key points:

Use file-based protocols: read at session start, write at session end
Keep state in predictable file locations
Use discovery relay for multi-wave orchestration
Document failures in postmortems for institutional memory

Start here:

Create a plan/ directory for task definitions
Create a review/ directory for outputs
Add session boundary prompts to your CLAUDE.md
Run your first multi-session workflow

The Reddit thread showed 198 agents across 109 waves. All coordinated through files. No database. No memory system. Just simple read/write protocols.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

👨‍💻 Reddit: From Zero to Fleet - The Claude Code Progression Ladder
👨‍💻 Claude Code Documentation

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!