I Launched Five Claude Code Sessions—and Built a Small Development Organization on My Laptop

Claude Code recently gained the ability to communicate across sessions.

In practical terms, you can run multiple Claude Code sessions at the same time, give each one a different role, and let them communicate with one another when necessary.

I had already been running multiple Claude Code sessions before this feature arrived. However, I was the one giving instructions to each session and carrying relevant information from one to another.

Before that, I had also experimented with orchestration tools designed to coordinate multiple AI agents.

The idea is simple: give a task to an AI acting as the coordinator, and it delegates the work to several other AIs. They consult one another and continue development on their own. In the ideal version, the human only gives the initial instruction and reviews the final output.

In practice, however, I did not find this particularly efficient.

Every time one AI passed an instruction to another, the information changed slightly, like a game of telephone. Token usage also grew quickly because multiple AIs repeatedly read and rewrote the same background information.

Eventually, I settled on a more practical arrangement:

I give instructions directly to each AI. When the AIs need to communicate, I relay the necessary prompts and information myself.

Now that Claude Code supports cross-session communication, that arrangement is beginning to evolve.

Instead of merely opening several Claude Code sessions, I am now using them to build a small development organization inside my own computer.

Here is how it works.

Launching Five Claude Code Sessions

To make the setup easier to explain, imagine a fictional video streaming service. This is not a real project I am working on.

Suppose the system consists of three parts, each managed in its own Git repository:

• Membership management
• Content management
• Billing management

I am responsible for membership management, but naturally I cannot develop it in isolation. Questions involving other systems come up constantly: “Is this content available to this user?” or “What is the current billing status of this member?”

So I launch five Claude Code sessions locally.

Membership management
├─ Development session
├─ Task management session
└─ Referee session

Content management
└─ Content management session

Billing management
└─ Billing management session

They are all Claude Code sessions, but their roles are completely different.

Separating the AI That Develops from the AI That Organizes the Work

The central role belongs to the development session.

This is a conventional Claude Code session. It writes code, runs tests, and conducts technical research.

Beside it, I keep a task management session. This session is not there to write code. It updates the work breakdown structure, organizes progress, and prepares documents for external stakeholders or the team.

I used to ask a single Claude Code session to do all of this.

Over time, however, one context would accumulate requests such as, “Think through this requirement,” “Fix this code,” “Now update the WBS,” and “Also prepare slides for the meeting.”

In human terms, it is like asking a programmer to write code while continuously interrupting them with progress tracking, meeting minutes, and PowerPoint requests.

It is simpler to separate the roles from the beginning.

Let the developer focus on development and the project manager focus on management. Since these are AIs, there is no need to make one of them wear two hats.

When a Decision Becomes Difficult, Hand It to the Referee

I also keep a referee session.

I assign the strongest model available at the time to this role—for example, a top-tier model such as Fable.

Most of the time, it does very little.

I call it only when there is a disagreement over a design decision, when the development session and another system’s session make conflicting claims, or when something is clearly wrong but nobody can identify the cause.

Then I simply tell it:

“I can no longer make sense of this. Investigate it and make the call.”

The referee contacts the relevant sessions as needed, examines their arguments and code, and reaches a decision.

Previously, I had to gather everything myself—“Membership management says this, billing management says that, and this specification says something else”—and explain the entire situation again to a single AI.

This is the one part of the setup where I actively use communication between sessions.

I only need to review the referee’s final judgment.

The Most Interesting Part Is Keeping the Other Team’s AI on My Laptop

The content management and billing management sessions are the most interesting part of this arrangement.

I launch each of them in a directory completely separate from the membership management system I am developing.

I believe this separation is extremely important.

When Claude Code runs in the same environment as my own project, it learns my CLAUDE.md, design philosophy, previous conversations, and local rules.

Because the AI is capable, it also begins to understand my intentions.

That is useful during ordinary development, but it becomes a problem when I want the AI to represent another system.

