Make your own event-sourced agent harness using stream processors — Jonas Templestein, Iterate
Jonas Huckestein introduces a novel, event-sourced architecture for building AI agents. The core abstraction consists of three parts: a state, a synchronous reducer that derives state from events, and an after-append hook for side effects. This design ensures debuggability and allows state to be rebuilt without re-running expensive operations like LLM calls. A key innovation is the ability to deploy an agent by simply appending a 'dynamic worker configured' event—containing JavaScript code for a processor—to an event stream, eliminating the need for servers or complex deployment pipelines. This enables a distributed and composable ecosystem where processors from different authors can collaborate on a single stream.
The conventional approach to building AI agent harnesses often obscures side effects, making debugging difficult. A more robust and transparent architecture can be achieved by adopting a pure event-sourcing model, where every action—from generating streaming LLM chunks to tool calls, errors, and even circuit breaker triggers—is recorded as an immutable event in a log.
### Core Architectural Principles
This model is built on a simple yet powerful abstraction composed of three key elements:
1. **State**: The current condition or memory of the agent.
2. **Synchronous Reducer**: A pure function that derives the current state by processing the log of events. It takes the previous state and a new event to compute the new state. Crucially, this reducer is synchronous and free of side effects.
3. **After-Append Hook**: A separate function where all side effects, such as making API calls to an LLM, are executed.
The separation between the reducer and the after-append hook is critical. When a system restarts or a new processor comes online, it can catch up by replaying the entire event log through the synchronous reducer to rebuild its state. This process is fast and efficient because it doesn't re-execute expensive, state-changing side effects like LLM requests. Only after the state is fully caught up does the system begin executing new side effects based on the current state.
### The Event Stream as the Central Primitive
The foundation of this architecture is the event stream, demonstrated with a service at `events.iterate.com`. Each agent is represented by a unique path (e.g., `/jonas/my-agent`), which holds its log of events. This stream is the single source of truth and the sole interface for interacting with the agent.
Key characteristics of the event stream include:
* **Simplicity**: Interaction can be as simple as sending `curl` requests to an HTTP endpoint.
* **Immutability**: New events are appended to the stream. Everything is an event, including errors. For instance, if an invalid event is posted, the system appends an `invalid.event.appended` event to the stream, preserving the history of what occurred.
* **Control via Events**: System control actions are also events. To pause a stream (e.g., to prevent an infinite loop), one appends a `stream.paused` event. To resume it, a `stream.resumed` event is appended. This circuit-breaker logic is itself a processor that monitors the event frequency.
### Dynamic, Serverless Deployment
A groundbreaking feature of this architecture is the concept of "dynamic worker configured" events. A developer can package a complete agent processor—including its reducer and after-append hook—into a JavaScript string and append it as the payload of a `dynamic.worker.configured` event.
Upon appending this event, the underlying platform instantly spins up a serverless worker that subscribes to the stream and begins processing events according to the provided logic. This turns any event stream into a fully functional AI agent without requiring the developer to manage servers, dependencies, or deployment pipelines.
### A Vision for a Distributed and Composable Ecosystem
This event-sourced approach enables a future where AI agents are distributed and composable by design.
* **Composability**: Processors from different authors, written in different languages and running on different servers, can all subscribe to and operate on the same event stream. One processor could handle LLM interactions, another could provide safety checks, and a third could add context from a knowledge base.
* **Distribution**: An agent is not a monolithic process. Its logic can be distributed across multiple, independent processors. For example, a primary agent running on one server can interact with a specialized plugin running on another, simply by appending and reacting to events in a shared stream.
* **Non-Blocking Extensibility**: This architecture allows for powerful, non-blocking integrations. A safety checker, for instance, could be given a 200ms window to inspect a pending LLM request. It can inject new context or security warnings by appending events to the stream. If the checker doesn't respond in time, the agent proceeds with the original request, ensuring performance is not degraded. This avoids the pitfalls of traditional "before" hooks, which can introduce latency and complexity.