Why We Rarely Discuss New Graph, Loop, and Harness Engines

Over the past few months, graph engines, loop engines, harnesses, Agent Teams, and nested subagents have become popular topics.

People may wonder why we rarely discuss or share these mechanisms.

The answer is simple: most of them extend the product’s inner loop. CMS already owns the outer loop.

That does not make the inner loop unimportant. Claude Code, Codex, and Grok are products, so they should keep making agents better at reasoning, using tools, and delegating across more layers of subagents. But once you own the outer loop, a new graph, loop, or harness is no longer a capability unlock. It is a component you can evaluate, adopt, or replace.

Products Should Make the Inner Loop Work

The basic inner loop of a coding agent looks like this:

prompt
  -> model judgment
  -> tool call
  -> observation
  -> next judgment

Claude Code, Codex, and Grok continue to add better context management, subagents, teams, graphs, hooks, background tasks, and resume flows inside this loop.

That is exactly what products should do. Not every user is familiar with supervisors, state machines, checkpoints, or failure domains. Products need to absorb that complexity so engineers can complete work reliably without first designing an execution system.

At the architecture level, there is another option: Claude Code, Codex, or Grok does not have to own the entire task lifecycle. It can simply be a worker.

Move Task Ownership Into the Outer Loop

Once you understand processes, state, retries, idempotency, locks, and recovery, you can place the product’s inner loop inside an outer loop of your own:

load durable state
  -> choose an inner-loop worker
  -> start an isolated process
  -> validate the actual result
  -> write a checkpoint
  -> retry, switch CLI, stop, or continue

At that point, a model session no longer owns the workflow. The external control plane does.

Models can change. CLIs can change. A process can die. The mission still exists because completed work, pending work, decisions, blockers, and the next action are stored outside the model context.

That is the core of CMS, the Claude Multi-Session system.

CMS Turns claude -p Into a Replaceable Worker

CMS does not put all of its intelligence into a larger root prompt. It takes Claude Code’s non-interactive -p / --print mode and treats it as a worker protocol that an external program can start repeatedly:

CMS orchestrator
  -> read checkpoint
  -> spawn claude --print
  -> worker completes one bounded task and writes a report
  -> orchestrator validates the result and updates state
  -> process exits; the next iteration starts a fresh worker

The worker can still use subagents, Agent Teams, or a graph workflow internally. The difference is that it does not own the whole mission. Scheduling, concurrency, retries, stopping conditions, CLI routing, and the recovery point all belong to the outer loop.

CMS is not tied to one model either. The same state contract can be handed to Claude, Codex, or Gemini. As long as a worker can read task state and return a structured report, another CLI can take over in the next iteration.

A Checkpoint Is the API Between Processes

An outer loop cannot rely on a conversational summary that says the previous run “did a lot of work.” The next process needs explicit state:

• completed and pending items;
• important decisions and constraints that must remain intact;
• current blockers and the reasons for failure;
• actual changes and validation results from the previous iteration;
• the next executable action.

CMS stores this information in checkpoints and per-iteration reports. State updates use locks, atomic writes, and backups so parallel workers cannot overwrite one another and an interrupted process cannot leave half-written state behind.

A process crash therefore does not erase the mission. A new terminal, a new process, or even a different CLI can continue from the checkpoint.

One Substrate, Different Long-Running Tasks

The advanced CMS we use internally is not one enormous prompt. It is a family of commands built on the same process, state, and recovery contract:

Command	Purpose
/cms	Decompose engineering work and assign independent planner, builder, tester, reviewer, and fixer workers
/cms-auto-cycle	Run each TDD or acceptance-criteria cycle in a fresh process
/cms-iterate	Run a general iterator that can continue for dozens of iterations, stop, and resume
/cms-auto-explore	Repeatedly discover, evaluate, implement, and validate the next high-value opportunity
/cms-review	Review a large project module by module, preserve findings, and fix and validate them in batches

What these commands share is not the number of agents. It is that the task lifecycle lives outside every agent process.

Internal Use and the Public Foundation

We began using the outer-loop architecture internally during our July-November 2025 buildout and have continued using it since. The advanced CMS isolates each iteration in its own process and handles checkpoints, reports, resume, backups, concurrency, and cross-CLI routing. In January 2026, we shared the foundation through the open-source Director Mode Lite project. Its first release included iteration, checkpoint, resume, status, stop, and a Stop Hook; the later Evolving Loop and Orchestrator added phased state and file-based reports. The open-source project contains the basic outer-loop model, while the complete process-isolated CMS remains the advanced edition we use internally.

The key distinction is not the feature name. It is who owns the loop.

Why We Don’t Chase Every New Engine

If a new Agent Team, graph engine, or harness makes workers faster, improves collaboration, or provides better telemetry, we can use it. It can run inside one of CMS’s worker processes.

Our evaluation is no longer based on whether it is the newest approach. We ask:

• Does it improve the state contract?
• Does it improve isolation, recovery, or observability?
• Does it reduce the cost of failure?
• Does it make workers easier to replace?

If it does, we adopt the useful mechanism. If it only gives an existing topology a new name, we keep working.

That is why we spend little time discussing every popular inner-loop mechanism. Once the outer loop exists, those mechanisms simply need to be placed in the right part of the architecture.

Tool names will keep changing, and subagent trees will keep getting deeper. A mature execution system still has to answer the same question:

If the process doing the thinking disappears, can the work itself continue?

CMS answers yes. The process is a worker, the checkpoint is the source of truth, and the outer loop owns the mission.

Further reading: We Built Agent Teams Before Agent Teams Existed and From Userland Hack to Native SDK: The CMS Migration Blueprint.