Goodbye Slop; Welcome Determinism | David Khourshid at Agent Conf 2026

Technological concepts and main message

• Determinism for AI agents: The talk argues that agent “negligence” (failure modes / unhelpful behavior when agents are given too much freedom) comes from unstructured delegation—handing an agent broad control without enforceable process constraints.
• Finite State Machines (FSMs) / state graphs as the solution: By modeling agent behavior as a finite automaton / state machine, you can make agent workflows predictable and testable.
  • Core determinism idea: given the same inputs, the workflow follows the same state transitions and produces consistent outcomes.
  • The speaker contrasts the “black box” approach (megaprompts + embedded control flow) with explicit state-machine control.

Key feature/principle: remove negligence via explicit transitions

In an FSM-based agent, you define allowed transitions (e.g., you cannot “send an email” before required states are completed).

Example safety rules for a “draft then send email” workflow:

• Draft/compose before sending
• Only send after user approval / verification
• Never invent recipients

Mathematical impossibility claim:

If “send” is only reachable from a “verified/recipient-specified” state, then the agent cannot transition into sending prematurely.

Critique of megaprompt / prompt-only control flow

Embedding process control directly into prompts leads to issues:

• Tool calls become entangled with control logic (e.g., “call tool only after approval” repeated in prompt/tool descriptions).

• Hard to prove effectiveness: behavior is opaque even with “reasoning” enabled.

• Rules lose meaning as context accumulates (text-based rules are treated like any other context).

• Usually locks you into one strategy (one system prompt / one model settings), instead of stage-specific strategies.

Demo: state-machine email drafting agent

The agent uses a state machine to:

1. Request missing details (recipient address, subject, etc.)
2. Draft the letter
3. Enter verification
4. Send (in the demo, to an “Outbox” simulation)

Even when the user says to proceed with a draft despite missing info, the workflow still enforces state-gated steps (e.g., it can show “forgot email address” when verification requires it).

Product/process insight: evaluation per stage + iterative improvement

Because FSMs produce structured traces, you can:

• Evaluate individual nodes/stages (e.g., draft correctness)
• Evaluate the entire workflow output
• Use an LLM judge for scoring (mentioned as an option)

The speaker emphasizes producing a “machine gun” artifact:

• Hand the state machine + traces to another process/agent to suggest improvements.
• Iteratively update the FSM and compare versions using nearly identical test scripts.

Example outcome described:

• An improved V2 workflow removed extra “passes” and moved faster through draft → proofreading → verification → send, producing better results.

Implementation guidance (tools/approaches mentioned)

The talk argues you don’t strictly need a special product, since the loop is general:

• Start in an initial state.
• While incomplete, execute actions (LLM calls, tool calls, async tasks).
• Determine the next state from current state + events.

Examples/tools referenced:

• XState (the speaker’s FSM library)
• LangGraph (described as a popular state-machine-with-agents tool)

Also mentioned:

• Agent Spec
• AIFlow
• Process mining (older ~20-year-old concepts: turn event traces into formal models and optimize)

“Graphs keep agents honest” → “graphs improve agents”

• Prior message (2023): graphs provide “fuses”/boundaries to keep agents within safe behavior (honesty).
• This talk (2026): same graph thinking can help agents improve their own workflow by tracing and re-modeling behavior.

Second demo: Jev + an automaton-based “coffee machine” controller

The speaker demonstrates Jev (announced by Typesafe) integrating with a large finite automaton:

• Jev receives the automaton and the set of event/action possibilities a “virtual barista” can perform.
• Orders like cappuccino and cortado trigger step-by-step fulfillment in real time.

Deliberate chaos:

• The demo introduces failures (e.g., breaking a machine component).
• Jev then chooses appropriate recovery actions (e.g., deciding to fix the coffee grinder) so the system continues working.

Key implication:

• Behavior is driven by the automaton and event possibilities, not rigid preprogrammed scripts.

Main speakers / sources

• David Khourshid (founder/creator of XState, founder of stately.ai)
• Mentions/attributions within the talk: XState, stately.ai, LangGraph, Agent Spec, AIFlow, process mining, and Jev (by TypeSafe)