Temporal's Durable Execution: A Human-in-the-Loop Architecture That Keeps AI Agents Online

When "Humans Are an Asynchronous API"

At an AI Engineer conference, a speaker from Temporal put forward a thought-provoking idea: humans are, fundamentally, an asynchronous API for AI agents.

Almost everyone today is talking about the agentic loop — the cycle of reason, act, and observe. Whether you write it as a for loop or a while loop, the core of any agent is this continuously running cycle. But as we push agents toward greater autonomy, an unavoidable problem surfaces: humans respond too slowly.

A model can return a result in 200 milliseconds, but a human might take minutes, days, or even weeks to approve a decision. If you write "wait for human input" as an ordinary function call, it becomes a blocking call. Worse, if the service goes down, that waiting state is lost — and the system may have no idea where it left off.

The Ice Cream Delivery Demo: A Real-World Multi-Agent Scenario

The speaker used a "Ziggy Ice Cream Delivery" demo to illustrate the problem. In this scenario, multiple agents work together:

• Fleet Agent: Uses tools like Google Maps to research drivers and routes
• Customer Agent: Uses tools like Google Search to look up order information
• Dispatch Agent: Receives input from both and makes decisions

The demo integrates Google's ADK (Agent Development Kit, a multi-agent orchestration solution) with Temporal. ADK coordinates activity between agents, while Temporal is embedded to track and manage system state and provides a visual UI to display the event history of the entire workflow.

The key moment in the demo: when a customer modifies an order on the fly, the system pauses "Driver A" who is waiting on that update — but the rest of the system keeps running normally. New orders continue to come in and get fulfilled. Only the specific step tied to that change is waiting for another human's approval. When the approver clicks "approve," the update is processed and the order continues to its next destination (Oracle Park) for delivery.

This is what Temporal calls "durable execution."

Temporal's Three Core Primitives

Temporal's positioning is to help you standardize failure handling and state management in distributed systems — especially those involving agents. It's both software and a service: the software itself provides a set of ready-to-use primitives that can be applied directly to your code, supporting multiple languages including Python, TypeScript, and Rust.

The three most frequently cited core primitives are:

Worker

The execution unit that actually runs your code.

Workflow

Responsible for tracking steps in the system. Since an agent is itself a loop, an ADK framework or a single agent can run inside a workflow.

Activity

All operations that interact with the outside world. Within the loop, any model call or tool call should be set up as an activity.

In other words, you use these primitives to organize your code structure so the system becomes "stateful." Temporal itself is free and open source (self-hostable on GitHub) — you only pay when you let Temporal host your state service.

---

"Durable execution" is Temporal's core design philosophy, and understanding it helps clarify how these three primitives work together. In traditional distributed systems, program state lives in memory — if a process crashes, in-flight tasks are lost, and recovery typically relies on manual retries or external message queues. Temporal's approach is to persist the execution history of a Workflow as an immutable event log. When a Workflow recovers from a crash, the runtime doesn't re-execute all side effects — it "replays" the log, skipping already-completed Activities and restoring execution directly to the point of interruption, like fast-forwarding a tape to where it broke. This means developers can write long-running stateful tasks in a style close to ordinary sequential code, without having to manage checkpoint-and-resume logic, idempotency compensation, or similar complexity themselves. Activities are designed as the sole boundary between the system and the outside world precisely so Temporal knows which operations have side effects and which results need to be recorded in the log.

---

Wait Condition and Signal: Taming the "Asynchronous Human"

Back to the central challenge of human-in-the-loop. Humans aren't tools, yet from an agent's perspective they function like one — so how do you elegantly handle these slow, potentially long-blocking interactions?

The answer is a combination of two key primitives: wait condition and signal.

The approach is: isolate an event, apply a wait condition to it, and store that state in the workflow's persistence layer. This means:

• The system isn't blocked by a call to a human; the rest keeps running
• If the system crashes, it can resume from where it left off after restarting
• You can send a signal at any point to resume the flow
• It doesn't occupy a thread and can survive crashes
• Built-in mechanisms like timeout are available — you can set a maximum wait time for human responses

The speaker emphasized that even with millions of workflows in a "parked" state waiting for input, the system continues to run.

In the second demo, the dispatch agent determines that a special order requires human intervention and enters a pause state waiting for approval. At this point, the speaker deliberately kills the worker service and clicks "approve" while it's offline. Because the event's state is stored in a separate data store, the approval action is queued. When the service comes back online, the event log is "replayed" rather than "redone" — it replays up to the last interruption point, recognizes that the human has approved, and the order is assigned and delivered. This is the disaster recovery capability that durable execution provides.

---

The concept of "signal" is borrowed from message-passing mechanisms in operating systems and the actor model. In Temporal, a running Workflow instance has a unique ID, and external systems can send signals to it via that ID — essentially an asynchronous message with a data payload. Inside the Workflow, a wait condition declares "continue only when a certain condition is true," and the signal handler is responsible for updating that condition. This mechanism is philosophically aligned with event-driven architecture, but the key difference lies in state ownership: event-driven systems typically externalize state to a database or message queue, and developers must ensure idempotency and ordering themselves. Temporal internalizes the waiting state into the Workflow itself, with persistence managed by the framework — developers only need to declare "what to wait for" and "what to do when it arrives." This is also why millions of paused Workflows don't occupy threads — they're simply a suspended record in the log, only scheduled for execution when awakened.

---

When Should Humans Enter the Loop?

This is the question the speaker considers hardest to answer. His criteria are straightforward and practical:

The core is assessing the cost of getting it wrong. When the cost of error is high — especially in safety-critical scenarios — human approval becomes more important. It's a case-by-case tradeoff.

But the other side of the scale is alert fatigue. Many people have experienced this: when a system constantly asks "do you want to approve this?", you start mechanically clicking yes, yes, yes. Models are probabilistic and can't be made perfectly reliable, so while we rely on humans as a safety net, we can't let humans be buried under a flood of meaningless confirmation requests. The industry's push to make models more trustworthy is, in part, an effort to alleviate this fatigue.

Whether initiated by a human or a computer, whether you're taking a process fully offline or bringing it back online, the underlying mechanism is always those two primitives: use wait condition to pause the workflow, use signal to resume it and pass back the result. And this mechanism can be reused across multiple frameworks.

---

"Alert fatigue" was originally a medical concept describing how ICU nurses become desensitized to genuine alarms due to frequent false alerts from monitoring equipment. It was later widely adopted in information security and DevOps. In the context of AI agents, it refers to how approvers lose their ability to discriminate when systems over-request human confirmation — treating high-risk and low-risk operations with equal indifference and waving them all through, effectively nullifying the safety guarantee that human review was supposed to provide. This issue has been studied extensively in Security Operations Center (SOC) contexts, where research shows that high false-positive rates don't reduce risk — they systematically degrade human response quality to genuine threats. Human-in-the-loop design is therefore not just a technical problem; it's a human factors engineering problem that requires thoughtful trigger thresholds, tiered approval flows, and contextual presentation to ensure human attention is spent where it actually matters.

---

Closing Thoughts

While this talk has an obvious product-marketing angle, the engineering problems it identifies are real and widespread. As agentic systems grow more complex and increasingly dependent on human-machine collaboration, ensuring state is never lost and systems never go dark will become a critical piece of bringing agents into production. Temporal's answer — treating humans as an asynchronous API that can be waited on and awakened by a signal — offers a clear architectural model worth considering for any developer building agentic systems.