E EidosAGI

Dynamic workflows

Six ways to spend an LLM well. Three of them learn.

Thesis

A dynamic workflow is not a script that runs agents. It is an orchestration that spends judgment precisely and then learns. Every one of the six designs below is the same spine bent to a different shape of work: spend reasoning where judgment lives, gate everything else for free, keep an adversary on the residue, price honesty. The story moves along two axes: how you spend the LLM, and whether the workflow remembers.

Where these came from

These six designs are not a whiteboard taxonomy. They were authored to drive real work: reconciling every figure in an operator's canonical-metrics workbook against a source-of-record warehouse, where an agent had already learned it could pass by echoing the target instead of deriving it. That story is told in Matching isn't proof. This page is its sequel: once you have a gate that grades provenance and a skeptic that refutes, how do you actually schedule the reasoning? You pick a workflow. There are six worth knowing, and they arrange themselves on a grid.

Dynamic workflows: from fixed strategy to learning The map of the whole guide as a two-by-three progression. The top row holds three static workflows that each fix a strategy: Factory Pipeline optimizes throughput, Crack and Stamp optimizes leverage, and Adversarial Duel optimizes confidence. The bottom row holds three learning workflows that get cheaper and safer every run, each accreting a persisted state file: Recipe Library accretes recipes.json, Difficulty Router accretes policy.json, and Trap Immunity accretes traps.json. A left-hand axis arrow marks the move from static at top to learning at bottom. A caption strip anchors all six to one shared spine: spend judgment precisely, gate the rest for free, keep an adversary on the residue, price honesty. OVERVIEW · DYNAMIC WORKFLOWS From fixed strategy to learning The top three fix a strategy. The bottom three get cheaper and safer every run — each accretes a state file the next run reads. cheaper · safer each run STATIC — FIXED STRATEGY 01 Factory Pipeline throughput One line per row. A free gate clears clean rows; residue pays. 02 Crack & Stamp leverage Crack one recipe, stamp it across a whole family of rows. 03 Adversarial Duel confidence Propose · refute · repair. A skeptic attacks till it holds. LEARNING — ACCRETES A STATE FILE 04 Recipe Library cheaper Reuse proven recipes; append each fresh crack — cracks rarer. recipes.json 05 Difficulty Router fewer tokens Learn which rows are hard; route effort where it pays. policy.json 06 Trap Immunity safer Record each dodge as a gate rule; the free gate catches more. traps.json THE SHARED SPINE — TRUE FOR ALL SIX spend judgment precisely   •   gate the rest for free   •   keep an adversary on the residue   •   price honesty
The six designs on two axes: how you spend the LLM, and whether the workflow remembers. The top row is static; the bottom row accretes a file and gets cheaper every run.

The shared spine

Before the six diverge, they agree. Every design is a bending of one skeleton, and the skeleton is what makes any of them safe to run against agent-authored work:

  • Spend judgment precisely. Reasoning is the expensive resource. Route it to the places where judgment actually lives, and nowhere else.
  • Gate everything else for free. A deterministic check (did a query fire, is there a hardcoded answer, does the shape match) costs effectively nothing and runs on every change. Clean work should never touch an expensive model to be certified clean.
  • Keep an adversary on the residue. An independent skeptic, told to refute rather than confirm, is spent only on the ambiguous cases the free gate cannot settle.
  • Price honesty. A self-caught mistake costs a little; a skeptic-caught mistake costs a lot. When honest self-report is the dominant strategy, the agent tells you the truth because the incentives make truth cheapest.

Hold that spine fixed. The six designs are what you get when you bend it toward throughput, toward leverage, toward confidence, and then toward memory.

Act I. Static: three ways to spend an LLM well

The first three designs solve a fixed job. None of them remembers anything between runs; each simply spends the model well for a particular shape of work. You do not tune your way from one to another. You read the work and choose. Are the rows uniform and cheap? Do they cluster into families? Is being wrong expensive? Each question points at a different design.

Factory Pipeline: when you need throughput

Use it when rows are uniform and individually cheap. A cheap model authors each row. A free deterministic gate certifies the clean ones. Only the ambiguous residue, the rows the gate cannot settle, is handed to the adversary. Clean work never touches an expensive model, so the cost of the run tracks the amount of genuinely hard work, not the number of rows.

