Where to Go Next

The agent is a service. It has a deploy, a pager, a bill, a data retention policy and an on-call rotation, and roughly three quarters of the work of running one is the ordinary craft of running services — which this book did not teach, because other courses in this catalogue teach it properly and Chapter 13 would have doubled in length repeating them.

So this is the handoff page: what to read next, what to build next, and the two directions the book left alone on purpose. It ends with three things worth doing in the first month, all of which are useful even if you never build another agent.

A quality regression is running right now and the error rate is flat, because nothing has actually failed→Observability Deep Dive

The tools are already exposed and nobody has written down what a fully steered run could do with them→CyberSecurity Deep Dive

The sandbox is a sentence in a design document rather than a boundary anything enforces→Linux Deep Dive

The loop runs on somebody's laptop and has to ship somewhere reproducible→Docker Deep Dive

Checkpointed long runs need a worker pool that survives a node going away mid-turn→Kubernetes Deep Dive

The sampling in Chapter 2 or the hallucination discussion in Chapter 8 read as received wisdom rather than mechanism→Machine Learning from Zero

You want to use the finished coding agents well, rather than build the machine underneath them→Planned, not written

None of the above, and you have a month — the three that pay whether or not an agent is on your roadmap→An eval set, one traced run, a threat model

The Ordinary Half

Everything the agent inherits from being a service is somebody else's chapter. Chapter 13 applied spans and SLOs to a component whose output is non-deterministic, and assumed you knew what a span was. Chapter 12 applied threat modelling to a component whose input is attacker-written prose, and assumed you knew what a threat model was. Chapter 11 put a sandbox around code the model wrote and assumed you knew what a container boundary buys. The table below is where those assumptions come from.

Course	What the agent inherits from it
Observability Deep Dive	Spans, metrics, SLOs and alerting — Chapter 13 applied them to model calls and never taught them
CyberSecurity Deep Dive	Threat modelling and the security canon that Chapter 12 applied to a component breaking its assumptions
Docker Deep Dive	Images, builds and the runtime your loop and its sandbox actually ship in
Kubernetes Deep Dive	Scheduling and the worker pool that Chapter 11's checkpointed runs live in
Linux Deep Dive	Processes, filesystems and the isolation a sandbox depends on to mean anything

Read that as an argument about where the agent lives rather than as a reading list. An agent that gets its own deployment pipeline, its own dashboards, its own runbook conventions and its own on-call rotation is a second operational practice for one service, maintained by people who already have one. Fold it into what your team already runs: same deploy, same alerting stack, same incident process, same retention rules. The parts that are genuinely different — a non-deterministic component in the control flow, a quality regression that shows flat error rates, a blast radius defined by a tool surface — are the parts this book spent fourteen chapters on, and they fit inside the operational practice you already have rather than beside it.

The Model Half

One layer below the API call is Machine Learning from Zero, which covers what a language model is and why it behaves the way it does: tokens, training, why the same prompt gives two different answers, why a confident answer and a correct one are unrelated properties. This book assumed all of it and never re-taught it. Read it if the sampling behaviour in Chapter 2 or the hallucination discussion in Chapter 8 felt like received wisdom rather than mechanism.

One correction belongs here, because it is the most common wrong turn taken after a book like this. Fine-tuning shapes behaviour and does not add knowledge. Training on five thousand resolved Sundry tickets would make the agent write in the support team's register, hold the output format without being asked, and choose between overlapping tools more reliably — all real gains. It would not teach it the seller supplement edited on Tuesday, because that fact is not in the weights and cannot be put there on a weekly cadence. Grounding problems are retrieval and tool problems, and they stay that way. A tuned model is also a version you own the lifecycle of: it needs re-tuning when the base model moves.

The Applied Half

The third direction is agentic coding tools as a category — the finished products that write and edit code in a repository. That is a different book, about using them well where this one was about the machine underneath: the same ladder as how containers work against how to run Docker. A course on it is planned for this catalogue and does not exist yet, so treat this as a plan rather than a link. What is worth saying now is that you are unusually well placed to use those tools, because you know what the loop under them is doing: why the wrong tool was a schema-description problem, why the lost context was a compaction decision, and why a permission prompt is the only thing between an instruction in a file and a command on your machine.

What to Build Next in the Product

The second agent is usually a worse target than it looks and a better one than the alternatives, provided you pick it for blast radius rather than for ambition. Internal tools are the strongest second case: an agent over finance's reconciliation work or Sundry's 210-ticket seller-onboarding queue has the same tool discipline, a fraction of the exposure, and users who report a failure precisely instead of writing an angry paragraph. A bigger customer-facing agent as a second project spends the credibility of the first one on a system nobody has evaluated yet.

Reuse the eval discipline before the code. Copying the first agent's loop gets you its prompt, its context layout and every assumption baked into both, which is a head start on a system with a different tool surface and different failure modes. Copying its discipline — a graded case set built from real cases, deterministic assertions before any judge, a rubric with anchors, a trace format, an intent record before every side effect, a ceiling in the dispatcher — gets you the thing that actually made it work. The tooling is shared: one trace format, one eval runner, one dashboard. The prompts and the tool surface are not, and pretending otherwise is how a second agent inherits the first one's incidents.

A Reading and Practice Path

Three things are worth doing in the first month after this book, and all three are useful whether or not an agent is on your roadmap. Build an eval set for something you already run. Forty real cases with graded outcomes, taken from production rather than invented, on any system that makes decisions — a classifier, a rules engine, a support macro. Sundry's took two people three days and was the single change that redirected everything after it. You will learn what your current system actually does, which is rarely what the dashboard says.

Trace one production run end to end. Every model call, every tool call, the token counts, and the exact request as sent. Most teams find something in the first hour: a carrier result eleven hundred tokens long being re-sent on nine consecutive turns, a system prompt with two rules that contradict each other, a retry nobody knew was happening. If you have no agent in production, trace whatever calls a model in your codebase today — the finding is usually the same shape.

Write the threat model for the tools you have already exposed. One page: which tools exist, whose credentials they run with, what a fully steered run could do with them, and what undoing that costs. This is the cheapest item on the list and the one most often deferred, because the tools are already exposed and nothing has happened yet. Sundry's version is a table with nine rows and one sentence per row, and writing it is what turned Chapter 12 from a worry into a blast-radius statement: a steered run can move at most $150, only to the verified customer on the ticket in front of it, only once, and every attempt is in the run record.

What you can build now is specific. A loop around a stateless model call, with a tool surface you designed, a context you assemble deliberately, retrieval that carries provenance, a turn limit, a spend ceiling, an intent record, scoped credentials, an approval gate, a trace, an eval set and a rollout procedure. On a queue the shape of Sundry's, that is two engineers for about eleven weeks to something in production, six cents a ticket in model spend, roughly a day and a half a week to keep running, 88% of the work handled and 6% going to a person with a summary attached.

And here is what the next model release will not rescue. If your tools are not scoped, a better model steers more competently into the same actions. If instructions and data share a channel — and they do, in every API in this field — a better model follows a hostile instruction more fluently, not less. If a task needs twenty steps to all succeed, per-step accuracy has to reach numbers nobody has published before the compounding stops deciding the outcome. And if you have no eval set, a better model changes your product in ways you cannot see, in either direction, and you will find out from a customer. Those four are properties of the interface and of the arithmetic rather than of the model, and the loop is the only place any of them gets fixed — which is why this book made you write it yourself.