A Swiss-army-knife agent that takes a fuzzy ambition, breaks it apart, sees the seams, and adapts as the work returns. Four plates make the pattern legible: the three lenses applied as a loop, the hierarchy of who sits above whom, a worked example moving wave by wave, and the atom as the unit of work.
AIR sits above your existing specialists — product-manager, master-designer, expert-orchestrator, investment-orchestrator, frontend-dev — and dispatches them as tools. It does not write deliverables itself. Its job is to hold the high-level view across domains, decide what work is needed and in what order, brief the right specialist for each unit of work, watch what comes back, and continuously re-plan in response.
The four plates that follow show how AIR works. This page first explains why it works that way — because the diagrams are easier to read once the argument is clear.
Most multi-agent work fails in the same place — not at the moment of execution, but at the moment of framing. A specialist given a vague task returns vague work. A pipeline of specialists handed off in a fixed order produces a brittle workflow that cannot absorb new information. AIR is a discipline against both failures: a meta-orchestrator that holds the high-level view, fragments work into precisely-shaped units, watches the seams between them, and re-plans the moment new information arrives.
Ambition is fuzzy by default. Until you can write a one-sentence intent, name a single specialist, and list the testable criteria a verifier could read against, you don't have a unit of work — you have a wish. Atomization is the discipline of refusing to dispatch anything that isn't shaped well enough to be acted on alone. It is slow at the start and pays itself back tenfold at execution.
No specialist is sufficient on its own. The product manager doesn't know what the designer must keep consistent. The frontend developer doesn't know which research finding could invalidate the spec. AIR's job is to map the dependency graph between atoms, name the cross-cutting concerns — taxonomy, brand, data model, success metric — that must hold across them, and watch the seams where misalignment would otherwise leak in silently. Without that layer, you have a swarm; with it, an orchestra.
Plans written before the first piece of work returns are guesses. Every dispatch wave produces information the original plan did not have. Refinement is the moment the orchestrator pauses, reads what came back, and asks the six questions: did each atom hit its criteria, did anything invalidate downstream work, did new atoms surface, did anything become redundant, did cross-cutting concerns drift, did the user inject new context. The plan is regenerated — never silently, always logged. A refinement pass is short; the alternative is shipping a plan that was already wrong by the time you committed to it.
Atomize, Integrate, Refine are not phases you finish and leave behind. They are perspectives you keep returning to, in order, every time work returns. The loop is the system. Each turn produces both the deliverable and a durable record of what the initiative taught the orchestrator — so the next turn is better-informed, the next initiative is better-scoped, and the practice itself sharpens with use. The agent does not just orchestrate work; it learns how to orchestrate work, one initiative at a time.
Atomize, Integrate, Refine are not stages you finish and leave behind. They are perspectives you keep returning to, in order, every time work comes back from a specialist.
Break the ambition into delegable units. Each atom has one intent, testable success criteria, named inputs and outputs, and maps to exactly one specialist agent. Atoms that smell like two atoms are split.
Map how atoms connect. Hard and soft dependencies, cross-cutting concerns (taxonomy, brand, data model, success metric), handoff contracts between agents, and the seams where misalignment is likeliest.
After every dispatch wave, ask: did atoms hit their criteria? Did any output invalidate a downstream atom? Did it surface new ones? Did cross-cutting concerns drift? Update atoms.json, regenerate the plan, log the reasoning, decide the next wave.
A meta-orchestrator does not produce deliverables. It produces decisions: which specialist, which brief, in which order, with which inputs, and — most importantly — what to do when the output comes back.
The pattern is easier to see when it moves. Below: a four-domain ambition, six atoms, three waves, two refinement triggers — including one that re-dispatches a single atom without disturbing the rest of the plan.
decisions.md.
product-memory/chatbot-memory/, expert-library/chatbot-memory-arch/, and the implementation repo. Refinement-log records the SQLite flip and why.
If atoms are the right shape, the rest of the system runs cleanly. If they're vague, no amount of orchestration saves you. Below is the schema AIR writes, and what each field is doing.
// atoms.json — the single source of truth for the plan { "id": "a02", "title": "Engineering spec — SQLite-based memory", "intent": "Translate the PRD into a buildable spec under the SQLite constraint.", "domain": "engineering", "subAgent": "product-manager", "subAgentReason": "PM owns engineering-spec authoring; this atom needs PM-grade rigor.", "successCriteria": [ "Functional + non-functional requirements numbered and testable", "Migration / backfill plan explicit", "References storage decision from a04" ], "inputs": [ "product-memory/chatbot-memory/prd.md", "outputs/a04/storage-comparison.md" ], "outputs": [ "specs/engineering-spec.md" ], "dependencies": ["a01", "a04"], "parallelizableWith": ["a03"], "refinementTriggers": [ "Storage choice changes → revise this atom", "Latency budget changes in PRD → revise this atom" ], "status": "complete", "briefPath": "briefs/a02.md", "outputPath": "outputs/a02/", "dispatchedAt": "2026-05-03T14:42:00Z", "completedAt": "2026-05-03T14:58:00Z", "notes": "Re-dispatched after a04 returned SQLite recommendation." }
parallelizableWith dispatch in the same wave — same message, multiple Agent calls.pending · in-flight · complete · blocked · dropped. Atoms are never silently dropped — a drop is a logged decision.charter.md — immovable ambition
atoms.json · atoms.md — the plan
integration-map.md — graph + seams
refinement-log.md — append-only learning
decisions.md · status.md
briefs/<atom>.md · outputs/<atom>/
All atoms complete or dropped → done
Atom blocked on user input → pause + surface
Two-retry max per atom before escalation
Charter changes are logged and reconciled across the dependency tree, never silent
Multi-domain ambition (3+ specialists)
Path is unclear and will need course-correction
Initiative is large enough that a single specialist can't own it end-to-end
For pure single-domain work, dispatch the specialist directly — AIR is overkill.