OpenAI + @Temporalio : Building Durable, Production Ready Agents - Cornelia Davis, Temporal

• The OpenAI Agents SDK provides a framework for building AI applications where Large Language Models (LLMs) control the application flow and tool usage.
• Temporal is an open-source distributed systems backing service that ensures durability and fault tolerance for complex applications.
• Integrating OpenAI Agents SDK with Temporal allows developers to build robust AI agents by offloading complexities like retries, state management, and crash recovery to Temporal, preserving LLM token usage.

• The OpenAI Agents SDK, available in Python and TypeScript, simplifies building LLM-driven applications where the LLM determines the application's flow.
• An agentic loop represents the core pattern where an LLM repeatedly makes decisions, potentially invoking tools, and processes their output until a task is complete.
• Temporal functions as a distributed systems backing service, offering durability features similar to how databases or message queues serve applications.
• Temporal Activities are fundamental units of work, often involving external calls or operations that might fail, and are decorated to receive special handling like automatic retries.
• Temporal Workflows orchestrate Activities to define the overall business logic, ensuring that the application's state and execution progress are preserved even across crashes or network issues.
• Dynamic Activities in Temporal enable workflows to call activities by name at runtime, allowing for flexible integration of different tools in an agentic loop without modifying core workflow code.
• Temporal's built-in state management and event sourcing prevent re-execution of LLM calls and associated token burning if an application crashes, ensuring efficient resource usage.
• By using Temporal, developers can program the "happy path" of their AI agent's business logic, as Temporal automatically handles retries, queues, and crash recovery for distributed operations.

OpenAI Agents SDK — A framework that facilitates building applications where Large Language Models (LLMs) control the application flow and decide when to use tools. Temporal — An open-source distributed systems backing service that provides durability and fault tolerance for complex application logic. Distributed System — A system where components located on different networked computers communicate and coordinate their actions by passing messages. Microservice Architecture — An architectural style that structures an application as a collection of loosely coupled, independently deployable services. Agentic Loop — A recurring sequence where an LLM makes a decision, possibly calls a tool, processes the tool's output, and then repeats the process until a goal is met. LLM — Large Language Model. An artificial intelligence model that has been trained on a massive amount of text data and can generate human-like text, answer questions, and perform various language tasks. Activity — A specific unit of work within a Temporal workflow, often involving external calls (e.g., API integrations, database operations) that Temporal can retry and manage. Workflow — The durable, fault-tolerant execution of a business process defined in Temporal, orchestrating one or more Activities. Dynamic Activity — A Temporal feature allowing a workflow to invoke an activity by its name at runtime, enabling flexible tool integration without hardcoding activity references. Backing Service — A service (like a database, message queue, or in this case, Temporal) that an application depends on, typically managed by the platform or a third party. Event Sourcing — An architectural pattern where all changes to application state are stored as a sequence of immutable events, allowing for reliable recovery and auditing. Temporal Cloud — A SaaS offering of the Temporal service, abstracting away the operational complexities of managing a Temporal server infrastructure.

