Tier IV — Scaling Judgment¶

The bar: you compose agents deliberately, and you start from the spec instead of the code.

L6 — Composition¶

CORE — You compose agents — deliberately, not reflexively.

There is really one primitive — the agent — and three ways it elaborates: a thing below it (skills), a role it plays (subagent), and a specialization of it (orchestrator). They stack at different altitudes, and the discipline of this rung is restraint: composing only what the task earns. The trap of the current moment is multi-agent architecture as premature optimization.

Layer	What it is
ORCHESTRATOR	An agent whose action space is other agents. Loop: decompose → dispatch → collect → synthesize → done.
SUBAGENT	The agent in the child position — own window, own loop, returns a distilled result. A tool from the outside.
AGENT	The base unit — model + harness + loop. The smallest thing that can pursue a goal on its own.
SKILLS / TOOLS	Capability packages loaded on demand — no loop of their own. Below the agent, like libraries to a program.

One primitive (the agent). Below it: skills. A role it plays: subagent. A specialization: orchestrator. Earn each layer.

What you're actually learning¶

Skills — capability packaging, below the agent: instructions plus optional scripts and resources, bundled and loaded on demand, with no loop of their own — inert until invoked. Skills are to agents what libraries are to programs, and a skill definition is itself a spec at the capability grain (SDD, one level down). Progressive disclosure — load the capability only when relevant — protects context.

Subagents — the agent in the child position, a role rather than a new type: its own context window, its own loop, returning a distilled result to its caller. From the parent it looks like a tool; inside it's a full agent. The real reason it exists is usually context isolation — delegate so the parent's window stays clean and gets back a compressed answer — which is why so much "multi-agent architecture" is really context architecture, a direct callback to L3. The second reason is parallelism: fan out independent subtasks.

Orchestrators — an agent whose action space is other agents, a specialization whose loop is decompose → dispatch → collect → synthesize → decide-done, sitting at the top of the coordination layer. And termination goes fractal: every composed agent (except skills, which don't loop) must know when it's done, and the orchestrator faces the harder nested version — when is the collective done? That's L2's problem raised a level, and it's where multi-agent systems actually break.

Concepts to master¶

• Skills — loaded-on-demand capability packages with no loop.
• Progressive disclosure — load capability only when relevant.
• Subagent — agent in child position; own window/loop; distilled return.
• Multi-agent as context architecture — isolation + parallelism.
• Orchestrator — decompose / dispatch / collect / synthesize.
• Fractal termination — per-agent and collective done-ness.
• Earned-complexity discipline — justify every layer in one sentence.
• Result contracts — the schema a subagent returns to its caller.
• Failure isolation — a dead subagent must not kill the run.
• Shared vs. isolated memory — what state crosses agent boundaries.
• Cost of coordination — every hop adds latency, tokens, failure surface.

Clear it when¶

• ☐ You can justify every added layer in one sentence — packaging, isolation/parallelism, or genuine decomposition.
• ☐ You've removed a layer that wasn't pulling its weight.
• ☐ Your orchestrator has a real answer to "when is the collective done?"
• ☐ You can explain why a given task got a single loop instead of a swarm.

Where people get stuck¶

• ✗ A subagent swarm under an orchestrator where one loop would have shipped.
• ✗ Multi-agent as a capability story when it's really a context story.
• ✗ No collective-termination logic — the orchestrator that never cleanly finishes.
• ✗ Skills, subagents, and tools conflated instead of placed at their altitudes.

L7 — The Inversion¶

EXPERT — Expert. You don't climb the ladder anymore — you start at the top and drive down.

Every rung so far was bottom-up: assemble primitives because you don't yet know what's buildable. Expertise is the inversion — you start from intent, from a spec, and drive downward, because the primitives are now internalized. The whole playbook exists to be climbed once and then run in reverse. Spec-driven development is the governance that makes it possible; evals-first is how you think.

SPEC → BUILD EVAL → SHIP → OBSERVE → REVISE ↻

The outer loop. The spec (gold) is the single source of truth feeding BUILD and EVAL alike; production signal flows back to revise it.

What you're actually learning¶

Spec-driven development as governance: the spec is a single durable artifact — behavior contracts, acceptance criteria, success metrics, constraint budget — that drives both the implementation and the evals. The same document your build follows is the document your eval suite derives from, and that shared source of truth is what makes the system verifiable.

The outer lifecycle loop: spec → build → eval → ship → observe → revise spec → … — the slow loop that wraps everything. Inside it sits the fast inner dev loop (prompt/harness iteration, dozens of times a day), and inside that, at runtime, the agent loop from L2. Three loops at three timescales; SDD governs the outer one. Evals-first thinking is the L5 skill promoted to a default stance — you specify the test of "done" before you build.

And the inversion itself: why beginners must go bottom-up (they don't yet know the shape of the buildable) and why experts go top-down (intent → governed build). Being able to hand a spec to another engineer — or to an agent — and get the intended system back is the mark of the level. Finally, revising the spec from production signal: the observability from L5 feeds spec revision, closing the outer loop without breaking it.

Concepts to master¶

• Spec as single source of truth — for build and eval.
• Contracts + criteria + budgets — the anatomy of a spec.
• Three nested loops — runtime / dev / lifecycle and their timescales.
• Evals-first — specify "done" before building.
• Spec-driven delegation — to humans and to agents.
• Closing the outer loop — revise from production signal.
• Executable acceptance criteria — criteria that are evals.
• Constraint budget — latency, cost, and safety as first-class spec terms.
• Versioned artifacts — prompt, model, and data pinned like code.
• Spec change log — every revision traceable to a signal.

Clear it when¶

• ☐ You start from a spec, not a prompt.
• ☐ Your evals derive from your spec.
• ☐ You can hand the spec to another engineer or an agent and get the intended system back.
• ☐ You revise the spec from production signal without breaking the loop.

Where people get stuck¶

• ✗ Staying a builder — starting from code forever, never inverting.
• ✗ A spec that governs the build but not the evals (or vice versa) — the two drift.
• ✗ The spec as a one-time document instead of the thing you revise each cycle.
• ✗ Skipping the spec entirely — the one thing that makes the loop closeable.