State Machine

A state machine describes a system that is always in exactly one of several possible situations. These situations are called states. A ticket vending machine, for example, is either idle, or waiting for money, or currently printing. You can only get from one state to the next through certain events, such as inserting a coin. These changes are called transitions, and anything that is not defined as a transition simply cannot happen. This is exactly where the value of the model lies: it makes visible which sequences of events are allowed and which are not.

Why programmers use it to prevent chaos

Software often ends up in situations that nobody thought of. A user clicks “Pay” twice, an internet connection drops in the middle of a process, a server responds twice. Without a clear model, this leads to errors that are hard to find. A state machine forces developers to write down all states in advance.

The practical benefit is completeness. If you have five states and three possible events, there are fifteen combinations. For each one, you have to decide what should happen. If you forget one, it becomes apparent while writing it down, not only later when it reaches the customer. Payment systems, elevators, and traffic light controllers are therefore almost always designed this way.

A second advantage is verifiability. A model with a finite number of states can be fully computed by a computer. So you can prove that a traffic light never switches both directions to green at the same time. With ordinary program code, such a proof is usually impossible, because the number of possible execution paths grows toward infinity.

States, transitions, and what the model cannot do

You need three things: a list of states, a defined starting state, and a table of transitions. The table always answers the same question: if I am in state A and event X occurs, which state am I in afterwards? Often a transition also carries an action, such as “print ticket”. There are no further components.

Crucially, a classic state machine has no memory beyond the current state. It only knows where it currently is, not how it got there. This sounds like a weakness, but it is actually the reason for its clarity. If memory is needed after all, you add variables, for example a counter for the money inserted.

A common mistake is to turn every conceivable detail into its own state. Then the number of boxes explodes and the model becomes unreadable. Good practice is to only represent as states those situations in which the system’s behavior genuinely differs. Everything else belongs in variables.

From traffic lights to AI agents

In everyday life, this principle is found in washing machines, coffee machines, and traffic lights. Order processes in online shops are also built this way: “ordered”, “paid”, “shipped”, “delivered”, “cancelled”. The status display you see when tracking a package is nothing other than the current state of a state machine.

In the world of AI, the term appears in connection with so-called agents. These are programs that have a language model carry out several work steps one after another, such as searching, summarizing, checking. Because such models can respond unpredictably, they are often framed within a state machine. It defines which step is allowed to follow which, and where execution should be aborted.

In technical articles you will also encounter the term as “finite automaton” or as the abbreviation FSM for Finite State Machine. It should not be confused with the “state” in app development, which simply refers to the stored data of a user interface. A state machine is more than a stored value: it is the set of rules that determines how that value is allowed to change.