The model is only one part of the machine.

The chain of limitations — 11 sheets

1. 01Instructions→Who the model is, the work it does, the tone, the constraints — CLAUDE.md, AGENTS.md, system prompts, repo rules. The first harness layer: it shapes everything the model does.
   ↓

   Instructions are passive. They can say “follow project conventions,” but they cannot discover those conventions. The model needs to be handed material.

2. 02Context Delivery→Giving the model the material it needs: the relevant file, the failing test, the stack trace. The difference between a bare model and an agent starts here.
   ↓

   Dumping everything in is not context engineering. The window is finite and attention is not free — wrong context is worse than missing context.

3. 03Context Management→Protecting the model's attention: retrieval and re-ranking, summaries, compaction, prompt caches. Deciding what enters the model at this instant.
   ↓

   A well-fed model is still just a talker. It can propose the command and name the file — but someone has to actually act.

4. 04Tool Interfaces→Structured action: name, description, schema. Function calling, MCP, bash, grep. The model stops describing work and starts requesting it.
   ↓

   The model chose the tool and the arguments — but where does it run? With what access? And how much do we trust what comes back?

5. 05Execution Environment→Where tool calls become bounded reality: sandboxes, containers, worktrees, filesystem scope, network and secrets. Trust made practical — the model doesn't avoid secrets, it never gets them.
   ↓

   One clean sandbox isn't enough for long work. Tasks pause, resume, fork, and fail — and if progress only lives in the context window, a crash erases it.

6. 06Durable State→The workbench that survives the turn: plan files, checkpoints, branches, logs, memory stores. Progress becomes inspectable outside the model's current attention.
   ↓

   State preserves work but doesn't coordinate it. A plan file can't decide what to retry, when to pause, or when to ask a human.

7. 07Orchestration→How work moves: lifecycle hooks, retries, approval gates, heartbeats, human handoff. The layer where agent work looks less like chat and more like a runtime.
   ↓

   Orchestration helps one agent do more — but one agent still has one attention stream. Serial work is slow, and its context gets crowded.

8. 08Sub-agents→Bounded loops with a narrower job, narrower context, narrower tools. One explores, one reviews, one verifies — and the orchestrator integrates the results.
   ↓

   Delegation creates a new problem: if every sub-agent invents its own process, you get parallel inconsistency.

9. 09Skills & Procedures→Reusable know-how, loaded at the right time: skills, slash commands, playbooks, runbooks. Repeated expertise becomes a named capability the harness can invoke.
   ↓

   Skills make work repeatable but don't prove it succeeded. “Run the tests” is a procedure — did they pass is evidence.

10. 10Verification & Observability→The harness asks for receipts: tests, type checks, screenshots, evals. And it records the run — traces, tool-call timelines, costs — so failure becomes debuggable.
    ↓

    Verification tells you something failed; observability tells you why. But neither, alone, makes the next run better.

11. 11Evolution→Failures become infrastructure: a missed context becomes a retrieval rule, a dangerous command becomes a permission gate, a repeated workflow becomes a skill. The harness compounds.
    ↓

    This is where the chain closes. The point is not a perfect run — it's making the next run start from a better place.