Human Approval for AI Agents

Hey everyone, welcome again. This is studio time agent conf 2026 Warsaw, Poland. We are here with David who is the creator of XState. Hey David, how are you? Can you tell us a few words on what you've been working on recently? Surely yeah, so I'm the founder of stately.ai where we do state machine modeling and I'm the creator of XState which is a state machine library and so far state machines have been used in lots of different places like applications and workflows, but one of the newer emerging use cases is for agents actually and it seems like contradictory like why would you use a state machine for something that's so non-deterministic, but I think people are finding people yeah.

Exactly you want to control that non-determinism so that the agent doesn't go off rails and so we're exploring just new interesting ways to bring state machines and agents together. So for those who went at the talk which if you went at the talk on view the focus it was great. Could you do just a brief explanation of like what actually you presented in terms of like state machine and AI what like the overarching concept of what that was? Sure so again it's the combination of non-determinism with agents because you can never predict them and the determinism of state machines which seem like the complete opposite where state machines are purely deterministic. You know exactly it's math I said it's mathematically impossible to be in a state that you're not supposed to be in or to take an impossible transition with a state machine because it's a mathematical model. So if you combine them with agents you essentially the way I put it was that you have determinism in the core and non-determinism in the edges which means you might have like a step-by-step workflow where within the step the agent could do anything it wants, but outside of that the actual flow is determined by a state machine or a workflow or whatever other deterministic process you want to do.

So, that's how they so, then and you apply that state machine to what exactly? To what kind of workflows that we use AI for? So, if you're of course doing a basic prompt where it's like write me a haiku or poem, then you really don't need a state machine or anything complex like that. But companies have a lot more requirements and restrictions where the demo I gave was, for example, it's an email drafter. You must draft the email. You cannot send the email until the user approves. So, that would be an example of some business logic. And instead of just putting in your prompt, never do this, don't do that, and just telling the agents that I will punish you if you do like that's just it's not going to work. No, it's not going to work. I mean, you could say, "Hey, it never failed in my eval's." But you can't guarantee it.

With a state machine, you can. And these things get it more important with different industries. For example, self-driving. Obviously, we don't use LLMs for self-driving necessarily, but it's still AI-powered where the car has agency to go where it wants, but you want to be sure it never does things like runs red lights or accelerates when there's a car in front of it or invariants like that. So, it's there's a safety aspect and there's also the understandability aspect where you could say, "how well did this agents do?" it went through all the steps. What step did it get stuck on or keep repeating? Which flows did users take? And when you have a workflow or a state machine, you could actually map your traces to each of the transitions in the state machine and so you have a nice heat map and you could see that, "Oh, okay. So, this is how the agents is behaving." When you don't have that, when you just have logs of messages, it's very hard to debug and understand what an agent is doing.

Yeah, and I guess if you have like a bottom quarter on the on your heat map, and you don't expect that much time being spent there, like this is the place where you optimize your models or you optimize the workflow there.

Play from 0:00

But like the state machine itself, it defines the workflow in a way that it's deterministic. Exactly. Yeah, so it can't go off rail or anything like that. And what does the like implementation look like for this? So I talked about it in my talk where obviously I'm the creator of XState, which is a state machine library, but state machines are fundamental computer science I want to say primitive, but not really a primitive. It's a design pattern that pretty much anyone can implement in any language. It could be as simple as a switch statement or a pure function that tells you what the next state is given the current states and the event that just occurred. And so essentially it looks like a loop, where first you have your initial states and maybe the initial effects you want to execute, and then your loop is while the state isn't considered done, however you want to define that, then grab the next events, determine what the next state is, execute the effects, and then just keep looping through there.

