Agentic Orchestration V2

ATLAS V1 gave me one place where the state of every project lived. It did not give me back the job I actually wanted to hand off, which was deciding what should happen next. This generation moves that decision into an agent and gets me out of the loop entirely after the first conversation.

The shape of it

There are two roles and one rule. The Overseer Agent is Claude Code running in the desktop application, on Opus 4.8 Max with a one-million-token context, because it is the only process that has to hold the whole project in its head at once. The sub-agents are claude in terminal panes, each on Opus 4.8 in ultracode mode: extra-high reasoning effort plus dynamic workflow orchestration, so each one can spawn one to five agents of its own when a ticket turns out to be bigger than it looked.

The rule is that agents never talk to each other. Everything goes through the Overseer, and everything is a file. Traffic uses five message types (Question, Clarification, Answer, Issue, Done), four traveling up and Answer coming back down. That single constraint is what makes the whole thing debuggable: at any moment the complete state of the system is on disk and I can read it without attaching to anything.

The physical setup

Two monitors, four panes each, is eight concurrent agents. That is the ceiling, not the recommendation. I run four. Past four, the Overseer becomes the bottleneck and the thing you are optimizing stops being throughput and starts being your own ability to read what happened.

What each role actually does

Overseer Agent

1. Writes tickets into a specific lane. A lane belongs to exactly one agent for the life of a ticket.
2. Waits for signals. It does not poll the agents; it watches the filesystem for files appearing.
3. On .done.md: review → merge → push → log, in that order, on its own branch.
4. Fixes the issues it finds during review itself rather than bouncing them back, unless the fix is large enough to be its own ticket.

Sub-agent (n)

1. Watches its inbox for tickets.
2. Scopes, then builds, spawning its own agents if the ticket is bigger than one context.
3. Reviews its own work, then marks done by writing the signal file.

The kit, as designed

The intent is portability: dropping one folder into a repo and pasting two prompts should be the entire setup.

agent-workflow-kit/
├── README.md
├── Coordination.md        ← the rules every agent obeys
├── Workflow.md            ← the diagram and the breakdown
├── prompts/
│   ├── overseer.md        ┐ paste into an agent
│   └── lane-coord.md      ┘ to assign it a role
├── templates/
│   ├── agent.md           ┐ skeletons
│   └── ticket.md          ┘
└── inbox/
    └── README.md          ← how flow is managed

Configuration of record

What I got back

The measurable change is where my time goes, not how much of it there is. The planning conversation got longer and more careful, because it is now the only leverage point in the run. Everything after it (the dispatching, the context-switching between four half-finished things, the remembering which of them was blocked on what) stopped being mine.

The failure mode also changed shape. In V1 the failure was me: I would forget a blocked project for two days. Here the failure is an agent confidently finishing the wrong ticket, which is faster to cause and slower to notice. That trade is the honest cost of the generation, and it is the reason problem 02 below matters as much as it does.

What it still cannot do

Every sub-agent is a generalist. They run the same model with the same prompt shape and no standing knowledge of the domain they were dropped into. An agent working on the quoting engine and an agent working on the maintenance triage pipeline are the same agent wearing a different ticket. That is what V3 attacks: pushing the specialization into the agent itself (its own model, tools, skills and MCP servers) instead of into the prompt it was handed.

The Overseer cannot see its own overhead. It is supposed to notice and improve inefficiencies in the workflow: the standing instruction in the margin of the design notes reads “auto improve inefficiencies in workflow.” It is also the busiest process in the system and the one with no spare attention, which makes it the worst available candidate for the job. I do not have a good answer for this yet; the Agentic Orchestration Architecture paper states it as an open problem.

And the throughput claim is not measured. I can tell you my attention moved and that four agents run at once. I cannot yet hand you a before-and-after on tickets closed per day or on error rate, because V1 logged itself and V2 does not log itself the same way. That instrumentation gap is the honest reason this page has no performance table.