Why AI Agents Need State Machines to Coordinate Humans

Signup Write New Story Why AI Agents Need State Machines to Coordinate Humans by Akshay Panchavati by Akshay Panchavati | @ sitstraight iOS Developer, tinkerer, and entrepreneur with a passion for telling stories and AI.

iOS Developer, tinkerer, and entrepreneur with a passion for telling stories and AI.

Human-in-the-loop (HITL) is one of the best-known patterns in agent design. An agent works until it reaches a decision it shouldn't make alone, then pauses and asks a person: approve this refund, review this pull request, sign off on this contract. Agent frameworks now build it in as a standard feature.

Almost every example assumes the human is an employee. They're on the same Slack, answering the agent is part of their job, and if they're slow, you escalate to their manager.

This article describes a different setup: a dispatch architecture with two humans and an AI in the loop, where neither human works for the system. The AI isn't waiting on one approver. It's coordinating two people who have never met, while a third, the property owner, keeps the final say.

A tenant texts their landlord's agent: "the kitchen sink is leaking." The agent has to get a plumber and the tenant into the same place at the same time, with the landlord approving anything that costs money. Three humans, no shared channel, and no obligation on any of them to answer quickly.

An AI Agent that coordinates humans is classic finite state machine with allowed transitions and defined states. The only new component is an LLM sitting at its boundaries, translating between natural language and state transitions.

That framing matters because most agent architectures get it backwards. They put the model at the center, let it hold the workflow in its context window, and hope it remembers who agreed to what. When the participants are humans, who reply hours late, change their minds, and answer the same question twice, that design fails quietly and often.

This article builds the alternative from first principles: a deterministic FSM that owns all state and actions, and an LLM that only encodes inputs and renders outputs. Here is that machine for the leaking sink.

As a state machine, the job has nine states. Each arrow is a transition triggered by an input symbol; the diamonds mark transitions that also require an approval input from the landlord.

Under the hood, the dispatcher is a simple state machine. It has three parts:

Nothing in that list needs AI. The rules are ordinary if-then logic you can read and test.

The AI's job is translation, at two points.

Coming in, it turns a messy human message into one of a few clear answers. If the agent just asked the tenant to confirm Tuesday at 2pm, the possible answers are yes, no, a question, or "can't tell" ( UNCLEAR ). A reply like "yeah tues should be ok, after 3 tho" gets sorted into one of those. The AI never decides what happens next; it only says which answer the person gave. When it isn't sure, it picks "can't tell," and the agent simply asks again.

Going out, the code decides what needs to be said ("confirm Tuesday 2–4pm with the tenant"), and the AI writes it in friendly, natural words. It can change the tone, but not the facts.

So the flow is: the AI reads, the code decides, the AI writes. Keeping decisions out of the AI is what makes the system predictable. It can't book the wrong time because it misremembered the conversation, since the conversation's state never lived in its memory.

A textbook FSM assumes well-behaved inputs: they arrive on a clock edge, exactly once, and mean what they say. Human inputs violate all three.

Retracted ("actually, Tuesday doesn't work")

May answer a question you stopped asking

A tenant or contractor owes the agent nothing

The core machine doesn't change. What changes is the input stage and a few structures around it. That's exactly why the state belongs in code: the machine keeps track even when the people don't.

The hard part of an AI that coordinates humans isn't the AI. It's the bookkeeping: knowing exactly who has been asked what, what they agreed to, and what is still in flight. That bookkeeping is a state machine, and we have known how to build state machines for decades.

The model makes the machine speak human. The machine keeps the humans in sync.

I Used GPT-3 to Build an App that Writes Stories for Children On Demand