I'll introduce myself in just a moment, but I'd like to get to know a little bit about you. So you can see that there's two brands up on the screen here. There's OpenAI, Agents SDK, in particular, and there's Temporal. I work for Temporal. I'll tell you more about myself in just a second. I'm curious how many folks are using the OpenAI Agents SDK today? OK. About a quarter of you. Any other agent frameworks? OK. About the same set of you. So it looks like there's a quite a number of you who are not using an agent framework just yet. So I'll teach you a little bit about that. OK. Next question. How many folks are doing anything with Temporal? Not very many. Awesome. I'm going to get to teach you some stuff. OK. Cool. So we're going to talk today about both those technologies. I'm going to talk about them each independently, but I'm going to spend a lot of time on them together. Spoiler, we actually have an integration between the two products that Temporal and OpenAI worked on together. And so you'll see, it's really quite sweet. So let me very briefly introduce myself. My name is Cornelia Davis. I'm a developer advocate here at Temporal. I have spent a lot of time. I think the bulk of my career has been spent in this distributed system space. So I was super fortunate to be at Pivotal, working on Cloud Foundry from the early 2010s. So I was really there during the kind of movement toward microservice architectures, distributed systems, those types of things. Any Cloud Foundry folks in the room? Oh, just a few. So for those of you who don't know Cloud Foundry, Cloud Foundry was the early container technology out on the market. It was incubated as an open source project at VMware. And it used container images, Linux containers, container orchestration, eventual consistency, all of that stuff, before Docker even existed, and before Kubernetes existed. So I was very, very fortunate that I was there at the beginning of that movement over toward platforms that supported this more agile, distributed systems way of doing things. And because I spent so much time in the microservices world, I also wrote this book. OK, so what we're going to talk about today is we're going to talk about the open AI agents SDK. Then I'm going to give you a temporal overview. I'm going to do lots of demos, and I'm going to show you the repose if you want to follow along. You can go ahead and grab the repose. Both of my demos, I actually changed this morning, so they're sitting in branches instead of in the main branches, but I will make that very clear as well. I'm going to do lots of demos there, and then I'm going to move over to the combination of the open AI agents SDK and temporal together, and we'll do more demos there as well. And then I'm going to talk a little bit about orchestrating agents kind of in the general sense. So this here is a notebook that I'm not going to use today. And so I decided I just ran this workshop earlier this week, and I decided that for the AI e-crowd, it was way too basic. That said, if you're interested, you can go there. It will take you through its setup with Jupyter notebooks. You can run it in code spaces on GitHub, and you can run your first open AI agents SDK agent. Then you can run your first 101 temporal agent, but temporal application. Then you can move all the way through the agenda that way. But it's pretty basic, and I decided that for this crowd, I wanted to do something more advanced. So we're not going to use that today, and I just crafted some of these demos this morning. OK, so without further ado, this is going to be the shortest part of the presentation is I'm going to give you an intro to the open AI agents SDK. This was launched in I think around the May time frame or so. And I'm not going to read you these slides. And oh, just so you know where we're going, I am going to use some slides because I'm one of those people where I think the pictures really help. I've got lots of diagrams in here, but we are going to spend a lot of time stepping through the code as well. I don't think I need to define what an agent is. I will tell you that for me personally, the distinction that I make between Gen AI applications and then when they get to agents is when we give the LLM's agency. When the LLMs are the ones that are deciding on the flow of the application, that to me is what an agent is. And these frameworks, like the open AI agents SDK, are designed to make it easier for you to get started with those. And in fact, we'll see a contrast on that with the two major demos that I'm going to show you today. It's available in both Python and TypeScript. And here is the most basic application. So what you see here is that we've defined an agent. We've given it a name, and we've given it instructions, and it's taken defaults for the rest of it. There are things that are defaulted. Are things like the model itself? I don't know what the default is right now. And then all you need to do after that is you basically need to run it. And any time you see that runner.run, what that corresponds to is an agentic loop. And we'll talk about the agentic loop several times throughout the presentation. Every time you see one of those runner.runs, it's its own agentic loop. And when we get to the orchestration stuff later on, you'll see why I make that distinction. It also, as I said, this is really simple here, but it has a lot of other options that you can put in place into the agent, configurations that drive how the agentic loop works. You can have handoffs. We will talk about those. So I'll clarify that later, but you could put guard rails in place. You can add tools. And we're going to see both of my examples are heavy duty on LLM agency, and it deciding which tools to use. So I'm going to show you tools. So there's a lot more that you can do in here, and I'll show you examples of that as we go along. And really, this is the picture of what I'm talking about. Is that every one of those runner.runs basically has a loop that is constantly going back to the LLM. And after the LLM call, it decides to do things. And if the LLM, for example, has said, I want you to invoke some tools, it will go ahead and invoke those tools. And then it'll take the output from the tools and route it back to the LLM and keep going. And the LLM gets to decide when it's done, following the system instructions. And we'll see that. OK, so that is the basic agent framework overview. And there's lots of agent frameworks out there. OK, since very few of you know Temporal, I'm going to slow down a little bit here and tell you more about Temporal. So Temporal is an open source project. It's been around for about five or six years. So yes, it well predates the Gen AI boom that we're in. It's designed for distributed systems. And what are AI applications if not distributed systems? So it turns out that Temporal is beautifully suited for this category of use cases. Now, it's used in a lot of non-AI use cases. So for example, every snap, Snapchat, goes through Temporal. Every Airbnb booking goes through Temporal. Pizza Hut, Taco Bell orders, go through Temporal. There's lots of other ones that I'm not remembering. OpenAI Codex runs on Temporal. So now we start moving into the AI use cases. Codex runs on Temporal. OpenAI's image gen runs on Temporal. Those are the two I can tell you about. Those are the two that are publicly known. So we've got lots of others out there lovable runs on Temporal. So we're definitely making inroads lots of use in the AI space. So I've told you who's using it. But let me tell you what it is. What it is is distributed systems as a backing service. So I think everybody's familiar with the notion of redis as a backing service or Kafka as a backing service, or a database as a backing service. So I've got my applications that are running and I use these back end services to play a part of my application. Temporal is a backing service. What it delivers is distributed systems durability. And I'll make that clearer as we go through the presentation. What that means is that you as the developer get to program the happy path. You get to program your business logic. And the business logic that we're going to program today are AI agents. So you get to say, you know what? What I want to do is I want to call an LLM. Then I want to take the output from the LLM. And I might want to invoke some other APIs. And then I want to loop back to the LLM. And you don't have to build the logic in there that says, what happens if the LLM is rate limited? What happens if my downstream API is down for a moment? What happens if my application crashes? You don't have to program any of that. We do it for you. And I'll show you a few pictures on how this works in just a moment. So there's a temporal service that is the backing service. And the way that you connect to the backing service is through an SDK. And so the SDK sits alongside your business logic. So you get to program your business logic. And the way that you craft your business logic, you put wrappers around certain functions. And that allows the SDK to say, oh, hang on. If you're making a downstream API call, I'm going to step in and I'm going to provide you some service. So I'm going to provide you retries. If that downstream service succeeds, I'm going to record that for you. I'm going to record the answer for you so that in the event that something happens and we need to go through the flow again, I can just get the result that you called before. What that means is, for example, if you have used temporal to lend durability to your agents, when you're on the 1,350 second turn to the LLM and your application crashes, no sweat. We have kept track of every single LLM call and return and you will not be reburning those tokens. That's what it means. That's what durability means in this space. We formally support seven different programming languages, but Apple just a couple of weeks ago released a Swift SDK as well. So there's support in just about any language. There's also experimental stuff out there. In closure, those types of things. I said it's an open source project. The vast majority of it is MIT licensed. There's a little bit of Apache 2 left over in the Java SDK. So very, very permissive licenses. And those of you who don't know the history, temporal was a fork of a project that was created out of Uber called cadence. Anybody know cadence? Yeah, OK, so a few people know cadence. So cadence, pretty much every application running at Uber runs on cadence. And it's because they can program the happy path and all the durability is just taken care of for you. So that's kind of the overview of what temporal is. So I'm going to talk about two foundational abstractions. There's a handful of others as well. But the two foundational abstractions that you need to know about as a developer is you need to know about an activity. And an activity is just a chunk of work. This is work that either is going to make external calls. So it's work that might fail. It's like a lot of work that might fail. Or if you are doing a lot of work that you don't want to have to redo in the event that something goes wrong, you might want to put that in an activity as well. So it's things like withdrawing from an account, depositing into an account. We'll get to the AI use cases in just a moment. So those are activities. You wrap that. Oh, and I didn't mention it. But the SDKs are not just thin wrappers that are sitting on top of a REST API. These are SDKs where, as you can imagine, delivering durability across distributed systems means that all of those algorithms that you thought that you had to implement, like worry about concurrency and quorum and all of that stuff, that's all implemented in temporal. And so our SDKs have a lot of that logic is in the SDK. The service is mostly persistence for that. So there's a lot of intelligence in the SDK. So these activities, if you've said, look, here's my work. Here's a heavy duty piece of work or something that's going external. Let's put an activity decorator on that. Then the SDK says, oh, OK, I'm going to give you some special behavior. Then you'll orchestrate those activities together into your business logic. And what we call those orchestrations is workflows. So and you'll see that what happens when you put activities and workflows together, that's where the magic really happens. There is some level of magic in the activities. And in fact, we're just starting to release what we call standalone activities. So you'll be able to use activities without workflows and get some of those durability benefits there as well. So there's all sorts of evolution that's happening. But the type of magic that I'm talking about, when you bring workflows and activities together is that I overlaid a bunch of icons on here. So I overlaid these little retry icons. So what you do is you specify in your workflow logic, you specify the retry configuration. So you can decide, are you going to do exponential backups? Are you going to do unlimited retries? Are you going to top out at five retries? Are you going to have a maximum window between retries? You get to configure all of that. And as soon as you do that and you orchestrate these things together, now you get retries. And you'll see the code in just a minute. Simply by calling these activities, I don't have to implement the retry logic. I don't have to implement any of this other logic. It just happens for me. So I get retries. I also get these little cues. So what looks to you like a single process application? I'm calling this, that I'm calling this, and I'm calling this. Every single time you call into an activity, every time you come back from an activity to the main workflow, all of that is facilitated over cues. So that what looks like just a single monolithic application is already turns into a distributed system. So you can go and deploy a whole bunch of instances of those, and you can basically scale by just deploying more instances of it. You don't have to manage Kafka cues, any of that stuff. It's all built in. I spoke with somebody this week here at AI Engineers, who's an open source user, actually a customer of ours. And I asked him, it's a relatively small startup. And I said, why did you pick Temporal? And he said, because we tried to build all of this with Kafka cues, and we ended up spending all of our time doing operations on Kafka, and spending 25% of our time on the business logic. When we switched over to Temporal, we're spending 75% of our time on business logic, and they're using Temporal Cloud. I didn't mention our business model is that service, we offer that as SaaS. So they're using Temporal Cloud. So they basically shifted from 2575 to 7525 by moving over here. No longer have to manage Kafka cues or redis or anything like that. And speaking of redis, you see in the upper right-hand corner, you see state management. And so one of the things that we do as well is we keep track of where you are in the execution of your application. We do that by recording the state. Again, every time you're making calls to an activity and coming back, we record that. It's basically event sourcing. That's what we're doing. It's not only event-driven architectures, but we're doing event sourcing as a service. So you get to do that. So we store all of that state so that, if something goes wrong and I'm gonna demo that, we're gonna see things going wrong. It will pick up where it left off because we will just run through the event history and pick up where we left off. So those little icons that I showed overlaid on the logical diagram, I'll get to your question one second. Actually, all of those services live up here in the service, so they're all durable. So it's not that they're living in the process, but they're living here in the service. You have a question? Oh, great question. So, yes, so the question was, a lot of the agents that I'm building are doing streaming, do you do streaming? And the answer right now is a very simple no, we don't. But it is one of the things, and my colleague at the back, Johann, is head of AI engineering. So chat with him, chat with either of us. It is one of the two top priority things that we're working on right now. The other one is large payload storage. If I don't have a chance to talk about it here during the workshop, come find one of us we can tell you about that. You can imagine what large payload storage is. Is that you're doing LLMs, you're gonna, you're gonna pass big stuff around instead of passing it around by value, pass it by reference. That's what large payload storage is. That's Johann. True. Yeah, so I'm just gonna repeat what Johann said in case you couldn't hear it. So we do have customers that have built streaming support on top of Temporal, but what we're doing is building it in natively. So, yep, so you can do it today, it's just a little bit more work. It's not the happy path. So, okay. So with that, I want to give you a demo. So this is gonna be my first demo that I move over here. Let's see if I can get my screen back. Okay, so if you wanna follow along, the first thing I'm gonna do is I'm gonna come over here and I am going to, let me increase the font size. So I'm gonna point you to two repositories. This is actually the second repository, but what I have up on the screen right now, is that if you wanna get started with Temporal, super simple, you don't have to use Temporal Cloud, you can just run a Temporal Service so the backing service, you can just run it locally on your machine. So you can do it by curling this. You can home-brew install it as well. And then to run that local server, you can just say Temporal Server Start Dev. And now you've got a Temporal Service that's running locally. And all of my applications here are just connecting to my local host and we'll see the UI in just a moment. I'll come back to this repository in just a moment. The repo that I'm gonna demo for you is this one. And sorry, I don't know how to increase the font size, but you can see that the org and the repository here is the org is TemporalIO. That's also where you'll find all of the open source for Temporal. And then we have something called the AI cookbook. And that's one of the examples. I actually extended the example just this morning, but and you're gonna find that in the branch that we're gonna demo here today is called the Agentic Loop Branch. So if you want to go back and take a look at this later on, yourself, that's what we're gonna be looking at. Okay, so with that, let me get to my right terminal. And so this is where I'm gonna run it, but I wanna show you the code first. Okay, so am I in the right one open AI? Nope, this is the wrong one. My other cursor, here we go. So this is the Agentic Loop. So I'm doing two demos throughout today. And so what you see here on the left hand side, let me make it just one tick bigger, is that remember that I talked about activities and I talked about workflows. So that's the first thing I'm gonna do is I'm gonna show you the activities. Remember we had withdrawn and deposit, that type of thing. Here, of course, what we're doing is an Agentic Loop. So my activities are going to be call the OpenAI API, not the Agents SDK yet, just the OpenAI API, and then vote some tools. So these are my two activities. So let's look at the first one, and you'll see how simple it is. I promised you the happy path, it really is that. So here is my call to the OpenAI responses API. Okay, it is exactly what you would expect. I'm passing in the model, I'm passing in some instructions. The user input is gonna come in my tools, which I'll show you in just a moment, and then I've got some timeouts that I can configure there that's for the OpenAI. What I've done is I've wrapped that in a function. It takes in that request, so all of those parameters came from a request that I'm passing in, and you'll see how I invoke this in just a moment. And here is that annotation. Now the different SDKs have different approaches. TypeScript, for example, doesn't require a bunch of annotations. It just figures it out and knows where the activities are. Java has annotations, those types of things, but this is Python. So you can see here that we just have an activity decorator. So by just having that decorator, so you can see it's not complicated at all. All you need to do as a developer is say, here's a bunch of work that I wanna do, that I wanna kind of encapsulate into a step, and you just put it in a function, you put an activity decorator on that. So I'll come back to the tool invoker in just a minute because there's something interesting that's going on here. So now if we go to the workflow, the workflow is also pretty darn straightforward. So what I have here is I have my workflow definition. You can see it's a class. The reason it's a class is because when you create a workflow, you create the application main, what I call the application main, and that's what has the workflow.run on it. But this workflow also, I'm not gonna cover these abstractions today, but we have a handful of other abstractions like signals. So for a running workflow, you can signal into it, and we also have an abstraction called an update. It's a special kind of a signal, and we also have the analog, which is queries. So those things are added to this workflow class as just functions that are annotated with signal, update, or query. So that's why we've got a class for the workflow. And if we take a look at what the logic is in here, you can see that I have a while true. So this simple application is just that same picture that I showed you earlier, where I said the LLM, we're just looping on the LLM. And if the LLM makes the decision to do so, we're gonna call tools. That's the whole application. But you're gonna see that I'm doing a couple of interesting things with Temporal here. So in order to invoke the LLM, I execute that activity. So you can see that I'm passing in my model. The instructions here, I won't show it to you, but you can see it all in the repository. The helpful agent system instruction basically just says, you're a helpful agent. If the user says something, and you think you should be using a tool, let me know, you know, choose a tool. Otherwise, respond in high-cues. You'll see that in just a moment. Like, high-cues are like the food bar of the AI world, right? We're all gonna write agents. It's the hello world of the agent space. So we're gonna respond in high-cues. And that's it. So we're doing this in a while, true. And I've got a couple of print statements there. You're gonna see how this runs in just a moment. Simplifying assumption here, I'm making the assumption that it's only calling one tool at a time, so I'm grabbing the output of that. And then I just take a look at it and say, is it a function call? And if it is a function call, then I'm gonna handle that function call. I'll show you that code in just a second. And then I'm gonna take the output from that function call and I'm gonna add it to the conversation history. So I'm not doing any fancy context engineering here. None of that. I'm just basically tacking onto the end of the conversation history. Okay? Now, handling the function call is really straightforward as well. So the first thing that I'm doing is I'm adding the response from the LLM. So we're gonna, by the time we're done with this function call, we're gonna have added two things to the conversation history. We're gonna have added the response from the LLM which says, please make a function call. And then we're gonna do the function call and then we're gonna add the result. And I just showed you where we're adding the result of the function call. So here, this is just me adding that to the, and this is some of the squirreliest stuff. I have this application running against the Gemini API as well. And the biggest pain in the butt in all of this stuff is that the formats are different. So I have to rewrite because the JSON formats of conversation history are different between the different models. Yes, I know there's LLM out there but I don't like least common denominators and also I like to understand what those formats look like. So, but you can see here that I'm just doing some ugly parsing. And then I'm executing, remember, I'm handling the tool call here. I'm executing the activity with that tool call. So I've pulled the tool call out of the response from the LLM. And then I'm gonna invoke that activity which is execute activity and the item name is the tool. Now, one of the things that I was really intent on here is that I didn't wanna build one agentic loop application that does one set of tools. And then have to rebuild a whole another one when I have a different set of tools. The agent itself, and we heard, I don't remember who talked about this but somebody talked about this on stage this week where they said, look, the agentic pattern is fairly standard. And what we're doing now is we're inserting things into the standardized agentic loop. And that's exactly what these AI frameworks are doing, these agent frameworks. And I wanted to do that here in the temporal code as well. Well, the cool thing is that temporal has something called the dynamic activity. The dynamic activity allows you to call an activity by name but that activity is dynamically found at runtime. So the activity handler here, and I'm gonna show you the code in just a second, is basically gonna take in that name and say, oh, okay, I, and remember, this is event driven. So we have an activity that's waiting for things on a queue and so you can configure an activity, you can configure one of our workers to say, hey, this is a worker that will basically pick up anything off of an activity queue. Doesn't matter what the name is. So you don't have to tightly bind to a specific topic name for example, yes, question. That is separate. I'm gonna show you that module. There's a module here that you see that's called tools. If you see the tools directory. The way that I'm running it here, it is, it loads that stuff at the time that I load the application. So I'm not doing any dynamic loading but I can swap in and out that tools module and the agent code does not change at all. So I'm not going all the way to the point where I've implemented a registry and I'm doing dynamic calling of those things. You can do that but this simple example has basically just put that all into a separate module and you'll see how that module can be switched in and out because I'm loading it at start of runtime. So simplifying but yes, you could do that. Okay, so I'm just gonna call an activity and so let's take a look at what that activity looks like. It's this tool invoker. And so you can see here that it has the activity decorator just like I showed you before but now it says dynamic equals true. So that means that this activity handler will pick up anything that is showing up on a queue that isn't being picked up by some other activity already. So it'll pick up, it'll pick up, get weather, it'll pick up, get random number, it'll pick up whatever shows up in there. You have to register, you do have to register, no, you don't have to register all of those. Those things can be done dynamically. You don't have to register them into the worker. And what you can see here is that we basically grab that. We get the tool name and then what you can see here is that I'm effectively looking up the function. You can see here there's no tool names in here at all. It's basically looking up the tool name from a dictionary. It's metaphorically a dictionary. I'll show you those functions in just a second. So I have one function which is a get tools function which by the way, let me go back to that. So in the open AI responses, no, sorry, it's down in the workflow. When I invoke the LLM right here, notice that I made this get tools call. I'll show you that get tools call in just a second. It's completely outside of the scope of the workflow and the activities. It's in its own module. I'll show you that function in just a second. OK, so back to the tool invoker. It's basically now taking the name and then it's doing a get handler. So somewhere here is a get handler call. Here's the handler. I just passed it. Sorry. 17, thank you. I appreciate it. So here's the get handler. And I'll show you that function in just a second. So great question on the how tightly bound are these things. Let me show you where that binding is right now. So I have a tools module here. And I have in the end it is where I've got those two functions defined. So I've got the get tools. And the get tools are basically just taking the list of functions. And I'll show you those functions. And those functions we're passing in here is we are passing in the JSON blobs that are passed to the LLM as the tool descriptions. So these are the tool descriptions. So for example, let me show you the get weather one. So if we go over here to get weather, you can see that the JSON blob is right here. And it's interesting because OpenAI in the completions API, they had a public API that allowed you to take any function that has doc strings on it and generate the JSON for the completions API for the tools. The responses API has no such public API. So there's a warning in here that says this API that I'm using, which is in this tool helper. I'll show you the tool helper. Here's my tool helper. Helpers. Here we go. I guess I could put that in tools. Is that there's a thing in there that says warning. There is currently no public API to generate the JSON blob of tools for the responses API. So I'm using an internal one. There is an open issue on this. So there's just a warning in there that I'm using an internal one. So if we go back there, I've used an internal API to just take my get-weather alerts request, which is it's a pedantic model that has the functions in there and has some additional metadata around it and generates the JSON blob. So again, that's what you see when we go into the agent is that's what you're getting with get tools. Is you're getting the array of JSON blobs for each of the tools. And then, as I said, the get handler basically has, it's basically a dictionary that I've implemented as a set of if-thens. So it takes the tool name and then it picks up what the actual function is. Completely independent. And so this particular example has a set of, and I'm going to demo this for you in just a second, it has a set of tools here. And you can just switch those things out. You do have to restart your Python process at the moment just because of the way that I've implemented it. OK? Make basic sense? All right, let me show you this in action. And so what I've got here is I'm running the worker. I'm not spending a lot of time here talking about workers, but you remember that I said that this is all event driven. And so there's something that is picking up work off of event cues and then executing the right workflows and activities based on what it's pulled off of the event cues. The thing in temporal that does that is what we call a worker. So a worker is a process that you run. With that worker, you register the activities and the workflows that that worker is going to be responsible for. So it's going to be looking for things on the queue to pull off of those. That worker itself is multi-threaded. So it is not one worker, one process. In general, people run. It depends. You can do worker tuning. But in general, people run several hundred threads. So you run one worker and it's already concurrent multi-threaded architecture. So this is some solid stuff. Temporal is just the coolest stuff. It's really, truly as distributed systems designed. OK, so I'm running the worker up here, which is effectively where you're going to see the outputs coming from the activities and the workflows. And I'm going to go ahead and run a workflow. And so let's say, are there any weather alerts in California? That's where I'm from. And I think a lot of you are from. And hopefully where I will be headed back to tonight. And so we're going to start in what you can see here is the way that this application is written is basically, I say, whether or not I'm calling a tool. And so you can see here that it said, oh, I made a call to get weather alerts. And that is what's happening. So there's a tool called that's happening. And in just a moment, I happen to know that as soon as we get a few drops of rain in California, there's alerts all over the place. So here we go. Here's a whole bunch of weather alerts in California. You'll see why I'm pointing that out. It's kind of fun. OK, now let me show you what this looks like. In the temporal UI. So over here, I have the temporal UI. And you can see that I've run a bunch of workflows this morning. And so let me refresh this. And this is the one that I just ran. And what we see here is, yep, there's all of the dense fog advisory. That's about as extreme as we get in California. A little bit of fog, a little bit of wind, high surf, beach hazards. But here is what happened. So you can see in the temporal UI, you can see each one of those activities that I called. You can see that I made a call to an LLM. That's the create line that you see on the bottom. So we're working from bottom to top. Then you can see that I did a dynamic activity. But the dynamic activity that I did in particular, it doesn't say generic dynamic activity. It says I did a get weather alerts. And then as we do with agentic loops, we take the output of the tool and we send it back into the LLM and we get this. Now, I want to show you something here. I'm going to show you a different example. So I'm going to ask the question, are there any weather alerts where I'm at? So does it know where I'm at? And I'm going to start this. And I'm very quickly going to come over here. And we'll see this one running. And you can see, oh, I'm going to be too slow it looks like. But I'll come back and I'll redo this demo. But you can see how it just brought those things in. So I have three tools registered right now. I have a tool that takes in a state. I have a tool that takes in an IP address and returns a state. And I have a tool that gives me an IP address for the currently running computer. And so I didn't wire that up. That the LLM made those decisions just based on the tools. So all I did was I provided those tools. But you can get that visibility across this in temporal. So you can see that we started with get IP address. Then we got the location info from that IP address. Then we got the weather alerts. And here's the ironic thing. Is there are no weather alerts in New York. So I think of New York as a place that has much more weather. But maybe today has come. You have fog, but there's no fog advisories. So you all are a lot more resilient than the rest of our Californians. OK, so I want to show you one other thing, which is, I'm going to come back over here. I'm going to run this again. And I'm going to try to be, I can be a lot quicker. So I'm going to hit OK. And now I'm going to come up here. And I'm going to control C. No worker's running. My agent is not running. It's not running at all. And so if we come over here and we take a look at what this looks like in temporal, and this is going to give you the clearest picture of what I mean by durability and durable agents, is that I have this agent running. And you can see that it made the first LLM call. Then it got the, it made the tool call to the IP address. And now it's stuck. It started to call the LLM, but hang on. Something went wrong. The agent itself is not running. And by the way, I could have also done a demo. And I don't have the time to do all of those today. But I could have done a demo where I cut the network. So I could have cut the network. And what you would have seen here in this little red bar, is you would have seen it. Create attempt one. Create attempt two. Create attempt three. I could have brought the network back. And then it would have gotten through. But for brevity here, because I still want it, I still have more stuff to cover, I'm just showing you one of the failure scenarios. There's tons of failure scenarios that are covered. So I'm going to come back over here, and I'm going to restart the worker. And what we should see happen is, oh, sure enough, it keeps going. So it picked up where it left off. Now, when I say it picked up where it left off, of course, I killed the process. There was nothing running in memory anymore. So when I brought the worker back, it had to reconstitute the state of the application. It did that through event sourcing. So that's the way temporal works fundamentally. Any questions on that? Yes? Can we delegate one agent to another agent? Can you delegate one agent to another agent? Absolutely. Now, we do not yet have native support for A to A, if you're thinking about that protocol in particular. But one of the things that you can certainly do is that you can have an agent act as a tool. And so there are a number of different ways to do that. You can either have an activity and vote another agent, or you can use some other mechanisms. We have child workflows and those types of things. I'm not going to cover that in more advanced use case. But yeah, absolutely. Yep. OK. I'm not going to question it. OK. So first question is about around item potents. So you have recognized that the activities themselves should be item potent. We don't require it. We don't check on it because we really don't get into the inner workings of the activities. We leave that up to the developers. But that is that the guidance is that if they're not item potent, because remember that when we do retries on your behalf, we don't know why we never heard back from the first invocation. So we are going to keep retrying until we get back a response. Of course, it could be that the request never made it to the activity. It could be that it made it and it invoked the downstream function. Could have gone wrong in a number of places. So how do you make sure that your developers are creating your activities to be item potent education? So we don't have any silver bullets there. The second question was around latency. Because yes, I am going up to the server here with every one of those activity calls. And so when we think about agents, the type of latency, and Johann, I don't remember the exact numbers. Do you remember what the numbers are? I mean, it's tiny. The latency to go up to the server around activities. So it's going to affect a bit. Tens of milliseconds. So it's pretty small. So whether I think I have heard of several customers who are using this in quite real-time applications. But in the case of agents, especially agents where they're long running and they're running over minutes, hours, days, or they have user interaction, tens of milliseconds is tolerable. So there might be use cases where it's not applicable because of that latency, but it's pretty small. It's applicable in most cases. OK. All right. So that is the temporal overview. Now, I want to switch back over to the agents SDK now and show you the differences and the similarities. So let's come back over here. I'm going to go through a few more pictures. OK. So the OpenAI agents SDK, the combination of these two things at a very high level looks like this. At the foundation, we have the OpenAI models and the OpenAI API, not the SDK, but the OpenAI API. So you might have noticed that I've already been using the OpenAI API. And we're now going to start using the agents SDK. And then we also have temporal as a foundational element. And now that's what the agents SDK is layered over the top. So those are two foundational components. So it isn't that we're making that temporal sitting on the side or OpenAI, our models are sitting on the side. We have actually integrated these things. And I'll make some comments when we get to the code on how we did that integration. And I'll totally invite Yohan to add to that as well, because he led the engineering for the integration here. So now you've got the agents SDK. And now you're going to use the agents SDK to build your agents, to add guard rails. I'm going to show you some tracing. So I showed you the temporal UI. But the agents SDK has some really cool tracing features as well. And you'll see that we've integrated those things together. You're going to see those come together. And of course, tools. So I've been talking about these temporal activities. And we already saw this. I'll skip that. And so now I'm going to take the same exact example that we just went through. I'm going to have three tools. One is the weather API. And the other two are those location APIs. And what are we going to do? Well, we're going to put activity decorators around them. And I'll show you what that looks like in the other code base in just a moment. We are going to make sure we have dock strings in there, because I showed you how the OpenAI API had the internal helper function that allowed us to generate the JSON blobs to describe the tools. Well, the agents SDK actually does even more of that for us. So you'll see that some of my code went away. And then we'll continue on from that. And this is going to be our loop here. I'm going to show you when we get to the code that the way that we create that JSON blob is part of the integration. So you can take an activity. And we have provided for you a function called activity as tool that will take in the activity, the function itself. So you don't have to worry about serializing it yourself. No internal APIs. This is a public API. It's part of the integration. And you're going to call activity as tool, which is going to generate the JSON blob. And then you can have your timeouts as well. There's another part, which is really important, which is that you have to configure the integration. So the agents SDK alone doesn't use Temporal. And if you want to use Temporal, you need to make sure that you include a plugin. And I'll show you the code for that in just a second. And then, of course, we're going to run it. And we're going to run it the same basic way. OK, so let's demo that. So we're going to spend a lot more time in code and demo again. Let me come back over to cursor. OK, so I've got four files that I want to show you here. I'm going to start with the activities again. So here's the get-weather activity. And you'll see that it actually got a bit simpler. It just has the activity decorator on the get-weather alerts. And then here's the function where it actually makes the National Weather Service API. So there was a bit of code in there that was doing some formatting where it made that API call to generate the JSON blob. That goes away because we have a supported function for that. The location activities equally simple. So literally, this is the entire file. So I've got these two functions with the activity decorators and my doc strings. So the doc strings are describing the arguments and so on. OK? So now, what about the agent itself? So remember, activities were just the things that those were the tools that the agent was using. What I showed you before was an agent loop written in Python that was orchestrating the LLM call and the tool invocations. So now, if I come over to the workflow, what does my workflow look like? This is it. So I have, sorry, this is it. This is the workflow. And it's basically, let me increase the font size, because I have plenty of space, is notice that I'm using the agents SDK. So I'm defining an agent right here on line 18. I'm giving it a name. You're a helpful agent. And I'm giving it a set of tools. Those tools were implemented as activities. And there you can see that I've made the function call that says activity as tool. That generates the JSON blob. That's it. That's all there is to it. That's the way I've implemented it. Now, notice that I'm still doing it within the workflow. Because remember, earlier, I said, we've got activities. We've got workflows. When you put them together, that's where the magic happens. So putting this agent inside of a workflow, that's what adds all of these durability capabilities. Now, I am not going to demo the non-durable version of this, because again, we just have constrained time here today. But if I had implemented this with just the agent s SDK, which is just a Python library, I would have had a single process. And if I killed that process, everything would have gone away with it. There's no way for me to scale that process. And remember, I've got a runner down, right down here. So every one of those runners, it's just a monolithic agent. It's just one Python process. By doing it this way, you can see that if I'm running multiple workers, I can just keep scaling this out by just running multiple workers who are just pulling other things off of the queue. Yes. Do handoffs to other agents work? Do handoffs to other agents work? Yes. And I'm going to come back to that in the final section where we're going to talk about orchestrations. Yes, they do. Absolutely. OK. So now let me go to I need to. I do need to get one other thing out of here. I need to get my worker. Where's my worker? Here's my worker. Because it's in the worker where is the plugin? Johan, help me out. I just passed it. Oh, here we go. Open AI agents plug in. So it's in the worker. Remember, the worker is where all the execution is happening. Think of it as kind of like a logical metaphorical container. And oftentimes, you are running the workers in containers. And here's the configuration that you need to put in there. It's those in notice that it's doing things like it is configuring some of the retry behavior around the LLM. You'll notice did you notice that I did not give you an activity for invoking the LLM. That's done as a part of the agent. But we still want that to be durable. And that's one of the things that our implementation does here. So you're doing some retry policies for the LLM. And you're basically saying, hey, open AI agents SDK, use these parts of temporal. So let me tell you a little bit about what we did as a part of the integration. What we did, if you go back, and you look at the commit history of the OpenAI agents SDK, you'll find a commit where it says, make the runner class abstract. They did that for us. Because that's how we got this durability. That's how we were able to make the LLM calls durable, along with all of the tools that you just saw. So we have our own implementation of the abstract runner class. So that is the way that this works. OK. So we've looked at the activities. We've looked at the workflow. And then we run the tools workflow. I don't think there's anything more to look at there. So let's go over to this. Let me find my right window. It is this window. OK. So what I'm doing in this window, let me go ahead and increase my font size a little bit, is up here in the top window, and I'm going to exit out of these because I only need to. OK. So in the top window, I'm running my worker again. You saw that before. So I'm running the worker up there. And so it's got a little bit of log messages that are going to come out. And then down here is where I'm starting the workflow. Here's where I'm interacting with the agent. So I'm going to, I just pushed some of this stuff. Oh, I'll show you the repository in just a second. So are there any weather alerts in California? And remember the code. The code is just that agent. We've still implemented our activities. But the code is that agent. And you can see the things that are scrolling up there. So you can see actually the API calls to the LLM. You can see the API call to the National Weather Service. And so if we come back over to the temporal UI, it's a difference called Tools Workflow, here you can see it looks exactly the same. And that's why I wanted to spend some time showing it to you with temporal because temporal, if you're building these temporal native applications, you get all this durability, you get this visibility, it looks exactly the same. But you are using the agents SDK to implement your agents, which I think is just so cool. So let's run a second one. And I'll show you the repository in just a second. We're going to run this second example, which are there any weather alerts where I am? And we're going to come over here. We'll watch it in progress. So here it's running. And it's running exactly the same way. And I'm going to run it one more time when it comes back. And it says, nope, you're good in New York. Let me run it one more time. I'll let it get started, get part of the way in, control C out of this. And we come back here. And we see the same thing that we saw before. Agents SDK durable, which is so sweet. I, sorry, I do this all the time, but I still get so excited about this. And there it goes. I'm going to share with you a way to think about this intuitively what we're doing here. I've been writing software for over 30 years. Yes, I have the gray hair to prove it, right? I have written that software where I, when I'm writing the software, I'm thinking about the processes that it runs in. I'm thinking about the fact that, oh, I've got a process here and what happens if something happens to that process. Or as I'm scaling things out and things might not run in the same processes, I'm always thinking about processes. With temporal, what you get to do is you get to write your program thinking about a process as a logical entity. And just let temporal map it down to the actual physical processes that are there. This is particularly, it's so cool to look at. When you do things like human in the loop. So earlier this week, I've done another, another one of the talks that I do is around human in the loop with agents. And one of the big pains of human in the loop is that when you're thinking about building these things and you're thinking about the processes, you're like, OK, I need to run for a little while. And now I'm going to wait for the human in the loop. And it might take a second. It might take a minute. Likely, it's going to take hours or days before this human comes back. What do I do with that process that's waiting for that response in the meantime? Like, you as a developer have to figure that out. With temporal, you don't. You just code it. As if that process, and by the way, the worker architecture works, is that if it's waiting on something like human input, it'll keep it in memory for a little while, a few seconds, then it'll take it out of active memory, but it's still sitting in a cache. And after a little bit more time, it'll come out of the cache. And it'll be just as if you had just killed that process. So that when it does come back after days or weeks, when the user comes back and gives you that input, it just reconstitutes memory the way that it was when it was waiting for the user and continues on. So remember I said it's a crash, or it might be other things, operational things, all of those types of things. So it's so freeing. Once you start to really get into this temporal thing, it is so freeing to realize that I don't have to think about physical processes anymore. To me, the processes are just logical. Temporal takes care of the rest for me. Super cool stuff. All right, we have about 20 minutes left. I'm going to go through just a couple more slides to answer one of the questions around handoffs. And just show you just a little bit more content. And then we'll have a little bit of time in the last, I don't know, maybe 10 or 15 minutes, I'd be happy to take more questions. And Yeohan would be, I'm sure, very happy to jump in as well. OK, so let me. So with the OpenAI Agents SDK, this is what I'm talking about here is somewhat specific to the Agents SDK, but this does kind of generalize to agents in general, which is, with the OpenAI Agents SDK, the kind of paradigm that they use there is to build lots of small agents that have their own independent agent groups and then orchestrate them together. And there's two ways that you can orchestrate them together in the Agents SDK. And I'm going to show you both of those in just a moment. So what we see here on the screen are just a couple of diagrams of, OK, I've got a triage agent, I've got a clarification agent, then I've got a human in the loop, that's not an agent. Although you might think of the human as the agent in this application, right? Then I've got an instructions agent that's going to craft some stuff, then I've got a planning agent, then you can see that we're doing things in parallel. I didn't talk about this, but temporal has all those abstractions. Anything that you can write in a regular programming language, you want to do multi-thread it and have a bunch of different threads and do things in parallel and then wait for them to come back together. You can do that. You want to have some kind of an await that says, you know what, as they start coming in, I'll start processing them. No problem. You can do that. Anything that you can do in code, you can do with temporal, because you're just coding. So that's effectively the way that it works here with the agent SDK as well. I'll show you those things again as well. So you can do parallel, you can have long weights, and you can have loops. So I already showed you the fact that I didn't have to craft my logic in the Python. The logic, the LLM made the decisions on how the flow was going to happen in that application, right? So I just had a loop that the loop itself is like fixed, but what happens in the loop is entirely determined by the LLM. So those are all things that you can do. So there's two ways with the agent SDK that you can orchestrate these microagents. And by the way, I just have to say I love the term microagent. As I mentioned early on, I spent a lot of time in the microservices world. And oh my gosh, did we get a lot of mileage out of that, right? That's the reason that we can deploy software multiple times a day. That's the reason why we can scale the way we can scale. Micro-services have proven themselves to be very valuable. I think we're going to see a very similar paradigm, very similar success when it comes to building AI agents, MCP tools, and all of that kind of stuff. So I love the notion of microagents that do one thing and one thing well. I've spent enough time in the land of Unix as well that makes my heart sing. So just code and handoffs, the just code is really simple. It's what I described before. So you can see here that I have a runner.run. I'm executing an agent. I get back a result from that agent. And I pass that result into the next agent. I can parallelize, I can loop, I can do whatever I want. The second way that, oh yeah, and I already showed all that. So yeah, yeah, I mentioned all of those already. The second way that OpenAI, and were you talking about OpenAI specifically when you were asking about handoffs? Yeah. So for those of you who don't know, OpenAI has a second way of doing orchestrations, which are called handoffs. And so what you see here is that in my definition of an agent, I can define handoffs. Those handoffs are other agents. They've been defined, I probably should have it on the slide. But I have a weather agent that is defined very similarly. It's using agent, has a name, has instructions, might have tools. So these two are agents. And all of this works with the integration with temporal. And what's interesting here is that those microagents, when it hands off to an agent, it is not doing a separate agent to clube. It effectively, and this is my wacky attempt at trying to describe what's happening here, is that when you do a handoff, what you're effectively doing is just changing the context of the agentic loop. So there's one single agentic loop. You have a triage agent, for example. It decides that it's going to go into delivering, I worked at Alexa for a while. So did you ask how late is Costco open or did you ask what the current temperature is? So those are two different agents, the weather and the local info agent. And what you're effectively doing is you are that agentic loop is taking on a different persona. You're just switching the context. And we heard lots of talks this week about context engineering. Because that's the beautiful thing about the LLMs being forgetful, is that you can completely control what the context is that's going into them. So this works exactly so temporal is totally hand off aware. I don't have a live demo of that. And so that's it. OK. So with that, we're going to have a few minutes left for questions. I want to leave you with a few resources. So what you see here on the left hand side is you see a QR code for the temporal Python SDK. You'll find lots of great info on our Python SDK. But you'll also find a Contribute Directory. And that's where all of the integration code to the OpenAI agents SDK is. And you'll find lots of samples in there. On the right hand side, I didn't have a QR code for it because my marketing folks don't work on Saturday mornings. Good for them. Is you will see a URL here. So if you go to our documentation, so docs.tempoorol.io. In the top banner, you'll find AI cookbook. We have an AI cookbook that implements a bunch of patterns. The one that I showed you today, the agentic loop, is in a branch at the moment. It is ready to be merged. It's been reviewed. But my reviewer didn't actually give it an approval review. They just reviewed it and said, looks good. But I need an approved. So I couldn't merge it this morning. But that recipe will be up there. And there's a number of others. There's a recipe in there for OpenAI agents SDK. So you'll find that in there as well. So summing it up, I'm not going to belabor that. I think we went over that as well. Two other resources that I want to leave you with is on the left-hand side, you'll find our blog where we describe the integration of the OpenAI agents SDK and temporal. So that's the blog on the left-hand side. The other thing you'll notice is that I have a pedantic blog there. And so this idea of bringing durability to these otherwise non-durable agent frameworks is a very popular one. So after we did OpenAI agents SDK, pedantic themselves integrated temporal into their agent framework. And Johann, I don't know which ones we can talk about. We have a whole bunch of other ones in progress. Is that all we want to say? Or do you want to talk about any of those in specific? OK. There's more coming. Yeah. I think we have two or three or four that are in progress right now that will be popping out either from us or from some of the other agent frameworks. So this idea of bringing durability to what is otherwise kind of just a proof of concept tool is turning out to be quite powerful. And then finally, if you would be so inclined, here's a QR code and a URL. If you want to give us some feedback on this workshop, we'd really appreciate it. And include in that feedback, there's some freeform in there. Include in that feedback what you'd like to see more of. Like, hey, this was cool, but it didn't go far enough. Or you mentioned this. I'd really like to see more about human and the loop. By the way, if you go on our YouTube channel, you will find a bunch of different presentations. So the human and the loop I did a webinar on that like three weeks ago. We've done some MCP module, MCP things, even advanced. So we did an advanced one where we showed you how you can use temporal to implement an MCP server that is durable and supports sampling and elicitation in a much more durable way than it otherwise is. And with that, we still have now about eight minutes. So oh, I'll also mention, especially if you're in the Bay Area, but even if you're not, is that our conference, our replay conference, the temporal conference, is in May and it's going to be at Moscone. And so we sure would love to see you there as well. And oh, this QR code here was meant for the workshop that I did on Tuesday, but heck, might as well use it here. 75% off, yes, 75% off the registration for replay. So invite you to come there. You'll find me, you'll find Johan, you'll find a whole bunch more of us. And you can see that we've got all sorts of really cool people like Samuel Colvin is coming and we've got people from Repplet and Vidya and lots more coming. So I'll leave the feedback up there. So we have a few minutes left for questions. Yes. How state-safe? How was state-safe- You shut down the phone. Yeah. OK, so you're talking about the temporal server that I showed you how you can run it locally. So when you're running it locally, you can put a switch on there that says, hey, start in a SQL light or something like that. So there's state that backs it. I usually don't run that way because I want to throw away things anyway. So temporal is open source and we have lots of users that self-host it. Because it's open source, we literally at events like this always run into people. I ran into somebody yesterday or something who was like, oh, yeah, we're using temporal. And I'm like, and they're just using the open source. So it truly is open source. And so we do have people who are self-hosting it. And we support relational database in Cassandra as the backing stores. On temporal Claude, part of the reason that people come to Claude is that, first of all, we run Claude in 15 different Amazon regions. I don't know, 4 or 5 or 6 Google regions. We have multi-region names, faces, all of that durability. And then we do also have some special sauce on the persistence that allows us to do things more efficiently. But we have people who are hosting it quite successfully using the Cassandra or the database options. So yeah. Any other questions? Yes? Start and stop. When I start and stop the instance, the agent, you mean? How do we stop it if the user wants to stop it? The work? So yeah. So there are a couple of different ways that you can start a workflow. You can start a workflow expecting it to be synchronous. And it just ends and you would have to have some kind of a kill on that. But more commonly, you're going to start it in an async mode, and you're going to get back a handle. And then you can do things against that handle to stop workflows. But generally, the most common thing is that you are going to define in your logic what it means to have completed that agentic experience or completed that workflow in some way, shape, or form. And so you will decide, oh, I'm done now, and you'll just return. So it's really as simple as doing a return from it. It's a good question, though, since we're talking about these asynchronous things, I didn't talk about it in this session. But one of the really powerful things is that these workflows can run for hours, minutes, days, weeks, months, years. And it's super efficient. And what we, what a pattern that a lot of our users use is they use a workflow as kind of a digital twin of something else. We call it entity workflows as well. So for example, you might have a workflow that corresponds to a loyalty customer. And every time that loyalty customer scans their QR code at the checkout register, it'll send a signal into the workflow. And the workflow is otherwise not consuming any resources. And it will just pop up, take the signal, process what it needs to, and go away again. So that is a very, very common pattern. Is this notion of digital workflows as digital twins of some other processor, or some other entity? Super, super powerful. Lots of people use that. Yes? Yeah. So it will work for us. So as far as I know, we do not have those integrations, but our customers build those integrations. Yeah, yeah. They absolutely build those on top. Whether we have some of those in Claude, I'm not sure. But it isn't something like we don't have native Slack connectors or those types of things. And some of that of course wouldn't necessarily be a temporal thing. Like if you're running your workers on Kubernetes, you might have set up your Kubernetes configuration so that when the container goes down, you're going to get alerts. Or when you see something in the Kubernetes dashboard where, oh gosh, like my autoscaler. And of course, you can have these workers and you can have them running on Kubernetes with autoscalers. So a lot of that, you know, that like IT orchestration stuff probably would come through your operational environment. You are, that's actually a really good point, is that we host the server, but we do not host the workloads for you. So you're hosting the workloads yourself. Most people love that because they want complete control over that. We are toying with the idea in some instances of maybe hosting workers in the future, but that's nothing on the roadmap right now. Yes. Examples of people building voice agents with temporal. I don't know of any offhand. I don't know if any of that are important. Yep. Yes, question in the back. So I do not have Claude up, keep an eye on the cookbook. I do not have examples for Claude just yet. I have Gemini almost done. And yeah, we want to add Claude to the cookbook as well. We'll also happily take PRs. So if you want to take this example and map it over to Claude, we'd love to have PRs on that as well. So yeah, this is the cookbook is all open source. It's all in MIT licensed in our main repository, our main org. Yes. Any example agents on extracting information from Excel, media? Example agents of extracting from Excel or PDF. I don't have any personally. One of the other things that I'll mention is that we have a code exchange. So we have the cookbook is ours. And that's where we're very careful about making sure that it demonstrates best practices. And we do rigorous reviews on those because we don't want to mislead you at all. We also have a code exchange, which we have literally, I think 20 or 30 or 40 examples in there. There might be something in there. I'm honestly not sure. Yeah. Is it like a GitHub? Yes. So you'll find the code exchange on our website. And I believe all of the entries in the code exchange have GitHub URLs. We don't own most of them because they're from the community, but there are other people's repositories. So yeah, you would find that. All right. Well, this has been, is there another question? I just want to comment that we've mentioned a few times that's coming, or that'll be really, really cool to do. And my team is hiring for folks. The hiring plug. On these AI applications of Temporal. OK. And since he said that, I'm in developer advocacy. We're looking for developer advocates too. So if you fit the engineer profile talk to Yo-han, if you fit the developer advocate profile, come talk to me. So. OK. Well, thank you so much.