Chapter 03 · Section V · 9 min read
3.5 Codifying the cycle: dynamic workflows
When a cycle's shape stabilises, write it down as code — not as a prompt. Workflows are the rerunnable script version of a working loop.
The first time you build a loop, the cycle is fluid. The model decides what to do next each turn, based on what the last turn produced. That’s fine for exploration. But once the cycle has stabilised — you’ve run it dozens of times, the shape is the same every time — you can turn it into a workflow: an ordered script that runs the same steps in the same order, with model calls used only for the judgement-heavy parts.
The two shapes
A dynamic cycle. Each turn, the model looks at the state, picks a tool, gets a result, decides the next tool. The order is emergent. Flexible, adaptive, expensive. Every turn is a model call.
A codified workflow. The order is written down: “step 1: extract, step 2: classify, step 3: verify, step 4: file.” Each step calls whatever function is right — sometimes a model call, sometimes an ordinary function. The model is used only where judgement is genuinely needed. Cheaper, faster, more predictable.
Both are loops. The difference is where the loop’s structure lives — inside the model’s decisions, or inside your code.
When to promote from dynamic to workflow
Watch for these signals:
- The last 20 cycles took the same steps in the same order. The model is discovering the same plan every time. Just write it down.
- The costs are eating you. A workflow with 3 model calls per cycle is cheaper than a dynamic cycle with 15.
- The failure modes are consistent. Every failure happens at the same step. That’s much easier to fix in a workflow (change step N) than in a dynamic cycle (change the whole plan).
- You need predictability. Compliance, audit trails, reproducibility. A workflow can be reasoned about; a dynamic cycle has to be run to be understood.
When NOT to promote
- The shape genuinely varies. If cycle 1 needed 5 steps and cycle 2 needed 12, you don’t have a stable shape yet. Codifying prematurely locks in a rigid workflow that will feel wrong every time the task diverges from the assumed shape.
- You’re still discovering the problem. The first 20 cycles of a new loop are exploration. Locking in a workflow before you understand the problem freezes the wrong pattern.
The right time to codify is after the shape stabilises, not before.
What a workflow looks like
Concrete example — a ticket-triage cycle, first as a dynamic loop and then as a workflow.
Dynamic:
Give the model: the ticket, the reusable knowledge, tools for
read_customer_history, classify_ticket, draft_reply, request_approval.
Model picks tools in whatever order makes sense per ticket.Workflow:
Step 1: Load ticket + customer history (deterministic function; no model).
Step 2: Classify — one model call, returns label + confidence.
Step 3: If confidence low → escalate to human queue; end.
Step 4: Look up canned response template by label (deterministic).
Step 5: Draft personalised reply — one model call, using template + history.
Step 6: Verify reply against checklist — one model call (verifier).
Step 7: If verifier passes → post to review queue.
If verifier fails → escalate.The workflow makes explicit what the dynamic version had to rediscover every cycle. It’s cheaper (three model calls vs an average of ten), more predictable (same shape every ticket), and easier to change (edit step 4 without touching anything else).
The hybrid: workflow with dynamic pockets
Real loops often mix. The overall shape is a workflow — the top-level “extract, classify, verify, file” is fixed — but individual steps can be dynamic. Step 5 above (“draft personalised reply”) is a dynamic pocket: within that step, the model can freely decide how to structure the reply, use whatever tools it needs to enrich, and self-correct.
This is usually the right shape for anything non-trivial. Top-level structure in your code; per-step judgement in the model. Neither pure end is optimal.
What you gain from codification
- Cost. Fewer model calls per cycle.
- Speed. Deterministic steps run in milliseconds, not seconds.
- Debuggability. A failure at step 3 is a step-3 problem. Fix step 3.
- Reviewability. Anyone can read the workflow. The dynamic cycle’s logic exists nowhere concrete.
- Testability. You can unit-test individual steps. You cannot unit-test “the model decides.”
What you lose
- Flexibility. A workflow does exactly the steps you wrote. If a new kind of ticket needs a new step, you have to update the workflow.
- Fewer surprises. Dynamic cycles occasionally do something smarter than you’d have coded. Workflows never do.
The trade is usually worth it. Loops that stay dynamic forever tend to be either research prototypes or unreliable production systems.
Check your understanding
Quick check
—