Part 4 — Orchestration

In Part 1 you wrote a loop.

for step in range(1, self.max_steps + 1):
    reply = self.client.complete(...)
    ...

That loop is a real agent, and for a large class of problems it is the right answer. One model, one context window, one tool belt, one thread of control. Ship it.

Then the requests get bigger.

A ticket arrives that needs the order record, the refund policy, the customer-facing wording, and the account history — four lookups that have nothing to do with each other, run one after another because a loop only does one thing at a time. A run needs to pause for a human approval that will not arrive until Tuesday, and your loop is a Python function holding everything it knows in a local variable inside a process that will be redeployed on Monday. A single flaky vendor API takes down a trajectory that was ninety percent finished, because you had no way to say “this step may fail; here is what to do instead.” The context window fills with forty kilobytes of intermediate junk, and the model that was sharp on turn two is confused on turn nine. Something goes wrong at 2 a.m. and the only artifact you have is a flat list of messages with no structure that tells you which part of the work failed.

None of those are model problems. They are all control-flow problems, and they all live in the orchestration layer — the part of the system that decides what runs next, holds the state, enforces the limits, and cleans up when something breaks.

Part 4 is about building that layer properly.

What this part covers

Chapter 1 — Control flow: loops, graphs, and state machines. The structures agent control flow actually takes, from first principles. Why the bare loop hits a ceiling, and where exactly that ceiling is. Then the graph model that has become the production default — nodes, edges, conditional edges, shared state with reducers, and the superstep scheduler that makes parallelism deterministic. By the end you will know what LangGraph and its relatives are doing under the hood, which means you will be able to debug them. The chapter closes with durable execution — why a long agent run needs to survive a process restart, and what that costs — and with an honest test for when a plain state machine beats an agent loop entirely.

Chapter 2 — Mini-project 6: build a workflow engine. You write the engine. About two hundred lines, no framework, supporting sequential chaining, conditional routing, parallel fan-out and fan-in, typed shared state with declared reducers, per-step retry and recovery, and a hard budget on supersteps, node runs, and wall-clock time. Built in versions, each one added because you watched the previous one fail. Everything runs offline and every output in the chapter is real terminal output. Then the same workflow written in LangGraph, so you can map every piece you built onto the tool you will probably use at work.

Chapter 3 — Multi-agent systems: when one agent isn’t enough. The honest version. Multi-agent architectures are the most over-recommended pattern in this field, and most of the systems described as “a team of agents” are one agent with extra network hops and a bigger bill. This chapter gives you three tests for when the split genuinely pays, four topologies with their real trade-offs, a precise account of what a handoff has to carry, and the failure modes that only appear once you have more than one agent — cascading errors, duplicated work, diffused responsibility, and context lost at the boundaries. Plus the arithmetic: what parallel workers actually do to your cost and your p99.

Chapter 4 — Mini-project 7: build a multi-agent system. An orchestrator-worker system on top of the engine from Chapter 2. A supervisor decomposes a request into sub-tasks, dispatches them to specialist workers in parallel, collects distilled reports rather than raw transcripts, and synthesizes an answer. With an explicit handoff packet, per-agent step budgets and tool allowlists, and a failure path where one worker’s backend is down and the supervisor recovers into a degraded but truthful answer. The workers draw their tools from three separate MCP servers over real stdio subprocesses, which is where Part 2 comes back.

What you will have built

Two artifacts, both runnable.

A workflow engine with typed shared state, conditional routing, deterministic parallel execution, per-step error policy, and enforced budgets. It is small enough to read in one sitting and structurally the same as what the frameworks give you, which is the point: after writing it, a LangGraph stack trace stops being weather and starts being code.

A multi-agent system built on that engine, wired to multiple MCP servers, that decomposes, fans out, fails partially, and recovers.

A note on scope

This part builds machinery, not a pattern catalogue. There is a companion repository — the agentic-ai-evaluation-guide — with a twenty-one-pattern design-patterns playbook covering reflection, planning, iterative refinement, ensembling, and the rest, in far more depth than would fit here. Read that for the what. This part is the how: the engine those patterns run on.

How to read it

Chapters 1 and 3 are prose; read them anywhere. Chapters 2 and 4 are keyboard chapters. Type the code, run each version before reading why it is wrong, and resist the urge to skip to the finished file — the intermediate failures are the entire argument for the final design.