Chapter 1. The anatomy of a prompt

1.1 What a prompt actually is

Almost every prompt you have ever seen is missing the output schema SCHEMATIC. The model returns a paragraph where you wanted a table, or a bullet list where you wanted JSON. Adding ‘respond in JSON with keys summary, confidence, and source’ raises pass rates by tens of percent B — it is the single highest-leverage habit in the foundation layer.

1.2 Prompts are programs, not conversations

The 2024 'Building Effective Agents' essay from Anthropic B draws the same line: even a single prompt can be a compound AI system if it iterates with itself before returning. Prompts are no longer chat; they are the smallest deployable unit in modern AI work.

1.3 Common mistakes at the foundation layer

Three mistakes recur in nearly every beginner's prompts:

1. Vague verbs. ‘Tell me about’ produces survey essays. ‘Compare and contrast A vs B across three dimensions’ produces structured comparison. The verb does most of the work.

2. Missing output schema. As above. Always pin the shape SCHEMATIC.

3. Missing evidence layer. A confident answer with no source is the most expensive artefact in any AI product; it will fail in production the moment any user checks it. Add ‘if you do not know, say so and explain what you would check’ B.

Chapter 2. Skills: packaging recurring work

2.1 What a skill is

The five parts look like ceremony, but each one prevents a different failure mode. The name prevents two skills from doing the same thing under different labels. The description prevents the orchestrator from routing to the wrong skill. The frontmatter prevents the skill from calling tools it should not have, or running on the cheapest model when it needs the most expensive one. The body prevents ad-hoc behaviour. The handoff prevents the caller from having to parse free-form prose.

2.2 SKILL.md frontmatter, field by field

---
name: trade-ticket-format
description: Convert a verbal trade idea into a structured ticket; never execute.
model: sonnet
tools: Read, Grep, Glob
memory: project
effort: low
---

You are a trade-ticket formatter. ...
Inputs:  a verbal trade idea (1-3 sentences).
Outputs: a JSON packet with keys symbol, direction, size, stop, target, confidence.

Each field is doing real work. model routes the skill to the right cost tier — haiku for mechanical, sonnet for assembly, opus for judgment. tools is the deny-by-default filter: anything not in the list is forbidden. memory controls whether the skill persists state across sessions. effort controls how much the model deliberates per turn.

Two rules of thumb that go with the frontmatter. First: never set memory without a reason — a persistent memory directory is a maintenance and security surface, so the default is none. Second: the description field is the routing hint — write it the way you would write a commit message: one line, specific, no fluff B.

2.3 Skills compose, do not replace each other

Two common beginner traps:

Trap 1: mega-skills. A skill that does the work of six smaller skills. Mega-skills are unreviewable, untestable, and impossible to compose with other skills. Resist.

Trap 2: one-call skills. A skill that wraps a single well-known prompt with no frontmatter value. It bloats the registry without adding anything. Skip it — call the model directly.

The sweet spot is a skill per recurring task type: a single verb, a clear handoff, three to seven frontmatter fields of real work. Most real-world skill libraries ship with 5-15 such skills, not 50 SCHEMATIC.

Chapter 3. Agents: autonomous workers

3.1 Agent vs pipeline

Pipeline first, agent second. The Anthropic 2024 essay B draws the same line: 'prefer the simplest, most composable pattern'. Most beginner systems over-use agents because the idea of an autonomous worker is more exciting than a deterministic sequence. The discipline is: when the steps are stable and the outputs are predictable, run a pipeline. When the steps depend on the inputs in ways no one wants to enumerate, run an agent.

3.2 The agent loop

ReAct B (Yao et al., 2022, arXiv:2210.03629) named the loop and gave it a paper. Modern agents still run it, with two additions: memory lets the loop persist state, and a terminal condition lets the loop end cleanly. Both are pieces we pick up in the next chapter on loops.

3.3 Sub-agents and the orchestrator

One agent with a 1M-token context window can hold a lot; it cannot hold everything. Sub-agents are the pattern: a top-level agent (the orchestrator) delegates scoped tasks to children, each of which has its own context and toolset.

Anthropic's 2026 Dynamic Workflows documentation B describes the production version of this pattern: up to 16 concurrent sub-agents per workflow, a hard cap of 1,000 per workflow, fresh context for each sub-agent, intermediate state in script variables, triggers via :workflow or ultracode mode, and the Bun runtime supporting roughly 750,000 lines of Zig in Rust in 11 days with 99.8% test pass rate V — concrete numbers from the published documentation.

The cardinal rule: the orchestrator's context must stay thin. If the orchestrator is quoting tool results from the last five turns, it has leaked sub-agent state into its own window and is about to lose the thread. Sub-agents return paths and typed packets; the orchestrator carries decisions and references, not data.

Chapter 4. Loop engineering: the 5-must-have primitive

4.1 Where Karpathy's autoresearch came from

The autoresearch repository B reports that the agent edits train.py, evaluates with val_bpb, and either keeps or reverts the change with git reset. The pattern is exact: bounded change, measurable evaluation, reversibility, durable history V. Every production-grade loop has those four properties; the 5-must-have contract adds a fifth: terminal-state reporting, so a human can audit the run after the fact.

4.2 The 5-must-have contract

The contract is short and load-bearing:

1. Terminal state. Every loop ends in done | partial | blocked | converged. No ‘still running’.

2. Idempotent write. Running the loop twice with the same inputs and the same environment produces the same end state.

3. Dedupe key. Every record the loop writes has a unique key. Reruns of the same key are NOOPs.

4. Coverage filter. The loop declares what it covers and what it does not. The AAR reports both.

5. AAR. At terminal state, the loop writes a 1-page report: goal, decomposition, cost, evidence, critique, next run.

