Module 3 · Planning, Context & Multi-agent Systems · scripted
Code at the Forks: Workflows with Minds Inside
The next question
The pipeline handled tasks whose path is a straight line. But most real work branches: this receipt follows one procedure, that one another. The moment paths must be chosen, do we finally need an agent? The second technique answers: not yet — if we can make each step's output carry the information the choice needs, in a form code can read.
The move
Keep the first technique's rule: judgment only WITHIN steps. Add one requirement to every judging step: besides its work, it must emit a STRUCTURED VERDICT — a label, a class, typed fields — that ordinary code can read. Then code chooses the path. The mind reads the world; a label crosses the boundary; a switch chooses the road.
The deep idea is a division of labor we've been circling for two
days: interpretation is expensive and belongs to the model;
comparison is free and belongs to code. A fork only looks like it
needs judgment. It needs judgment's output — and if the step
before the fork compresses its messy world into a clean verdict,
the fork itself is an if statement.
The receipt workflow
The task: process incoming expense receipts — most are routine, some need the foreign per-diem procedure, some are missing information, and a few should never be auto-processed at all. The map first:
The workflow
One judging step feeds one fork. Everything downstream of the fork is last lesson's machinery — pipelines, some of them one stage long. Now look inside the judging step, because this is where the whole technique lives:
Read this receipt. Extract the fields and classify it into exactly one: STANDARD · FOREIGN_PER_DIEM · MISSING_INFO · REVIEW. Output only the JSON.
📷 crumpled handwritten receipt, partly in Japanese, with a
faded stamp
{ "vendor": "Izakaya Tanaka (居酒屋田中)", "date": "2026-09-03", "amount": 8400, "currency": "JPY", "category": "meal", "label": "FOREIGN_PER_DIEM", "reason": "meal expense incurred abroad — per policy, foreign meals fall under per-diem, not receipt reimbursement", "confidence": 0.93 }
And here is everything the fork itself needs — worth showing in full, because its dumbness is the point:
The router, in its entirety
verdict = classify_receipt(image)
match verdict.label:
case "STANDARD": log_expense(verdict)
case "FOREIGN_PER_DIEM": run_per_diem(verdict)
case "MISSING_INFO": request_info(verdict)
case "REVIEW": human_queue.add(verdict, reason)
No prompt. No wall. No re-reading. The fork compares strings —
because the step before it already did all the understanding.Run a second receipt through, and watch the same machine take a different road — with nothing improvised:
Same instructions.
📷 pristine printed receipt — office supplies, 340 kr
{ "vendor": "Clas Ohlson Molde", "date": "2026-09-10", "amount": 340, "currency": "NOK", "category": "supplies", "label": "STANDARD", "reason": "domestic, documented, within limits", "confidence": 0.99 }
match, in microseconds. A thousand
receipts a day flow through this and the diagram never changes.
That is what repeatable means: variability lives inside the
steps, where it belongs — never in the shape of the path.Why the label is enough
Pause on why this works, because it's the technique's load-bearing insight. At an agent's fork, the navigator re-reads a whole conversation and interprets it to choose. Here, interpretation already happened — once, inside a one-step mind, with exactly the context it needed — and what reached the fork is interpretation's residue: a value from an enumerated set. The fork doesn't understand anything. It doesn't have to.
You've seen this shape before, twice, and it's worth noticing the family resemblance. The enum parameter taught the agent a tiny map of the world in five tokens. The detecting tool classified the task and routed the agent. Now the same compression routes a workflow: in every case, a judgment somewhere produces a small symbol, and the symbol does the traveling.
The label set is the contract
The forks define the labels; the labels define the judging
step's brief. Design them together:
· one label per distinct downstream path — no more
· labels mutually exclusive, or the router's order decides
· always include the honest label: REVIEW / NOT_MY_CASE —
the world will exceed your enumeration, and the label set
must have a word for that
· low confidence IS a label: route it like oneThat last pair of rules is the escape hatch again, now built into the vocabulary itself: the 1% doesn't break this design, because "I shouldn't decide this" is one of the classes the mind can output — and the router sends it to the expensive machinery, an agent or a human, with the reason attached as the brief.
Faster, cheaper — and legible
The wins from the pipeline carry over: no re-orientation tax, no deliberation at forks that have only one honest answer. But branching-by-code adds a win the loop can never offer:
What the compliance office sees
The workflow is legible. Its shape is a diagram you can print, defend to an auditor, and reason about in advance — the road network drawn completely, with minds working the toll booths but never redrawing the roads. When the work is regulated, repeated, or high-volume, this legibility is not a nicety; it is frequently the requirement that decides the architecture.
- List every judgment in the receipt workflow — then confirm none of them happens at a fork. Where did each one happen instead?
- The REVIEW label routes to a human. Argue for routing it to an
agent instead: what would that agent's wall need, and what do
the classifier's
reasonand fields become in that design?
The spectrum, filled in
Where we now stand
Each rung up buys open-endedness with cost, latency, and opacity. Climb only when the world genuinely refuses enumeration — and even then, notice how much of the task still fits on the lower rungs.
Take a branching process from your research or institution — review triage, sample intake, application screening. (1) Draw the flowchart: every fork, every downstream path. (2) Design the label set from the forks — including the honest label — and write the classifying step's full prompt with its JSON output format. (3) Write the router as real code; count its lines. (4) Feed it three inputs on paper: a clean case, a case for the honest label, and the nastiest ambiguous case you can construct. For the last: does it deserve a better label, a lower confidence threshold — or a navigator?