Finite state machines give AI agent systems explicit states, transitions, guards, actions, and stored context.
2
Actors provide concurrent, message-driven execution, while large language models add dynamic intelligence to otherwise structured systems.
3
State charts can support tool use, human approval, feedback, collaboration, orchestration, and LLM-generated workflows, although flexibility and versioning remain difficult.
Summary
Adam Terlson argues that finite state machines can provide the predictability, observability, and control that large language models lack. He first explains state machines and state charts through a rock-paper-scissors example, then pairs them with the Actor model. Actors communicate through messages, update internal state, and create other actors, while a state machine defines each actor's behavior. Together they support replay, auditing, recovery, testing, explicit error handling, and distributed transactions. Terlson then presents agentic patterns built on this foundation. Tool use lets an LLM request actions without calling methods directly. Approval steps add human control, feedback lets agents revise their work, and collaboration composes specialized agents. Orchestration lets a planning agent choose valid next states. Chartering gives an LLM the whole state chart and asks it to invent a process. The approach keeps execution governed while allowing model-driven decisions where needed.
Terlson defines a finite state machine as a computational model with states and event-triggered transitions. His rock-paper-scissors example includes state definitions, transition logic, guards, actions, effects, and context. Guards enforce valid transitions, such as checking whether two throws match. Actions can send messages or update context, while context stores data used for transition decisions and final output. He distinguishes state charts from simpler state machines because state charts add hierarchical and parallel states. The richer model describes an application's behavior, but it does not provide the execution framework for a complete distributed application.
Actors provide the execution model around state machines
The Actor model complements state charts with concurrent, distributed, and encapsulated execution. An actor can send and receive messages, update its internal state, and create new actors. A finite state machine can define that actor's internal behavior. Terlson's architecture therefore separates concerns: actors provide autonomy and communication, state machines provide structure and enforce allowed behavior, and LLMs provide dynamic intelligence. This pairing lets teams use message-driven components without leaving the agent's behavior entirely implicit inside model prompts.
State machines make agent systems easier to inspect and recover
Terlson lists practical benefits of state machines for operating distributed systems. They are predictable, traceable, auditable, reliable, and recoverable. If current state is lost, the system can replay its event log to recalculate it. Replaying only part of the log can create a new branch in history. Declarative definitions support model-based testing, where tests can exercise every valid transition. State machines can also express difficult failure handling, including Saga-style compensating transactions that undo earlier steps after a later request fails.
Terlson is direct about the mismatch between LLMs and operational requirements. He says LLMs are not predictable, traceable, auditable, reliable, recoverable, declarative, or low latency. State machines cannot add intelligence, but they can constrain where and how model decisions affect the system. Actors enable autonomy and communication, state machines enforce predictable behavior, and LLMs supply flexible reasoning. The point is to put the model inside a structure that can record decisions, reject invalid transitions, pause for approval, and recover through known state and event history.
Tool use and approval steps put boundaries around model actions
Tool use is the foundation of the patterns Terlson presents. The model receives descriptions of available tools, including method names and expected arguments. It returns instructions describing how the caller should invoke a tool, then expects a later message containing the tool response. In his recipe example, a retrieval tool first fetches available inventory so the model uses ingredients that exist. A state machine can add an approval state before execution. An administrator can deny or approve the request through an authenticated and authorized message.
Feedback and collaboration divide work among agents
Feedback gives an agent a chance to improve its output after another agent or a human reviews it. Terlson's recipe writer sends its work to a critic specializing in nutrition, receives advice such as using less sugar, and revises the recipe. Collaboration extends this arrangement to a team of specialized agents. His meal-delivery example includes agents for writing the recipe, procuring ingredients, preparing the meal, receiving feedback, and publishing a report. The state machine keeps the overall flow explicit, and the report can become feedback for continued improvement rather than a mandatory final state.
Orchestration lets an LLM choose among governed transitions
In agentic orchestration, a centralized planning node determines which state should run next. This is useful when the system must reason about context, decide whether a goal has been achieved, or determine whether it can leave the flow. In Terlson's example, the planner uses event emitters to request transitions. Transition guards still enforce that the requested transitions are valid and route execution to the appropriate states. The LLM chooses within a defined state chart instead of directly controlling arbitrary application behavior.
Chartering asks an LLM to generate the process itself
Agentic chartering separates planning from execution by giving the LLM the whole state chart and asking it to create a new process. Terlson describes an experiment based on instructions for removing personal data from White Pages data-broker listings. The model generated a process essentially zero-shot, using available actors, events, context, patterns, and tools. He suggests that a visualization agent could inspect the generated state chart and provide feedback to the chartering agent. This pattern gives the model more freedom while keeping the resulting workflow expressible as a state chart.
"The opportunity is that by combining LLMs and state machines together we can build a system that leverages the strengths of one to mitigate the weaknesses of the other."07:43
Who should watch
You are building LLM agents that need approval gates, replay, auditing, or explicit recovery paths.
Your system has multiple specialized agents and you need a clear way to coordinate their messages and handoffs.
You are considering letting an LLM plan or generate workflows and want application code to constrain the transitions it can request.
