Tag: state machines

Why the May 2026 state-machine story is not finite automata becoming fashionable again, but durable execution becoming the reliability boundary for agents, workflow engines, and document-heavy product systems.

Outcome: 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.

Why a Go retry loop ran forever because the attempt counter lived on the loop instead of the state, and what the runtime guarantees of Elixir, Swift, and Zig change about which state-machine idioms are honest in each.

Outcome: Reader can pick the right state-machine idiom for their language by recognizing which runtime guarantees the language ships, distinguish a true finite-state machine from unidirectional data flow, and avoid the cross-language mistake of treating one language's idiom as the universal pattern.

Why an agent harness re-fired a half-finished tool after a worker restart, the four Python libraries that solve different parts of the problem, and a concrete contribution roadmap for xstate-python.

Outcome: Reader can map a Python workflow to the right state-machine library, distinguish statechart formalism from durable execution, and know where to start contributing to xstate-python with file paths and named missing features.

Why a hand-rolled retry double-charged a Stripe customer because the cancel state was implicit, and what XState 5's setup-plus-actors model gives you that useReducer does not.

Outcome: Reader can write an XState 5 machine using the setup pattern, distinguish invoked from spawned actors, decide when to graduate from useReducer to a state machine library, and read XState code as a structured argument rather than a configuration object.

Why a React form with seven boolean flags shipped a flicker bug that statecharts would have surfaced before the first render, and the decision rule that says when this discipline earns its place.

Outcome: Reader can decide when a workflow is state-machine-shaped, replace boolean-flag explosion with a small statechart that names guards and transitions, and recognize statecharts as an architectural discipline rather than a UI utility.