Part 7 — Production Systems

Six parts, nine mini-projects, and every one of them was a component.

A loop. A tool registry. An MCP client. A memory store. A workflow engine. A multi-agent handoff. An eval harness. A tracer. A container with health endpoints in front of it. Each one was built in isolation, tested in isolation, and put down.

This part picks them all up at once.

That is a different kind of engineering, and it is worth being explicit about what changes. When you compose components, the interesting failures stop living inside any of them. Your extraction code is correct and your citation format is correct, and the system still publishes a claim that the source does not support, because nothing in either component was responsible for that property. Your budget object is correct and your agent loop is correct, and a run still burns forty dollars, because the budget was charged after the spend instead of before. The bugs move into the seams, and the seams are where you now have to do your design work.

The second thing that changes is that you have to decide what the system is. A component has an interface. A system has a promise: a research agent promises that every claim is traceable, a writing workflow promises that the same brief produces the same document, an MCP server promises that a tool which says it is idempotent is idempotent. Everything in the build follows from picking that promise and then refusing to break it.

The three systems

Production System 1 — a deep research agent. The autonomous one. You give it a question and it plans, fetches, and reads: web pages, PDFs, GitHub repositories, YouTube transcripts. It runs its tools over MCP, keeps a working memory of findings, stops to ask a human before it does anything expensive or out of scope, and produces a report in which every claim carries a locator precise enough to check — page three, paragraph four, timestamp 00:16. It has budgets on steps, fetches, tokens, and wall-clock, and it degrades into a partial answer rather than dying when it hits one. This is the flagship chapter and the longest in the book.

Production System 2 — a deterministic writing workflow. The constrained one, and deliberately the opposite of System 1. An evaluator-optimizer loop: generate, critique against an executable rubric, revise, with real convergence criteria and a lap budget. A graph workflow with typed state. A standardized output format — prose, one Mermaid diagram, one code block that is validated by running it and comparing its output to the output the document claims. And an architecture built for testing: dependency injection at every seam, a rubric you can swap, a generator you can stub. The chapter makes the determinism argument explicitly, because knowing when not to reach for an agent is a senior skill.

Capstone — design, build, and deploy your own MCP server. Your project, not mine. How to pick a scope that is neither trivial nor a swamp, a design template to fill in, and then a complete worked reference: a release-notes server with four well-designed tools, one uniform error contract, structured output, pagination, scope-based authorization, idempotency on the mutating tool, a test suite, a container, and a deployment. Plus a rubric for judging whether what you built is portfolio-ready or merely finished.

What to expect

Every line of code in this part runs offline. No API key is needed for any of it: System 1 reads a fixture corpus through the same interface it uses for live HTTP, System 2’s generator is a deterministic template writer behind the same Protocol a model would sit behind, and the capstone server ships its own data. Every terminal output block in these chapters is real output from the code as printed. Where something genuinely cannot run in a sandbox — a live crawl of a real website, a docker build with no Docker daemon — the chapter says so plainly and shows you what it did instead.

Expect these chapters to be long, and expect to type. They are not walkthroughs of finished code. Each system is built in versions, each version motivated by something the previous one got wrong, and several of the bugs you will watch get fixed are bugs that were actually in the code while it was being written — including two in a validator, which is a lesson in its own right.

Expect heavy reuse. System 1’s tools are an MCP server and client built on Part 2’s harness. Its trace format is Part 5’s tracer, and its human-gate design is Part 6’s authorization layer with the same three rules. System 2’s graph is Part 4’s engine cut down to what it needs, and its rubric is Part 5’s eval harness pointed at documents instead of trajectories. The capstone’s container is Part 6’s Dockerfile pattern. Where a chapter leans on earlier work it names the chapter, so you can feel the return on having built it.

A note on scope: these are portfolio projects

Be honest with yourself about why you are building these.

Most people reading this want one of two things: to ship an agent at work, or to have something to show that proves they can. These three systems are chosen to serve both. Each is substantial enough that finishing it demonstrates real engineering — provenance discipline, deterministic testing of a nondeterministic component, protocol design, an auth model, deployment — and small enough to finish in a weekend or two of evenings.

That means the last part of each chapter matters as much as the code. A research agent with no README, no tests, and no honest list of what it does not do is a demo. The same code with a design rationale, a test suite that runs offline in under two seconds, a documented failure taxonomy, and a paragraph explaining the trade-off you chose is a portfolio piece. The capstone chapter ends with an explicit rubric for that difference; apply it to all three.

How to read this part

Read Chapter 1 with a terminal open. It is the deepest chapter in the book, and skimming it will leave you with the impression that a research agent is a fetch loop with a prompt, which is exactly the impression it exists to destroy.

Read Chapter 2 even if you only care about autonomous agents. Its argument — that for a whole class of tasks a constrained workflow beats an agent, and the constraint is what makes it shippable — is one you will need the first time someone asks you to make an agent “more reliable.”

Then do Chapter 3 properly. Not the reference example: your own. The reference is there so you have something to compare against when yours does not work.