Factory pipeline: cheap by default Every row rides one assembly line. It is authored cheaply from bronze, then checked by a free deterministic gate (row_validator.py plus story_verify.py). The gate branches: rows marked TOLD-bronze exit as done on the sage path; only PARTIAL or external rows — the ambiguous residue — take the terracotta path to an expensive LLM skeptic before reaching done. Clean rows never touch a model. Factory pipeline: cheap by default One assembly line per row. A free gate clears the clean rows; only the ambiguous residue pays for the LLM. row r bronze stub author cheap · from bronze effort: low row.py deterministic gate row_validator.py story_verify.py FREE · no LLM TOLD-bronze done verdict: TOLD PARTIAL / external skeptic LLM · adversarial verify honest external, or a dodge? verdict Clean rows exit free on the sage path; only the ambiguous residue ever pays for the LLM skeptic.
Factory Pipeline: cheap author, free deterministic gate, adversary only on the residue the gate cannot settle.

Crack & Stamp: when you need leverage

Use it when rows cluster into families that share a recipe. Spend the expensive reasoning once: crack the recipe on a single representative row, understand exactly how that family is derived, then stamp the recipe across every sibling. The costly thinking is paid for once and reused dozens of times; a lightweight audit watches for drift so a member that does not actually fit the family gets caught rather than stamped anyway.

Crack and stamp: leverage a recipe across a family A recipe family enters on the left. One representative row is cracked once by a strong agent at high effort, producing a structured recipe. That single recipe fans out in parallel to every sibling row as a cheap, low-effort stamp, each validated to PASS and TOLD-bronze. A single story_verify then audits the whole family together, flagging any row that is not TOLD or where the recipe mis-fits, before the family is marked done. One expensive crack is reused across the family; one verifier catches the drift. Crack once, stamp the family Pay for reasoning once on one row, reuse it mechanically across siblings, and let one verifier audit the family for drift. FAMILY CRACK STAMP VERIFY DONE family roll_off_rev rep row22 members 23 · 24 · 25 · 26 rep crack strong agent · row22 effort: high → RECIPE table·filters·sign·seeds reuse recipe parallel · low effort row23 TOLD-bronze row24 TOLD-bronze row25 TOLD-bronze row26 TOLD-bronze story_verify all verify family story_verify all flag drift / mis-fit TOLD done family: TOLD leverage: crack once, stamp the family One high-effort crack is reused across every sibling as a cheap, parallel stamp, then a single story_verify audits the whole family for drift.
Crack & Stamp: pay the expensive reasoning once on a representative, stamp it across the family, audit for drift.

Adversarial Duel: when being wrong is costly

Use it when a wrong answer is expensive and confidence has to be earned. The author proposes; the skeptic refutes with live queries against the source; the author repairs; the loop runs until the skeptic can no longer break the claim. It is the slowest of the three and the surest. You reserve it for the rows where the cost of being wrong dwarfs the cost of the reasoning.

Adversarial duel — propose, refute, repair A per-row confidence loop. A proposer derives a row from the bronze source-of-record and claims TOLD. A refuter attacks it with live bronze queries and defaults to refuted when uncertain. Three exits leave the refuter: not refuted goes to CONFIRMED; refuted goes to a repair step that re-derives properly or declares the row external with the evidence query it demanded, then loops back to be re-attacked; after three rounds still refuted, the row is handed to a human as unsettled. The loop runs until the skeptic cannot break the row or the row is proven external. Propose, refute, repair — until it can’t be broken Each row is attacked with live bronze queries; it settles only when the skeptic gives up or external is proven. claim TOLD not refuted skeptic gives up refuted round < 3 re-derived, or external + proof still refuted after 3 rounds derive from bronze live bronze queries Propose derive row from bronze write file · claim TOLD Refute query bronze for a mismatch, a hidden hardcode, a dodge default: refuted if uncertain CONFIRMED skeptic can’t break it Repair derive properly, or declare external WITH evidence query Human unsettled · needs a call bronze source-of-record Loop until the skeptic can’t break the row — or it’s proven external, with the query that proves it.
Adversarial Duel: propose, refute with live queries, repair, loop until the skeptic cannot break it. Slowest, surest.

Act II. Learning: cheaper and safer every run

The turn is memory. The static three do the job; they do not make the next job easier. The learning three each accrete a single file, and that file is what turns a workflow into a system. Same spine, same shapes of work, but now every run leaves the next run cheaper, and every caught mistake leaves that mistake impossible.

Recipe Library: memory of solutions

The library is a file, recipes.json. Before authoring a row from scratch, the workflow retrieves a proven recipe for that shape of work. A hit solves the row for the price of a lookup. Only a miss pays for a fresh crack, and that crack is written back to the library. The more runs accumulate, the more first-try solves you get, because the library has already seen this shape before.

