Featured Agent Teams CMS Architecture Knowledge Comic Claude Code

We Built Agent Teams Before Agent Teams Existed

How CMS Multi-Session architecture solved context isolation, state persistence, and team coordination 6 months before Claude Code's official Agent Teams feature — and what that tells us about building ahead of platforms.

February 7, 2026 • 8 min read • By Claude World

Knowledge Comic Series — Maximum technical depth, minimum words.

The Problem Nobody Talks About

Every Claude Code power user hits the same wall:

Turn 1-20:   Claude is sharp, focused, remembers everything
Turn 30-50:  Starts forgetting earlier decisions
Turn 80+:    "What file were we working on again?"

This is context rot. A single context window has finite capacity. The more you do, the more you forget.

Sub-agents (the Task tool) help — but they share the main context. The results flow back, filling the window even faster.

The real question: How do you run 50+ development iterations without losing your mind — or your context?

The CMS Answer (January 2026)

We built CMS (Claude Multi-Session) — a multi-session orchestrator that isolates each development iteration in its own process.

┌─────────────────────────────────────────────┐
│              CMS Orchestrator                │
│                                              │
│   Iteration 1    Iteration 2    Iteration 3  │
│   ┌─────────┐   ┌─────────┐   ┌─────────┐  │
│   │ Fresh    │   │ Fresh    │   │ Fresh    │  │
│   │ Context  │   │ Context  │   │ Context  │  │
│   │ Window   │   │ Context  │   │ Context  │  │
│   └────┬─────┘   └────┬────┘   └────┬─────┘  │
│        │              │              │         │
│        └──────┬───────┴──────┬───────┘         │
│               ▼              ▼                  │
│         checkpoint.json  (shared state)         │
└─────────────────────────────────────────────────┘

Each iteration:

  1. Spawns a fresh Claude Code process — full context window, zero baggage
  2. Reads checkpoint.json — picks up where the last iteration left off
  3. Does its work — implement, test, fix
  4. Writes checkpoint.json — saves progress for the next iteration
  5. Dies — process exits, context freed

The orchestrator loops. 50 iterations? 100? No context rot. Ever.

Then Agent Teams Dropped (February 2026)

Opus 4.6 shipped with Agent Teams — Claude Code’s official multi-agent coordination system.

We looked at the feature list and had a strange feeling of déjà vu:

  • Shared Task List → we had checkpoint.json
  • Cross-agent messaging → we had checkpoint state passing
  • Independent context windows → we had CMS per-iteration processes
  • Team Lead coordination → we had the 6-phase orchestration loop

The Mapping

┌─────────────────────┬──────────────────────────────────┐
│  Agent Teams (v2.1)  │         CMS (Jan 2026)           │
├─────────────────────┼──────────────────────────────────┤
│  TeamCreate          │  cms-iterate spawn               │
├─────────────────────┼──────────────────────────────────┤
│  TaskList / TaskGet  │  checkpoint.json                 │
├─────────────────────┼──────────────────────────────────┤
│  SendMessage         │  checkpoint state passing        │
├─────────────────────┼──────────────────────────────────┤
│  Teammate (process)  │  CMS iteration (process)         │
├─────────────────────┼──────────────────────────────────┤
│  Team Lead           │  self-upgrade 6-phase loop       │
├─────────────────────┼──────────────────────────────────┤
│  Shutdown protocol   │  iteration exit + checkpoint     │
├─────────────────────┼──────────────────────────────────┤
│  Idle notification   │  iteration completion signal     │
└─────────────────────┴──────────────────────────────────┘

Same problems. Same solutions. Different names.

Where CMS Still Wins

Agent Teams is elegant. But CMS has battle-tested advantages the official system hasn’t caught up to yet.

0. The Fundamental Difference: Who Owns the Loop?

This is the single most important architectural distinction:

Agent Teams:
  ┌──────────────────────────────┐
  │     Lead (MAIN context)      │  ← Lead lives in your terminal session
  │                              │
  │  spawn teammate A ──→ [A]    │  ← Teammates get fresh contexts
  │  spawn teammate B ──→ [B]    │
  │  wait for results            │  ← Lead's context fills up
  │  synthesize                  │
  │  spawn teammate C ──→ [C]    │
  │  ...                         │  ← After 50 iterations, Lead is bloated
  └──────────────────────────────┘

CMS:
  ┌──────────────────────────────┐
  │     CMS Orchestrator         │  ← Thin shell script, not an LLM
  │                              │
  │  spawn iteration 1 ──→ [I1]  │  ← Fresh context, does everything
  │  checkpoint.json ←── [I1]    │  ← State externalized, I1 dies
  │  spawn iteration 2 ──→ [I2]  │  ← Fresh context, reads checkpoint
  │  checkpoint.json ←── [I2]    │  ← I2 dies
  │  ...                         │  ← After 50 iterations, still fresh
  └──────────────────────────────┘

Agent Teams isolates the teammates, but not the Lead.

The Lead accumulates every spawn result, every message, every task update. After 50 iterations, the Lead’s context is as bloated as a single-session workflow.

CMS isolates everything — including the iteration loop itself.

The orchestrator is a shell script, not an LLM. It doesn’t consume tokens. It doesn’t forget. It doesn’t rot. Each iteration is a fully independent Claude Code process that reads a JSON file, does its job, and dies.

This is the difference between “parallel agents with a shared boss” and “serial processes with a shared disk.”

1. Parallel Without Sharing a Brain

When tasks have no dependencies, CMS doesn’t wait:

