Event-Driven Agent Architecture

The broker is the backbone of this architecture. Think of it as a database designed specifically for time-ordered messages. Producers write events to named topics. Consumers read from those topics at their own pace, independently, without needing to coordinate with each other or with the producers. The key property is durability. If an agent crashes while processing an event, the event is not lost. The agent restarts, picks up from where it left off, and processes the event again. The broker guarantees delivery — events do not disappear because a consumer was temporarily offline.

Not every event is ready to act on the moment it arrives. An agent responding to a fraud signal might need to know that three suspicious events from the same user happened within a five-minute window — a single event does not tell that story. A stream processor sits between the raw event log and the agents, transforming, joining, and aggregating events before forwarding them downstream. Think of it as the layer that does the heavy lifting of pattern detection and data assembly, so that downstream agents receive clean, enriched, actionable signals rather than raw event firehose data.

The agents in this pattern are designed around a single principle: do nothing until specifically asked to act. Each agent has a declared trigger — the exact type of event that should wake it. Everything else in the topic flows past without consuming resources. When its event arrives, the agent wakes up, runs its logic, and acknowledges that it has processed the event by writing a commit back to the broker. This commit is like a bookmark — "I have processed up to this point, so next time start from the next event." If the agent crashes before committing, it restarts from the last committed position, not from zero, which is what makes reliable processing possible.