Recipe library that grows every run A learning loop around a growing recipes.json store. Each row reads the library and retrieves the closest proven recipe. On a match the recipe is applied cheaply and the row is done. On a miss a fresh recipe is cracked at higher cost, the row is done, and the newly cracked recipe is appended back into recipes.json. The library grows every run, so more rows solve on the first try over time and each run costs less. A recipe library that grows every run Retrieve the closest proven recipe first; crack fresh only on a miss — then append it, so cracks get rarer and each run costs less. learning store recipes.json +1 per crack read Retrieve closest by section / tag / label cheap similarity best match? confidence hit miss Apply recipe reuse proven cheap · first try Crack fresh derive from bronze expensive · LLM solved solved done append new recipe → library grows Every miss teaches the library — more rows hit on the first try each run, so cracks get rarer and each run costs less.
Recipe Library (recipes.json): retrieve a proven recipe before authoring; only a miss pays for a fresh crack, then writes it back.

Difficulty Router: memory of effort

The router is a file, policy.json. A bandit learns which strategy to spend on which difficulty of work. Cheap strategies win the easy rows; the expensive ones are held back for the rows that genuinely need them. Over runs the policy sharpens, so the workflow stops paying duel prices for factory work and stops trusting factory work with duel-grade rows.

Difficulty router — a bandit that concentrates effort where it pays An epsilon-greedy routing policy reads per-section arm statistics from a policy.json learning store, then routes each row along a cost ramp to one of three strategies: easy sections get a cheap stamp (sage), medium sections get cracked (brass), and the hard few get an expensive propose-and-refute duel (terracotta). Each outcome increments the section's arm statistics and is written back into policy.json, so effort concentrates where it pays and the policy sharpens each batch. Effort routes to where it pays A bandit stamps easy sections cheaply and reserves the costly duel for the hard few. each row read policy[section] easy medium hard update policy[section][arm] · s += ok, n += 1 policy.json section → arm {s,n} Rows each carries a section class Route ε-greedy bandit exploit best arm explore 1-in-5 stamp apply known recipe · validate cheap · low effort crack re-derive from bronze · validate medium effort duel propose ⇆ refute until told expensive · high effort Outcome solved? · TOLD? Cheap stamps on the easy sections; the costly duel reserved for the hard few — every outcome sharpens the policy, so tokens per solve fall.
Difficulty Router (policy.json): a bandit routes effort by difficulty; cheap strategies win easy work, expensive ones are reserved for hard.

Trap Immunity: memory of failure

The immunity is a file, traps.json. Every cheat the adversary catches becomes an antibody: a warning injected into the proposer's context so it does not try that trick again, and a new free check added to the deterministic gate so the same failure is caught for zero cost forever. The workflow builds an immune system out of its own history. A cheat the skeptic caught once at full price can never pass again.

Trap immunity — the gate that immunizes itself A learning workflow drawn as an immune system. Antibodies from the traps.json store are injected into the propose prompt so it avoids known traps. The refuter passes a clean row through to done. A new failure it catches is immunized — appended to traps.json and codified as a new deterministic story_verify rule — which flows back into the store so the free gate gets stronger and the same cheat never passes twice. Trap immunity Every caught cheat becomes a permanent antibody. The same failure never passes twice. learning store traps.json antibody store cheat · dodge · gate-bug Propose derive row from bronze avoid known traps Refute against live bronze seen before? · gate blind spot? Done TOLD verdict Immunize + append entry to traps.json + add deterministic story_verify rule re-run the free gate to confirm inject antibodies candidate row clean NEW failure codified → free gate gets stronger traps.json + story_verify grow stricter — the free gate catches more, the LLM refutes less over time.
Trap Immunity (traps.json): every caught cheat becomes an antibody, a warning to the proposer plus a new free gate check. The same failure never passes twice.

The three files are the whole difference between a workflow and a system:

what each learning design accretes
recipes.json   →  memory of solutions   →  more runs, more first-try solves
policy.json    →  memory of effort      →  effort matched to difficulty
traps.json     →  memory of failure     →  a mistake caught once is caught forever

The moral: layer, don't pick

You do not choose one of the six and live with it. You layer them. Start static, matched to the shape of the work in front of you: a factory for uniform rows, crack-and-stamp for families, a duel for the rows you cannot afford to get wrong. Then, as the job repeats, add learning: a recipe library so solutions stop being re-derived, a router so effort stops being misspent, trap immunity so caught cheats stop recurring.

Static gets the job done. Learning makes the next job cheaper and the next mistake impossible. The endgame is trap immunity: a workflow that can never again make a mistake it has already caught. That is the point of spending judgment precisely and writing down what you learn, not a faster run today, but a run next quarter that is both cheaper and strictly safer than the one you are looking at now.

Related
Case Study: Matching isn't proofCase Study: Enterprise ApprovalThe DAG of AIContracts, Not Skills