CMS (parallel mode):
  ┌──────────────────────────────────┐
  │       CMS Orchestrator           │
  │                                  │
  │  Task A (no deps) ──→ [Process 1]│  ← Independent process
  │  Task B (no deps) ──→ [Process 2]│  ← Independent process
  │  Task C (no deps) ──→ [Process 3]│  ← Independent process
  │                                  │
  │  Wait for all ←─── checkpoint    │
  │                                  │
  │  Task D (deps: A,B) ──→ [Proc 4] │  ← Runs after A & B complete
  └──────────────────────────────────┘

Agent Teams (parallel):
  ┌──────────────────────────────────┐
  │       Lead (main context)        │
  │                                  │
  │  spawn A ──→ [Teammate A]        │
  │  spawn B ──→ [Teammate B]        │  ← All parallel, great
  │  spawn C ──→ [Teammate C]        │
  │                                  │
  │  receive result A ← fills Lead   │
  │  receive result B ← fills Lead   │  ← Lead accumulates everything
  │  receive result C ← fills Lead   │
  └──────────────────────────────────┘

Both execute tasks in parallel. But CMS’s orchestrator doesn’t consume context doing it. Agent Teams’ Lead does.

CMS gets parallelism AND context isolation. Agent Teams makes you choose.

2. Cross-Restart Recovery

CMS:
  Process crashes → checkpoint.json survives on disk
  Run `--resume` → picks up exactly where it left off

Agent Teams:
  Leader closes terminal → all teammates die (Death #4)
  Mailbox messages → orphan files
  Recovery → start over

CMS checkpoints are persistent by design. Agent Teams’ in-memory state is ephemeral by default.

3. Unbounded Iterations

CMS:
  Each iteration = new process = fresh 200k context
  50 iterations? 200k × 50 = 10M tokens of cumulative capacity
  Zero degradation at iteration 50

Agent Teams:
  Each teammate = one process = one context window
  Long-running teammate = same context rot problem
  Max turns limit = forced stop

CMS doesn’t fight context limits. It sidesteps them entirely.

4. Self-Evolving Loop

CMS + Self-Evolving:
  Iteration fails → extract learning → evolve skills → retry with better tools
  Each failure makes the next iteration smarter

Agent Teams:
  Teammate fails → Lead retries or spawns replacement
  No built-in learning mechanism between failures

CMS integrates a learning loop. Agent Teams provides coordination, not evolution.

Where Agent Teams Wins

1. Real-Time Peer Communication

Agent Teams:
  frontend-dev → SendMessage → backend-dev
  "Is your API schema ready?"
  Real-time, any-to-any, while both are running

CMS:
  Iteration 5 writes checkpoint
  Iteration 6 reads checkpoint
  Sequential only. No concurrent dialogue.

Agent Teams supports parallel conversation. CMS is inherently sequential.

2. Native Integration

Agent Teams:
  Built into Claude Code runtime
  Shift+Up/Down to select teammate
  Ctrl+T to view task list
  Zero configuration

CMS:
  Custom skill + checkpoint format + orchestration logic
  Requires setup and understanding
  Breaks if Claude Code internals change

Agent Teams is first-class. CMS is a userland hack (an impressive one, but still).

3. Topology Flexibility

Agent Teams:
  Star, Mesh, or hybrid topology
  Any teammate can message any other
  Lead can delegate and go hands-off

CMS:
  Strictly sequential pipeline
  No lateral communication between iterations
  Orchestrator is always in control

The Migration Path

When Agent Teams stabilizes, CMS concepts map directly:

# CMS checkpoint.json → Agent Teams TaskList
checkpoint = read_checkpoint()
for task in checkpoint["remaining_tasks"]:
    TaskCreate(subject=task["name"], description=task["spec"])

# CMS iteration spawn → Agent Teams teammate
# Before:
spawn_cms_iteration(task, checkpoint)
# After:
Task(subagent_type="general-purpose", team_name="dev-team", prompt=task)

# CMS state passing → Agent Teams messaging
# Before:
write_checkpoint({"api_schema": schema, "status": "ready"})
# After:
SendMessage(recipient="frontend-dev", content=f"API schema ready: {schema}")

# CMS resume → Agent Teams task list recovery
# Before:
cms_iterate --resume
# After:
TaskList()  # find pending tasks, reassign

The business logic stays. The transport changes.

The Deeper Lesson

This isn’t just a “we were first” story. It’s a pattern recognition lesson.

When you solve a real problem with first principles, you often converge on the same architecture that platform vendors eventually ship.

CMS didn’t copy Agent Teams. Agent Teams didn’t copy CMS. Both independently arrived at:

  1. Context isolation — separate windows for separate work
  2. Shared state — a coordination layer outside any single context
  3. Lifecycle management — spawn, work, report, die
  4. Orchestration — something needs to decide what happens next

These aren’t implementation choices. They’re architectural inevitabilities for multi-agent systems.

What To Build Next

If the pattern holds, here’s what Agent Teams will need eventually — and what you can build now:

Missing TodayWhy It’s NeededBuild It Now
Heartbeat protocolDetect silent deaths (Rate Limit Kill)Checkpoint timestamp + timeout detection
Delivery confirmationKnow if message was actually readAck field in checkpoint state
Cross-restart recoveryResume after crashAlready in CMS — --resume
Learning between failuresGet smarter, not just retryAlready in CMS — Self-Evolving Loop
Cost tracking per teammateBudget managementToken counting per iteration

Build the userland solution today. Replace with the native API tomorrow.

That’s how you stay 6 months ahead.

Further Reading