Whether traffic light switching, web front ends or LLM agents: many software systems can be modeled as state machines. State machines are a versatile design pattern that views systems not as step-by-step sequences of instructions, but rather describes them declaratively through states and state transformations. It clearly shows the behavior of a system under different circumstances. Like many design patterns, an understanding of state machines is beneficial even if a system is not explicitly implemented as a state machine. Viewing systems as state machines makes it easier to identify clearly defined states and response options, as well as communicate with non-technical stakeholders.
Advertisement
As co-founder of Inlinity, Kilian Kluge develops processes, software, and infrastructure for trustworthy AI systems. He previously worked as an IT consultant and developer and holds a doctorate in user-centered AI from the University of Ulm.
Philipp Schroppel works as a machine learning engineer and project manager at Inlinity, bringing explainable AI from research to practice. In addition to his work at Inlinity, he is a doctoral student at the University of Ulm researching interpretable machine learning and human-AI interactions.
State machines have a particular strength in complex systems that involve many independent and concurrent subsystems. The actor model can be used for modeling here, in which each subsystem, viewed as a state machine, manages its state as an independent actor and interacts with other actors only by exchanging messages. Is. The open source JavaScript library XState makes this combination of state machines and actuator models easily accessible. Originally developed with a focus on the web front end, it is also suitable for the implementation of backend applications and AI agents in which large language models (LLMs) take control of the system.
This article introduces the basics of state machines and actuator models and shows developers a variety of potential uses.
Introduction to State Machines
A state machine describes a system as a set of states between which transitions triggered by events are possible. State machines can interact with their environment through tasks. When and what action will be taken depends on the situation and the event received. An obvious example of state machines is the login flow: at the beginning the state is “logged out”. After entering the access data, clicking the “Login” button triggers the “Authentication” event. If successful, the system switches to the “logged in” state, otherwise it switches back to the “logged out” state. This process can essentially be described as a sequence of steps. What works in the simple case mentioned often leads to confusing and nested branches in the code in more complex processes. At the latest when it is necessary to synchronize concurrent processes – for example sending and verifying the second authentication factor – the effort and sensitivity to errors increases.
Representing state machines with state transition diagrams
The parlor game “The Werewolves of Mirkwood” in this article is an example of the use of state machines as a design pattern. In this role-playing game, which is played by a group of at least eight people, players interact with each other based on the game stage and role. Parallel actions and covert communications are a central part of this. In its simplest form, the werewolf game has two roles: villager and werewolf. If the werewolves manage to eat all the villagers they win the game, and if they kill all the werewolves the villagers are victorious. A game leader controls the process, votes and enforces the results.
The state transition diagram in Figure 1 visualizes the states and possible transitions in the werewolf game. State transition diagrams represent the logic of state machines clearly and without technical implementation details, so they make an effective communication tool for coordination between development teams and non-technical stakeholders.
State transition diagram for the role-playing game “Werewolves of Mirkwood” (Figure 1).
A werewolf game begins in the “Preparation” state, with each player randomly assigned one of two roles: Werewolf or Villager. The first night comes after preparation. (Therefore there is only one possible state change.) When the “night” state occurs, all players first close their eyes, only then the werewolves open their eyes at the instruction of the game master. They use signals to indicate which villager they want to kill (quietly and, if possible, without making any noise) and close their eyes again after making a decision.
There are two possible transitions from the “night” state. If any villager is still alive, the game enters the “day” state. However, if the werewolves have eaten the last remaining villager by their decision, they have won and the game goes to the “Werewolves win” state. In the “day” stage, all players open their eyes first and the game master announces who died during the night. This player is out and leaves the game. All remaining players discuss and ultimately decide by vote who they suspect of being a werewolf. The chosen player is removed and the remaining players are told their roles. There are three possible states that can be reached from the “day” state. If all werewolves die after the chosen player is eliminated, the game ends in a “Villagers Win” state. If the eliminated player is the last remaining villager, the game enters the Werewolves Win state. In all other cases the game returns to “night” state. The states “Werewolves win” and “Villagers win” indicate the end of the game and are the final states from which no more states can be achieved.
Implementing a state machine with XState
XState is a JavaScript library that allows state-based logic to be explicitly defined and managed as state machines. State machines implemented with XState can be integrated into common web frontend frameworks or run in the backend with Node.js. The Stately company is now behind the open source project and offers “Stately Studio”, a visual editor for creating and managing state machines. State machines can be displayed graphically and adjusted interactively. It is then possible to generate and export the corresponding source code. The editor requires no programming knowledge to use and enables employees with no programming knowledge to describe and understand the processes and logic.
The gameplay described in the previous section can be implemented in XState as shown in Listing 1. As can be seen in the diagram in Figure 1, the possible situations (states) top level. Changes are either mandatory (always) or due to some event (onYou can also select the next state (target) Make it dependent on the fulfillment of a criterion (guardThe state machine always starts in the “Start” state (initial) and ends immediately after the last position (final) had reached. Each state machine is a context in which any information can be stored (context,
export const gameMachine = setup({}).createMachine({
initial: "Start",
states: {
Start: {
always: {target: "Night"}
},
Day: {
on: {
votesCollected: (
{ guard: 'allVillagersDead', target: 'WerewolvesWin' },
{ guard: 'allWerewolvesDead', target: 'VillagersWin' },
{ target: 'Night' }
)
)}},
Night: {
on: {
votesCollected: (
{ guard: 'allVillagersDead', target: 'WerewolvesWin' },
{ target: 'Day' }
)
}
},
VillagersWin: {
type: "final"
},
WerewolvesWin: {
type: "final"
},
},
context: {},
});Listing 1: Implementation of the state transition diagram shown in Figure 1 in XState.
