AI Engineer World's Fair 2025
Events are the Wrong Abstraction for Your AI Agents
Read the talk
Events Are the Wrong Abstraction for Your AI Agents
An agent needs to survive failed calls, lost processes, and long waits. Durable execution puts that control flow at the center while moving event machinery into the platform.
From a talk by Mason Egger
Before you start: Familiarity with message queues, service APIs, and basic asynchronous programming will help you follow the architecture comparisons.
Choosing the center
Put Earth at the center of a diagram of planetary motion and the paths become elaborate loops. Put the Sun at the center and those same motions become much easier to understand. Mason Egger, who works at Temporal, opens with this comparison to ask a software design question: what belongs at the center of the system?
In Egger’s historical framing, the Copernican shift helped open the way to new discoveries about nature and gravity. His architectural point depends on the choice of reference frame, not on declaring one projection useless. Both can describe motion; Earth is a useful reference for a moon trajectory, while the Sun makes planetary trajectories easier to reason about. The best abstraction makes the problem you are solving simpler to express.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The event-driven agent baseline
Making AI software available and scalable brings familiar infrastructure problems into an unfamiliar application. Egger compares scaling agents with scaling microservices: the model does not remove the distributed-systems problems engineers have spent decades addressing. One established response is event-driven architecture. The definition he gets from Claude describes components producing and consuming events, processing asynchronously, and reacting to state changes rather than making direct method calls.
The agent diagram turns that definition into a recognizable system:
| Component | Responsibility |
|---|---|
| Cron jobs | Clean up inactive chat sessions |
| Message bus | Carry events between participating components |
| LLM orchestration and tools | Perform the agent’s work |
| Dead-letter queue | Retain failed tasks that cannot be reprocessed |
This is a workable design. But tracing its boxes raises a different question: how much implements the application’s purpose, and how much exists to prevent the application from breaking?
Egger speculates that hundreds of thousands of production agents use this architecture; he provides no measured adoption count. His objection is not that it cannot work. It is that events have become the organizing center, while the core logic is surrounded by machinery for managing their delivery and failure.
Egger recalls an SRE incident in which roughly 100 lines of simple application code brought down a large travel enterprise because of mismanaged queues. The anecdote illustrates the imbalance: a small amount of business logic can inherit a much larger operational failure surface from its coordination infrastructure.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Contracts, control flow, and state become scattered
The first cost is an unclear application contract. Egger argues that adopting events often sacrifices the explicit, documented interfaces developers expect from APIs. He acknowledges AsyncAPI, but describes it as documenting produced and consumed message formats. That description is narrower than the specification: AsyncAPI 3.0 also covers operations, channels, servers, security, and replies. The architectural concern remains useful, however: documenting individual interactions does not by itself make the application’s overall control flow easy to follow.
The next cost is reconstructing that control flow. In the extreme Egger describes, business logic is fragmented across thousands of services. Debugging no longer means opening the file containing a procedure. It means searching the codebase for an event name, finding its producers and consumers, and reconstructing who triggered what, when, and why. If the relationships remain opaque, an engineer may have to run the system just to discover how it fails. Egger likens that to crashing a car into a wall to learn whether it breaks.
Each participating service then becomes an ad hoc state machine, often with a local database or cache to remember its progress. Egger jokes that enthusiasm for implementing state machines fades after being paged for one. The operational problem is concrete: without a transaction joining message handling to the corresponding state update, the system can record one part of a transition without recording the other.
Those inconsistent intermediate states create opportunities for race conditions and difficult overnight incidents. Recovery becomes more application code—or manual work pushed onto customer-success teams, who reset the system or roll back a database after it crashes. The queues have not eliminated coordination; they have distributed responsibility for implementing and repairing it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Runtime independence is not design independence
This leads to Egger’s most provocative claim: event-driven systems can be tightly coupled. The distinction is between runtime coupling and design coupling.
| Dimension | Question |
|---|---|
| Runtime independence | Can other services keep running when one fails? |
| Design independence | Can one service change without breaking its consumers? |
An event bus can help with the first without guaranteeing the second. A consumer need not be running at the instant a producer emits an event, but its code can still depend on the producer’s event structure and meaning.
Egger illustrates the confusion with a fictional refactor: an engineer makes every local variable global, then celebrates that new code can read those variables without asking anyone. Access has become easier, but dependencies have become harder to see. Open-ended event consumption can create the same problem.
A producer changes an event format and breaks a consumer it never knew existed—perhaps through a dependency several services downstream. Once teams have experienced that failure, they become reluctant to change the event at all. Runtime flexibility has produced a design dependency that discourages iteration.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Execution that outlives its process
The proposed change of center is durable execution: express what the application should do, and give the platform responsibility for preserving its progress through failures. Egger calls this “crash-proof execution.” The promise is that a process failure need not become a failure of the application’s entire operation. He develops that promise through four characteristics.
First, preserve application state. An ordinary process crash loses in-memory variables. Developers compensate by writing state into Redis, a database, or another store, then implementing reconstruction themselves. Egger describes durable execution as automatically preserving variables, calls, inputs, outputs, and returns. For Temporal, the mechanism is more precise than a snapshot of arbitrary process memory: its Workflow Execution documentation describes deterministic replay against a recorded Event History, allowing workflow state to be reconstructed.
Second, virtualize execution. A logical execution no longer belongs to one process on one machine. If the process fails, another can recover progress from the recorded history and continue. The developer can reason about a continuing workflow even though different processes may perform its work over time.
Third, let execution outlive a short request window. A thirty-day wait becomes a reasonable operation because it does not require keeping the original process alive. A durable timer records the wait; a crash does not require starting the full interval again. For example, the wait can be expressed in a Python Temporal workflow as:
python
from datetime import timedelta
from temporalio import workflow
@workflow.defn
class ThirtyDayWait:
@workflow.run
async def run(self) -> str:
await workflow.sleep(timedelta(days=30))
return "Wait complete"
The significant operation is workflow.sleep: the workflow waits durably instead of relying on a process-local timer to survive for a month. If execution infrastructure is unavailable when the wait ends, work can continue after it recovers.
Fourth, put reliability in software rather than specialized hardware. Egger contrasts this approach with expensive fault-tolerant machines that support hot-swappable CPUs and memory. He points to a Raspberry Pi experiment as an illustration. The company’s Temporal in Space account describes a Raspberry Pi 5 Worker carried into the stratosphere by a weather balloon, with recovery after connectivity returned. That is the concrete experiment behind his outer-space shorthand: ordinary hardware participating in an execution whose progress survives interruption.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Put the workflow at the center of the agent
The revised architecture keeps the chat UI, LLM calls, and tools, but places a durable workflow between them. Failures such as an LLM outage or rate limiting become retryable operations managed by the execution platform. If a worker crashes during the operation, the workflow can reconstruct its state and continue.
Egger describes calls retrying until they succeed. In Temporal, that behavior belongs to Activities under a retry policy, rather than to every ordinary function call. Activity retries can stop because of configured attempt limits, timeouts, or non-retryable failures; Workflow Executions do not retry by default. Automatic retry removes repetitive recovery machinery, but does not guarantee that an unavailable dependency will eventually succeed.
The workflow can also arrange longer-term state storage for auditing, either at a predefined point or when the execution closes. In the completed diagram, the chat UI connects to the central Durable Workflow, with Tools, an LLM API, a Durable Timer, and chat-state storage around it. Automatic retries and LLM response validation appear at the relevant connections. The simplification is in the developer-facing control flow: the application’s steps are central, while queue and event management recede into the platform.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Different languages, shared execution machinery
Temporal provides this execution model, with an open-source server released under the MIT license. Egger presents it as a way for developers to concentrate on business logic rather than managing the surrounding queues.
At talk time, Egger lists seven SDK languages: Go, Python, TypeScript, Ruby, .NET, Java, and PHP. This is a historical inventory, not a claim that all seven had the same maturity: the Ruby SDK release history places Ruby in public preview at the June 2025 conference, with general availability announced that October. Egger also teases another SDK later that year without naming it.
The language interfaces can participate in a polyglot system. Egger’s example is Go code invoking work written in Ruby by supplying a function name and input parameters. The consequential reveal follows immediately: events still exist underneath. Durable execution changes the interface developers use to coordinate work; it does not make distributed communication disappear.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Moving complexity into the platform
Egger places this move in a history of programming abstractions reaching back to the 1950s. Progress often comes from moving machinery out of application code and into a language or runtime. His examples trace that shift:
| Abstraction | Machinery it helps developers stop managing directly |
|---|---|
| FORTRAN’s mathematical operations | Assembly and manual register manipulation |
| ALGOL 60 and Pascal’s structured control flow | Jumps and goto statements |
| Lisp’s garbage collection | Manual memory management |
| Simula and Smalltalk’s objects | Lower-level organization of state and behavior |
These are the milestones in his analogy: developers gain a more useful vocabulary for the work they intend to express.
Durable execution makes a similar proposal for distributed applications. Events and queues remain necessary implementation machinery, but the platform takes responsibility for coordinating them. The application can express a sequence of work, a retryable operation, or a long wait without spreading that sequence across independent event handlers.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The network boundary and the crash challenge
The closing Scooby-Doo meme removes an AI disguise to reveal distributed systems underneath. Its practical point is the network boundary: once an agent calls an external model or tool, it depends on another process and a connection that can fail. Naming the application an agent does not remove that responsibility.
Egger ends by inviting attendees to the Temporal expo demo and challenging them to turn off his computer or laptop. He promises that the durable agent will keep running; the recording ends with the invitation, rather than showing the shutdown and recovery. The challenge makes the intended abstraction tangible: the lifetime of the agent’s work should not be the lifetime of the machine currently executing it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Specification for documenting message-driven APIs, including operations, channels, messages, and security.
MIT-licensed Temporal server source with setup instructions and links to SDKs.
Account of a Raspberry Pi weather-balloon experiment testing workflow recovery after lost connectivity.
Further reading
- How Temporal Workflow Execution worksDocumentation
Explains Event History, replay, commands, and timers behind durable workflows.
Documents retry defaults, backoff, attempt limits, non-retryable failures, and timeout constraints.
Mason Egger's step-by-step tutorial builds an agent with event search, flight search, and invoice tools.
Updates since the talk
- Temporal Ruby SDK release historyDocumentation
Tracks Ruby SDK milestones, including public preview in May 2025 and general availability in October 2025.
Read the complete timestamped transcript
- 0:00
[upbeat music] Welcome, everyone.
- 0:15
Uh, my name is Mason Egger. I work at Temporal, and today we're gonna talk about, uh, events are the wrong abstraction for your AI agents. So, uh, who here, raise of hands, kn- recognizes what this diagram is, out of curiosity?
- 0:28
Okay, so this is a map of our sol-solar system, um, in a geocentric projection. Uh, this is where we have Earth as the center of our solar system, and this is how celestial objects move around the Earth.
- 0:40
And this was used to kind of calculate, uh, celestial trajectories prior to, like, the sixteenth, seventeenth century. Um, it's really pretty. I really like it. Uh, complex, but really nice.
- 0:52
And then around the sixteenth century, uh, Copernicus decided to put the Sun at the center of the g- of the solar system, and it greatly simplified how we view our world and how we view the universe.
- 1:03
Um, this allowed people to start thinking about the laws of nature. We got the laws of gravity and a lo-lot of different things because of us being able to recenter our focus on how we look at the way that we're looking at things, uh, the way that we, uh, build things.
- 1:15
And basically, a whole series of new dev- uh, discoveries and de-developments were made simply by just focusing our shift on how we decide to look at things. Now, it's interesting to note that both of these are actually accurate.
- 1:26
They're both correct. Um, however, it's interesting that you have to take the right frame of mind and look at what do you need to use, what tools do you need to use, what software are you using, and dec-determine how do we want to use this as a reference.
- 1:41
So for example, if we're looking at something like a moon trajectory, it might be useful to use the Earth as the frame of reference here. But if you're thinking about something as, like, the planets and how planetary objects move, then it's probably more useful to put the Sun at the center of your ecosystem.
- 1:52
So you're probably wondering why I'm talking about this, and that's a pro- pretty valid question. We're all building software here. We're all building AI software. And ensuring that the software is available and scalable for our users is extremely challenging.
- 2:05
Um, scaling our AI agents is actually no different than scaling a microservice architecture. At the end of the day, this is all just distributed systems. Um, which is great because we're not solving any new problems here.
- 2:16
We're solving the same problem that we've been solving for the last twenty years. Um, nothing here is new. It's this, all we did is we added a different label to it.
- 2:23
Um, and we do have d- patterns for design, for solving this, which is event-driven architecture. So I asked Claude this morning to give me a definition of what is event-driven architecture, and this is what it came up with.
- 2:33
It said, "Event-driven architecture is a software design pattern where components communicate by producing and consuming events, allowing for loose coupling and asynchronous processing where systems react to state changes and/or occurrences rather than direct method calls."
- 2:46
Um, I mean, that's a pretty fair, pretty fair, uh, thing, and I expect Claude to get that right. So that's a pretty good explanation of it. Um, but let's look at, say, what an event-driven AI architecture would potentially look like.
- 2:57
So we have, mm, pretty fairly decent design, if I do say so myself. I didn't make this, so if, if it's great, I made it. If it's not, blame some, blame my colleague.
- 3:06
Um, so we have some cron jobs here to handle inactive chat sessions, basically acting as a garbage collector for a whole bunch of things. We, uh, have a message bus where events can be published and ingested by the various tools that we are using, different LLMs, all of those things.
- 3:18
Um, we have a dead-letter queue for handling tasks that have failed, and we just cannot possibly reprocess them. Um, this is pretty great. This is a pretty straightforward, uh, E-EDA-based eco, uh, architecture.
- 3:29
The question is though, how much of this in here is actually the core business logic of your application? How much of this is actually what we're trying to solve versus trying to make sure that the darn thing doesn't break?
- 3:41
Good question. So some of you might be going, "Hey, this is great. Ship it. Love it." Um, and you're right, that diagram does work. There are probably hundreds of thousands of agents deployed into production right now that use that exact same architecture.
- 3:53
I'm not gonna argue. It's a great, fine architecture. It works. But I wanna go back to our discussion that we were having earlier. Do we have the right thing at the center of our eco- of our, of our ecosystem?
- 4:03
Are we looking at this through the right same frame of mind? And I'm here to say that I don't think we do. Um, we have built all of our applications in the modern world with events as the center of our universe instead of the core logic, the core foundation of what we're trying to solve.
- 4:18
Um, and if you look at that diagram that I previously had, there are more parts about handling the events than there was the core logic of the actual application.
- 4:26
Uh, I was an SRE in a past life, uh, for a company, and I've seen applications with hundred lines of code, dead simple logic that have brought entire enterprises down, large traveling industries that begin with the letter E, um, because of mismanaged queues. [chuckles]
- 4:42
So find me after the talk. I'll tell you about my horror stories. So issues with this approach. So what do we have? Well, we don't get APIs in an EDA architecture.
- 4:52
We sacrifice clear, well-defined APIs, uh, because when we adopt events. Uh, the events lack documentation and structure that all of our APIs that we've spent all these years building have given us.
- 5:02
Um, and yes, there is an AsyncAPI spec, but that really discusses the formats of the messages. It's not really an API. It's just what is produced and what is consumed.
- 5:10
It doesn't really give us much more than that. And as we all know, developers are great at documentation. That's why there's so many of y'all working on documentation AI tooling right now.
- 5:19
Um, so this is great, right? Then we-- now we have scattered logic. Um, we have our business logic now becomes fragmented and s-spread out across thousands of different services.
- 5:28
Um, instead of having a bug and let me going, "Oh, let me open the file and see what that is," now I have to open multiple files. Now I have to grep across the code base for the event name to figure out who called what, when, and where, and how.
- 5:38
Um, and it, if it gets even worse, I have to run the thing to figure out how it failed. That's worst-case scenario, but I've seen it happen. It's like I have no idea what this is doing, but if I run it, I can figure it out.
- 5:47
I'm like, that's, that's like saying we don't know if the car's gonna break when we crash it, so let's just slam it into the wall and see what happens.
- 5:54
Not a great way to go about things. Um, and now every single one of our services [chuckles] is now an ad hoc state machine. Like, and I know that CS majors love implementing state machines, and I'll pr- tell you this, the only reason they love them so much is because they've never been paged for one.
- 6:08
Uh, once you get page four one, you stop loving your state machines really quick. Um, services now have local databases and local caches to make sure that things aren't failing.
- 6:16
Um, in many cases, there's no transactions between the message and when you've updated your state, so you get into this really fun state where we've updated something, but we haven't quite actually updated it yet, and now we've got into this weird case.
- 6:28
And that leads us to the best case of all, race conditions. So now we don't know what's actually happening, um, and now we get paged at two AM in the morning to f- to deal with the hardest bugs of all.
- 6:39
Um, and we now either have to write log to do this, or we can do what some companies do, and we can just push it off to customer success and be like, "Oh, they'll just reset the system whenever it crashes.
- 6:47
That'll work, right? We'll just roll back the database." Um, eh, I don't think that's a good, good thing. All in all, I could go on hours and hours about why this approach doesn't work, but it leads to one thing, and I'm gonna ruffle some feathers, so we'll do this lightly.
- 7:01
EDA is a tightly coupled system. Now, I know everyone's gonna go, "Tightly coupled? Whoa." We've been told that event-driven architectures are loosely coupled. It's what I'm taught in school.
- 7:10
It's what Claude told me this morning when I asked it. And it is true, they are, they are loosely coupled, but they're loosely coupled at runtime. They are not loosely coupled at design time.
- 7:20
We conflate the two. They think that because they're loosely coupled, because we can have a service go down, and that it-- the other services can keep running, that they are loosely coupled at runtime, that that, that translates into design time.
- 7:30
And that is not the case. That is not how this works. Um, so imagine that we had this re-- this discussion. Uh, engineer A comes up and says, "Hey, I've refactored all the code to make everything more loosely coupled."
- 7:40
And you go, "Wow, that's great. How did you do it?" "Well, I turned all of my local variables into global variables." [audience groans] "Oh, great. Uh, why on earth did you do that?"
- 7:48
"Well, now we can add new code, and everybody can just read from them, and we don't have to worry about telling anybody when we update it." [audience laughs]
- 7:55
That sounds insane, right? That's what we do with events. So I-- that's what's happening. So [laughs] it's just wild that we think that that's a good use case. And it sounds like it's the same logic, um, and we can just read from that event until somebody decides to change the format because you were reading from an event that
- 8:12
you didn't te-- somebody didn't know you were, and now somebody else downstream from you three stories you didn't know were reading your event broke-- you broke their system because you updated the event, and I can hear people's pages going off as I'm saying this.
- 8:24
Like, been there, done that. Um, and what it does is it leads to people not being willing to iterate on their architecture or their design because they're scared if they touch the magic event, everything will crumble to the ground.
- 8:35
So this is what basically happens. So, so now what? Where do we go? I propose we need to reorient ourselves. We need to fo- take a step back and go, "Is this the actual proper center?"
- 8:45
Take a step back and see what the frame is. So let's put the right thing at the center. I believe this is durable execution. So what is durable execution?
- 8:53
It's kind of a new category of software. It's called crash-proof execution. Um, and basically, it enables developers to write software with less effort. Um, it allows them to focus on the application, on what the application should achieve, instead of trying to anticipate or mitigate everything that could possibly go wrong.
- 9:08
This, in turn, will accelerate your development, and basically, it turns out that failures are inevitable, but durable execution makes them inconsequential. So here's the four characteristics that we've come up with to define durable execution.
- 9:20
Durable execution applications automatically preserve, preserve your application state. So in a typical application, uh, a crash causes, uh, causes the variable-- Like, a crash will cause you to lose all your variable state.
- 9:30
Everything is lost. And developers will typically make a cache, a Redis cache, a local database, something of that nature, to save all this backup to so that we can rebuild the state if it crashes.
- 9:40
In dur-- in a durable execution system, you automatically get the saving of the state, like, for, like, out of the box. Just automatically, all your local variables, all of your function calls, the inputs, outputs, returns, all of it is stored automatically for you.
- 9:52
Because of this, this allows us to virtualize the execution. So execution usually takes place in a single process on a single machine and will im- and basically will immediately end if that process crashes for any certain reason.
- 10:03
Um, durable execution can happen across a series of processes across multiple machines. If one of the current process fails, durable execution will basically take that state that it saved, restart the execution, and resume execution from the point of the last known g- last known save point and continue on very often without this ever even being aware-- the
- 10:21
developer being aware that this even happened. This is also not limited by time. Because durable execution can survive a crash, it enables it to run for as long as you like.
- 10:31
Um, so it's... You know, most people would never even think about putting sleep for thirty days inside your code. That's a totally valid and one hundred percent achievable goal within a durable execution system because it just comes back online whenever it's ready to be run.
- 10:44
It will survive that crash. I can sleep for thirty days. If it crashes, it doesn't matter. Bring it back online, resume the timer, continue forward. And it's hardware agnostic.
- 10:53
We, in the, in the past, have tried to solve some of these problems with fault-tolerant hardware. We pay a lot of money to be able to hot swap out our CPUs, to be able to hot swap out memory, all of that stuff.
- 11:03
Durable execution is completely hardware agnostic. It can run anywhere. We ran it on a Raspberry Pi and shipped it into outer space. Check out our YouTube channel. Um, you can run it wherever you wanna run it.
- 11:11
Uh, it's builds reliability into the software side, not the hardware side, and it requires no actual specific hardware. Um, and it runs natively anywhere. And it overcomes all of these issues.
- 11:22
So this is what a durable execution agent architecture would look like. We have... We still have our chat UI. We have a durable workflow. We automatically get retries. Whenever a failure happens, when we're, we're talking out to our LLMs, when we're talking out to our tools, if a, if, if the LLM goes down, we're getting rate limit,
- 11:37
automatic retries. You don't even have to develop that. You call a function call. That function will automatically retry until that thing becomes successful. Doesn't matter. If this thing crashes in the middle of it, automatically reconstructs the state, continues on as if this had never happened.
- 11:50
Uh, we can store our, our longer states for dur-- for storage for audit purposes at a, at a s- predefined time or whenever we decide we wanna close the execution.
- 11:58
Um, this is basically a much simpler diagram than what we had earlier, and now the developer doesn't have to focus at all about managing queues or events or any of those things.
- 12:08
They can focus solely on the business logic. So Temporal, uh, provides durable execution. It's an open source MIT licensed product. Um, we're here at the, at the booth today, uh, or in the hall, and you can come and visit us.
- 12:21
And it supports currently seven, uh, programming language SDKs. Uh, so Go, Python, TypeScript, Ruby, .NET, Java, and PHP. There will be another one coming later this year. If you looked into it, it's not that hard to figure out which one it is.
- 12:33
Um, and the interesting thing about durable execution is all of these are natively polyglot. So I can call a function written in Ruby, uh, from a code written in Go with basically just providing it the function name and the input parameters because, here's the dirty secret, it's still events under the hood. [laughs]
- 12:49
But what did we... Why, why is this a thing? We've abstracted the complexities away from the platform layer. Software engineering as a, as a vocation, as a history, if you look back over the fifty years, fifty, sixty, seventy years software engineering has existed, we go back to, uh, you know, 1950s.
- 13:03
We have made most of our advancements in programming languages, um, as we have abstracted away the complexities away from the programmer and into the, into, like, into the programming language.
- 13:13
None of us are sitting here writing assembly code anymore, thankfully. I mean, some of you might be, and good on you. I'm not. Um, FORTRAN gave us mathematical operations.
- 13:21
We don't have to write assembly language anymore and store things manually in registers. Algo, uh, 60 and Pascal gave us if-then-else structure and structured flow concepts. We're not writing go-tos and jumps in our code anymore.
- 13:31
Lisp gives us memory management and garbage collection. Simula and Smalltalk gave us object-oriented programming, and this just continues on and on. We've continually abstracted away complexity. Durable execution is the next, is the next foray into this.
- 13:43
We are abstracting away events and the complexity of events into the software layer and removing that from ha- from anyone having to worry about it. So you no longer have to worry about your queues or any of that stuff.
- 13:54
And I leave you with a meme. So
- 13:58
all AI is just distributed systems under the hood. [laughs] If you're, if you are calling out to, uh, if you are calling out across the network, you're a distributed system, and you basically need to, to, to handle that.
- 14:08
If you want to come and learn more, um, Temporal is in the hallway, or in the booth. Uh, sorry, in the expo hall. I will be there for literally as soon as this talk is over, so you're welcome to come by.
- 14:18
We have an a, uh, an, a durable agent running demo. Come by, try to break my demo. Try, try... Turn off my computer. Turn off my laptop. I guarantee you it'll still keep running when it's done, when it's done.
- 14:27
I'll show you how all of this works. You can also ch-chat with me in Slack. Uh, we have a community Slack channel, and we have a newsletter if you're interested.
- 14:33
Uh, thank you very much. [outro music]