Multi-Account Agent
── When Multiple Claudes Share One Memory

1. The Wrong Question About Memory

Claude doesn't retain memory across sessions. This is well-known, often called a limitation. End a conversation, and the context disappears. Start a new session, and you're explaining everything again from scratch.

But calling this a limitation misframes the problem. The frustration comes from trying to store memory inside Claude. The real question is: where should memory live?

GitHub doesn't forget. A repository written to today will be there tomorrow, next year, a decade from now. If Claude reads that repository at the start of each session, memory is restored. Not stored inside Claude — stored outside Claude, in infrastructure that outlasts any conversation. This shift in location is what makes the architecture work.

2. What Multiple Accounts Actually Means

Claude.ai supports multiple accounts. One for personal use, one for business, one for a specific project — that's the conventional framing. But under that model, more accounts means more fragmentation. Account A doesn't know what Account B discussed.

Point all accounts at the same tr/ repository, and the dynamic reverses entirely.

Account A (morning briefing) → reads tr/ → decides → writes to tr/
Account B (essay writing) → reads tr/ → writes → pushes to tr/
Account C (project management) → reads tr/ → updates → writes to tr/

Each account has its own session, its own conversation history. But every one of them begins from the same memory and commits back to the same memory. That's not fragmentation — it's a division of labor with a shared brain.

3. Specialization Without Isolation

Organizations don't expect one person to do everything. They create roles: engineering, operations, communications. Each role has domain expertise. The organization functions because roles coordinate around shared context.

Multi-account agents follow the same logic. Each Claude account gets a system prompt that defines its specialty — not general instructions, but deep, role-specific guidance. The essay account's system prompt embeds the full essay skill definition from tr/skills/essay/SKILL.md. The project account knows GitHub Project structure intimately. The briefing account defaults to the morning-briefing skill on every startup.

Different characters, same memory. A team that thinks as one.

4. Memory Architecture Is Agent Architecture

The shared tr/memory/ directory isn't just a folder — it's the connective tissue of the entire system. Its structure determines how well the agents coordinate:

tr/memory/context/claude-flow.md — the design philosophy and system history
tr/memory/daily/YYYY-MM-DD.md — today's work log and next actions
tr/project/cache/project.json — latest task cache from GitHub Projects
tr/skills/ — skill definitions each account references

Every account reads these at startup. It's not optional — the agent constitution (CLAUDE.md) mandates it as the first step of every session. Reading memory is the ritual that makes each Claude the same agent. Writing to memory at session end is what keeps continuity alive for whoever — or whatever — starts next.

5. The Cost of a New Body Is Near Zero

The most striking property of this architecture is how cheaply it scales. To create a new agent: make a new account, give it the PAT for the tr/ repository, write a system prompt defining its role. That's it. A new body with the same brain.

Scale the count to ten accounts, and you have ten specialists who share every insight written into tr/. What one agent learned yesterday, another can act on today. The knowledge compounds. The coordination is automatic.

The same principle extends to teams. Multiple people sharing a single tr/ repository creates a shared agent that knows everyone's context — and can serve each person with role-appropriate expertise. Not a chatbot, not a tool. Infrastructure.