One request, end to end

Lesson 1 of 5 in Orchestration End to End: One Request Through the Whole System.

You now know the patterns individually: routing, fan-out, orchestrator–worker, supervisor–worker, state machines, subagents, human gates. A real production system is four or five of them wired together — and nearly every production surprise lives at the joins, not inside the patterns. The pattern modules cannot show you the joins, because each one is a module about a pattern. This one is about the wiring.

So we will follow a single request all the way through a system that is deliberately ordinary. No pattern here is new to you. What is new is seeing them adjacent.

The system we will trace: an order-exception resolver

A B2B distributor receives supplier and customer exception mail. One message arrives:

“Order 88213 arrived short by 4 units of SKU-4471. I need the replacement on site before Friday or we stop the line.”

What the business needs to happen: identify the order and the shipment, establish whether the shortage is real, find out whether the units can physically arrive by Friday, check what the customer’s contract entitles them to, propose a remedy (reship, credit, or partial), get a human to approve anything expensive, execute it, and reply — with the whole thing auditable afterwards because remedies cost money.

That is a mundane business process. Wiring it takes routing, a parallel fan-out, a delegated research task, a durable state machine, an approval gate, two side-effecting tools, and a merge. Everything in this module refers back to this one request.

The order-exception resolver, request to reply

Message arrives
Untrusted content from outside the trust boundary. Everything downstream treats it as data, never as instructions.
Classify: which exception?
A small model, structured output, fixed label set, plus confidence — and a fallback route for low confidence. Code dispatches; the model only labels.
Resolve the entities
Order 88213 → order record, shipment, SKU, customer. Deterministic lookups in code. The agent has no business guessing an order id.
Fan out: three warehouses + contract research
Independent work, so it runs concurrently: stock and lead time at three warehouses (plain tool calls), and a delegated research task over the contract PDF set.
Stock + lead time ×3
Read-only tool calls. Fast, cheap, and the branch most likely to time out — warehouse 2 is on an ERP that answers in 200ms or 30 seconds.
Subagent: remedy entitlement
A delegated task with its own context: read the master agreement and amendments, return the entitlement clause plus a citation. Isolated because the PDFs would swamp the main context.
Merge — and reconcile disagreement
The join everyone under-builds. Two of three warehouses answered; the entitlement says credit-only; the customer wants units by Friday. These conflict, and something must decide.
Propose a remedy
The model reasons over resolved facts, not raw mail: entitlement, availability, deadline, cost. Output is a structured proposal with an explicit cost figure.
Cost over threshold?
Code compares the proposal’s cost to a limit. The model does not decide whether it needs approval — that is the exact-parameters rule from the human-in-the-loop module.
Approval queue
The run suspends on a durable checkpoint and may resume hours later, on a different process, after the approver edits the remedy.
Execute: reship and/or credit
Side effects with real money attached. Idempotency keys derived from run identity, and a compensating action defined before the first call is written.
Reply and close
One message out, one audit record written to the system of record, one trace covering the whole journey.
Escalate to a human owner
The route for low router confidence, unresolvable entities, and merges that cannot be reconciled. Every branch above needs one.

Count the patterns: a router, a deterministic resolution step, a fan-out/fan-in, one delegated subagent, a state machine with a durable suspend, an approval gate, and two side-effecting executions. Every one of those is taught elsewhere on this site. The interesting engineering is in the arrows.

Every hop, the pattern it is, where it is taught properly — and the risk that belongs to the join rather than the pattern
Hop	Pattern	Taught in	The seam risk
Message → classify	Routing	Workflow Patterns	A confident wrong label is executed flawlessly downstream. The seam needs a confidence threshold and a fallback route — not a better specialist
Classify → resolve	Deterministic lookup	Tools & Tool Use	Handing the model the raw mail and the resolved record invites it to prefer the mail. Pass resolved facts forward and drop the prose
Resolve → fan out	Parallelization	Workflow Patterns	Partial results. Two of three branches returning is the normal case, and it is the case with no code written for it
Fan out → subagent	Delegation	Subagents & Context Isolation	The brief is the whole interface. A subagent given “help with this order issue” returns something unusable and expensive
Branches → merge	Fan-in	Workflow Patterns	Concatenation masquerading as a merge. When availability and entitlement disagree, something must resolve it — usually code with an explicit precedence rule
Propose → gate	Approval gate	Human in the Loop	Gating on the model’s opinion that approval is needed. Code evaluates the threshold, and the human approves the exact parameters that will execute
Gate → resume	Checkpoint + resume	Deploying & Versioning	Resuming into a changed world: prices moved, stock is gone, the approver edited the amount. The resumed run must re-validate, not replay blindly
Execute → reply	Side effects	Reliability Plumbing	A retry that ships twice. Idempotency keys derived from run identity, plus a compensating action for the half-completed case

Key terms: orchestration, fan-out / fan-in, delegation, checkpointing, approval gate

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.