The mental model
If you internalize one page, make it this one. Every Claude Code feature — skills, hooks, MCP, teams, workflows — is a special case of four nested levels of control over a model. Reviewed 2026-06-10.
Prompt ⊂ Context ⊂ Harness ⊂ Loop
Each level is a bigger unit of work than the last and contains the one before it: a message sits inside a context window, which sits inside a single session, which a loop runs over and over. Start at the message; end at a system that runs itself.
Prompt
Context
Harness
Loop
Prompt engineering
Compose one best input, then refine the weakest ingredient and resend.
Context engineering
A finite budget. A curator selects, compresses, drops so only what matters reaches the model each step.
Harness engineering
The outer loop — Gather → Act → Verify → retry — that contains prompt and context inside it, and runs once.
The harness loop, zone by zone
① GATHER — the context-engineering zone. A curator fills a finite context window from: the user request, memory (CLAUDE.md, sessions), prior tool outputs, retrieved docs.
② ACT — the prompt-engineering zone. Assemble one prompt → run inference → branch to tools (exec, fetch, MCP) or subagents (specialists).
③ VERIFY — a verifier (tests, LLM-as-judge) checks the result. Pass → final answer. Fail → retry: re-run gather → act → verify with updated context.
Loop engineering
The harness put on a timer that feeds itself: it finds work, hands it out, checks it, records progress, decides the next thing — then pokes the agent instead of you.
/loop · /goal · routines (the heartbeat) + the repo as system of record.What a loop is built from — a heartbeat, five blocks, and a memory
The heartbeat — what restarts the cycle without you. Three flavours:
/loop = a clock (run again every N minutes);
/goal = a condition (keep going until a separate validator confirms done);
a routine = cloud cron (a saved config a trigger runs unattended, laptop closed).
Subagents — split the maker from the checker so a verifier the loop trusts decides
“done” (no model grading its own homework — what /goal’s separate Haiku evaluator does).
Worktrees — git isolation so concurrent runs don’t collide on the same files.
Skills — project intent written down once, so the loop doesn’t re-derive it from zero each cycle.
Plugins + MCP — connectors that let the loop act in real tools: open a PR, update a ticket, post to Slack.
On-disk memory — the repo is the system of record. The model forgets everything between runs, so “what’s done” has to live on disk, not in a context window.
Pick the heartbeat — two questions
The official docs don’t stack these as control levels; they treat them as siblings you pick between, split on two questions. Where does it run — inside an open session you’re driving, or independent of any session? What fires the next unit of work — a clock, a condition, or an event? “Where it runs” is the load-bearing one: the scheduling-options table makes “Requires open session” its spine, and the agents page fences this whole family off as “a different problem than splitting work across agents.”
| Clock — an interval | Condition — a check passes | Event — something happens | |
|---|---|---|---|
| In an open session |
/loop 5m — re-run a prompt every N min on a fixed cron step |
/goal — until a separate small-model validator confirms done; self-paced /loop (Claude picks the delay); a custom Stop hook |
Hooks (PreToolUse, Stop…); Channels — CI pushes a failure straight into the session |
| Independent of session |
Routines (schedule) · Desktop scheduled tasks · OS cron · GitHub Actions | — rare; encode the check as the routine’s own first step | Routines (GitHub event · API /fire) · GitHub Actions (CI events) |
Every primitive pulls one of four levers
Once you see Claude Code as a harness around a model, each feature is just a way to change one of these:
① What the model knows
Soft context & instructions.
② What the model can reach
Tools & external systems.
③ What is guaranteed
Deterministic enforcement.
④ How work is coordinated
Single-thread → fleet.
The three axes that separate everything
Axis 1 — Soft vs Hard
Does the model choose to follow it, or does the client enforce it no matter what?
Axis 2 — Who holds the plan
The single best discriminator among the coordination primitives. As you move right, more runs in parallel and you watch each step less.
| Who decides what runs next | Primitive | Where intermediate results live |
|---|---|---|
| You, in one prompt | Prompt engineering | The single response |
| The model, across one session | One session / context engineering | The context window |
| The model, delegating turn-by-turn | Subagents | Each subagent’s own context; summary returns |
| You, supervising many sessions | Agent view | Each session’s transcript + worktree |
| A lead agent, turn-by-turn | Agent teams | A shared task list + mailbox |
| A script the runtime executes | Dynamic workflows | Script variables (not a context window) |
Axis 3 — Breadth vs Depth
Two different kinds of scaling. Breadth = how many things run in parallel. Depth = how much sustained, single-thread reasoning & shared context a unit of work keeps. Picking the wrong axis is the most common mistake: people reach for agent teams or workflows (breadth) when they needed one deep session (depth), and vice-versa.
How it all nests
These aren’t nine flat options — they stack. Reading inside-out:
managed policies ← hard ceiling over everything (org governance)
└── harness (one session) ← Gather → Act → Verify loop
├── memory / CLAUDE.md ← soft context in Gather
├── skills ← procedures pulled into Act on demand
├── MCP servers ← extra tools available in Act
├── hooks ← deterministic code at lifecycle events
├── subagents ← delegated workers (own context, summary returns)
└── /loop & /goal ← keep the session working (clock / until a condition holds)
...and when one session isn't enough:
agent view = you supervising MANY of these sessions
agent teams = a LEAD session coordinating PEER sessions that message
workflows = a SCRIPT spawning dozens–hundreds of subagents
worktrees = git isolation UNDER all of the above (so files don't collide)
routines = a saved config a TRIGGER runs unattended in the cloud (laptop closed)
The coordination spectrum — three questions
When a job is too big for one session, the docs reduce the choice to three questions (agents):
Who coordinates?
You → agent view. The model in one session → subagents. A lead model → agent teams. A script → workflows.
Do workers talk to each other?
No, report up → subagents / agent view. Yes, peer-to-peer → agent teams.
Do they touch the same files?
If yes → isolate with worktrees (automatic under agent view; manual partition for teams).
A dynamic workflow in miniature — how this guide was researched
You wanted to see the workflow pattern, not just read about it. A dynamic workflow moves the plan into code: a script fans work out to many subagents, holds the intermediate results in variables, cross-checks them, and returns only the synthesis. This guide was built with exactly that shape — here is the “script” that was effectively run:
// pseudo-workflow: research the Claude Code primitives
const slices = [
"parallel surfaces: subagents, agent view, agent teams, worktrees",
"skills + MCP: mechanism, invocation, security",
"terminology: hooks vs rules, conventions vs policies, 'routines'",
"curriculum + leveling + announcement dates",
];
// PHASE 1 — fan out (parallel, isolated context each)
const findings = await Promise.all(
slices.map(s => agent({ task: s, sources: "code.claude.com/docs only" }))
);
// PHASE 2 — cross-check (claims that disagree get dropped or flagged)
const verified = crossCheck(findings); // e.g. "routines" → 2 meanings: colloquial=skills, official=cloud automation
// PHASE 3 — synthesize (only the answer reaches the main context)
return synthesize(verified); // → this field guide