Every single and I'll I'll put money on this. Every single agentic workflow, agentic loop, fits that exact pattern because it's so fundamental. Yeah, it's almost like the pattern is almost academical and theoretical. And then so the workflow is the state machine, and like inside the state you could have like just like one model or you can have like few models like talking with each other or you could have other state machines as well. And then so like it just depends on the implementation, right? On the like the environment when you want to implement it. And I guess this is what you what you consult on with companies where like you see the problems and then you say, "Oh, I'm going to create you a state machine with 15 different states and like right, yes. It's a little bit of consultation, but more just building the tooling around it.

And something that I've argued, you know, since LLMs have become a thing is that people keep reinventing these patterns. For example, they say, "we're doing loop engineering. Now we're doing graph engineering. We're doing sub-agents. We're doing deep agents and things like that." But everything eventually comes down to software principles. And in my view, it's two main things: the actor model and state machines. And both of those work really well together. So, the actor model, that's how like you said, these different agents or actors coordinate and talk to each other. And with state machines, that's how each agent actually behaves. But how would one say I had a state and it talks to an AI model and that gives me non-deterministic output? How would one then decide what the next state would be from that non-deterministic output? With the state machine, it forces you to think of pretty much every possibility. So, in a classical state machine, like let's say that you have sign-in, sign-out as events, and you have some unknown event, which is go to admin dashboard or something like that.

The state machine, it just ignores it. So, it's an event that it doesn't recognize. With with state machines and agents, of course, you could try to get an agent to have the perfect events to send back or the perfect output, but of course, it's not going to happen all the time. So, that's why with state machines and statecharts, you have guards. You could say it must pass the schema and it sort of forces you to handle that error. So, if something goes wrong, you could say you could have some mitigation where you could either retry that agent call or you could go to a state where it's like this isn't working, something is broken, you have to compensate or do something else. And do you have a state machine set up for like your internal work and everything like that? Yeah, so I did a lot of projects that involve using state machines and agents, but also super dog fooding and we have been doing this since 2023.

At stately.ai, we use AI itself to create a state machine, which at least nowadays, it might seem pretty simple, like just ask the agents for an XState state machine, but back then in 2023, it was getting confused between different versions, sometimes there are syntax errors, sometimes it hallucinated different things. So, even back then, we had to create a state machine that said call the agents. Well, actually, we had three different possibilities. So, it created three state machines and it picked the best one. And then from there, it did a loop where it was statically checking, is this actually valid? And if it's not, then it goes back. And so, at the end of the day, or hopefully not day, but like after a few seconds, it says, this is a valid state machine. And so, now we're doing that and more because we have AI that allows you to generate a state machine, visualize it, but also make edits and say, actually, I need this transition or I need this different logic, and it will do the correct patches to update the machine.

And that's not as simple as just prompt output. There are many steps in between. Wow. So, what are the scales of the application of this approach? Like, what did you see out there in the world that actually already works in production? Like, how many states? Like, how do you even describe the scale of the state machine even? Some agents are simple where it's just, you know, two or three states and then somewhere it's, you know, I would argue you don't need a state machine just because it's a simple input output and the output doesn't matter too much. So, like free text and things like that. But I have seen some very complex state machines. Trust me, it's because we get pings and it's like, "Hey, this the visual editor is a little bit laggy." And then I open the machine and it's like 200 states.

Play from 4:00

And so, yeah, it gets a little bit crazy. But, LangGraph by LangChain also does a state machines. So, LangGraph is essentially a graph library for creating essentially the same thing, state machines with agents. And I think that's one of their most popular things that people use now instead of LangChain. They would go to LangGraph just because it's more elegant and more precise to define your agent logic as a state machine. And those could get pretty large. And you said you have a visual editor. Yes, we do. So, it's at our company stately.ai, but if you go to states.new, that's where the visual editor is. Nice. Okay, cool. Well, I think we'll wrap it up there. Yeah, that was like awesome to listen to. Such a again fundamental software engineering idea, state machines, but then applied to this like new exciting AI workflows. And yeah, I'm looking forward to seeing the product and yeah.

Thank you so much.

Play from 10:00