AI Engineer World's Fair 2026
The Human Is an Async API — Melanie Warrick, Temporal
Slide chapters
22 slide and demo groups · Timestamps are approximate. 16 additional groups were omitted from this pass.
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.
The high-value order survives the worker outage
Read the diagram as text
- Assess the high-value order. Order execution — Customer and fleet agents send their results to dispatch.
- Wait for a human. Order execution — Dispatch pauses this order’s progression; other deliveries continue.
- Worker goes offline. Worker outage — Kill Worker disconnects the executing process.
- Human presses Approve. Worker outage — The response arrives while the worker is offline.
- Approval event is queued. Preserved state — A separate data store tracks the event outside the worker.
- Worker returns and replays history. Recovery — Reconstruct the prior state and receive the queued approval.
- Assign and deliver the order. Recovery — Execution continues from the recovered state.
- Assess the high-value order → Wait for a human: Dispatch requests human involvement.
- Wait for a human → Worker goes offline: Worker is killed during the wait.
- Worker goes offline → Human presses Approve: Human responds during the outage.
- Human presses Approve → Approval event is queued: Record and queue the response.
- Approval event is queued → Worker returns and replays history: Approval is available when execution resumes.
- Worker returns and replays history → Assign and deliver the order: Continue with the approved decision.
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
10 slide groups · 12 demo milestones. Extracted from the recording; expand builds to follow changes. Timestamps are approximate. 16 additional groups were omitted from this pass.
- 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
Ice cream delivery dashboard
Ziggy’s dashboard maps deliveries while fleet, customer and dispatch agents coordinate orders. A customer-change control lets a human submit a new destination during delivery.
Text in image
MELTDOWN DURABLE HUMAN-IN-THE-LOOP Ice Cream Delivery · San Francisco Temporal | Google ADK Human → Agent Human-initiated Agent → Human Agent-initiated Cross-Framework ADK + LangGraph SERVICE ONLINE CONTROLS START DELIVERIES Customer changes an order mid-delivery — the driver holds, you approve, then the ADK agents re-reason the new location and the driver reroutes. order-12 — Moscone Center (driver-b) Address Change Oracle Park Submit Change Reset View the ADK agents ADK AGENT TEAM FLEET AGENT — COMPLETE Operations and logistics FLEET STATUS · ROUTE INFO ASSESSMENT driver-a — 10min ETA, closest with capacity. ASSESSMENT driver-b — 13min ETA, closest with capacity. ASSESSMENT driver-a — 4min ETA, closest with capacity. ASSESSMENT driver-c — 1min ETA, closest with capacity. ASSESSMENT driver-d — 5min ETA, closest with capacity. DELIVERY FLEET Driver-A — EN ROUTE DELIVERY — Order: order-14 Driver-B — DELIVERING — Order: order-12 Driver-C — IDLE — Order: None CUSTOMER ORDERS 150 servings #6 VIP Moscone Center — DELIVERED Moscone Center conference catering — 80 servings Driver A — Deadline 35 min #7 Standard Fisherman's Wharf — DELIVERED Map labels: Fisherman's Wharf; Chinatown; Moscone Center; ZIGGY’S Map Style Interface text: localhost:8080 New Chrome available Temporal Spaces - Jira Apps-Dash temporal.io All Bookmarks
0:47Demo milestone
Delivery agent team
Fleet, customer and dispatch agents coordinate Ziggy’s ice cream deliveries. The dashboard shows their assessments alongside driver status, customer orders and delivery locations on a map.
Text in image
MELTDOWN DURABLE HUMAN-IN-THE-LOOP Ice Cream Delivery · San Francisco Temporal | Google ADK Human → Agent Human-initiated Agent → Human Agent-initiated Cross-Framework ADK + LangGraph SERVICE ONLINE CONTROLS ADK AGENT TEAM FLEET AGENT — COMPLETE Operations and logistics FLEET STATUS · ROUTE INFO driver-b — 13min ETA, closest with capacity. ASSESSMENT driver-a — 4min ETA, closest with capacity. ASSESSMENT driver-c — 1min ETA, closest with capacity. ASSESSMENT driver-d — 5min ETA, closest with capacity. ASSESSMENT driver-a — 5min ETA, closest with capacity. CUSTOMER AGENT — COMPLETE Priorities and deadlines ORDER PRIORITIES · GOOGLE SEARCH VIP, tight deadline (20min), Chinatown Night Market (10,000–18,000 visitors) ASSESSMENT VIP, tight deadline (20 minutes), 100 servings for banquet hall event. ASSESSMENT VIP, tight deadline (35min), Chinatown night market. DISPATCH AGENT — COMPLETE Weighs both, assigns driver FLEET INPUT · CUSTOMER INPUT Order #11 → driver-b — Fisherman's Wharf PLAN Order #12 → driver-b — Moscone Center PLAN Order #14 → driver-a — Chinatown PLAN DELIVERY FLEET Driver-A — DELIVERING — Order: order-14 Driver-B — IDLE — Order: None Driver-C — IDLE — Order: order-15 CUSTOMER ORDERS 150 servings #6 VIP Moscone Center — DELIVERED Moscone Center conference catering — 80 servings 80 servings Driver A · Deadline 35 min #7 Standard Fisherman's Wharf — DELIVERED Map labels: Fisherman's Wharf Chinatown Moscone Center ZIGGY'S Ice Cream Map Style Interface text: localhost:8080 New Chrome available
1:00Demo milestone
- 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
Ice cream delivery dashboard
Ziggy’s dashboard maps deliveries while fleet, customer and dispatch agents coordinate orders. A customer-change control lets a human submit a new destination during delivery.
Text in image
MELTDOWN DURABLE HUMAN-IN-THE-LOOP Ice Cream Delivery · San Francisco Temporal | Google ADK Human → Agent Human-initiated Agent → Human Agent-initiated Cross-Framework ADK + LangGraph SERVICE ONLINE CONTROLS START DELIVERIES Customer changes an order mid-delivery — the driver holds, you approve, then the ADK agents re-reason the new location and the driver reroutes. order-12 — Moscone Center (driver-b) Address Change Oracle Park Submit Change Reset View the ADK agents ADK AGENT TEAM FLEET AGENT — COMPLETE Operations and logistics FLEET STATUS · ROUTE INFO ASSESSMENT driver-a — 10min ETA, closest with capacity. ASSESSMENT driver-b — 13min ETA, closest with capacity. ASSESSMENT driver-a — 4min ETA, closest with capacity. ASSESSMENT driver-c — 1min ETA, closest with capacity. ASSESSMENT driver-d — 5min ETA, closest with capacity. DELIVERY FLEET Driver-A — EN ROUTE DELIVERY — Order: order-14 Driver-B — DELIVERING — Order: order-12 Driver-C — IDLE — Order: None CUSTOMER ORDERS 150 servings #6 VIP Moscone Center — DELIVERED Moscone Center conference catering — 80 servings Driver A — Deadline 35 min #7 Standard Fisherman's Wharf — DELIVERED Map labels: Fisherman's Wharf; Chinatown; Moscone Center; ZIGGY’S Map Style Interface text: localhost:8080 New Chrome available Temporal Spaces - Jira Apps-Dash temporal.io All Bookmarks
1:34Demo milestone
Cross-framework delivery demo
The delivery dashboard pairs Google ADK fleet and customer assessments with a LangGraph dispatch agent. Temporal tracks the workflows, while the dashboard offers controls for changing an order.
Text in image
MELTDOWN DURABLE HUMAN-IN-THE-LOOP Ice Cream Delivery · San Francisco Temporal | Google ADK + LangGraph Human → Agent Human-initiated Agent → Human Agent-initiated Cross-Framework ADK + LangGraph SERVICE ONLINE CONTROLS START DELIVERIES One system, two frameworks: Fleet + Customer assess on Google ADK, the Dispatch agent runs on LangGraph — each its own Temporal child workflow, joined by Temporal (no agent framework can orchestrate across frameworks). Both HITL directions work: drop a high-value order → the LangGraph dispatch agent calls ask_human; or change an order → the ADK team re-reasons and the driver reroutes. Agent → Human Drop high-value order Human → Agent order-17 — Fisherman's Wharf (driver-a) Address Change Oracle Park Submit Change Reset View the cross-framework graph DELIVERY FLEET Driver-A EN ROUTE DELIVERY Order: order-17, order-18 CUSTOMER ORDERS #1 Standard Fisherman's Wharf DELIVERED Driver A Deadline 30 min Fisherman's Wharf seafood fair afterparty — 120 servings 120 servings Map labels: ZIGGY'S, Chinatown, Moscone Center, SAN [illegible] Map Style ADK + LANGGRAPH AGENT TEAM FLEET AGENT COMPLETE Operations and logistics driver-d — 5min ETA, closest with capacity. 543 Workflows +27 6 Running +1 490 Completed +26 1 Failed 46 Terminated Start Workflow Add Filter Saved Views Status | Workflow ID | Run ID Running | order-generation | [illegible] Running | route-driver-d | [illegible] Running | route-driver-c | [illegible] Running | route-driver-b | [illegible] Running | route-driver-a | [illegible] Running | meltdown-demo | [illegible] Terminated | route-driver-d | [illegible] Terminated | route-driver-c | [illegible] Terminated | route-driver-b | [illegible] Terminated | route-driver-a | [illegible] Terminated | order-generation | [illegible] Terminated | dispatch-order-26 | [illegible] Terminated | meltdown-demo | [illegible] Completed | assess-order-26 | [illegible] Completed | dispatch-order-25 | [illegible] 100 1–100 of 543 default Interface text: localhost:8080 Temporal Spaces - Jira Apps-Dash temporal.io New Chrome available
1:38Demo milestone
- 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
Workflow event history
The delivery dashboard sits beside Temporal’s timeline and event history. The history shows the parent workflow coordinating the delivery activities across the agent frameworks.
Text in image
MELTDOWN DURABLE HUMAN-IN-THE-LOOP Ice Cream Delivery · San Francisco Temporal | Google ADK + LangGraph Human → Agent Human-initiated Agent → Human Agent-initiated Cross-Framework ADK + LangGraph SERVICE ONLINE CONTROLS START DELIVERIES One system, two frameworks: Fleet + Customer assess on Google ADK, the Dispatch agent runs on LangGraph — each its own Temporal child workflow, joined by Temporal (no agent framework can orchestrate across frameworks). Both HITL directions work: drop a high-value order → the LangGraph dispatch agent calls ask_human; or change an order → the ADK team re-reasons and the driver reroutes. Agent → Human Drop high-value order Human → Agent order-18 — Fisherman's Wharf (driver-a) Address Change Oracle Park Submit Change Reset View the cross-framework graph DELIVERY FLEET Driver-A PICKING UP Order: order-18 CUSTOMER ORDERS #1 Standard Fisherman's Wharf DELIVERED Driver A Deadline 30 min Fisherman's Wharf seafood fair afterparty — 120 servings 120 servings ZIGGY'S Chinatown Moscone Center ADK + LANGGRAPH AGENT TEAM FLEET AGENT COMPLETE Operations and logistics driver-a — 5min ETA, closest with capacity. Workflow timeline: [#20] ADK framework — Fleet | Customer assessment new_order add_order register_assignment · [#19] Dispatch Agent — order-19 → driver-b publish_agent_events_batch order_delivered [#19] LangGraph framework — dispatch decision add_order register_assignment · [#18] Dispatch Agent — order-18 → driver-a publish_agent_events_batch [#18] LangGraph framework — dispatch decision [#19] ADK framework — Fleet | Customer assessment new_order Event ID | Timestamp | Event Type 878 | 7/2/26, 2:27:34.32 PM PDT | Workflow Task Completed 877 | 7/2/26, 2:27:34.32 PM PDT | Workflow Task Started 876 | 7/2/26, 2:27:34.32 PM PDT | Workflow Task Scheduled 875 | 7/2/26, 2:27:34.32 PM PDT | Child Workflow Execution Started 874 | 7/2/26, 2:27:34.32 PM PDT | Start Child Workflow Execution Initiated 873 | 7/2/26, 2:27:34.32 PM PDT | Workflow Task Completed 872 | 7/2/26, 2:27:34.31 PM PDT | Workflow Task Started 871 | 7/2/26, 2:27:34.31 PM PDT | Workflow Task Scheduled 870 | 7/2/26, 2:27:34.31 PM PDT | Workflow Execution Signaled 869 | 7/2/26, 2:27:33.19 PM PDT | Workflow Task Completed 868 | 7/2/26, 2:27:33.18 PM PDT | Workflow Task Started 867 | 7/2/26, 2:27:33.18 PM PDT | Workflow Task Scheduled Interface text: localhost:8233/namespaces/default/workflows/[illegible]/history Temporal Spaces - Jira Apps-Dash temporal.io New Chrome available All Bookmarks default localhost:8080
1:51Demo milestone
Customer change and workflow history
A customer prepares an address change for order-18. The dashboard says the driver holds for approval before ADK agents reassess the route; beside it, Temporal shows the parent workflow’s event history.
Text in image
MELTDOWN DURABLE HUMAN-IN-THE-LOOP Ice Cream Delivery · San Francisco Temporal | Google ADK Human → Agent Human-initiated Agent → Human Agent-initiated Cross-Framework ADK + LangGraph SERVICE ONLINE CONTROLS START DELIVERIES Customer changes an order mid-delivery — the driver holds, you approve, then the ADK agents re-reason the new location and the driver reroutes. order-18 — Fisherman's Wharf (driver-a) Address Change Oracle Park Submit Change Reset View the ADK agents DELIVERY FLEET Driver-A EN ROUTE DELIVERY Order: order-18 CUSTOMER ORDERS #1 Standard Fisherman's Wharf DELIVERED Driver A Deadline 30 min Fisherman's Wharf seafood fair afterparty — 120 servings 120 servings Map labels: ZIGGY'S; Chinatown; Moscone Center ADK AGENT TEAM FLEET AGENT — COMPLETE Operations and logistics FLEET STATUS · ROUTE INFO ASSESSMENT driver-a — 5min ETA, closest with capacity. ASSESSMENT driver-d — 8min ETA, closest with capacity. ASSESSMENT driver-c — 13min ETA, closest with capacity. ASSESSMENT driver-a — 13min ETA, closest with capacity. ASSESSMENT driver-b — 10min ETA, closest with capacity. Workflow timeline: set_dispatch_mode 7 (30s) [#20] ADK framework — Fleet | Customer assessment new_order add_order register_assignment - [#19] Dispatch Agent — order-19 → driver-b publish_agent_events_batch order_delivered [#19] LangGraph framework — dispatch decision add_order register_assignment - [#18] Dispatch Agent — order-18 → driver-a publish_agent_events_batch [#18] LangGraph framework — dispatch decision [illegible] Event ID | Timestamp | Event Type 887 | 7/2/26, 2:27:39.36 PM PDT | Workflow Task Completed 886 | 7/2/26, 2:27:39.35 PM PDT | Workflow Task Started 885 | 7/2/26, 2:27:39.35 PM PDT | Workflow Task Scheduled 884 | 7/2/26, 2:27:39.35 PM PDT | Workflow Execution Signaled 883 | 7/2/26, 2:27:38.81 PM PDT | Timer Started 882 | 7/2/26, 2:27:38.81 PM PDT | Workflow Task Completed 881 | 7/2/26, 2:27:38.80 PM PDT | Workflow Task Started 880 | 7/2/26, 2:27:38.80 PM PDT | Workflow Task Scheduled 879 | 7/2/26, 2:27:38.80 PM PDT | Timer Fired 878 | 7/2/26, 2:27:34.32 PM PDT | Workflow Task Completed 877 | 7/2/26, 2:27:34.32 PM PDT | Workflow Task Started 876 | 7/2/26, 2:27:34.32 PM PDT | Workflow Task Scheduled Interface text: localhost:8080 New Chrome available Temporal Spaces - Jira Apps-Dash temporal.io All Bookmarks Map Style default localhost:8233
2:01Demo milestone
Show 2 builds
- 2:01
Customer-change controls and delivery map beside a workflow timeline and event history.
Text in image
MELTDOWN DURABLE HUMAN-IN-THE-LOOP Ice Cream Delivery · San Francisco Temporal | Google ADK Human → Agent Human-initiated Agent → Human Agent-initiated Cross-Framework ADK + LangGraph SERVICE ONLINE CONTROLS START DELIVERIES Customer changes an order mid-delivery — the driver holds, you approve, then the ADK agents re-reason the new location and the driver reroutes. order-18 — Fisherman's Wharf (driver-a) Address Change Oracle Park Submit Change Reset View the ADK agents DELIVERY FLEET Driver-A EN ROUTE DELIVERY Order: order-18 CUSTOMER ORDERS #1 Standard Fisherman's Wharf DELIVERED Driver A Deadline 30 min Fisherman's Wharf seafood fair afterparty — 120 servings 120 servings Map labels: ZIGGY'S; Chinatown; Moscone Center ADK AGENT TEAM FLEET AGENT — COMPLETE Operations and logistics FLEET STATUS · ROUTE INFO ASSESSMENT driver-a — 5min ETA, closest with capacity. ASSESSMENT driver-d — 8min ETA, closest with capacity. ASSESSMENT driver-c — 13min ETA, closest with capacity. ASSESSMENT driver-a — 13min ETA, closest with capacity. ASSESSMENT driver-b — 10min ETA, closest with capacity. Workflow timeline: set_dispatch_mode 7 (30s) [#20] ADK framework — Fleet | Customer assessment new_order add_order register_assignment - [#19] Dispatch Agent — order-19 → driver-b publish_agent_events_batch order_delivered [#19] LangGraph framework — dispatch decision add_order register_assignment - [#18] Dispatch Agent — order-18 → driver-a publish_agent_events_batch [#18] LangGraph framework — dispatch decision [illegible] Event ID | Timestamp | Event Type 887 | 7/2/26, 2:27:39.36 PM PDT | Workflow Task Completed 886 | 7/2/26, 2:27:39.35 PM PDT | Workflow Task Started 885 | 7/2/26, 2:27:39.35 PM PDT | Workflow Task Scheduled 884 | 7/2/26, 2:27:39.35 PM PDT | Workflow Execution Signaled 883 | 7/2/26, 2:27:38.81 PM PDT | Timer Started 882 | 7/2/26, 2:27:38.81 PM PDT | Workflow Task Completed 881 | 7/2/26, 2:27:38.80 PM PDT | Workflow Task Started 880 | 7/2/26, 2:27:38.80 PM PDT | Workflow Task Scheduled 879 | 7/2/26, 2:27:38.80 PM PDT | Timer Fired 878 | 7/2/26, 2:27:34.32 PM PDT | Workflow Task Completed 877 | 7/2/26, 2:27:34.32 PM PDT | Workflow Task Started 876 | 7/2/26, 2:27:34.32 PM PDT | Workflow Task Scheduled Interface text: localhost:8080 New Chrome available Temporal Spaces - Jira Apps-Dash temporal.io All Bookmarks Map Style default localhost:8233
- 2:08
Delivery dashboard with an address change prepared and workflow history beside it.
Text in image
MELTDOWN DURABLE HUMAN-IN-THE-LOOP Ice Cream Delivery · San Francisco Temporal | Google ADK Human → Agent Human-initiated Agent → Human Agent-initiated Cross-Framework ADK + LangGraph SERVICE ONLINE CONTROLS START DELIVERIES Customer changes an order mid-delivery — the driver holds, you approve, then the ADK agents re-reason the new location and the driver reroutes. order-18 — Fisherman's Wharf (driver-a) Address Change Oracle Park Submit Change Reset View the ADK agents DELIVERY FLEET Driver-A EN ROUTE DELIVERY Order: order-18 CUSTOMER ORDERS #1 Standard Fisherman's Wharf DELIVERED Driver A Deadline 30 min Fisherman's Wharf seafood fair afterparty — 120 servings 120 servings Map labels: ZIGGY'S; Chinatown; Moscone Center ADK AGENT TEAM FLEET AGENT — COMPLETE Operations and logistics FLEET STATUS · ROUTE INFO ASSESSMENT driver-a — 5min ETA, closest with capacity. ASSESSMENT driver-d — 8min ETA, closest with capacity. ASSESSMENT driver-c — 13min ETA, closest with capacity. ASSESSMENT driver-a — 13min ETA, closest with capacity. ASSESSMENT driver-b — 10min ETA, closest with capacity. Workflow timeline: [#20] LangGraph framework — dispatch decision set_dispatch_mode 7 (30s) [#20] ADK framework — Fleet | Customer assessment new_order add_order register_assignment - [#19] Dispatch Agent — order-19 → driver-b publish_agent_events_batch order_delivered [#19] LangGraph framework — dispatch decision add_order register_assignment - [#18] Dispatch Agent — order-18 → driver-a publish_agent_events_batch [illegible] Event ID | Timestamp | Event Type 898 | 7/2/26, 2:27:49.26 PM PDT | Workflow Task Scheduled 897 | 7/2/26, 2:27:49.26 PM PDT | Child Workflow Execution Completed 896 | 7/2/26, 2:27:47.06 PM PDT | Workflow Task Completed 895 | 7/2/26, 2:27:47.06 PM PDT | Workflow Task Started 894 | 7/2/26, 2:27:47.06 PM PDT | Workflow Task Scheduled 893 | 7/2/26, 2:27:47.06 PM PDT | Child Workflow Execution Started 892 | 7/2/26, 2:27:47.06 PM PDT | Start Child Workflow Execution Initiated 891 | 7/2/26, 2:27:47.06 PM PDT | Workflow Task Completed 890 | 7/2/26, 2:27:47.05 PM PDT | Workflow Task Started 889 | 7/2/26, 2:27:47.05 PM PDT | Workflow Task Scheduled 888 | 7/2/26, 2:27:47.05 PM PDT | Child Workflow Execution Completed 887 | 7/2/26, 2:27:39.36 PM PDT | Workflow Task Completed Interface text: localhost:8080 New Chrome available Temporal Spaces - Jira Apps-Dash temporal.io All Bookmarks Map Style default localhost:8233
- 2:01
Change awaiting approval
An address change to Oracle Park awaits approval or rejection. Driver A pauses for the update while the delivery system keeps running; the workflow history remains visible beside the dashboard.
Text in image
MELTDOWN DURABLE HUMAN-IN-THE-LOOP Ice Cream Delivery · San Francisco Temporal Google ADK Human → Agent Human-initiated Agent → Human Agent-initiated Cross-Framework ADK + LangGraph SERVICE ONLINE CONTROLS START DELIVERIES Customer changes an order mid-delivery — the driver holds, you approve, then the ADK agents re-reason the new location and the driver reroutes. order-18 — Fisherman's Wharf (driver-a) Address Change Oracle Park Submit Change Reset Address change for order-18 — awaiting approval... Approve Reject View the ADK agents DELIVERY FLEET Driver-A EN ROUTE DELIVERY Order: order-18 CUSTOMER ORDERS #1 Standard Fisherman's Wharf DELIVERED Driver A Deadline 30 min Fisherman's Wharf seafood fair afterparty — 120 servings 120 servings Map: ZIGGY'S; Chinatown; Moscone Center; Oracle Park Map Style ADK AGENT TEAM FLEET AGENT COMPLETE Operations and logistics FLEET STATUS · ROUTE INFO driver-d — 8min ETA, closest with capacity. ASSESSMENT driver-c — 13min ETA, closest with capacity. ASSESSMENT driver-a — 13min ETA, closest with capacity. ASSESSMENT driver-b — 10min ETA, closest with capacity. ASSESSMENT Workflow timeline: Attempt 1 / ∞ · invoke_model · [#21] Customer Agent — LLM reasoning on order priorities invoke_model · Customer Agent — evaluating order tool_get_order_priorities · Customer Agent — get order priorities Attempt 1 / ∞ · invoke_model · [#21] Fleet Agent — LLM reasoning on fleet data tool_get_fleet_status · Fleet Agent — get fleet status order_delivered publish_agent_event update_pending customer_change invoke_model · [#21] Customer Agent — evaluating order for Moscone Center invoke_model · [#21] Fleet Agent — evaluating order for Moscone Center new_order add_order [illegible] Event history: Event ID | Timestamp | Event Type 944 | 7/2/26, 2:27:50.54 PM PDT | Pending Activity 962 | 7/2/26, 2:27:54.28 PM PDT | Pending Activity 962 | 7/2/26, 2:27:54.28 PM PDT | Activity Task Scheduled 961 | 7/2/26, 2:27:54.28 PM PDT | Workflow Task Completed 960 | 7/2/26, 2:27:54.27 PM PDT | Workflow Task Started 959 | 7/2/26, 2:27:54.27 PM PDT | Workflow Task Scheduled 958 | 7/2/26, 2:27:54.27 PM PDT | Activity Task Completed 957 | 7/2/26, 2:27:50.80 PM PDT | Activity Task Started 956 | 7/2/26, 2:27:50.80 PM PDT | Workflow Task Completed 955 | 7/2/26, 2:27:50.80 PM PDT | Workflow Task Started 954 | 7/2/26, 2:27:50.80 PM PDT | Workflow Task Scheduled 953 | 7/2/26, 2:27:50.80 PM PDT | Activity Task Completed Interface text: Chrome localhost:8080 New Chrome available Temporal Spaces - Jira Apps-Dash temporal.io All Bookmarks default localhost:8233
2:11Demo milestone
- 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,
Parent workflow details
An address change for order-18 awaits approval while driver A pauses. Beside the delivery dashboard, the parent workflow remains running and displays its input and history.
Text in image
MELTDOWN DURABLE HUMAN-IN-THE-LOOP Ice Cream Delivery · San Francisco Temporal Google ADK Human → Agent Human-initiated Agent → Human Agent-initiated Cross-Framework ADK + LangGraph SERVICE ONLINE CONTROLS START DELIVERIES Customer changes an order mid-delivery — the driver holds, you approve, then the ADK agents re-reason the new location and the driver reroutes. order-18 — Fisherman's Wharf (driver-a) Address Change Oracle Park Submit Change Reset Address change for order-18 — awaiting approval... Approve Reject View the ADK agents DELIVERY FLEET Driver-A EN ROUTE DELIVERY Order: order-18 CUSTOMER ORDERS #1 Standard Fisherman's Wharf DELIVERED Driver A Deadline 30 min Fisherman's Wharf seafood fair afterparty — 120 servings 120 servings ZIGGY'S Chinatown Moscone Center Oracle Park ADK AGENT TEAM FLEET AGENT Operations and logistics COMPLETE FLEET STATUS • ROUTE INFO driver-c — 13min ETA, closest with capacity. ASSESSMENT driver-a — 13min ETA, closest with capacity. ASSESSMENT driver-b — 10min ETA, closest with capacity. ASSESSMENT driver-b — 13min ETA, closest with capacity. ASSESSMENT Back to Workflows Running Request Cancellation More Actions meltdown-demo Start Jul 2, 2026, 2:24:38.65 PM PDT End - Duration 3m 20s 829ms Run ID [illegible] Workflow Type MeltdownDemoWorkflow Task Queue meltdown-workflows History Size (Bytes) 516306 State Transitions 689 SDK Python 1.27.2 History 989 Relationships 41 Workers 1 Pending Activities 1 Call Stack Queries User Metadata Search Attributes Memo Input { "escalation_enabled": false, "max_orders": 50, "dispatch_mode": "adk", "history_threshold": 0, "driver_orders": {}, "orders_generated": 0, "reprocess_counts": {} } Result Results will appear upon completion. Interface text: localhost:8080 Temporal Spaces - Jira Apps-Dash temporal.io All Bookmarks New Chrome available default localhost:82332:18Demo milestone
Workflow list
An address change for order 18 awaits approval, pausing driver A while the rest of the delivery system keeps running.
Text in image
MELTDOWN DURABLE HUMAN-IN-THE-LOOP Ice Cream Delivery · San Francisco Temporal Google ADK Human → Agent Human-initiated Agent → Human Agent-initiated Cross-Framework ADK + LangGraph SERVICE ONLINE CONTROLS START DELIVERIES Customer changes an order mid-delivery — the driver holds, you approve, then the ADK agents re-reason the new location and the driver reroutes. order-18 — Fisherman's Wharf (driver-a) Address Change Oracle Park Submit Change Reset Address change for order-18 — awaiting approval... Approve Reject View the ADK agents DELIVERY FLEET Driver-A EN ROUTE DELIVERY Order: order-18 CUSTOMER ORDERS #1 Standard Fisherman's Wharf DELIVERED Driver A Deadline 30 min Fisherman's Wharf seafood fair afterparty — 120 servings 120 servings Map labels: ZIGGY'S, Chinatown, Moscone Center, Oracle Park ADK AGENT TEAM FLEET AGENT COMPLETE Operations and logistics FLEET STATUS · ROUTE INFO driver-a — 13min ETA, closest with capacity. ASSESSMENT driver-b — 10min ETA, closest with capacity. ASSESSMENT driver-b — 13min ETA, closest with capacity. ASSESSMENT driver-b — [illegible]min ETA, closest with capacity. ASSESSMENT 579 Workflows Jul 2, 2026, [illegible] PM PDT 6 Running 526 Completed 1 Failed 46 Terminated Start Workflow Add Filter Saved Views Status | Workflow ID | Run ID Running | order-generation | [illegible] Running | route-driver-d | [illegible] Running | route-driver-c | [illegible] Running | route-driver-b | [illegible] Running | route-driver-a | [illegible] Running | meltdown-demo | [illegible] Completed | dispatch-order-20 | [illegible] Completed | assess-order-20 | [illegible] Completed | dispatch-order-19 | [illegible] Completed | assess-order-19 | [illegible] Completed | dispatch-order-18 | [illegible] Completed | assess-order-18 | [illegible] Completed | dispatch-order-17 | [illegible] Completed | assess-order-17 | [illegible] Completed | dispatch-order-16 | [illegible] No Views 100 1–100 of 579 Interface text: localhost:8233/namespaces/default/workflows Temporal Spaces - Jira Apps-Dash temporal.io All Bookmarks New Chrome available default localhost:8080
2:28Demo milestone
Driver workflow history
An address change pauses driver A while the rest of the delivery system keeps running. The dashboard awaits human approval beside the driver’s workflow history.
Text in image
MELTDOWN Ice Cream Delivery · San Francisco DURABLE HUMAN-IN-THE-LOOP Temporal Google ADK Human → Agent Human-initiated Agent → Human Agent-initiated Cross-Framework ADK + LangGraph SERVICE ONLINE CONTROLS START DELIVERIES Customer changes an order mid-delivery — the driver holds, you approve, then the ADK agents re-reason the new location and the driver reroutes. order-18 — Fisherman's Wharf (driver-a) Address Change Oracle Park Submit Change Reset Address change for order-18 — awaiting approval... Approve Reject View the ADK agents DELIVERY FLEET Driver-A EN ROUTE DELIVERY Order: order-18 CUSTOMER ORDERS #1 Standard Fisherman's Wharf DELIVERED Driver A Deadline 30 min Fisherman's Wharf seafood fair afterparty — 120 servings 120 servings Map labels: ZIGGY'S, Chinatown, Moscone Center, Oracle Park ADK AGENT TEAM FLEET AGENT Operations and logistics COMPLETE FLEET STATUS · ROUTE INFO driver-b — 10min ETA, closest with capacity. ASSESSMENT driver-b — 13min ETA, closest with capacity. ASSESSMENT driver-b — [illegible]min ETA, closest with capacity. ASSESSMENT driver-d — 10min ETA, closest with capacity. ASSESSMENT Results will appear upon completion. Event History Auto Refresh On update_pending update_pending navigate_to - [#18] Driving to Fisherman's Wharf get_route_polyline - [#18] Calculating route to Fisherman's Wharf pickup_orders - [#18] Loading 1 order(s) at Ziggy's 12 (2s) set_driver_idle navigate_to - Returning to Ziggy's get_route_polyline - Calculating return to Ziggy's order_delivered deliver_order - [#17] Order delivered to Fisherman's Wharf add_order navigate_to - [#17] Driving to Fisherman's Wharf Event ID | Timestamp | Event Type 354 | 7/2/26, 2:27:51.76 PM PDT | Workflow Task Completed 353 | 7/2/26, 2:27:51.75 PM PDT | Workflow Task Started 352 | 7/2/26, 2:27:51.75 PM PDT | Workflow Task Scheduled 351 | 7/2/26, 2:27:51.75 PM PDT | Activity Task Completed 350 | 7/2/26, 2:27:39.68 PM PDT | Activity Task Started 349 | 7/2/26, 2:27:49.80 PM PDT | Workflow Task Completed 348 | 7/2/26, 2:27:49.80 PM PDT | Workflow Task Started 347 | 7/2/26, 2:27:49.80 PM PDT | Workflow Task Scheduled 346 | 7/2/26, 2:27:49.80 PM PDT | Workflow Execution Signaled Interface text: localhost:8233/namespaces/default/workflows/route-driver-a/[illegible]/history Temporal Spaces - Jira Apps-Dash temporal.io New Chrome available All Bookmarks localhost:8080 default
2:37Demo milestone
- 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
Delivery order change
After approval, the control shows order-18’s new destination, Oracle Park, while other deliveries continue. The adjacent workflow history records the pending update.
Text in image
MELTDOWN Ice Cream Delivery · San Francisco DURABLE HUMAN-IN-THE-LOOP Temporal | Google ADK Human → Agent Human-initiated Agent → Human Agent-initiated Cross-Framework ADK + LangGraph SERVICE ONLINE CONTROLS START DELIVERIES Customer changes an order mid-delivery — the driver holds, you approve, then the ADK agents re-reason the new location and the driver reroutes. order-18 — Oracle Park (driver-a) Address Change Oracle Park Submit Change Reset View the ADK agents DELIVERY FLEET Driver-A EN ROUTE DELIVERY Order: order-18 CUSTOMER ORDERS #1 Standard Fisherman’s Wharf DELIVERED Driver A Deadline 30 min Fisherman’s Wharf seafood fair afterparty — 120 servings 120 servings ZIGGY’S Chinatown Moscone Center Oracle Park ADK AGENT TEAM FLEET AGENT Operations and logistics COMPLETE FLEET STATUS · ROUTE INFO driver-b — 13min ETA, closest with capacity. ASSESSMENT driver-b — 1min ETA, closest with capacity. ASSESSMENT driver-d — 10min ETA, closest with capacity. ASSESSMENT driver-b — 2min ETA, closest with capacity. ASSESSMENT driver-a — 1min ETA, closest with capacity. Result Results will appear upon completion. Event History Auto Refresh On update_pending update_pending navigate_to · (#18) Driving to Fisherman’s Wharf get_route_polyline · (#18) Calculating route to Fisherman’s Wharf pickup_orders · (#18) Loading 1 order(s) at Ziggy’s 12 (2s) set_driver_idle navigate_to · Returning to Ziggy’s get_route_polyline · Calculating return to Ziggy’s order_delivered deliver_order · (#17) Order delivered to Fisherman’s Wharf add_order navigate_to · (#17) Driving to Fisherman’s Wharf Event ID | Timestamp | Event Type 354 | 7/2/26, 2:27:51.76 PM PDT | Workflow Task Completed 353 | 7/2/26, 2:27:51.75 PM PDT | Workflow Task Started 352 | 7/2/26, 2:27:51.75 PM PDT | Workflow Task Scheduled 351 | 7/2/26, 2:27:51.75 PM PDT | Activity Task Completed 350 | 7/2/26, 2:27:39.68 PM PDT | Activity Task Started 349 | 7/2/26, 2:27:49.80 PM PDT | Workflow Task Completed Interface text: localhost:8080 Temporal Spaces - Jira Apps-Dash temporal.io New Chrome available All Bookmarks Map Style localhost:8233
2:58Demo milestone
Show 2 builds
- 2:58
Delivery dashboard showing the order's updated destination beside the driver's workflow history.
Text in image
MELTDOWN Ice Cream Delivery · San Francisco DURABLE HUMAN-IN-THE-LOOP Temporal | Google ADK Human → Agent Human-initiated Agent → Human Agent-initiated Cross-Framework ADK + LangGraph SERVICE ONLINE CONTROLS START DELIVERIES Customer changes an order mid-delivery — the driver holds, you approve, then the ADK agents re-reason the new location and the driver reroutes. order-18 — Oracle Park (driver-a) Address Change Oracle Park Submit Change Reset View the ADK agents DELIVERY FLEET Driver-A EN ROUTE DELIVERY Order: order-18 CUSTOMER ORDERS #1 Standard Fisherman’s Wharf DELIVERED Driver A Deadline 30 min Fisherman’s Wharf seafood fair afterparty — 120 servings 120 servings ZIGGY’S Chinatown Moscone Center Oracle Park ADK AGENT TEAM FLEET AGENT Operations and logistics COMPLETE FLEET STATUS · ROUTE INFO driver-b — 13min ETA, closest with capacity. ASSESSMENT driver-b — 1min ETA, closest with capacity. ASSESSMENT driver-d — 10min ETA, closest with capacity. ASSESSMENT driver-b — 2min ETA, closest with capacity. ASSESSMENT driver-a — 1min ETA, closest with capacity. Result Results will appear upon completion. Event History Auto Refresh On update_pending update_pending navigate_to · (#18) Driving to Fisherman’s Wharf get_route_polyline · (#18) Calculating route to Fisherman’s Wharf pickup_orders · (#18) Loading 1 order(s) at Ziggy’s 12 (2s) set_driver_idle navigate_to · Returning to Ziggy’s get_route_polyline · Calculating return to Ziggy’s order_delivered deliver_order · (#17) Order delivered to Fisherman’s Wharf add_order navigate_to · (#17) Driving to Fisherman’s Wharf Event ID | Timestamp | Event Type 354 | 7/2/26, 2:27:51.76 PM PDT | Workflow Task Completed 353 | 7/2/26, 2:27:51.75 PM PDT | Workflow Task Started 352 | 7/2/26, 2:27:51.75 PM PDT | Workflow Task Scheduled 351 | 7/2/26, 2:27:51.75 PM PDT | Activity Task Completed 350 | 7/2/26, 2:27:39.68 PM PDT | Activity Task Started 349 | 7/2/26, 2:27:49.80 PM PDT | Workflow Task Completed Interface text: localhost:8080 Temporal Spaces - Jira Apps-Dash temporal.io New Chrome available All Bookmarks Map Style localhost:8233
- 3:04
Delivery dashboard with an address-change control, map, and workflow event history.
Text in image
MELTDOWN Ice Cream Delivery · San Francisco DURABLE HUMAN-IN-THE-LOOP Temporal | Google ADK Human → Agent Human-initiated Agent → Human Agent-initiated Cross-Framework ADK + LangGraph SERVICE ONLINE CONTROLS START DELIVERIES Customer changes an order mid-delivery — the driver holds, you approve, then the ADK agents re-reason the new location and the driver reroutes. order-18 — Oracle Park (driver-a) Address Change Oracle Park Submit Change Reset View the ADK agents DELIVERY FLEET Driver-A EN ROUTE DELIVERY Order: order-18 CUSTOMER ORDERS #1 Standard Fisherman’s Wharf DELIVERED Driver A Deadline 30 min Fisherman’s Wharf seafood fair afterparty — 120 servings 120 servings ZIGGY’S Chinatown Moscone Center Oracle Park ADK AGENT TEAM FLEET AGENT Operations and logistics COMPLETE FLEET STATUS · ROUTE INFO driver-b — 13min ETA, closest with capacity. ASSESSMENT driver-b — 1min ETA, closest with capacity. ASSESSMENT driver-d — 10min ETA, closest with capacity. ASSESSMENT driver-b — 2min ETA, closest with capacity. ASSESSMENT driver-a — 1min ETA, closest with capacity. "driver_id": "driver-a", "current_lat": 0, "current_lng": 0, "delivered_total": 0, "history_threshold": 0 } Result Results will appear upon completion. Event History Auto Refresh On update_pending update_pending navigate_to · (#18) Driving to Fisherman’s Wharf get_route_polyline · (#18) Calculating route to Fisherman’s Wharf pickup_orders · (#18) Loading 1 order(s) at Ziggy’s 12 (2s) set_driver_idle navigate_to · Returning to Ziggy’s get_route_polyline · Calculating return to Ziggy’s order_delivered deliver_order · (#17) Order delivered to Fisherman’s Wharf add_order navigate_to · (#17) Driving to Fisherman’s Wharf Event ID | Timestamp | Event Type 354 | 7/2/26, 2:27:51.76 PM PDT | Workflow Task Completed 353 | 7/2/26, 2:27:51.75 PM PDT | Workflow Task Started 352 | 7/2/26, 2:27:51.75 PM PDT | Workflow Task Scheduled Interface text: localhost:8080 Temporal Spaces - Jira Apps-Dash temporal.io New Chrome available All Bookmarks Map Style localhost:8233
- 2:58
- 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.
Order rerouted
The address change is processed, and driver A reroutes order 18 to Oracle Park while the rest of the delivery system keeps running.
Text in image
MELTDOWN Ice Cream Delivery · San Francisco DURABLE HUMAN-IN-THE-LOOP Temporal Google ADK Human → Agent Human-initiated Agent → Human Agent-initiated Cross-Framework ADK + LangGraph SERVICE ONLINE CONTROLS START DELIVERIES Customer changes an order mid-delivery — the driver holds, you approve, then the ADK agents re-reason the new location and the driver reroutes. order-18 — Oracle Park (driver-a) Address Change Oracle Park Submit Change Reset View the ADK agents DELIVERY FLEET Driver-A EN ROUTE DELIVERY Order: order-18 CUSTOMER ORDERS Moscone Center expo hall social — 60 servings 60 servings ZIGGY’S Chinatown Moscone Center Oracle Park ADK AGENT TEAM FLEET AGENT COMPLETE Operations and logistics FLEET STATUS • ROUTE INFO ASSESSMENT driver-d — 10min ETA, closest with capacity. ASSESSMENT driver-b — 2min ETA, closest with capacity. ASSESSMENT driver-a — 1min ETA, closest with capacity. ASSESSMENT driver-b — 0min ETA, closest with capacity. ASSESSMENT driver-c — 5min ETA, closest with capacity. [illegible] "driver_id": "driver-a", "current_lat": 0, "current_lng": 0, "delivered_total": 0, "history_threshold": 0 } Result Results will appear upon completion. Event History Auto Refresh On Attempt 1 / [illegible] — navigate_to — (#18) Rerouting to new destination get_route_polyline — (#18) Rerouting to new destination resolve_update update_order update_pending update_pending navigate_to — (#18) Driving to Fisherman's Wharf get_route_polyline — (#18) Calculating route to Fisherman's Wharf pickup_orders — (#18) Loading 1 order(s) at Ziggy's 12 (2s) set_driver_idle navigate_to — Returning to Ziggy's get_route_polyline — Calculating return to Ziggy's Event ID Timestamp Event Type 369 7/2/26, 2:28:53.29 PM PDT Pending Activity 369 7/2/26, 2:28:53.29 PM PDT Activity Task Scheduled 368 7/2/26, 2:28:53.29 PM PDT Workflow Task Completed default Interface text: localhost:8080 New Chrome available Temporal Spaces - Jira Apps-Dash temporal.io All Bookmarks Map Style localhost:8233
3:14Demo milestone
Order delivered
After the address change is processed, driver A delivers the order to Oracle Park. The workflow history shows the rerouting steps followed by delivery.
Text in image
MELTDOWN Ice Cream Delivery · San Francisco DURABLE HUMAN-IN-THE-LOOP Temporal Google ADK Human → Agent Human-initiated Agent → Human Agent-initiated Cross-Framework ADK + LangGraph SERVICE ONLINE CONTROLS START DELIVERIES Customer changes an order mid-delivery — the driver holds, you approve, then the ADK agents re-reason the new location and the driver reroutes. order-18 — Oracle Park (driver-a) Address Change Oracle Park Submit Change Reset View the ADK agents DELIVERY FLEET Driver-A DELIVERING Order: order-18 CUSTOMER ORDERS Moscone Center expo hall social — 60 servings 60 servings ZIGGY’S Ice Cream Chinatown Moscone Center Oracle Park Remove Map Style ADK AGENT TEAM FLEET AGENT Operations and logistics COMPLETE • FLEET STATUS • ROUTE INFO driver-d — 10min ETA, closest with capacity. ASSESSMENT driver-b — 2min ETA, closest with capacity. ASSESSMENT driver-a — 1min ETA, closest with capacity. ASSESSMENT driver-b — 0min ETA, closest with capacity. ASSESSMENT driver-c — 5min ETA, closest with capacity. "driver_id": "driver-a", "current_lat": 0, "current_lng": 0, "delivered_total": 0, "history_threshold": 0 } Result Results will appear upon completion. Event History Auto Refresh On deliver_order - [#18] Order delivered to Oracle Park navigate_to - [#18] Rerouting to new destination get_route_polyline - [#18] Rerouting to new destination resolve_update update_order update_pending update_pending navigate_to - [#18] Driving to Fisherman's Wharf get_route_polyline - [#18] Calculating route to Fisherman's Wharf pickup_orders - [#18] Loading 1 order(s) at Ziggy's 12 (2s) set_driver_idle navigate_to - Returning to Ziggy's Event ID Timestamp Event Type 43 Pending Activity 375 7/2/26, 2:29:05.36 PM PDT Activity Task Scheduled 374 7/2/26, 2:29:05.36 PM PDT Workflow Task Completed default Interface text: localhost:8080 Temporal Spaces - Jira Apps-Dash temporal.io New Chrome available All Bookmarks localhost:8233
3:27Demo milestone
The Human is an Async API
Melanie Warrick introduces her talk on designing durable human-in-the-loop agents.
Text in image
The Human is an Async API Designing durable human-in-the-loop agents. Melanie Warrick · AI & DevRel @ Temporal Temporal ZIGGY’S Ice Cream Interface text: Chrome File Edit View History Bookmarks Profiles Tab Window Help Thu Jul 2 2:29 PM New Chrome available Temporal Spaces - Jira Apps-Dash temporal.io All Bookmarks
- 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
A core agent is a loop
An agent cycles through reason, act, and observe, repeating until it is done.
Text in image
THE LOOP A core agent is a loop Reason Act Observe REPEAT UNTIL DONE 02 Interface text: Chrome File Edit View History Bookmarks Profiles Tab Window Help Thu Jul 2 2:29 PM New Chrome available Temporal Spaces - Jira Apps-Dash temporal.io All Bookmarks
- 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
A loop needs a harness
Warrick’s harness surrounds the reason–act–observe loop with capabilities, controls, operations and human input, with durable execution underneath. She notes that the harness’s boundaries are still debated.
Text in image
LOOP → PRODUCTION A loop alone isn't reliable. It needs a harness THE HARNESS LOOP REASON OBSERVE ACT CAPABILITY Tools · Memory · Retrieval CONTROL Guardrails · Governance OPS Observability · Versioning Human-in-the-loop Durable execution · the substrate it all runs on 03 Interface text: Chrome File Edit View History Bookmarks Profiles Tab Window Help New Chrome available Temporal Spaces - Jira Apps-Dash temporal.io All Bookmarks Thu Jul 2 2:30 PM
- 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.
One agent system inside a harness
In the demo, fleet and customer agents research drivers and orders. The dispatch agent uses their input to make decisions and can ask a human; durable execution tracks the system in event history.
Text in image
THE DEMO · SAME GRAPH ON ADK OR LANGGRAPH One agent system, inside a harness MELTDOWN THE DEMO · AN ICE-CREAM FLEET IN SF THE HARNESS START Fleet Agent REASON OBSERVE ACT get_fleet_status Customer Agent REASON OBSERVE ACT get_customer_info Dispatch Agent REASON OBSERVE ACT ask_human UI · HUMAN END Durable execution · tracked in event history 04 Interface text: Chrome File Edit View History Bookmarks Profiles Tab Window Help Thu Jul 2 2:31 PM New Chrome available Temporal Spaces - Jira Apps-Dash temporal.io All Bookmarks
- 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.
Durable execution in three primitives
A worker runs a workflow that coordinates agent durability and calls activities for tool or model calls. The Temporal service stores event history and drives retries and timeouts.
Text in image
WHAT IS TEMPORAL Durable execution, in three primitives github.com/temporalio/temporal Worker Worker(task_queue=…) process runs the code Workflow @workflow.defn Coordinates framework / agent durability CALLS Activity @activity.defn Tool call or a model call ↑ Worker runs the code ↓ Service stores the state Temporal Service stores the event history · drives retries & timeouts · the durable backbone 05 Interface text: Chrome File Edit View History Bookmarks Profiles Tab Window Help New Chrome available Temporal Spaces - Jira Apps-Dash temporal.io All Bookmarks Thu Jul 2 2:31 PM
- 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,
One agent system inside a harness
In the demo, fleet and customer agents research drivers and orders. The dispatch agent uses their input to make decisions and can ask a human; durable execution tracks the system in event history.
Text in image
THE DEMO · SAME GRAPH ON ADK OR LANGGRAPH One agent system, inside a harness MELTDOWN THE DEMO · AN ICE-CREAM FLEET IN SF THE HARNESS START Fleet Agent REASON OBSERVE ACT get_fleet_status Customer Agent REASON OBSERVE ACT get_customer_info Dispatch Agent REASON OBSERVE ACT ask_human UI · HUMAN END Durable execution · tracked in event history 04 Interface text: Chrome File Edit View History Bookmarks Profiles Tab Window Help Thu Jul 2 2:31 PM New Chrome available Temporal Spaces - Jira Apps-Dash temporal.io All Bookmarks
Durable execution in three primitives
A worker runs a workflow that coordinates agent durability and calls activities for tool or model calls. The Temporal service stores event history and drives retries and timeouts.
Text in image
WHAT IS TEMPORAL Durable execution, in three primitives github.com/temporalio/temporal Worker Worker(task_queue=…) process runs the code Workflow @workflow.defn Coordinates framework / agent durability CALLS Activity @activity.defn Tool call or a model call ↑ Worker runs the code ↓ Service stores the state Temporal Service stores the event history · drives retries & timeouts · the durable backbone 05 Interface text: Chrome File Edit View History Bookmarks Profiles Tab Window Help New Chrome available Temporal Spaces - Jira Apps-Dash temporal.io All Bookmarks Thu Jul 2 2:31 PM
- 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
The blocking human tool
A synchronous human input call blocks the agent loop. If the worker dies, the interaction can be lost; the platform cannot see it.
Text in image
THE ANTI-PATTERN The blocking human tool A SYNCHRONOUS CALL INSIDE THE AGENT LOOP. @tool def ask_human(question: str) -> str: return input(question) # ← blocks the loop Blocks the loop. Dies with the worker. Invisible to your platform. 06 Interface text: Chrome File Edit View History Bookmarks Profiles Tab Window Help Thu Jul 2 2:33 PM New Chrome available Temporal Spaces - Jira Apps-Dash temporal.io All Bookmarks [illegible]- 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.
Workers die. Workflows don't
A wait condition pauses the agent loop while the workflow persists. A signal resumes it, even if the original worker dies or restarts during a wait lasting seconds to days.
Text in image
THE FIX · ISOLATE AND AWAIT THE HITL EVENT Workers die. Workflows don't wait_condition signal arrives Loop the agent reasons REASON OBSERVE ACT loop paused resume Workflow the durable core durable across the entire wait Worker ephemeral process running may die or restart here new worker the wait: seconds to days 07 Interface text: Chrome File Edit View History Bookmarks Profiles Tab Window Help New Chrome available Temporal Spaces - Jira Apps-Dash temporal.io All Bookmarks
- 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.
The human is an async API
The workflow waits for an answer; a signal supplies the decision and resumes it. A query exposes the question awaiting a human response.
Text in image
The human is an async API Every HITL pause is the same Temporal primitive — only who initiates differs. await workflow.wait_condition(lambda: self._answer is not None) # pause (durable) @workflow.signal def answer(self, decision): self._answer = decision # resume · the human, async @workflow.query def pending(self): return self._question # surface · what we await (UI) MELTDOWN 08 Interface text: Chrome File Edit View History Bookmarks Profiles Tab Window Help Thu Jul 2 2:34 PM claude.ai [illegible] New Chrome available Temporal Spaces - Jira Apps-Dash temporal.io All Bookmarks
- 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.
You declare the wait
Temporal waits hold no thread and survive crashes. A timeout can limit how long a workflow waits for a human, while millions of workflows can remain parked independently.
Text in image
WHAT THE DURABLE WAIT GIVES YOU You declare the wait. You don't build it → Holds no thread → Survives crashes → Built-in timeout → Independent, not queued Independent durable pauses — not one serial queue. Millions park at once, none blocking another. Interface text: Chrome File Edit View History Bookmarks Profiles Tab Window Help Temporal Spaces - Jira Apps-Dash temporal.io All Bookmarks New Chrome available 09
- 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,
ADK on Temporal
Temporal wraps the ADK model and tools as activities, runs the agent through a workflow, and registers the workflow with a worker using the Google ADK plugin.
Text in image
GOOGLE ADK on Temporal MELTDOWN ADK on Temporal Three layers: the model + tools become activities, the Runner drives them in a workflow, the worker registers it. # ① ACTIVITY — Temporal wraps the ADK model + tools fleet_agent = Agent(name="assignment_fleet_agent", model=TemporalModel(DEFAULT_MODEL, ...), # each LLM call → an ACTIVITY tools=[activity_tool(tool_get_fleet_status), ...]) # each tool → an ACTIVITY # ② WORKFLOW — the Runner drives the team inline, durably @workflow.defn class MeltdownDemoWorkflow: async for _ in runner.run_async(...): ... # calls recorded in history # ③ WORKER — register the workflow + the ADK plugin Worker(client, task_queue=Q, workflows=[MeltdownDemoWorkflow], # + ADK plugin plugins=[GoogleAdkPlugin()]) # agents worker runs LLM/tool activities 10 Interface text: Chrome File Edit View History Bookmarks Profiles Tab Window Help Thu Jul 2 2:36 PM claude.ai/design/p/[illegible] New Chrome available Temporal Spaces - Jira Apps-Dash temporal.io All Bookmarks- 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.