AI Engineer World's Fair 2026
The Human Is an Async API — Melanie Warrick, Temporal
Read the talk
The Human Is an Async API
Melanie Warrick’s ice cream delivery demo shows how Temporal lets an agent wait for a human without stopping unrelated work—and recover an approval even when its worker goes offline.
From a talk by Melanie Warrick
At a glance
Ideas worth remembering
A human-dependent decision should pause the affected work while unrelated orders continue.
Temporal separates workers that execute code, workflows that coordinate steps, and activities that perform external model and tool calls.
A wait condition preserves the pending interaction without holding a thread; a signal supplies the human’s response later.
In the worker-outage demo, the separate event store queues an approval, and replay reconstructs the workflow’s state so the order can continue after recovery.
Choose human checkpoints by balancing the cost of a wrong decision against alert fatigue.
One changed order should not stop the delivery fleet
An ice cream customer changes their mind after placing an order. Driver A now needs to wait while another human approves the change. Meanwhile, other orders should keep arriving and other drivers should keep delivering. This is the opening problem in Melanie Warrick’s Temporal demo: how to pause the work affected by a human decision without freezing the service around it.
The fictional business belongs to Ziggy, Temporal’s mascot, and operates from San Francisco’s Ferry Building. Three agents coordinate its deliveries: a fleet agent, a customer agent and a dispatch agent. Google ADK orchestrates the agents, while Temporal tracks their execution state. Temporal’s UI exposes an event history for the parent workflow coordinating the delivery system.
The order change produces a visible, local interruption: driver A waits, but the rest of the fleet continues working. After approval, the system reads the update and A moves toward Oracle Park. The important relationship is between the decision and the work it controls. A human response gates this order’s next step; it does not need to gate every order in the system.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Agent loops need a place to preserve their progress
The familiar agent loop is reason, act, observe. It can be implemented as a for loop or a while loop, but the loop alone does not explain what happens when a process fails halfway through its work. The surrounding harness supplies the structure needed to run an agent in production. Its precise scope is debated—models, tools, memory, guardrails and security may all enter the picture—but Warrick’s addition is clear: durability belongs there too.
Ziggy’s service contains three such loops with different jobs:
- Fleet research: Assess drivers using tools such as Google Maps.
- Customer research: Investigate orders using tools such as Google Search.
- Dispatch decisions: Combine the fleet and customer agents’ findings to decide what happens next.
Human input can enter this structure, but so can failures. Preserving the agents’ progress and handling those failures is a separate concern from choosing the next delivery.
Temporal supplies primitives for state management and failure handling that application code can use. The aim is to make these concerns consistent across the distributed system, rather than requiring each agent loop to invent its own recovery behavior. Temporal is available as software and as a managed service; the execution model is something the application explicitly adopts.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Workers execute code; workflows track steps; activities call outside
Three parts divide the execution responsibilities:
- Worker: Runs the application code.
- Workflow: Tracks the steps and coordinates their progression. An agent loop can run inside a workflow.
- Activity: Performs an interaction with something external, including a model call or a tool call.
For an agent, this separates the sequence of decisions from the external operations used to make those decisions. The workflow coordinates the loop; activities perform its model and tool interactions.
The software is free and open source, with self-hosting available. The managed service is the paid option. That choice changes who operates the state-management infrastructure; either way, the application structures its code around workers, workflows and activities.
A human decision exposes the weakness of an ordinary blocking function. If “call the human” means keeping a live invocation waiting for a response, the service can lose track of that engagement when it goes down. The problem is larger than a slow response: the application must remember what question is pending and where execution should continue after an answer arrives.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A wait condition parks the work; a signal brings the answer
Two primitives turn the human interaction into an asynchronous exchange. A wait condition suspends the affected progression and preserves it in the workflow’s durability layer. A signal supplies input to that workflow later. Because the waiting state is preserved, recovery can return to the point where the human decision was needed instead of losing the pending interaction.
Waiting does not mean holding a thread until somebody answers. The waiting execution yields, allowing other coroutines or workflows to continue; a workflow with no runnable work can be parked. Timeouts can bound how long an application waits for a human. Warrick describes the ability to keep millions of workflows parked, although this demonstration does not establish throughput or resource requirements at that scale.
The ADK integration applies the same division of work to an existing agent setup. A Temporal model wrapper surrounds the model, activity tooling wraps the tools, and the wrapped components go into the ADK agent. The worker receives the Google ADK plugin. The agent still runs through its framework, while its external calls participate in Temporal’s execution model.
The wait condition controls the path that depends on the response. The signal injects the human’s input into the workflow. This distinction matters: pausing a decision-dependent path does not require stopping all concurrent work, and accepting the answer does not require keeping the original process alive throughout the wait.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
An agent can request the human through a graph interrupt
The first interaction began with a customer changing an order. The next reverses the direction: an agent decides it needs a human. The same wait-and-signal mechanism handles both. To demonstrate that the durability layer can span frameworks, the second setup keeps the customer and fleet agents on ADK and runs the dispatch agent on LangGraph.
In the LangGraph integration, graph nodes receive integration metadata. Model invocations and other tool calls become activities, while workflow code coordinates the steps. Warrick describes the distinction as deterministic workflows and nondeterministic activities: the orchestration must be recoverable from its history, while external calls can produce results that depend on the outside world. The worker also receives the LangGraph plugin.
LangGraph’s interrupt provides the point where a node asks for outside input. The surrounding loop uses a wait condition to pause the affected workflow, and a signal captures the human’s response. The graph expresses where the decision is needed; Temporal preserves the waiting execution and carries the eventual answer back into it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Approve the high-value order while the worker is offline
A high-value order now enters Ziggy’s service. The parent workflow continues coordinating the system, while child workflows split off for each order per framework. The customer and fleet agents assess this order and send their results to dispatch. Dispatch requests human involvement and enters a waiting state. Other delivery cars continue moving.
This is where the title becomes an execution requirement. Humans generally do not answer in 200 milliseconds; a response may take minutes, days or weeks. The high-value order therefore needs a preserved waiting state whose lifetime can exceed the lifetime of the process handling it.
Warrick presses Kill Worker. The worker goes offline and the demo shows it disconnected. She then presses Approve while it is still offline. The approval can be tracked and queued because the event is stored outside that worker, in a separate data store. The worker’s absence prevents it from executing the next step immediately; it does not erase the human’s decision.
When the worker comes back online, the event history is replayed to reconstruct the workflow’s state. “It’s not redone,” Warrick explains: recovery establishes where execution left off, then proceeds with the queued approval. The order is assigned and delivered. This demonstrates recovery from a worker outage while the separate event store remains available; it does not imply recovery from every possible failure of the whole system.
What survives when the worker disappears? The flow below follows the same high-value order through the interruption. The approval is recorded before the worker returns, so recovery has both the prior execution history and the new decision needed to move forward. That separation between stored events and active execution is what makes the offline approval useful.
Customer and fleet agents send their results to dispatch.
The human’s approval enters the separate event store while the worker is offline. On return, the worker reconstructs state from history and continues with that approval.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Choose human checkpoints by the cost of being wrong
Durable waiting answers how to involve a human. It leaves a harder product decision: when should the agent ask? Warrick’s starting point is the cost of being wrong, particularly where security is involved. The high-value order illustrates a case where dispatch escalates, but the appropriate policy depends on the problem being solved.
Two pressures pull that policy in different directions:
- Costly mistakes: Probabilistic models can make unreliable decisions, so consequential actions may justify human review.
- Alert fatigue: Repeated requests can train people to answer “Yes, yes, yes” without giving each decision meaningful attention.
Asking more often is therefore not automatically safer. The checkpoint must be valuable enough to deserve the attention it consumes.
The wait-and-signal mechanism supports whichever checkpoints the application chooses. A customer can initiate a change, or an agent can request approval; both become preserved waits followed by human input that lets execution continue. The mixed ADK and LangGraph example also shows that this interaction need not belong to a single agent framework.
Warrick closes by inviting builders to discuss the problems they are solving with autonomous agents. The practical question to carry into that discussion is specific: which decision deserves a human’s attention, and what must the system remember while it waits? In Ziggy’s service, the answer is an order’s pending decision and execution state—even when the worker responsible for advancing it disappears.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Read the complete timestamped transcript
- 0:13
All right. Well, I'm here to talk to you today about, uh, this demo, and I've already stepped outside the box they told me not to step outside of. Anyways, I'm here to talk to you da- today about an ice cream delivery demo that I've got for you, and ultimately, I'm here to talk to you about Temporal. So you're gonna hear me pitching about the company that I work for, and specifically in a way that will be about this ice cream delivery that's happening, uh, as you can see online right now. So what's happening? Well, this is Ziggy. Ziggy's i- Ziggy's is our mascot. I love Ziggy, and
- 0:43
Ziggy has an ice cream store. Not really, but let's say he does down in the Ferry Building, currently working hard delivering all kinds of ice cream. Now, what's happening on this screen is that, um, we have multiple agents that are currently coordinating the delivery that's happening for deliver- for Ziggy's ice cream service. We have a, a fleet, uh, agent and a customer agent and a dispatch agent all working in coordination to make sure that the ice cream goes where it needs to go. In this specific demo, what I've got up
- 1:13
here is showing you we have ADK integrated with Temporal. So ADK is a, um, solution that Google is providing to help you orchestrate agents or multiple agents, um, and in this case, it's specifically helping to coordinate the activities in relation to these agents. And Temporal is ba- baked into it. We are integrated into it so that we can help track the state of what's happening with this kind of delivery. So Temporal actually helps you track your state
- 1:43
and manage that state, and we provide a UI that allows you to see what's going on on that screen. So this is what you're seeing over here. And in that UI, it's showing you the event history. There's this... This is the parent workflow for all the activities that are happening for Ziggy right now in its delivery suite. And in this world, sometimes what we'll have in, uh, multiple agents is we need to have human in the loop. So let's say a customer made an order and the customer said, "Hey, I think I've changed my mind about that order, so I'm gonna submit
- 2:13
a change." And of course, when you do submit that change, uh, it will not... I- if you, depending on how you build it out, it could actually break your system, but heaven forbid you have it break your system when somebody has a change to submit. In this case, we have an order, and this order is currently pausing driver A, and so driver A is waiting for that update to come through. The system is running while this one specific,
- 2:44
uh, change is only pausing one part of your system, that one change coming from a human. And another human needs to make a call on whether or not they want to accept that, so they say approve, and you'll watch that, as I mentioned, the rest of the system kept running. Orders are coming in. They're being filled. But in this specific question that came up about changing that order, the update is getting processed and should go through
- 3:14
in a second. I suspect internet is part of it. You can see it does get processed. The update is read, and that order will now move on to its next location, which is to Oracle Park, and there goes little A delivering the order for you. So there you go. That is durable execution with Temporal and ADK integrated. All right. I'm here to talk to you about the human is an async API.
- 3:41
Let's go into... First off, we've been hearing about agentic loops, right? You can reason, act, and observe. That is our whole thing that everybody's been talking about when they're talking about building out these agents and these agents running as autonomously as we possibly can. Um, there's this kind of loop that we're looking at, right? We've heard other words for this where we're thinking, we're acting, we're perceiving, um, and that's, that's the e- essence of it. It can be a for loop. It can be a while
- 4:11
loop. Most of this year, we've been hearing people tell us about the harness and what the harness is supposed to be to help us get those agents into production. So the harness, I'm not gonna sit here and tell you I, I am the expert on the harness. Um, I'm gonna tell you from everything I've researched, I'm trying to give you at least a map to a degree of what I understand so far with the understanding that there's a lot of debate about this. I've heard that the harness is possibly the model is, is part of all of this, or it's not. I
- 4:41
think there's, there's debates around whether the model's in it, whether tools are in it, memory's in it, uh, guardrails, security. But ultimately, it's all about getting these agents with structure so that they can work reasonably well when they're put out into production, and part of that picture should be durability.
- 5:00
The system that I showed you, the demo that I just showed you, this is what it is. It's got these loops. We've got a loop for the fleet agent. We got a loop for the customer agent. We got a loop for the dispatch agent. The fleet and the customer are doing research. One's doing it on the actual drivers using th- tools like Google Maps. Um, the other one is doing research on the orders like Google s- with tools like Google Search while the dispatch agent is taking that input and making decisions with it.
- 5:28
All right, so that's great that these activities are happening with these three loops, and we've got the human potentially providing input in part of this structure. But what's important is that we need to have some durability in that system to make sure that it stays up and running and doesn't fall over, and that's where Temporal comes in. So Temporal is helping you to standardize your fa- failure handling and your state management in your system. Any system. Any distributed system, especially any systems with agents,
- 5:58
we are gonna help you standardize that. We're software, and we're also a service. The software itself is creating a lot of primitives that you can just use out of the box and basically apply to your code base. We come in all kinds of flavors of code, uh, so you can use us in Python or TypeScript or Rust. Um, but ultimately, we're giving you some standard primitives to apply to your code to be able to make sure your s- your state, your, your system is stateful. So the three main primitives we tend to talk
- 6:28
about are the worker, the workflow, and the activity. The worker is really running that code. The workflow is where you're going to be able to, uh, keep track of the steps in your system, and so this is where, like, an ADK framework would be running inside a workflow. Uh, your agent could wor- run inside of a workflow 'cause it's a loop, right? Whereas the activity is all the stuff that's integrating or in- interacting with stuff externally. So if you've got a loop, uh, any kind of model call or
- 6:58
any kind of tool call, those would be set up as activities. So these are the primitives. So you structure your code with our primitives to be able to track the state of your system. And we're free and open source at that GitHub URL. Um, you pay us if you, you have us manage your state with our service. Otherwise, you can host it, self-host it on your own system. Let's get back to human-in-the-loop. Why, uh, what I wanted to really get across to you about this whole
- 7:28
talk. So the human, granted, you know, we're not tools, but we are a tool to the agent. Um, and you might think, "Okay, well, we're gonna call the human," or, "We're gonna have the human come in and give us, uh, some kind of information to pass into this loop." If you write it just straight out as a function to say, "Call the human," or let the human have a, uh, an input, it can become a blocking call, and it can get lost if your service went down. It might lose track of what was
- 7:58
going on with that human's, uh, engagement.
- 8:04
What you want is these two core primitives to be applied to your, your code and your agents. You want a wait condition and a signal. You're allowing yourself to isolate an event, apply a wait condition, store that in that workflow, in that durability layer so that if anything fell over in the system, when that ca- system came back up, it would know where it left off, and you could send a signal at any point, but
- 8:34
the whole system could keep running without you necessarily being blocked on that one call to the human.
- 8:42
The code pretty much is pr- is, is fairly simple in terms of the primitives, and granted, I know this is Python, but it's the same situation. You're gonna apply a wait condition, and you're going to apply a signal.
- 8:54
You basically-- You're not holding a thread. You're not, uh, it's going to survive any kind of crashes. It's got all kinds of built-in, uh, primitives like timeouts, for example. If you're waiting on a human to respond and you wanna make sure that it only waits for so long, you can apply timeouts and other types of primitives. Um, and this can scale. You can have millions of workflows out there parked, and it can keep running. So what I wanna show you-- Actually, I'm gonna show you some more code, but I'm gonna kick off the next demo so
- 9:24
that it's up and running. And I'll share with all of you, if you haven't already figured this out, uh, my eyes are injured, so I am squinting at times and also realizing that I need s- additional in-- support here that I did not prepare for. But that's okay 'cause I can adapt. All right. So let's get this other example up and running, and then I'm gonna tell you a little bit more about the code that's up here. Let's make sure that's running. I'm resetting my example, and of course, it's not
- 9:54
gonna be as easy-peasy as I'd like. Also, is everybody hearing me okay? Think so. Great. It's an interesting condition to be, uh, working in this space with the noises around us. All right. I think it's up and running. All right, so let's talk a little bit more about the code. Now, I already told you about our primitives of activity, uh, workflow, and worker. And so with the activity, um, you are basically,
- 10:24
for ADK in particular, we have, uh, we have the Temporal model class that you will wrap around the model, and then you'll pass it in for ADK to be able to set up that actual agent. It's pretty simple. Um, you apply this Temporal model. You apply our activity tool, uh, to wrap around your tools, and you, uh, you run your, um, agent. You run your agent like you would with any kind of ADK setup that you're gonna do. And you also set up a worker, and you pass in the Google
- 10:54
ADK plugin. So that's setting up your worker, workflow, and activity. And then similarly, you have your wait condition, and the wait condition is using this asyncio when it uses a wait to say, like, for that specific workflow, I want you to pause it. Don't run any other code. But you can keep running the coroutines on that workflow or any other workflows in the system. Meanwhile, that workflow.signal, it will be able to take any kind of input and inject it into a running workflow.
- 11:25
And the workflow will be, uh, taken off of your memory or taken off of your system and put in, in parked if it's not running anything at that point.
- 11:36
So I showed you human to agent. What I wanna show you is what does it look like when the agent comes in and needs the human to in- be involved. It's pretty similar. You're using-- I'm just gonna go ahead and h- tell you right now, you're gonna use a workflow-- You're gonna use a wait condition and a signal. I'm going to use LangGraph in this example and also ADK because the reality is, with Temporal, we can work with multiple frameworks. We are framework-agnostic. Uh, we work across a variety of different tools. Um,
- 12:06
so in terms of LangGraph, they build out graphs in, to build out the multiple agent setup. And in this integration, the way we work, uh, you're passing us into each node for your graph. So you're setting up what the metadata looks like. And if you're making any kind of, uh, model call, like an invoke the model, that would be set up as an activity. If you're making any type of other tool call, it would also be set up as an activity. But if it's a step, a step in that process, then that's set up as a workflow. This is
- 12:35
determinism and non-determinism in terms of workflows are deterministic, activities are non-deterministic. And then of course you pass in for the worker, the plugin for the LangGraph.
- 12:50
In terms of LangGraph in particular, we use the interrupt to call out from their nodes, so this is part of LangGraph. And also, to be fair, LangGraph is more than a framework, but in this case I'm using it as a framework. But you use interrupt to call out, and then what you're going to do next is use that wait condition in the loop, tracking for that interrupt signal to pause that workflow, and then the signal will capture whatever the human, human or responds with to the question that's been asked. Okay,
- 13:21
let's see what that looks like. I'm going to bring up my demo and show you as they're running. This is the design that I've got. I've got the customer and the fleet agents running on ADK. I've got the dispatch agent running on LangGraph. And Temporal is interwoven throughout. So that's how that's working. Now, let's see if I can show you.
- 13:47
In this case, I'm gonna drop a high value order. This is an order that will most likely want a human involved. The workflow for the whole system is showing that all these agents are doing their job, they're continuing to keep assessing orders, and the way I've got this set up is I have workflows, uh, child workflows that are split off for each order per framework. So that special order actually had its own assessment done,
- 14:17
and here we see that the customer and the fleet agents did their work, they did their assessment, and they came back with a result. And they sent that off to the dispatch agent. And the dispatch agent said, "Hey, okay, I need..." Oh, well, there we go.
- 14:34
"I need to get, uh, a human involved in this. So I'm going to go into a pause state while I'm waiting for the human to respond." And we know that humans are not going to respond in 200 milliseconds. If you are, that's great. Maybe there's a, uh, there's probably a couple of people out there who are. But humans are most likely going to take several minutes, maybe days, maybe weeks, maybe longer. And you can, you can because this is just pausing that one specific event. And as you can see, the little cars are continuing to keep
- 15:04
going. So now what I'm gonna try to do is show you what happens if I was to take this service offline. So, uh, let's make it bigger for all of us and
- 15:19
hit Kill Worker. Cool. So that takes it offline.
- 15:25
You can see it's disconnected. Don't mind me as I do this in a very interesting way. All right. If I say Approve while it's offline, so what's happened is, as I mentioned, this is stuff that's happening off of your service. It's over on its own data store. So we can still keep track of that event and queue it, and then when I bring it back up... Ah. Yeah, I know. I have this really well organized here, here for y'all. But I'm gonna, I'm gonna bring it back up and then we're gonna see if it
- 15:55
works. Let's see. Make it-- And it's back online. And you'll notice that the dispatch agent will-- What's happening is that your event log is getting replayed. It's not redone. It's just replayed up until the point at which it last left off so it knows, "Here's my current state, and this is now the next step in that state." And it's been queued up to then have that step know that it, that the person approved it, and that order got assigned, and it's already been delivered actually. So there you
- 16:25
go. That is durability in your system. Your system can come down, and it can recover. And it can have all these other primitives that will help you manage a complex state, because these kinds of distributed systems are complex. All right, last couple things I wanna mention. When should the human be in the loop? Ah, this is the real question. It's a hard one. I will say this, the big thing you wanna take into consideration is the cost of being wrong is high, right?
- 16:55
It's a case-by-case basis, and we know we're trying to get to autonomy as much as we possibly can. We also know these models are probabilistic, and they are hard to get to a place to be reliable. That's why we've got all this stuff happening around harnesses that are interesting. I could go into a whole 'nother conversation about that if y'all want at a later date. But ultimately, you want to assess the cost of being wrong, what is that worth to you? And especially in a security standpoint. And we know, like, on the other side of this picture, alert fatigue is real. Like, a lot of us are seeing, you know, you just start saying, "Yes, yes, yes,
- 17:25
yes, yes," every time it asks you questions, so you're trying to balance between those two. And we're trying to get the models better so that you can trust them so that you can address that alert fatigue, but they're still probabilistic models. So when should they be in the h- uh, when should the human be in the loop? That's the thing you've got to evaluate for the problems that you're solving.
- 17:45
At the end of the day though, what you saw there, what I gave you as an example, whether it's the human initiating it or the computer initiating it, um, you are seeing that we are using two main primitives in terms of you're applying a wait condition to pause that workflow and a signal from the human to be able to continue the work and say, "Here's the result. Now keep moving forward." And be m- mo- and whether you've actually paused it and taken it offline or you brought it back online.
- 18:15
And I've shown you that we can use multiple frameworks.
- 18:20
All right. If you have any questions, I'm gonna stick around for a few more minutes. Um, if you-- I've got up here a QR code that will take you to some resources about Temporal as well as some of the demos that I've done, uh, this demo included. This is up on GitHub. Uh, the slides itself will be up later 'cause of course, uh, in true form, I've been tweaking them up until now. So I'll be posting those up, uh, and linking them to the GitHub repo. But yeah, if you have questions, please reach out, um, and, you know, have fun building your agentic loops. I'm also
- 18:50
curious to hear what you're, what problems you're solving with agents and how you're building them autonomously currently, so feel free to find me. And thank you.