Agentic Orchestration V1

The command center everything else on this site came out of. ATLAS spawns Claude Code CLI sessions into terminal panes, coordinates a seven-role team through flat markdown files, and closes a full strategy-to-commit loop with a file watcher and a post-commit hook. Built in four weeks, April 6 to May 3, 2026. It is the ancestor of the protocol, not the current version of it: ATLAS V2 is what runs today.

The problem it was built for

Running five projects alone does not fail on the building. It fails on the re-entry. You open a repo you have not touched in nine days and spend forty minutes reconstructing what you were doing, what you had decided, and which of the three half-finished things was blocked on a decision you never made. Multiply that by five projects and the cost of holding a portfolio is almost entirely the cost of remembering it.

Agents make this worse before they make it better. An agent that worked on something while you were not watching has produced a state you now have to catch up on, and the transcript is somewhere in a terminal you have since closed.

So ATLAS is not primarily an agent runner. It is a place, one durable, local, file-based state that every project and every agent reads from and writes to. What is active. What is blocked, and on what. What an agent touched last, and why it said it did. There is no database. All state is human-readable markdown and CSV, which bought two things I did not plan for: the whole system can be understood by grepping it, and Sift, a separate intelligence pipeline I ran, reads the vault with zero integration code.

The stack, concretely

What it looks like running

Eight surfaces in a terminal-brutalist monospace shell, with an ops strip across the top. On launch day the dashboard read PROJ 04 | TKT 21 / WIP 00 BLK 00 | SYNC 00:06s: four projects, twenty-one open tickets, none in progress or blocked, state six seconds old. The strongest single piece of evidence that the loop worked is that ATLAS is a project inside its own registry: all 162 tickets that built it were dispatched, executed, reviewed and logged by its own loop.

What it proved

Durable state beats a long conversation. A coordinator that is a running context window dies with the process, and every restart pays the reconstruction cost again. A coordinator that is a set of files on disk survives the laptop closing, and any agent, or any human, can be brought up to date by reading it.

The unit of memory should be the project, not the session. Sessions are an artifact of how the tool works. Projects are the thing that actually persists, and organizing state around them is what let five run at once.

Writing down why is worth more than writing down what. A log of what an agent changed is a diff, and git already has it. A record of what it was trying to accomplish is the thing that makes the next agent, or me nine days later, able to continue instead of re-deciding.

The wall

ATLAS held the state; deciding what happened next stayed mine. Every morning the system could tell me precisely what was blocked and why, and every morning I was the one who had to read that, choose, and start the agent. The bottleneck moved from remembering to dispatching, a real improvement, and still a human in the middle of every loop. Two human gates sat in the circuit by design: I acked the ticket plan before a sprint spawned, and Middle Manager review preceded every commit.

V2 takes that decision and gives it to an Overseer Agent, which turned out to require a different isolation model to be safe: one git worktree per lane, and file signalling instead of a shared board.

The four questions people actually ask