The whole system in one picture

This book has eight parts and forty-odd chapters, and it is easy to lose the shape of the thing while you are deep in any one of them. So here is the whole system on one page.

Read it now as a map of where you are going, and come back to it later as a summary of where you have been. Every box corresponds to a chapter, and there is a lookup table at the bottom telling you which.

The run

This is what happens when a user sends one message.

┌─ HARNESS ──────────────────────────────────────────── LangGraph · Agents SDK · your own ─┐
│                                                                                          │
│   Everything inside this box is EPHEMERAL. It dies when the run ends.                     │
│   What survives is memory, checkpoints, and traces — the three things written outward.    │
│                                                                                          │
│     system prompt ─┐                                                                     │
│     user message  ─┼──▶  WORKING MEMORY ──▶┌─ LOOP ───────────────────────────────────┐  │
│     chat history  ─┘     (the context      │                                          │  │
│            ▲              window itself)   │      model ──── tool call ────┐          │  │
│            │                               │        ▲                      ▼          │  │
│   ┌────────┴─────────────────────┐         │        │              ┌───────────────┐  │  │
│   │ MEMORY            (persists) │         │        └── result ────│ TOOL GATEWAY  │  │  │
│   │                              │         │                       │  authorize    │  │  │
│   │  procedural   files, skills  │         │   ┌──────────────┐    │  rate limit   │  │  │
│   │  semantic     vector store   │         │   │ BUDGET       │    │  human gate   │  │  │
│   │  episodic     SQL + vectors  │         │   │  steps       │    │  on writes    │  │  │
│   │                              │         │   │  tokens      │    └───────┬───────┘  │  │
│   └────────┬─────────────────────┘         │   │  dollars     │            ▼          │  │
│            ▲                               │   │  wall clock  │      the real world   │  │
│            │ distill into facts            │   └──────────────┘   (APIs, DBs, email)  │  │
│   ┌────────┴──────┐                        │                                          │  │
│   │  summarizer   │◀── only after N turns  └──────────────────┬───────────────────────┘  │
│   │ (cheap model) │                                           │                          │
│   └───────────────┘                                    exit guardrails                   │
│                                                               │                          │
│   CHECKPOINT ──▶ written each turn, so a crash resumes        ▼                          │
│                 instead of restarting                      reply ──────────────────────────▶
└──────────────────────────────────────────────────────────────────────────────────────────┘

Three things in that picture are worth saying out loud.

The run is disposable; memory is not. Everything in the harness box is thrown away when the run ends. That is not a limitation, it is the design — it is why you can retry, why you can run many at once, and why state has to be written somewhere deliberate rather than accumulating by accident.

The three memories differ by how you retrieve them, not just by what they hold. Procedural memory is a file you read. Semantic memory is a vector store you search by meaning. Episodic memory needs both — vectors for relevance and a SQL query for recency, because “what did we discuss about billing” and “what happened last Tuesday” are different questions and only one of them is a similarity search.

Consolidation is deliberate and cheap. Raw turns land in episodic memory immediately, but they only get distilled into durable facts after N turns, by a smaller model. Doing it every turn would cost more than the agent itself.

The loop around the loop

The diagram above runs thousands of times a day. This one runs on a slower clock, and it is what turns a demo into a system that improves.

   every run emits ──▶ ┌── TRACE ──────────────────────────────┐
                       │  one trace per run: spans for each    │
                       │  model call, tool call, sub-agent     │
                       └──────────────┬────────────────────────┘
                                      │
                   ┌──────────────────┴───────────────────┐
                   ▼                                      ▼
        ┌─ WAS IT GOOD? ─────────┐          ┌─ WAS IT HEALTHY? ────────┐
        │  outcome checks        │          │  latency, tokens, cost   │
        │  trajectory checks     │          │  tool error rate         │
        │  LLM-as-judge scores   │          │  budget exhaustion       │
        └──────────┬─────────────┘          └───────────┬──────────────┘
                   └──────────────────┬─────────────────┘
                                      ▼
                              ┌─ DIAGNOSE ────┐
                              │ which turn?   │
                              │ which tool?   │
                              │ which prompt? │
                              └───────┬───────┘
                                      ▼
                                  ╱ GATE ╲          fails ──▶ fix, re-run, re-trace, re-eval
                                  ╲      ╱                              │
                                      │ passes                          │
                                      ▼                                 │
                       ┌─ RELEASE ─────────────────────┐                │
                       │ new prompt version            │                │
                       │ model or config change        │                │
                       │ tool change, retrieval params │                │
                       └───────────────┬───────────────┘                │
                                       │                                │
                                       └──── back into the harness ◀────┘

The important property is that the arrow returns. Traces feed evaluation, evaluation feeds diagnosis, diagnosis produces a change, the gate decides whether the change ships, and the shipped change alters the very prompts and configuration the next run uses. An agent without this loop does not get worse over time — it just stays exactly as good as it was the day you stopped paying attention, while the world around it moves.

What most diagrams leave out

Draw this system on a whiteboard and you will produce something close to the picture above. Most people stop there, and the gap between that drawing and a system you would put in front of customers is made of four things.

A budget. The loop has no natural end. A model that keeps deciding to call one more tool will keep calling it until something stops it, and “something” needs to be a step cap, a token ceiling, a spend limit, and a wall-clock deadline — with the remaining budget visible to the model so it can wrap up gracefully rather than being cut off mid-thought.

A gate on irreversible actions. Notice the tools in any realistic version of this diagram: write to the CRM, issue the refund, send the email. Those are not reads. A tool gateway that authorizes each call, applies least privilege, and routes anything irreversible past a human is not an enhancement — it is the difference between a bug and an incident.

Durability. “Everything inside the box is ephemeral” is a clean idea right up until a forty-turn run dies at turn thirty-eight and you discover that the eight dollars and four minutes it spent are gone, along with a half-finished set of changes to the outside world. Checkpoints, and a record of what has already been done, are what let the run resume instead of restart.

A trust boundary. Tool results flow straight back into the context window. If any tool reads content an attacker can influence — a web page, an email, a document, a third-party MCP server — then that content is now sitting in the same context as your instructions. Nothing in the diagram stops it from being read as one.

None of these are exotic. They are all boring, and they are all the reason the boring parts of this book are longer than the exciting ones.

Which chapter covers which box

Checkpoints and resume, which sit at the bottom of the first diagram, are covered in the sibling agentic-ai-evaluation-guide’s long-horizon operations track, along with the failure modes that only appear once a run gets long — context drift, retry budget exhaustion, and agents that report success while stuck.

If you remember one thing

The model is the smallest part of this diagram.

Everything else — assembling context, deciding what to remember, authorizing actions, bounding cost, capturing traces, judging quality, gating releases — is ordinary software engineering wrapped around a component you did not write and cannot fully predict. That wrapping is the job. It is also, conveniently, the thing interviewers are actually asking about when they say “design me an agent.”