What is a state machine?

A state machine is a mathematical model that describes a system as a finite set of states, transitions between those states, and the events that trigger those transitions. At any moment, the system is in exactly one state. When an event occurs, the system transitions to a new state based on defined rules. A traffic light is a state machine: it's always in one state (red, yellow, green), and it transitions based on a timer event.

Unlike generic AI automation posts, this guide shows real CodeWords workflows — not just theory. State machines are foundational to workflow automation, and understanding them helps you design reliable systems.

Related: what is durable execution, workflow automation tools, best serverless workflow tools, AI workflow automation, workflow builder, CodeWords integrations, CodeWords templates.

Why state machines matter

Without explicit state modeling, workflow logic scatters across conditionals, flags, and implicit assumptions. A variable named is_approved doesn't capture whether the approval is pending, granted, denied, or expired. Adding a new state (suspended, under review) means hunting through code for every place that checks approval status.

State machines formalize this. David Harel's statechart formalism extended basic state machines with hierarchy, concurrency, and history — concepts that modern workflow tools build on. AWS Step Functions uses the Amazon States Language, a direct implementation of state machines for cloud workflows. XState, a popular JavaScript library, brings statecharts to frontend and backend applications.

State machines matter for automation because:

• All valid states are explicit: You can see every possible state and transition at a glance
• Invalid transitions are impossible: The machine enforces rules about which states can follow which
• Debugging is straightforward: Ask "what state is this in?" and the answer is always one value
• Complex workflows stay manageable: Even workflows with 20+ states remain understandable when modeled as a machine

How state machines work

A state machine has four components.

States: The distinct conditions the system can be in. An order might be in states: placed, payment_processing, payment_failed, fulfilled, shipped, delivered, refunded. Each state is mutually exclusive — the order is in exactly one state at any time.

Events: Inputs that trigger transitions. For the order: payment_succeeded, payment_declined, item_shipped, delivery_confirmed, refund_requested. Events come from external systems, user actions, or timers.

Transitions: Rules that define which state follows which, given a specific event. placed + payment_succeeded = fulfilled. placed + payment_declined = payment_failed. A transition can only happen if the current state and event match a defined rule.

Actions: Side effects that execute during transitions. When transitioning from fulfilled to shipped, the action might be "send tracking email to customer" and "update inventory system." Actions are the bridge between the abstract model and real-world effects.

Types of state machines

Finite state machine (FSM): The basic model. A fixed set of states with deterministic transitions. Good for simple workflows where every state and transition is known upfront.

Hierarchical state machine (statechart): States can contain sub-states. An active state might contain idle, processing, and waiting sub-states. This reduces the combinatorial explosion when modeling complex systems. Harel's original contribution.

Extended state machine: Adds data (context) alongside states. The state might be processing, but the context includes retry_count: 3 and last_error: "timeout". This combines state modeling with data tracking.

Examples in practice

CI/CD pipeline: States: triggered, building, testing, deploying, deployed, failed, rolled_back. Events: build_success, test_failure, deploy_complete, rollback_initiated. The CI/CD pipeline is naturally a state machine, and modeling it as one prevents invalid transitions like deploying after a failed test.

Support ticket lifecycle: States: open, in_progress, waiting_on_customer, resolved, reopened, closed. Transitions enforce rules: you can't close a ticket that's still in_progress. You can't resolve a ticket that's waiting_on_customer without a customer response event.

AI agent workflow: States: researching, analyzing, generating, reviewing, complete, failed. The agent moves through states as it completes each phase. If generation fails quality checks, it transitions back to analyzing rather than pushing bad output to complete.

State machines in AI automation

CodeWords workflows implicitly use state machine patterns. A monitoring workflow cycles through states: check API health, analyze response with LLM, decide whether to alert, send notification or wait, repeat. State persistence via Redis maintains the machine's current state across scheduled runs.

For explicit state machine modeling in AI workflows, tools like LangGraph (from the LangChain ecosystem) define agent workflows as graph-based state machines where nodes are states and edges are transitions. CodeWords handles the execution infrastructure: built-in LLM access (OpenAI, Anthropic, Gemini), 500+ integrations, and serverless deployment. Explore templates or check pricing.