Claude Code Highlights 04: In-Process Teammates

Digital Strategy Review | 2026

Claude Code Top 10 Highlights 04 | In-Process Teammate Runtime: Finding a Better Balance Between Performance and Isolation

By Uncle Fruit · Reading Time / 8 Min

In-Process Teammate Runtime Main Visual

Preface

As multi-agent systems move toward the collaboration layer, the biggest bottleneck is choosing the right execution model: too heavy, and you kill the user experience; too light, and you end up with chaotic boundaries. Claude Code’s approach is worth examining because it isn’t just a compromise—it’s a genuinely functional middle-ground strategy.

In-Process Teammate Runtime: Finding an Optimal Balance Between Performance and Isolation

When multi-agent systems reach the collaboration stage, they usually hit a classic dilemma:

Independent processes for every agent: Strong isolation, but high overhead and complex synchronization.
Everything in the main context: Low cost, but messy boundaries.

Claude Code’s answer: Introduce the in-process teammate.

It is neither a separate OS process nor a simple sub-call of the main agent; it is a teammate running within the same process, possessing its own identity and task state.

Key implementation files include:

src/utils/swarm/spawnInProcess.ts
src/utils/swarm/inProcessRunner.ts
src/tasks/InProcessTeammateTask/*

1. Why build an in-process teammate?

If you only use standard sub-agents, you can already achieve some level of delegation. But Claude Code aims to solve more complex problems:

Long-term collaboration between multiple agents.
Clear team identities for each participant.
Unified visibility within the UI.
Maintaining low operational costs.

If you were to use tmux panes or independent sub-processes for everything, the system would become bloated.

Claude Code chose a pragmatic compromise:

Run in the same process, but strictly isolate identities, permissions, tasks, and messages.

Comparison of collaborative execution models

Claude Code chose the third path: avoiding heavy processes without blurring the boundaries.

Some systems claim to be “lightweight multi-agent” but actually just shove multiple logic branches into a single event loop, which offers no real isolation.

Claude Code is different.

It implements specific mechanisms for the in-process teammate:

Independent AbortController
Teammate identity
Independent task state
AsyncLocalStorage / Teammate context
Independent pending user messages
Dedicated permission bridge
Mailbox collaboration with the leader

Therefore, its essence is not “multiple agents happening to be in the same process,” but rather:

Multiple agents running in the same process, each with a dedicated context and state shell.

3. What `spawnInProcessTeammate` solves

The spawnInProcess.ts layer is primarily responsible for:

01 Generating a stable identity for the teammate. 02 Creating an independent abort controller. 03 Creating the teammate context. 04 Constructing the InProcessTeammateTaskState. 05 Registering it with the AppState.

In short, it formally registers the teammate as a system object. This is crucial because it means the teammate is not just a parameter for runAgent, but a real, trackable execution entity within the system.

4. `inProcessRunner.ts` is where the teammate actually runs

The significance of this file is that it doesn’t reinvent a special agent engine; instead, it ensures the teammate ultimately returns to the standard runAgent(...) flow.

In other words:

The in-process teammate has its own shell.
The core reasoning execution remains the standard Claude Code agent loop.

This is a mature architectural trade-off:

The outer layer differentiates based on the execution model.
The inner layer reuses the execution engine as much as possible.

This prevents the issue where “standard sub-agents behave one way, while teammates behave in another strange way.”

5. Why this design is UI-friendly

Because the teammate is ultimately a task, the REPL can naturally support:

Teammate lists.
Transcript viewing.
Injecting user messages into specific teammates.
Tracking pending and running states of teammates.

If teammates were just background Promises, these experiences would be extremely difficult to implement.

Through the in-process teammate design, Claude Code incorporates “other agents in collaboration” into a unified visualization system. This is one of the reasons its UI feels more like a “collaborative workspace” than a standard terminal agent.

6. The performance advantages are tangible

1. Fast startup

No need to repeatedly spawn new processes or build excessive IPC infrastructure.

2. Shared runtime environment

Within the same process, many foundational capabilities can be shared:

Initialized runtime environment.
Partial caching.
State bridging.
Permission interaction channels.

3. Suitable for high-volume, lightweight collaboration

Some tasks only require:

Quick code searches.
Running a few read-only analyses.
Performing short, fast validations.

In these scenarios, an in-process teammate is much more cost-effective than a heavy, isolated agent.

7. Of course, it’s not a silver bullet

The boundaries of this design are clear.

1. Isolation is not as strong as independent processes / worktrees / remote

If a task is extremely heavy, long-running, or requires strict environment isolation, an in-process teammate may not be the best choice.

2. Permissions and control planes must be handled carefully

Because it shares the main process, you need a robust leader permission bridge, mailbox, and context isolation to prevent conflicts.

3. Lifecycle management must be meticulous

Interrupts, backgrounding, user message injection, and shutdown requests must be handled reliably; otherwise, it is easy to end up with hanging states.

Claude Code is successful precisely because it handles these details with such rigor, making this approach viable.

8. Understanding it at a glance

Mermaid Diagram 1

9. Conclusion

The in-process teammate runtime is a highlight not just because it “saves resources,” but because it achieves an excellent balance between:

Operational costs
Identity isolation
Unified control plane
Collaborative experience

Many systems, when reaching the multi-agent stage, are either too heavy or too chaotic. Claude Code provides a third answer with the in-process teammate:

Not every agent needs to be an independent process, but every agent must be an independent object.