What explicit state buys — and what it costs
Lesson 2 of 5 in State Machines vs LLM Loops: Who Owns Control Flow?.
“Explicit state” means three concrete things: the system’s possible situations have names (awaiting_approval, refund_issued), the moves between them are enumerated transitions, and the current situation is a serializable object you can write to a database — not an implicit vibe smeared across a context window.
That discipline is expensive, so be precise about what it buys. Four dividends, each of which becomes an operational superpower the moment your agent touches production.
Replay
Re-run any failed run and get the same path. When transitions are code, replaying a run from its recorded inputs reproduces the exact sequence of states — so you can bisect a failure, fix the bug, and prove the fix against the original run.
Contrast the free loop: non-determinism in the model plus a context that accumulates differently on every attempt means a “replay” is really a new run that may never hit the bug again. To replay a loop faithfully you must record and stub every model response — possible, but now you’re rebuilding what explicit state gave you for free.
Checkpointing
Persist state at every boundary; resume from anywhere. A crashed process restarts at step_7, not from zero. A human-in-the-loop approval gate can pause a run for three days and resume it on click, because “where we were” is a row in a table, not a live process’s memory.
This is the idea the durable execution world (Temporal and friends) industrialized — Pydantic AI, for one, ships first-party Temporal, DBOS, Prefect, and Restate integrations precisely so agent steps survive crashes and waits.
Audits
Answer “what state was this run in, and who approved the transition?” — the question every regulator, incident reviewer, and refund-dispute lawyer asks. An explicit state history is the audit trail: named states, timestamps, actor on each transition.
A trace of a free loop tells you what happened; it can’t tell you what was allowed to happen, because nothing enumerated that. Auditability is the single most common reason regulated teams get pushed down-spectrum toward explicit state.
Testable transitions
Unit-test the skeleton without a model in the room. Each transition is a function: given state and event, assert the next state. You can enumerate coverage — every state, every event, including the weird ones — and run the whole suite in milliseconds in CI.
The model calls inside states still need evals, but you’ve shrunk the untestable surface from “the whole system” to “the judgment inside each node”. That separation is the foundation the deploy-and-rollback story in agentops is built on.
Now the bill. Rigidity: the world must fit your enumerated states, and real inputs are creative — every state machine eventually meets a situation its authors never imagined, and without an explicit exception state it dead-ends or, worse, misfiles. Upfront design: you pay the enumeration cost before the first run, when you know the least about the task. Change amplification: each new capability is graph surgery — new states, new transitions, new tests — where a loop-based agent might have absorbed it with a sentence in the system prompt. State explosion: model real-world concurrency and exceptions honestly and the state count multiplies until nobody can hold the graph in their head.
The engineering question is never “is explicit state good?” It is “which parts of this task are stable enough to be worth enumerating?” — which is exactly where the next two lessons go.
Key terms: checkpointing, replay, durable execution, trace, approval gate
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.