Suppose I assume that a particular API should obviously return a certain value. If the AI representing the other system already knows my assumptions, it may accommodate them and respond, “Yes, that is probably what you intended.”

That does not give me a meaningful second opinion.

Instead, I launch Claude Code in a separate folder and make the content management code and rules its primary world.

In other words, I create an AI that does not share my side’s conventional wisdom.

The sessions can still inspect one another’s source code through Git when necessary.

The result is an environment where the other session does not cater to my circumstances but can investigate my code if the situation requires it.

That feels remarkably close to working with a real team on the other side of a system boundary.

ADRs Are the Real Key

There is an important prerequisite for making this arrangement work:

Project knowledge must live in Git.

The setup breaks down when large parts of the specification exist only in people’s heads or when important documents are stored somewhere the AI cannot access.

In this project, we preserve design decisions and the reasoning behind requirements as ADRs—Architecture Decision Records—whenever possible, and manage them in Git.

The name and exact format are not what matter. What matters is placing knowledge that cannot be inferred from source code somewhere the AI can read it: why a design was chosen, which alternatives were rejected, and what a particular value means.

Once enough of this knowledge has accumulated, an AI assigned to represent another system becomes surprisingly capable.

The billing management session, for example, can read not only the billing source code but also earlier ADRs and the history of requirement changes.

When asked why an API behaves in a certain way or how a particular case should be handled, it begins to respond much like a real person responsible for the billing system.

If the knowledge base lives elsewhere and the AI cannot access it, the source code becomes almost its only clue.

The AI can inspect the implementation and determine what the system currently does. But code alone does not reveal why it was designed that way, which exceptions apply, or what decisions were made in the past.

Naturally, the accuracy of its answers declines.

Before adding more cross-session agents, put project knowledge somewhere the AI can read it. Without that foundation, adding more AIs does not make unknown information known.

Ask the Local Counterpart Before Asking the Real One

This arrangement is also useful for real-world inquiries.

Suppose I am developing membership management and need to ask the content management team about a requirement.

Previously, I would send a Slack message:

“What does this API do in this particular case?”

Now I ask my local content management session first.

It inspects the code and ADRs. If it responds, “The implementation already answers that,” or “This was previously decided and recorded in an ADR,” there is no need to interrupt the real content management team.

If it instead concludes that the code is inconclusive, the requirement conflicts with the implementation, or the case has never been defined, I then contact the external team.

In effect, the counterpart AI screens my questions before I send them.

In development work, asking another team something I could have discovered myself consumes their time and often results in a simple response: “Please read the code first.”

An AI does not become irritated, no matter how many foolish questions I ask.

So I may as well ask the patient counterpart first.

Slack for Humans, Markdown for AIs

I also separate the communication channels.

Human ⇔ Human
    Slack

AI ⇔ AI
    Markdown + Git

There is no reason to put every minor human-to-human question into Git, so we continue to use Slack for those conversations.

Information formally exchanged between AIs, however, goes into Markdown files stored in Git.

For example:

docs/integration/content-api.md
docs/integration/billing-api.md
docs/questions/content/
docs/questions/billing/

At the beginning of a project, we decide which Markdown files on which branch of which repository each session should read.

This creates a history, makes diffs available, and allows the information to be reviewed.

It also prevents important requirements from disappearing into a chat history and later becoming something that “someone supposedly mentioned last month.”

I still act as the project manager, assigning work to each session and connecting them only when necessary. For now, this modest level of coordination is easier to manage.

One Person Is Starting to Look Like an Organization

There is only one human sitting in front of the computer, yet the team now includes a developer, a task manager, representatives of other systems, and a referee.

It is beginning to feel like an organization.

Whenever another role is needed, I can simply launch one more Claude Code session.

In this example, development is handled by one development session, but I could also add a dedicated testing session.

In a human company, that would mean hiring a tester. In an AI company, it just means opening another terminal window.