AI agents are distributed systems, so they inherit the operational problems of distributed software rather than creating an entirely new class of problems.
2
Event-driven architecture can keep services running independently, but it scatters business logic, weakens design-time coupling, and makes failures difficult to understand.
3
Durable execution stores execution state, resumes work after crashes, and lets developers write agent logic without directly managing queues, retries, or event coordination.
Summary
Mason Egger argues that AI agents should be treated as distributed systems. Their network calls to language models, tools, data stores, and other agents create the same reliability problems found in microservice architectures. Event-driven architecture can connect these components, but Egger says it puts events at the center instead of the application's business logic. That choice produces scattered code, undocumented contracts, race conditions, local state, and difficult debugging. He proposes durable execution as the better abstraction. A durable execution system automatically saves variables, function calls, inputs, outputs, and return values. It can then resume execution on another process or machine after a crash, retry failed calls, and run for long periods. Temporal provides this model through SDKs for several programming languages. Egger's argument is about hiding event and queue management inside the platform so developers can focus on what the agent should do.
Egger frames AI agents as distributed systems because they call services over a network and must remain available and scalable. He says this means teams are solving problems that have existed for about 20 years, even though the software now carries an AI label. Event-driven architecture is a familiar pattern for handling these systems. In the example he shows, cron jobs clean up inactive chat sessions, a message bus distributes events to tools and language models, and a dead-letter queue handles tasks that cannot be reprocessed. The diagram works, Egger says, but much of it exists to prevent failures rather than express the application's business logic.
Putting events at the center scatters the application
Egger says event-driven designs often contain more machinery for handling events than code for the application's actual behavior. Business logic spreads across services, so debugging requires searching for an event name and finding who produced or consumed it. Developers may have to run the system to discover how it failed. Each service becomes an ad hoc state machine, with local databases and caches compensating for the lack of shared execution state. Without a transaction between receiving a message and updating state, a system can reach an ambiguous intermediate condition. Egger connects this structure to race conditions and painful overnight incidents.
Event systems are loosely coupled at runtime, not at design time
Egger challenges the usual claim that event-driven architecture is loosely coupled. He accepts that services are loosely coupled at runtime because one can go down while others continue running. He says that does not make them loosely coupled at design time. His analogy compares events with turning local variables into global variables: any service can read them, but changing their format can break an unknown downstream consumer. This uncertainty makes teams afraid to change their architecture. An event can look like an independent contract while silently connecting services that its producer may not know exist.
Egger defines durable execution as crash-proof execution. In an ordinary application, a crash loses variables and forces developers to rebuild state with caches or databases. A durable execution system saves local variables, function calls, inputs, outputs, and return values automatically. When a process or machine fails, the system reconstructs the saved state and resumes from the last known save point. Execution can move across processes and machines. Egger says this also removes the usual time limit on a task: code can sleep for 30 days, survive a crash, and continue when its timer is ready.
Egger says durable execution does not depend on special fault-tolerant hardware. It can run on ordinary hardware and places reliability in the software layer. He gives Temporal's Raspberry Pi deployment in outer space as an example of where the system can run. In his durable agent diagram, a workflow surrounds the chat interface and calls to language models and tools. Failed calls can retry automatically, including rate-limit failures. If the workflow crashes during a call, the saved state is reconstructed and execution continues. Longer-lived state can also be stored at a chosen time or when the execution closes.
The platform should hide event complexity from application code
Egger explains that durable execution does not eliminate events underneath the system. Temporal still uses them, but the platform hides their coordination and failure handling from application developers. He compares this with earlier programming abstractions. Higher-level languages removed the need to write assembly instructions, manual register operations, jumps, and explicit memory management for ordinary application code. Durable execution applies the same idea to distributed execution. Developers can focus on the application's behavior instead of directly managing queues, retries, event formats, and recovery paths.
"It's still events under the hood. But we've abstracted the complexities away from the platform layer."12:49
Who should watch
You are building an AI agent that calls tools or language models across a network and need a way to reason about retries and crashes.
Your event-driven system has scattered logic, undocumented event contracts, race conditions, or failures that require tracing several services.
You want to compare direct event and queue management with a workflow model that can save state and resume execution.