Most loops ship with the first two and ignore the rest. The cost is silent: the loop runs forever, fills disk with duplicates, never reports what it tried and what it skipped, and leaves no audit trail SCHEMATIC. The 5-must-have contract is cheap insurance against all of those failure modes.

def ratchet_loop(inspect, propose, apply, evaluate,
                 keep, revert, better, baseline):
    history, current = [], baseline
    while True:
        state = inspect()
        change = propose(state)
        commit = apply(change)
        try:
            score = evaluate()
        except Exception as exc:
            revert(commit)
            history.append(Trial(commit, change, None, "crash", ""))
            continue
        if better(score, current):
            keep(commit); current = score
            history.append(Trial(commit, change, score, "kept", ""))
        else:
            revert(commit)
            history.append(Trial(commit, change, score, "reverted", ""))

# caller MUST check terminal state, idempotent write, dedupe key,
# coverage filter, and write an AAR before this loop is deployable.

4.3 The five failures when one is missing

Each of the five must-haves prevents a specific, common failure:

Missing terminal state. The loop runs forever; bills rack up; the orchestrator cannot tell whether it finished.

Missing idempotent write. Two runs produce two divergent copies of the same artefact. Merge hell.

Missing dedupe key. Records multiply; storage costs balloon; downstream queries get confused.

Missing coverage filter. The loop covers half of what was asked; no one notices; the user re-runs the loop ten times to discover the gap.

Missing AAR. The loop terminates with no record of what it tried, what worked, what crashed, or what to try next. The next run starts from zero.

Chapter 5. Graph engineering: the integrating layer

5.1 Four kinds of graphs inside AI

Three of these are about memory (knowledge, agent, computation); one is about the substrate (the neural net). The graph-engineering layer focuses on the first three, because those are the ones the engineer builds.

5.2 The Karpathy loop → AgentHub → Anthropic playbook

The progression identified by the 2026 Anthropic playbook B is strikingly consistent. Stage 1 is a single loop that runs bounded experiments with measurable evaluation. Stage 2 is a swarm — many independent workers, each running the same loop, coordinated through a commit DAG and a message board (Karpathy's AgentHub is exactly this). Stage 3 is a knowledge graph that externalises shared memory: entities, relations, sources, lineage.

Anthropic's Knowledge Graph Construction Cookbook B operationalises stage 3 with a four-step pipeline: extract entities with Haiku, resolve aliases with Sonnet, assemble with NetworkX MultiDiGraph, and query by serialising subgraphs. The cookbook warns about the most common failure: entity resolution can cause catastrophic errors — a false merge between two people with similar names propagates downstream. Resolution must be additive, inspectable, and reversible.

5.3 The 6-question decision framework

The same playbook offers a six-question framework for choosing an architecture. Answer each question; the answers map to a pattern:

Question 1 is the most important: if you cannot define what success looks like, do not begin with autonomy. A loop that runs unbounded on an unverifiable task is a fast path to expensive noise. The other five questions build on that first answer.

5.4 The Commit DAG and Knowledge Graph are complementary

The Anthropic playbook V summarises this with one sentence: the DAG remembers which work descends from which experiment; the graph remembers which claims connect to which entities and sources. Together they prevent agents from rebuilding the world from scratch in every context window.

Production systems connect the two: every write to the commit DAG includes a link to a claim in the knowledge graph, and every claim in the graph includes a link to the agent run that produced it. The compound structure becomes queryable in both directions: ‘show me the lineage of this experiment’ and ‘show me what produced this fact’ are the same question in two forms.

5.5 When NOT to use a graph

Graphs are not free. The playbook B lists the cases where a graph is the wrong tool: tasks are independent; answers depend on one document; relations are fixed and simple; a relational table answers every query; or extraction errors would outweigh traversal value.

Three more costs to weigh:

Dynamic workflows are expensive. A 1,000-sub-agent run at high effort can cost tens of dollars per task. Parallel workers create correlated errors; the verification wave is the only thing that catches them.

Fragmentation can reduce quality. Architecture design, narrative writing, and tightly coupled refactors may degrade when split into isolated units.

Knowledge graphs reflect their corpus. A biased corpus produces a biased graph; missing documents produce missing edges.

The discipline is: introduce a graph when at least one of questions 4 or 5 is yes. Otherwise stay with loops and skills.

Chapter 6. Operating the stack: cost, observability, scaling

6.1 The four dials

The Anthropic Dynamic Workflows docs B report that a 1,000-sub-agent workflow with high-effort reasoning can cost tens of dollars per task at the top model tier. That is a useful upper bound: if your design admits a 1,000-sub-agent run, you must be ready to spend that much per task SCHEMATIC. The cheapest fix is almost always route to the smallest model that can solve the task, not average out with cheaper tools.

6.2 Observability what to log

Three things must be on every agent run log:

Inputs and outputs. Hash the input. Hash the final output. Store both with the run id. Without these you cannot reproduce a failure or measure drift.

The agent graph at run time. Which skills were invoked, in what order, with what arguments, returning what. This is the agent graph as telemetry SCHEMATIC. Most teams under-invest here.

The verification wave. Whatever review step catches errors. Did it catch a wrong answer? How many times? What was the false-positive rate?

6.3 The three most expensive anti-patterns

Three patterns recur in production AI failures. Each one wastes budget or produces unreliable output:

1. Mega-skills. A skill that does the work of ten. Reviewer cannot audit; output cannot be partial. Fix: split by task type.

2. Long-context as memory. Stuffing state into the prompt instead of writing to disk. Costs scale linearly with context size; quality falls non-linearly. Fix: offline-first files, references by path.

3. Aggressive parallelism without a reducer. 16 sub-agents returning uncorrelated outputs. The synthesis step becomes a guessing game. Fix: the agent-graph telemetry tells you whether the workers agree before they merge.