David Khourshid (creator of XState, founder of Stately.ai) argues that agent "slop" comes from unstructured delegation — handing an agent one mega-prompt and hoping for the best — and that modeling agent workflows as explicit state machines makes behavior inspectable and fixable. Using a small email-drafting agent as the example, he shows how the deterministic rules (you must draft before sending, only send approved emails, never invent a recipient) belong in the graph rather than in prompt text. His main new point versus his 2023 talk: the state machine isn't just guardrails, it's a durable artifact you can hand back to an agent along with traces and evals so the agent proposes an improved version of its own workflow, which you then A/B against the original.
- Slop comes from "unstructured delegation" — giving an agent all the judgment, structure, implementation and taste at once; it works until it doesn't, and then there's nothing concrete to point at as the thing to fix.
- A state machine is just the relation state + event → next state; determinism means the same input produces the same predictable output, and in an agent it lives in the rules, not in the free-form content.
- Mega-prompts encode control flow in text ("never call send_email until the user approves"), leak that control flow into tool descriptions, lock you into one model and one strategy, and the rules decay as context grows.
- With an explicit state machine it becomes mathematically impossible to send an email while in the drafting or reviewing state, because no such transition exists.
- Explicit structure gives structured logs of states and events instead of plain reasoning text — "you cannot draw arrows in paragraphs."
- Beyond evaluating individual steps and the overall outcome, you can evaluate the edges: feed the machine plus traces plus eval results to a separate agent and ask it to propose workflow changes.
- The demo of this produced a v2 machine that drafts the email first and asks clarifying questions after, a noticeably faster flow — even though all evals passed on v1.
- No special library is required: the loop is while-active, run LLM/tool/async calls, compute next state and effects; XState, a switch statement, a reducer, or LangGraph all work.
- The improvement loop — model, observe, propose, compare — echoes prior art including process mining, which is roughly 20 years older.
- Closing demo: a chaotic espresso-machine state machine driven live by a newly announced tool (transcribed as "Jeb"), where breaking the grinder makes the agent decide to repair it before continuing.
The clearest articulation of the failure mode he's arguing against, including the subtle cost of losing per-step model and prompt choices.
We're encoding control flow inside the prompt. We're saying, first do this, then do that... Obviously, you should never write tools like this where the tool is part of the control flow.
This is the talk's actual new idea — the state machine as a durable artifact for agent self-improvement — and it immediately pays off in a better v2 workflow.
Here's my state machine, here's all the traces from a few of the sample workflows... and here's all of the evals from each of the steps, and the overall evals from the machine. Please propose some changes to this agent.
Modeling is not ceremony when it actually replaces confusion, both for you and for the agents.
You cannot draw arrows in paragraphs.
In 2023 I was talking about how the graph keeps the agent honest. In 2026, I'm talking about how using that exact same graph thinking can make the agent improve on its own behavior.