Melanie Warrick (Developer Relations, Temporal) demonstrates how to build human-in-the-loop agents that wait for human responses without blocking or losing state. Using a live multi-agent ice cream delivery demo with fleet, customer, and dispatch agents built on Google ADK and LangGraph, she covers why durability belongs in the agent harness, how Temporal's workers, workflows, and activities track state, and how two primitives — a wait condition and a signal — let an agent pause for a human for minutes or weeks. She also shows a worker being killed mid-approval and recovering with no lost work, and discusses when a human should be in the loop by weighing the cost of errors against alert fatigue. Recorded at AI Engineer World's Fair 2026 in San Francisco. # Video Identity Observations ## Explicit Self-Description (Creator Claims) - **Employer affiliation:** The speaker openly frames the talk as promotion for her company — *"ultimately I'm here to talk to you about Temporal. So, you're going to hear me pitching about the company that I work for."* - **Role implied:** She speaks as a practitioner/evangelist for Temporal, demonstrating its product and integrations (e.g., *"Temporal is baked into it... we can help track the state"*). - **Honesty about expertise limits:** *"The harness I'm not going to sit here and tell you I am the expert... 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."* - **Offered resources:** A QR code to *"resources about Temporal, as well as some of the demos"*; the demo and slides are posted on **GitHub** (*"We're free and open source at that GitHub URL"*). ## Intended Audience (Evidence from Content) - **Developers building agentic AI systems**, particularly those deploying agents to production: - Technical depth assumed: live code in **Python**, discussions of `wait_condition`, `signal`, workflows/activities, async I/O, workers. - Direct address to builders: *"have fun building your agents"*, *"I'm also curious to hear what problems you're solving with agents and how you're building them autonomously."* - Practical deployment concerns: productionization, failure handling, durability, scaling to *"millions of workflows."* - Conference audience context: live demos, Q&A offer (*"I'm going to stick around for a few more minutes"*), audience laughter and reactions. ## Claimed Scope - **Core thesis:** Humans in agent systems should be treated as an **async API** using Temporal's two primitives — *"You want a wait condition and a signal"* — so human input doesn't block or crash the system. - **Product scope claims:** - Temporal provides **durable execution**, state management, and failure-handling standardization for distributed and agentic systems. - **Framework agnostic:** *"we can work with multiple frameworks... LangChain... ADK"*, with languages including *"Python or TypeScript or Rust."* - Business model stated: free/open-source software; paid managed service (*"you pay us if you have us manage your state"*). ## Demonstrated Presentation Patterns (Observable, Not Claimed) - **Demo-driven, engineer-oriented talk:** two live demos (ice cream delivery with fleet/customer/dispatch agents; killing and restoring a worker to show durability recovery). - **Transparent, improvisational tone:** acknowledges technical difficulties and personal circumstance on stage (*"my eyes are injured... I can adapt"*), *"in true form I've been tweaking [slides] up until now."* - **Positioning within the broader AI discourse:** references current community topics — *"agentic loops"* (reason/act/observe), *"the harness"*, model reliability, alert fatigue — situating the talk in the 2024–25 agentic-AI conversation. ## Notes for Synthesis - The only self-description evidence is from this single conference talk; channel-wide conclusions (upload cadence, content mix) cannot be drawn from this material alone. - No curated metadata beyond the title was supplied; the title itself ("The Human Is an Async API — Melanie Warrick, Temporal") confirms speaker identity and affiliation. # Delivery Observations: "The Human Is an Async API" (Melanie Warrick, Temporal) *Basis: title and transcript only. No curated metadata was supplied. Bracketed numbers are transcript line markers, not verified video timestamps.* --- ## 1. Tone and Register ### 1.1 Conversational and self-deprecating The speaker often acknowledges their own imperfections or demo friction in a light way. > "I've already stepped outside the box they told me not to step outside of." [13] > "my eyes are injured." [561] > "I am squinting at times and also realizing that I need additional in support here that I did not prepare for, but that's okay cuz I can adapt." [571] ### 1.2 Playful asides Humor appears in short, offhand lines rather than set-piece jokes. > "But, heaven forbid you have it break your system when somebody has a change to submit." [141] > "Don't mind me as I do this in a very interesting way." [922] Audience laughter is marked twice in the transcript, at [561] and [865–876]. ### 1.3 Direct audience address The speaker addresses the room informally and collectively: - "y'all" (e.g., "if y'all want it at a later date" [1011]) - "all of you" [910] - "everybody" [1045] --- ## 2. Recurring Verbal Markers These are the most frequent repeated words and phrases. They are directly countable in the transcript. ### 2.1 Discourse openers and transitions - **"All right."** Used as a section transition at least six times, including [13], [221]-adjacent sections, [328], [581], [1101]-adjacent sections. - **"So,"** used as a sentence opener throughout (e.g., "So, what's happening?" [36]; "So, Temporal actually helps you track your state" [93]). - **"Let's"** as a directive opener: "Let's go into First off" [221]; "Let's get back to human in the loop." [441]; "let's talk a little bit more about the code" [581–618]. ### 2.2 Wrap-up phrase: "there you go" Used to close demo or explanatory moments: > "And there goes little A delivering the order for you." [208] > "So, there you go. That is durable execution with Temporal and 80K integrated." [208] > "So, there you go. That is durability in your system." [989] The phrase recurs at demo endpoints, and the 2nd and 3rd uses both follow with a "That is ___" statement. ### 2.3 Hedging and framing: "ultimately" > "ultimately I'm here to talk to you about Temporal." [24] > "ultimately it's all about getting these agents with structure" [285] > "ultimately giving you some standard primitives" [372] > "ultimately, you want to assess the cost of being wrong." [1023] Uses of "ultimately" cluster around restating the core point. ### 2.4 Tag questions for shared context > "We've been hearing about agentic loops, right?" [221] > "it's a loop, right?" [403] These invite agreement or confirm the audience follows. ### 2.5 Filler and self-correction - "Um" appears frequently, e.g., "Um there's this kind of loop" [243], "Um and this can scale" [549]. - Repetitions appear in the transcript ("I I am the expert" [264], "your your system" [382], "human human responds" [799]). These may be transcription artifacts rather than deliberate delivery features; this cannot be confirmed from text alone. ### 2.6 Hedging about certainty > "I'm not going to sit here and tell you I I am the expert on the harness." [264] > "I'm trying to give you at least a map... with the understanding that there's a lot of debate about this." [264–275] > "I suspect internet is part of it." [186] > "probably a couple people out there who are" [886] The speaker repeatedly distinguishes what they know from what is debated or uncertain. --- ## 3. Teaching Habits ### 3.1 Demo-first, then concept The speaker presents a live demo (Ziggy's ice cream delivery) before explaining the underlying primitives, then returns to the demo to illustrate them. Examples: - Demo introduction [36–208], followed by "That is durable execution" [208]. - Code explanation [581–685], followed by a second demo [799–989]. ### 3.2 Explicit signposting The speaker frequently announces what is coming: > "So, the three main primitives we tend to talk about are the worker, the workflow, and the activity." [382] > "What I want to show you is what does it look like when the agent comes in and needs the human to be involved?" [696] > "Last couple things I want to mention." [1001] ### 3.3 Enumerated primitives Concepts are grouped into named sets and then defined in turn: - **Worker, workflow, activity** [382–424] - **Wait condition and signal** [481–515, 663–685] - **Workflow vs. activity determinism** [753–763] ### 3.4 Analogy and mapping > "the human, granted, you know, we're not tools, but we are a tool to the agent." [448] The speaker frames the human as a tool in the agent's loop, which links the talk's title metaphor to the architecture. ### 3.5 Restating and summarizing Major points are repeated near their conclusions, for example the closing summary: > "you were seeing that we are using two main primitives in terms of you're applying a weight condition to pause that workflow, and a signal from the human..." [1068–1080] ### 3.6 Framework-neutral framing The speaker deliberately notes multiple frameworks: > "We are framework agnostic." [719] This appears alongside the use of ADK and LangChain examples. --- ## 4. Communication Patterns ### 4.1 Pitch integration The speaker openly identifies a commercial context: > "you're going to hear me pitching about the company that I work for" [24] The talk alternates between product explanation and general architectural points. ### 4.2 Calls to action at the end > "if you have any questions, please reach out." [1125] > "I'm also curious to hear what your what problems you're solving with agents" [1125–1135] The closing invites ongoing dialogue rather than only ending the talk. ### 4.3 Pacing around live tasks The speaker narrates while performing live actions ("I'm resetting my example," "Make it. And it's back online.") and fills time during technical waits ("Is everybody hearing me okay? Think so. Great."). --- ## 5. Limits of This Analysis - Evidence comes from one transcript, so **recurring** patterns are observed within this talk only. No cross-talk comparison is possible. - Repeated words such as "I I" and "your your" may reflect transcription quality rather than delivery style. Treat these as uncertain. - No audio, prosody, pacing, or visual evidence is available, so observations about energy, volume, or gesture cannot be made. # Observation Record: "The Human Is an Async API" (Melanie Warrick, Temporal) **Speaker attribution:** All positions below are attributed to Melanie Warrick, identified in the video title. The transcript itself identifies the speaker as someone who works for Temporal. Positions are recorded as expressed in the talk, not as her private beliefs. --- ## 1. Framing and Purpose - **Stated goal:** Pitch Temporal through a live ice-cream delivery demo, and argue that "the human is an async API." - **Self-described stance:** The speaker presents the talk as a pitch for her company. She also says she "stepped outside the box" of what she was told to do. --- ## 2. The Demo ("Ziggy's Ice Cream Delivery") ### 2.1 Described Setup - Three agents coordinate deliveries: a **fleet agent**, a **customer agent**, and a **dispatch agent**. - The speaker says the fleet and customer agents run on **"80K"**, which she describes as a Google-provided solution for orchestrating agents. The transcript also refers to "ADK" and a "Google ADK plugin," so the "80K" rendering may be a transcription artifact. This record preserves the transcript's spelling and does not resolve it. - The dispatch agent runs on **LangGraph**, which the speaker also calls LangChain. - Temporal is described as "interwoven throughout" and as tracking state through an event-history UI. ### 2.2 Human-in-the-Loop Scenario - A customer submits a change to an order. The speaker says this change pauses one driver's part of the system while the rest keeps running. - A human approves the change. The speaker reports that the update was processed and the order moved on. - **Speaker's own hedge:** "I suspect internet is part of it," offered as a possible cause of a delay. ### 2.3 Durability Test - The speaker says she stopped the worker ("kill worker") and submitted an "approve" while it was offline. - She states that the event was queued in a store outside the service. - On restart, she describes the event log as **replayed, not redone**, up to the last checkpoint. - **Reported outcome:** The approval was applied and the order was assigned and delivered. > "That is durability in your system. Your system can come down, and it can recover." --- ## 3. Conceptual Claims ### 3.1 Agentic Loops - Agents are described as running a loop of **reason, act, observe** (also framed as think, act, perceive). - The speaker notes the loop "can be a for loop, it can be a while loop." ### 3.2 The Harness (Explicitly Uncertain) - The speaker explicitly disclaims expertise: "I'm not going to sit here and tell you I am the expert on the harness." - She offers "a map" based on her research, "with the understanding that there's a lot of debate about this." - Open questions she raises (not resolved): - Whether the model is part of the harness. - Whether tools, memory, guardrails, and security are part of it. - Her working view: the harness exists to give agents structure so they work reasonably well in production, and **durability is part of that picture.** ### 3.3 Durability as a Need - Agent systems are distributed systems, and the speaker argues they need standardized **failure handling** and **state management**. - Temporal is presented as providing these as primitives. --- ## 4. Temporal's Primitives (Speaker's Account) | Primitive | Speaker's description | |---|---| | **Worker** | Runs the code. | | **Workflow** | Tracks the steps of the system. An agent loop can run inside a workflow. Deterministic. | | **Activity** | Handles external interaction, such as model calls and tool calls. Non-deterministic. | - Languages named: Python, TypeScript, Rust. - **Licensing claim:** Temporal is "free and open source." The speaker says users "pay us" only if they use Temporal's managed service; otherwise they can self-host. - **Framework claim:** Temporal is "framework agnostic" and works across multiple agent frameworks. --- ## 5. Core Argument: Human as Async Dependency - **Problem with a blocking human call:** If a human call is written as a plain function, the speaker says it "can become a blocking call" and "can get lost if your service went down." - **Proposed pattern:** Two primitives: - A **wait condition** that pauses the workflow and stores the state durably. - A **signal** that delivers the human's input into the running workflow. - **Claimed benefits:** - The system keeps running while one workflow waits. - Recovery after crashes. - Built-in **timeouts** for limiting how long the system waits on a human. - Scale: "You can have millions of workflows out there parked." - **Stated reasoning on timing:** "Humans are most likely going to take several minutes, maybe days, maybe weeks, maybe longer." ### 5.1 Integration Pattern for LangGraph - Temporal is passed into each graph node. - Model invocations and other tool calls are set up as activities. - Graph steps are set up as workflows. - The speaker says LangChain's **interrupt** is used to call out from a node. Then a wait condition in the loop, tracking the interrupt signal, pauses the workflow until a signal delivers the human's response. --- ## 6. When Should a Human Be in the Loop? The speaker presents this as an open question she does not fully answer: - **Guiding principle:** "The big thing you want to take into consideration is the cost of being wrong is high." - **Case-by-case:** "It's a case-by-case basis." - **Tension identified:** - Desire for autonomy: "we're trying to get to autonomy as much as we possibly can." - Model limits: "these models are probabilistic, and they are hard to get to a place to be reliable." - Alert fatigue: "you just start saying yes, yes, yes, yes, yes every time it asks you questions." - **Her stated resolution:** "That's the thing you've got to evaluate for the problems that you're solving." She also says better models could address alert fatigue, but that they "are still probabilistic models." --- ## 7. Unresolved Tensions and Qualifications - **Harness definition:** Explicitly contested and left open. - **Human-in-loop placement:** Presented as a per-problem judgment with no general rule. - **Autonomy vs. oversight:** Both are endorsed; the speaker does not resolve which should dominate. - **Demo caveats:** The speaker attributes a delay to possible internet issues, and the demo was run live under acknowledged setup difficulties ("not going to be as easy peasy as I'd like"). - **Vendor framing:** Claims about Temporal (scale, open source, framework neutrality, ease of code) come from a speaker employed by Temporal and are not independently verified in the transcript. - **Code claim:** The speaker says the code "pretty much is fairly simple" in terms of primitives, and notes the example is in Python. --- ## 8. Closing Statements - Resources are available via a QR code and a GitHub repository. Slides are to be posted later. - The speaker invites questions and asks what problems the audience is solving with agents and how they are building them "autonomously currently." # Speaker Attribution and Provenance Observation ## Video Identification - **Video ID:** `01a15ca6-f476-77c7-8f25-92546c91cae8` - **Title:** "The Human Is an Async API — Melanie Warrick, Temporal" - **Metadata supplied:** Title only. No description, channel, upload date, cited-source list, or comment data was provided. ## Speakers and Roles ### Primary Speaker - **Name:** Melanie Warrick (name from title only; the transcript does not state it) - **Affiliation:** Temporal. The speaker says she is pitching "the company that I work for," and the title attributes the talk to Temporal. - **Role:** Presenter and demonstrator. She gives the talk, runs the live demos, and explains the technical concepts. - **Other roles described:** Presenter of the Ziggy's ice cream delivery demo. ### Other Persons Referenced - **Ziggy:** Described as the speaker's company mascot and as a fictional ice cream store owner in the demo scenario. This is presented as a demo character, not a real participant. - **Unnamed "customer," "human reviewer," and "another human":** Appear only as hypothetical or demo roles within the demonstration. No real identities are given. - **Audience:** Addressed directly ("y'all," "if you have questions"). Audience reactions appear only as bracketed laughter and "Woo!" markers. ### Speaker-Assigned Agent Roles (Demo Components) - **Fleet agent:** Researches drivers using tools described as Google Maps. - **Customer agent:** Researches orders using tools described as Google Search. - **Dispatch agent:** Makes decisions from the other two agents' outputs. Described as running on LangGraph. - **Human reviewer (hypothetical):** Approves or rejects a high-value order change. These are demo-internal roles as described by the speaker, not independently verified system descriptions. ## Referenced Sources and Named Tools | Reference | How the speaker characterizes it | Notes | |---|---|---| | "80K" (rendered in transcript) | Described as a solution "Google's providing" to orchestrate agents | Transcript rendering is uncertain; the term "ADK" also appears later in the transcript, and the two may refer to the same framework. Unresolved. | | Google ADK | Framework for which a Temporal model class and plugin are described | Named in transcript. | | LangChain / LangGraph | Used for the dispatch agent and multi-agent graph | Named in transcript; described as a framework the speaker uses. | | Google Maps | Tool for the fleet agent | Named as a tool example. | | Google Search | Tool for the customer agent | Named as a tool example. | | Temporal GitHub repository | Speaker says Temporal is "free and open source at that GitHub URL" and that demos are "up on GitHub" | URL not spoken in the transcript. | | QR code | Speaker says it links to "resources about Temporal" and "some of the demos" | Destination not present in transcript. | | Slides | Speaker says they "will be up later" and will be linked to the GitHub repo | Not yet available at time of recording, per speaker. | | "Oracle Park" | Named as a delivery destination within the demo | Demo-internal location. | | Ferry Building | Named as the location of the fictional ice cream store | Demo-internal location. | ## Third-Party Claims The speaker attributes or frames the following as coming from outside sources, without specific citations: - **Harness debate:** "from everything I've researched," the speaker reports ongoing debate over whether the model, tools, memory, guardrails, and security belong inside the "harness." The speaker says "there's a lot of debate about this" and does not name sources. - **Industry phrasing:** "We've been hearing about agentic loops," and "people tell us about the harness." These refer to unnamed commentators. - **Google's role:** The speaker says Google is providing the "80K" solution. No further attribution is given. ## Promotional Segments The following segments are **flagged as promotional** by the speaker's own framing: - **Temporal product pitch:** The speaker states she is "pitching about the company that I work for." This pitch runs through the demo, the explanation of primitives, and the closing remarks. - **Product primitives presentation:** Descriptions of the worker, workflow, and activity primitives are presented as Temporal's offerings. - **Pricing and hosting mention:** The speaker says "you pay us if you have us manage your state with our service" and offers a self-hosted option. - **Call to action:** The closing directs viewers to the QR code, GitHub resources, and to "reach out" to the speaker. Non-promotional framing (the general discussion of agentic loops, human-in-the-loop design, and alert fatigue) is presented as the speaker's own perspective and is not labeled as sponsored. ## Demonstration Provenance - The Ziggy's ice cream delivery demo is **live and speaker-operated**. The speaker states she is resetting it, that it "isn't as easy peasy as I'd like," and that a service was taken offline and brought back. - Demo outcomes are the speaker's own reports of what appeared on screen during the recording. No independent verification of the demo's behavior is present in the record. - The speaker notes a possible connection issue ("I suspect internet is part of it") during the demo. ## Availability and Limits - **Comment availability:** Not provided in the supplied material. Cannot be determined from the record. - **Cited-source list:** None supplied. Sources are only those named within the transcript. - **Speaker identity:** Taken from the title. The transcript itself does not state the speaker's name. - **Transcript quality:** The transcript contains apparent rendering artifacts, including "80K" and "fai- failure" (a mid-word restart), and bracketed speech markers. Some names and terms may be transcribed imperfectly. - **Visual content:** Screen contents, slides, and the QR code are referenced but not present in the transcript. Descriptions of on-screen elements come only from the speaker's narration. - **Timestamps:** None supplied in the source material. ## Self-Check Notes - Named roles and provenance facts are drawn from the transcript and title only. - Promotional segments are flagged above. - No quality evaluation of the content has been recorded. All right. Well, I'm here to talk to you today about 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 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 going to 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 as you can see online right now. So, what's happening? Well, this is Ziggy. Ziggy's Ziggy's is our mascot. I love Ziggy. And 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 fleet 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 here is showing you we have 80K integrated with Temporal. So, 80K is a um solution that Google's 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 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 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 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 changed my mind about that order. So, I'm going to submit a change." And of course, when you do submit that change, it will not it 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 change is only pausing one part of your system. That one change coming from a human. And another human needs to make a call and 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 were 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 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 the Oracle Park. And there goes little A delivering the order for you. So, there you go. That is durable execution with Temporal and 80K integrated. All right. I'm here to talk to you about the human is an async API. 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 essence of it. It can be a for loop, it can be a while 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 going to sit here and tell you I I am the expert on the harness. Um I'm going to 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 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. 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 thing tools like Google Maps. Um the other one is doing research on the orders like Google with tools like Google Search. While the dispatch agent is taking that input and making decisions with it. 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 fai- failure handling and your state management in your system. Any system, any distributed system, especially any systems with agents, we are going to 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 this 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 your state your your system is stateful. So, the three main primitives we tend to talk 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 80K framework would be running inside a workflow. Uh your agent could work run inside of a workflow cuz it's a loop, right? Whereas the activity is all the stuff that's integrating or interacting with stuff externally. So, if you've got a loop, uh any kind of model call or 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 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 going to call the human or we're going to 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 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 going on with that human's engagement. 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 system came back up, it would know where it left off. And you could send a signal at any point, but the whole system could keep running without you necessarily being blocked on that one call to the human. The code pretty much is is is fairly simple in terms of the primitives. And granted, I know this is Python, but it's the same situation. You're going to apply a wait condition and you're going to apply a signal. You basically you're not holding a thread, you're not it's going to survive any kind of crashes. It's got all kinds of built-in primitives like timeouts, for example. If you're waiting on a human to respond and you want to 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 want to show you actually I'm going to show you some more code, but I'm going to kick off the next demo so 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. \>\> \[laughter\] \>\> I am squinting at times and also realizing that I need additional in support here that I did not prepare for, but that's okay cuz I can adapt. All right, so let's get this other example up and running and then I'm going to 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 going to be as easy peasy as I'd like. Also, is everybody hearing me okay? Think so. Great. It's an interesting condition to be 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 workflow and worker. And so with the activity, you are basically for ADK in particular, we have 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. You apply this temporal model, you apply our activity tool to wrap around your tools and you you run your agent. You run your agent like you would with any kind of ADK setup that you're going to do. And you also set up a worker and you pass in the Google 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 async io 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 co-routines 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. And the workflow will be 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. So, I showed you human to agent. What I want to show you is what does it look like when the agent comes in and needs the human to be involved? It's pretty similar. You're using I'm just going to go ahead and tell you right now, you're going to use a workflow you're going to use a wait condition and a signal. I'm going to use LangChain in this example and also 80K because the reality is with Temporal we can work with multiple frameworks. We are framework agnostic. We work across a variety of different tools. Um so, in terms of LangChain they build out graphs and to build out the multiple agent setup. And in this integration the way we work, you're passing us into each node for your graph. So, you're setting up with the metadata looks like. And if you're making any kind of 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 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 LangChain. In terms of LangChain in particular, we use the interrupt to call out from their node. So, this is part of LangChain and also to be fair, LangChain 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 responds with to the question that's been asked. Okay, 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 80K. 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. In this case, I'm going to 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. And here we see that the customer and the fleet agents did their work. They did their assessment. They came back with a result. And they sent that off to the dispatch agent. The dispatch agent said, "Hey, okay, I need Oh, well, there you go. \>\> \[laughter\] \>\> 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 there's probably a couple 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 going. So, now what I'm going to try to do is show you what happens if I was to take this service offline. So, let's make it bigger for all of us. And kill worker. Cool. So, that takes it offline. 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, yeah, I know. I have this really well organized here here for y'all. But, I'm going to I'm going to bring it back up and then we're going to see if it 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 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 want to mention. When should the human be in the loop? This is the real question. It's a hard one. I will say this. The big thing you want to take into consideration is the cost of being wrong is high. Okay, 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 got all this stuff happening around harnesses that are interesting. I could go into a whole 'nother conversation about that if y'all want it 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, 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 When should the human be in the loop? That's the thing you've got to evaluate for the problems that you're solving. 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 were seeing that we are using two main primitives in terms of you're applying a weight 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 And whether you've actually paused it and taken it offline or you brought it back online. And I've shown you that we can use multiple frameworks. All right, if you have any questions, I'm going to 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, this demo included. This is up on GitHub. Uh the slides itself will be up later cuz of course in true form I've been tweaking them up until now. So, I'll be posting those up and linking them to the GitHub repo. But yeah, if you have questions, please reach out. Um and you know, have fun building your agent clips. I'm also curious to hear what your what problems you're solving with agents and how you're building them autonomously currently. So, feel free to find me. And thank you. \>\> Woo!