Outcome focus: Reader can distinguish statechart formalism from durable execution, pick the right runtime for agents and long-running workflows, and model document-heavy product lifecycles with explicit states, transitions, checkpoints, and ownership.
state machinesdurable executionagentsworkflow enginesxstatetemporallanggraph
An agent passed the demo and failed after lunch.
The first run read a document, called a model, asked for approval, and waited. The approver came back two hours later. During the wait, the worker was recycled. When the process resumed, the harness rebuilt the chat history, inferred that the approval had happened, and ran the tool again. The tool was not pure. It had already created a draft artifact before the restart.
The second artifact looked plausible enough to hide the failure.
The problem was not that finite state machines were missing from a computer-science lecture. The problem was that a real workflow had no durable answer to four ordinary questions: where are we, what already happened, what is allowed next, and what can be retried without replaying side effects?
As of May 16, 2026, the state-machine story is not "state machines are new." They are not. The story is that state-machine thinking has become one of the dominant ways teams are trying to make AI agents, workflow engines, and complex app logic reliable enough to survive production.
This is the field update to the earlier four-part state-machine series on this site:
- Part 1 covered the UI and domain-logic shape: invalid states, boolean explosions, guards, and explicit transitions.
- Part 2 covered XState 5, actors, and the TypeScript statechart argument.
- Part 3 separated Python statechart libraries from durable execution with LangGraph and Temporal.
- Part 4 compared how different runtimes change which state-machine idioms are honest.
The May 2026 update is that infrastructure vendors and agent frameworks are converging on the same shape from different directions. The names differ: graph runtime, workflow engine, durable execution, checkpointing, actor orchestration, human-in-the-loop. The common architecture is explicit state plus controlled transitions plus persistence at the boundaries where production breaks scripts.
What Changed in 2026#
Most prototype agents are written like scripts:
read input
think
call tool
maybe ask human
call another tool
return answerThat shape works until the workflow needs to pause, retry, resume, wait for a webhook, wait for a human, survive a deploy, or explain what happened after an incident. Then "just keep the conversation history" becomes a weak substitute for state.
The production shape looks different:
state = planned
event = tool_started
checkpoint
state = executing_tool
event = tool_succeeded
checkpoint
state = awaiting_approval
event = approval_received
checkpoint
state = ready_to_commitThe second version has more ceremony. It also has somewhere to put the truth. A retry can replay from the last safe checkpoint. An approval can resume a dormant run without guessing from chat history. A dashboard can show that the run is waiting on a person, not mysteriously slow. An incident review can distinguish "the model decided" from "the workflow was in awaiting_approval and received APPROVE from user u_123 at 14:03."
I have seen teams treat that ceremony as optional until the first side-effecting tool call repeats. After that, the workflow stops being "agent magic" and starts being an operations problem.
The Landscape, as of May 16#
The important current movement is not one tool winning. It is multiple tools admitting that state, persistence, retries, and observability have to be first-class.
| Tool or platform | 2026 signal | Use it when |
|---|---|---|
| LangGraph | Graphs built from state, nodes, and edges, with checkpointers and production features such as persistence, durable execution, interrupts, memory, time travel, and fault tolerance in the docs. | The workflow is agentic and needs conditional routing, loops, memory, checkpoints, human review, or controlled tool calls. |
| Temporal | Replay 2026 added Serverless Workers, Standalone Activities, Workflow Streams, External Payload Storage, and AI integrations including Google ADK and OpenAI Agents SDK support. | You need industrial durable execution across services, timers, signals, retries, versioned workers, and operational maturity. |
| OpenAI Agents SDK | The April 2026 SDK update emphasized a stronger agent harness, sandbox execution, memory, tool orchestration, and portable workspace manifests. | You want model-native agent execution with controlled sandboxes, file/tool work, and integration points for durability providers. |
| Google ADK | The May 2026 long-running-agent tutorial models onboarding as explicit session state with named steps and pause/resume cycles. | You are building Gemini/ADK agents that wait days or weeks on people, documents, or hardware. |
| Cloudflare Workflows | Workflows V2 was rearchitected for agent-triggered workloads with durable steps, sleeps, retries, approvals, and higher concurrency. Dynamic Workflows routes durable runs to tenant-provided code. | You want durable execution close to Workers, multi-tenant dynamic code, or edge-native agent/application workflows. |
| Vercel Workflows | Vercel positioned Workflows as generally available durable execution for long-running agents and backends, with steps, event logs, queues, retries, persistence, and observability. | Your app is already on Vercel and the workflow belongs near the application code rather than in a separate orchestration service. |
| AWS Step Functions | Still the mature managed state-machine service. Recent movement is practical: JSONata, variables, broader Distributed Map inputs, and observability improvements. | You want cloud-native state machines with AWS integrations, visual workflow tooling, and managed operations. |
| XState and Stately | XState remains the TypeScript statechart reference point; GitHub shows XState 5.31.1 released on May 10, 2026. Stately Sketch launched March 26, 2026 for quick visualizing and simulating machines from code. | The core problem is app behavior, UI flows, domain lifecycle logic, or statecharts that product and engineering can inspect together. |
The table hides a key split that has to stay visible:
| Question | Statechart answer | Durable-execution answer |
|---|---|---|
| What states are valid? | XState, statecharts, domain lifecycle models. | Usually a workflow schema or persisted run state. |
| Which event can move the system next? | Transitions and guards. | Step routing, task queues, signals, resumes, branch functions. |
| Can the process survive a restart? | Only if you add persistence around the machine. | Yes, if the runtime checkpoints and replays safely. |
| Can a human approve later? | Model the awaiting_approval state and event. | Persist the run, wait, and resume when approval arrives. |
| Can a tool call retry safely? | Model idempotency and allowed transitions. | Retry the isolated activity or step without replaying unsafe prior work. |
Statecharts name the valid lifecycle. Durable execution keeps that lifecycle alive when the process, machine, deployment, or user disappears for a while. Treating one as a substitute for the other is how teams get surprised.
LangGraph: Agent Logic as State Plus Edges#
LangGraph's Graph API overview describes agent workflows as graphs built from three concepts: state, nodes, and edges. State is the current application snapshot. Nodes perform work. Edges decide what runs next. That sounds simple, but it is the right simple.
The useful detail is that LangGraph exposes production capabilities around that state: persistence, durable execution, fault tolerance, interrupts, time travel, and memory. A graph can pause before a sensitive node, persist its state, wait for a human, and resume without the model re-deriving the path from old messages.
That is why LangGraph belongs in the agent column rather than the generic statechart column. It is not trying to be XState. It is trying to make LLM and tool loops inspectable and recoverable.
The failure mode it addresses is specific: the agent run is not a single chat completion. It is a process. Processes need checkpoints.
Temporal: Activities as the Durable Boundary#
Temporal's Replay 2026 announcements read like a checklist of what agent teams discover after the first real deployment: serverless workers for easier compute, standalone activities for durable job processing, workflow streams for live LLM/tool updates, external payload storage for large AI inputs and outputs, and integrations with Google ADK plus the OpenAI Agents SDK.
The architectural point is bigger than the product list. Temporal wants each LLM call and tool call to become a durable activity. That means a failed tool call can retry with the runtime's retry policy, while the workflow does not lose the fact that earlier steps completed. It also means the operator can ask a concrete question: which activity failed, how many attempts happened, and what state is the workflow in now?
That is a cleaner operating model than one giant agent loop wrapped in a retry.
The tradeoff is weight. Temporal is an execution platform. You pay for a server, workers, task queues, worker versioning, operational literacy, and a mental model that is stricter than normal application code. For a serious business workflow that can run for hours or days, that price is often lower than the hidden price of rebuilding durability yourself.
OpenAI, ADK, and the Return of the Harness#
OpenAI's April 2026 Agents SDK update frames the agent not as a chat endpoint but as a harness around files, tools, memory, sandbox execution, and workspace manifests. The state-machine angle is implicit: a long-running agent needs a durable execution surface, not just a better prompt.
The post's sandbox and manifest focus matters because agents now do work in environments: inspect files, run commands, edit code, call tools, write artifacts. Once an agent has a workspace, the execution state is not only messages. It is files, tool outputs, permissions, mounts, and the run plan.
Google's ADK long-running-agent tutorial makes the state-machine shape explicit. The example onboarding agent has named steps such as START, WELCOME_SENT, DOCUMENTS_SIGNED, IT_PROVISIONED, HARDWARE_DELIVERED, and COMPLETED. It can wait while documents are signed, wait again while hardware ships, and resume from session state rather than asking the model to infer progress from chat history.
The caution is the one Part 3 already made: state is only durable if the backing store is durable. A state enum in memory is not a recovery strategy. A session table, event ledger, workflow history, or checkpoint store is the recovery strategy.
Cloudflare and Vercel: Durable Execution Moves Into App Platforms#
Cloudflare's Workflows V2 post is unusually direct about why this is happening now: workflows are being triggered less by humans clicking slowly and more by agents creating work at machine speed. Cloudflare's answer is a durable asynchronous engine where steps are independently retryable, runs can pause for human approval, and instances survive failure without losing progress.
That is state-machine thinking expressed as platform infrastructure.
Cloudflare Dynamic Workflows adds another wrinkle: the workflow code itself can vary per tenant, agent, or request. The durable engine still owns retries, hibernation, sleeps, approvals, and resume semantics, but execution can route back into tenant-provided code later. For multi-tenant platforms and agent systems where code is generated or supplied dynamically, that is a serious new primitive.
Vercel Workflows makes a similar argument from the application-platform side. The gap between local prototypes and production is failures, restarts, and traffic. Vercel's model uses steps, an event log, queues, persistence, retries, and observability while keeping orchestration close to app code.
I would not choose between Cloudflare, Vercel, Temporal, or Step Functions based on branding. I would choose based on failure mode and operating home:
- If the workflow belongs inside an existing edge/app platform, Cloudflare or Vercel may fit the team shape.
- If the workflow cuts across services and needs deep durability semantics, Temporal is the heavier but stronger center.
- If the organization already runs on AWS and wants managed visual state machines with AWS service integrations, Step Functions is still the boring answer.
Boring answers are underrated when the thing being orchestrated affects money, health, legal documents, or customer trust.
AWS Step Functions: Less Fashionable, Still the Baseline#
AWS Step Functions did not need an AI rebrand to be relevant here. It has been "state machines as a managed service" for years.
The current Step Functions direction is practical rather than flashy. AWS's recent-launches page shows the newest listed launch on September 18, 2025, focused on broader Distributed Map data-source support and observability improvements. The November 2024 launch brought variables and JSONata into Step Functions. The JSONata documentation shows the operational value: less awkward JSONPath plumbing, clearer transformation surfaces, and incremental adoption by state.
That is the mature-platform version of the same movement. Not "agents." Not "vibes." Workflows with state, transformations, failure handling, observability, and managed operations.
XState and Stately: The App-Logic Side Still Matters#
The agent/platform news should not make app-state work look smaller. The original reason statecharts pay off still holds: invalid UI states are expensive, form workflows grow branches, onboarding flows gain exceptions, and domain lifecycles outgrow boolean flags.
XState's docs still describe the JavaScript/TypeScript library around state machines, statecharts, event-driven programming, and actors. GitHub lists XState 5.31.1 as the latest release on May 10, 2026. Stately Sketch, published March 26, 2026, is a small but meaningful signal: paste machine code, see an interactive diagram, simulate transitions, and share it.
That is not durability. It is inspectability.
For product teams, inspectability is often the missing bridge. Product, design, and engineering can look at a statechart and argue about the lifecycle. They cannot usefully argue about five scattered booleans and three effects unless everyone wants to spend the afternoon in source code.
The Decision Rule I Would Use Today#
Start with the failure mode, not the tool.
| If the problem is... | Reach for... | Check before you commit |
|---|---|---|
| Invalid UI states, form wizards, checkout flows, onboarding screens, domain lifecycle rules | XState, statecharts, or a small explicit machine | Does it need durability, or only valid transitions? |
| Agentic routing, tool loops, memory, human review, conditional LLM/tool paths | LangGraph or an agent graph runtime | Where are checkpoints stored, and what happens after worker restart? |
| Long-running distributed work with timers, external APIs, retries, human approval, and service boundaries | Temporal, Step Functions, Cloudflare Workflows, Vercel Workflows, Azure Durable Functions | What is the idempotency model for each step or activity? |
| A one-request computation with no pause, no resume, no branch history | Plain code | Are you adding a workflow engine because the architecture feels serious? |
The last row saves teams money. Not every function wants to become a workflow. Not every form wants a statechart. The discipline earns its place when the lifecycle has branches, waiting, retry, ownership, or audit requirements.
The sharper rule:
If the workflow can pause, retry, resume, or require human approval, model it as state and run it on something that persists state.
The model and the runtime can be separate. An XState chart can describe valid transitions while Temporal runs durable activities. A LangGraph workflow can checkpoint agent state while a small domain enum records the business lifecycle. A Step Functions machine can orchestrate service calls while an internal module owns the domain rules. The work is to avoid hiding lifecycle in prompts, booleans, or async call stacks.
A Document-Heavy Workflow Example#
Document-heavy vertical software is where this stops being academic. Crop insurance, healthcare, finance, legal, and compliance workflows are rarely "submit form, done." They are closer to this:
Now make it operational:
| State | Owner | Durable checkpoint | Allowed next events | Audit requirement |
|---|---|---|---|---|
intake_started | intake system | case created, required-field snapshot | REQUIRED_DOC_ABSENT, DOCUMENT_UPLOADED | who created case, source channel |
missing_documents | producer/customer ops | missing-doc manifest | DOCUMENT_UPLOADED, CANCELLED | which documents missing, notification sent |
validation_failed | validation service | validation result, failed rules | CONTACT_PRODUCER, OVERRIDE_REQUESTED | rule version, input digest |
adjuster_review | adjuster | review assignment and triage output | REVIEW_PASSED, SEVERITY_HIGH, MORE_INFO_REQUIRED | reviewer, timestamp, evidence bundle |
underwriting_review | underwriting | underwriting packet | UNDERWRITING_PASSED, POLICY_EXCEPTION | approver, policy rule references |
approval_pending | carrier/manager | approval request | APPROVED, REJECTED, EXPIRED | signer identity, decision reason |
policy_bound | policy admin | bound policy artifact | RENEWAL_WINDOW_OPENED | final artifact digest |
That table is the artifact I would put in an architecture review. It forces the system to name ownership, persistence, allowed transitions, and audit evidence together. It also prevents a common product failure: a UI says "approved" because the model guessed the intent, while the workflow state is actually approval_pending because the signed receipt never arrived.
The first version of teams' agent workflows often misses this because the model is asked to narrate the lifecycle. Narration is not state. If a regulator, support lead, or engineer needs to know what happened, the answer should come from the workflow history and domain state, not from a reconstructed conversation.
The Practical Checklist#
Before you put an agent or workflow into production, answer these in the repo:
| Question | Acceptable answer |
|---|---|
| What are the named states? | A state enum, machine, graph schema, or workflow definition in source control. |
| What events can move state? | Transitions or routing rules with guard conditions. |
| Which steps have side effects? | Each side-effecting step has idempotency keys, activity IDs, or step IDs. |
| Where is state persisted? | Checkpointer, workflow history, event log, durable session store, or database table. |
| What happens after a worker restart? | Resume from last safe checkpoint; do not replay unsafe side effects. |
| Where does human approval live? | Explicit awaiting_approval state or workflow wait, with identity and timestamp. |
| How do you debug a bad run? | Run ID, state history, step attempts, tool outputs, and audit events are queryable. |
| What is the escape hatch? | Low-confidence, policy-flagged, or failed runs route to human review. |
If the answers are not in source control, they are probably in a prompt, a meeting memory, or one engineer's head. That is not enough once the workflow affects real users.
What to Do Differently Now#
Do not start by asking which state-machine framework is hottest. Start by writing the lifecycle down.
Name the states. Name the events. Mark which transitions need guards. Mark which steps have side effects. Mark the checkpoint after each step. Mark who owns the alert when the run gets stuck. Then pick the smallest runtime that preserves those truths under the failures your product actually has.
For a UI flow, that may be XState and a diagram in the PR. For an agent loop, it may be LangGraph with a persistent checkpointer. For a business process that waits on humans and external systems, it may be Temporal, Step Functions, Cloudflare Workflows, Vercel Workflows, or Azure Durable Functions. For a tiny two-state widget, it may be one explicit union type and no library at all.
The May 2026 lesson is blunt: production agents and long-running workflows are not improved by letting the model improvise the lifecycle. Let the model reason inside bounded steps. Keep the lifecycle explicit.
If your system can wait, retry, resume, or ask a human, draw the machine before the next tool call. Then make sure the runtime can remember it after the process dies.