Agentic Orchestration V3

In ATLAS V2 every sub-agent is the same agent wearing a different ticket. Specialization is something I type at the start of a run and it dies with the process. This generation makes specialization structural: the agent is a whole unit that knows a domain, and it is still that unit tomorrow morning. Everything on this page is design. It exists as one notebook page dated August 18, 2026 and the reasoning below it. No V3 code exists, and I would rather show you the sketch with that label on it than wait until there is something to demo.

The unit

A domain agent is six things assembled together and version-controlled as one artifact, not a prompt handed to a generic runtime:

The system

Domain agents do not form a hierarchy. A coordinator routes work to whichever unit owns that domain, and every output comes back to the top to be evaluated before it counts. Running alongside them is a research agent whose only job is to keep a shared knowledge layer current: an Obsidian vault as the human-readable substrate, with a vector index over it so any agent can retrieve into its own context.

The distinction that matters: the vault is shared, the tools are not. Every agent can read what the system knows. Only the agent that owns a domain can act on it.

Why bother

Three things V2 pays for on every single run, that this is meant to stop paying:

Those are hypotheses, stated in the form they will be tested in. The paper measures them against V2 on the same tickets; if orientation cost does not drop measurably, the whole premise of this generation is wrong and that is worth publishing too.

What is unresolved

The handoff

This is the one blocking real construction, and it is written on the page in my own hand: “Need to figure out how the handoffs work. The process.” When the coordinator routes work to a domain agent and the result comes back, what crosses the boundary? Full context is expensive and gets lossy as the tree deepens. A summary makes the agent re-derive what the coordinator already knew. A pointer into shared state means both sides need to agree on a view of a world that is changing while they read it. I have written it three ways and none is obviously right.

Evaluating at the top

The feedback loop only works if the coordinator can score an output cheaply. A coordinator thorough enough to catch a subtle domain error has just done the task twice, which deletes the reason to delegate. The open question is whether a domain-specific evaluator, a seventh unit that is cheap and narrow, is the answer, or whether that just moves the problem down one level.

Which models can host a unit

A domain agent needs tools, skills and MCP servers at once, under a system prompt it did not write. The set of models that can hold all of that simultaneously is smaller than the set that advertises it, and it changes month to month. I re-test by hand because I have not found a capability matrix I would stake a build on.

Metering, if this is ever sold

If a domain agent system runs on someone else’s behalf rather than my own, usage has to be attributed and billed per client across a tree where agents spawn their own agents. The plumbing is straightforward. Pricing a unit of work whose cost varies by an order of magnitude depending on how hard the problem turned out to be, which nobody knows in advance, including the agent, is not.