Event-Driven Multi-Agent Architectures

Ever wonder why adding one agent to your team means editing five other agents? Or why a small change to how one agent works breaks three others downstream? That tight coupling is the default outcome of orchestrating agents with direct calls, and it's exactly what an event driven multi agent design fixes. Instead of agents calling each other by name, they publish events and react to events - so they don't need to know who else exists.

This guide builds one from scratch. By the end you'll have a decoupled agent team where adding capability means adding an agent, not rewiring the whole system. And you'll understand the specific tradeoffs, because event-driven isn't free - it trades directness for flexibility.

Quick-Start (Copy This Right Now)

Here's a minimal event bus and two agents that coordinate through it without ever referencing each other:

[object Object], collections ,[object Object], defaultdict

,[object Object], ,[object Object],:
    ,[object Object], ,[object Object],(,[object Object],):
        ,[object Object],._subscribers = defaultdict(,[object Object],)

    ,[object Object], ,[object Object],(,[object Object],):
        ,[object Object],._subscribers[event_type].append(handler)

    ,[object Object], ,[object Object],(,[object Object],):
        ,[object Object], handler ,[object Object], ,[object Object],(,[object Object],._subscribers[event_type]):
            handler(payload)   ,[object Object],

bus = EventBus()
bus.subscribe(,[object Object],, ,[object Object], p: extractor.handle(p))
bus.subscribe(,[object Object],, ,[object Object], p: analyzer.handle(p))
bus.publish(,[object Object],, {,[object Object],: ,[object Object],})

What this does: It sets up a bus where agents register interest in event types and react when those events fire. Publishing "document.received" triggers the extractor, whose own output publishes "data.extracted," which triggers the analyzer - a chain that runs with no agent naming another. The extractor doesn't know the analyzer exists.

Understanding the Variables

The pieces that matter in an event driven multi agent system are events, subscriptions, and the bus itself.

Events are the vocabulary of your system. Design them as facts that happened, past tense - "invoice.parsed," "risk.flagged," "report.drafted" - not as commands. This is the crucial mindset shift. A command ("parse this invoice") names who should act; a fact ("invoice arrived") just states reality and lets any interested agent decide to respond. Facts keep agents decoupled; commands recouple them.

Subscriptions define which agents care about which facts. An agent subscribes to the events that are its inputs and publishes the events that are its outputs. That's its entire contract with the world - it never needs to know the identities of upstream or downstream agents.

The bus routes events to subscribers. In-memory for a single process, or a real message broker for distributed systems. The bus is also where you add cross-cutting concerns: logging every event, enforcing rate limits, replaying event history for debugging.

⚡ Pro tip: Name events as past-tense facts, always. The moment you name an event as a command ("agent.should_parse"), you've smuggled coupling back in - now the publisher is implicitly deciding what happens next. Facts describe; commands direct. Keep your event names describing, and decoupling maintains itself.

Step-by-Step: Building an Event Driven Multi Agent System

Let's build a real one. A content pipeline where a document flows through extraction, analysis, and reporting - but decoupled, so we can add a translation agent later without touching anything.

Step one, define the event vocabulary as facts:

EVENTS = [
    ,[object Object],,   ,[object Object],
    ,[object Object],,   ,[object Object],
    ,[object Object],,    ,[object Object],
    ,[object Object],,        ,[object Object],
]

What this does: It declares the facts that flow through the system as a small, named vocabulary. Every agent's contract is expressed in these terms - what it listens for and what it announces - which keeps the whole system's interactions visible in one place.

Step two, write agents that consume one fact and produce another, never calling each other:

[object Object], ,[object Object],:
    ,[object Object], ,[object Object],(,[object Object],):
        bus.subscribe(,[object Object],, ,[object Object],.handle)
        ,[object Object],.bus = bus

    ,[object Object], ,[object Object],(,[object Object],):
        result = ,[object Object],.run_analysis(payload[,[object Object],])
        ,[object Object],.bus.publish(,[object Object],, {,[object Object],: store.put(result)})

What this does: The analyzer wakes on "content.extracted," does its work, and announces "content.analyzed." It has no reference to the reporter that will consume its output. To add a new consumer of analysis, you subscribe that consumer to "content.analyzed" - the analyzer never changes.

Step three, add a new agent without editing existing ones. Say you want translation after analysis. You write a translator that subscribes to "content.analyzed" and publishes "content.translated," and you point the reporter at whichever event it should now use. No existing agent's code changes. That's the payoff - the whole reason to accept the indirection of events.

Step four, and this is the one tutorials skip: decide what happens when a handler fails. In a direct-call system a failure propagates up the stack naturally. In an event driven multi agent system there's no stack - the publisher already moved on. So a handler that throws can vanish silently unless you catch it and turn the failure into its own event.

[object Object], ,[object Object],(,[object Object],):
    ,[object Object], handler ,[object Object], ,[object Object],(,[object Object],._subscribers[event_type]):
        ,[object Object],:
            handler(payload)
        ,[object Object], Exception ,[object Object], e:
            ,[object Object],
            ,[object Object],._publish_raw(,[object Object],,
                              {,[object Object],: event_type, ,[object Object],: ,[object Object],(e)})

What this does: It wraps each handler call so a failure doesn't disappear into the void. Instead the bus publishes a "handler.failed" event, which a monitoring agent can subscribe to. Failures become first-class facts in the system rather than exceptions swallowed by a decoupled publisher who's no longer listening.

This "failures are events" pattern is one of the genuine advantages of event-driven design that rarely gets mentioned. Because everything is already an event, errors fit the same model - you get a uniform way to observe, route, and react to failures, and you can build a single failure-handling agent that watches "handler.failed" across the whole system rather than scattering try/except through every agent.

Pro-Level Variations

For distributed teams, swap the in-memory bus for a real broker (this is where message queues and pub/sub systems come in) so agents can run on different machines and survive restarts. The event contract stays identical; only the transport changes - which is itself a benefit of the decoupling.

For systems that need to reason about sequences of events - "if risk.flagged happens twice within an hour, escalate" - add an event-pattern detector that subscribes to raw events and publishes higher-level ones. This is where event-driven architecture gets genuinely powerful: agents can react to patterns, not just individual facts. Modern agent protocols are moving this direction too - the 2026 MCP revision leaned into stateless, event-style interactions specifically so servers could scale on ordinary HTTP infrastructure without holding sessions open, which is the same decoupling instinct applied at the protocol layer.

⚡ Pro tip: Give every event a correlation ID that flows through the whole chain. In a decoupled system you lose the natural call stack, so the correlation ID is how you reconstruct "these twelve events all belong to processing document 42." Without it, event-driven debugging is genuinely painful; with it, you can trace any request end to end.

Troubleshooting Common Issues

If events fire but nothing happens, you likely have a subscription mismatch - an agent publishing "content.analysed" while another subscribes to "content.analyzed." Spelling and tense drift are the top cause of silent event-driven failures. Centralize event names as constants so a typo is a code error, not a runtime no-op.

If the same event triggers an agent twice - because you added a redelivery mechanism, or an agent double-subscribed - you'll get duplicated work and sometimes duplicated side effects. Make handlers idempotent by tracking which events they've already processed, keyed by the event's correlation ID. In a decoupled system you can't assume exactly-once delivery, so design handlers to tolerate seeing an event more than once. This is the same idempotency discipline queues demand, and it applies here for the same reason: the transport won't guarantee it for you, so the handler must.

There's also a subtler failure worth naming: the lost first subscriber. If an agent publishes an event before another agent has subscribed - a startup ordering race - the event fires into an empty room and is gone. Either buffer early events until subscribers register, or enforce that all subscriptions complete before the first publish. Startup races produce the maddening bug where the system works on the second run but not the first, and they're pure event-driven pathology.

If you can't tell what's happening, you're missing observability. Decoupling removes the call stack, so you must log every publish and every handler invocation. Build that in from the start, not after you're lost.

⚡ Pro tip: Build a "replay" mode that re-publishes a recorded sequence of events into a fresh system. Because agents only react to events, replaying the events reproduces the exact run - the closest thing to a debugger you'll get in a decoupled system. This single capability makes event-driven systems more debuggable than direct-call ones, flipping what looks like their biggest weakness into a strength.

⚠️ Common mistake: Making events into disguised commands by putting the intended handler in the payload ("event: work_ready, assigned_to: analyzer"). This recreates the coupling you built events to avoid - now the publisher decides who acts. Publish the fact and let subscribers self-select. If you find yourself wanting to name the handler, that's a signal your event is really a command and your design is drifting back toward tight coupling.

Your Turn

Take a tightly coupled agent pipeline you already have and convert one handoff to an event. Replace a direct call with a publish, subscribe the receiver, and confirm it still works. Then prove the payoff by adding a second subscriber to that same event without touching the publisher.

Keep your event vocabulary and agent-contract prompts versioned - the list of facts, and each agent's "you listen for X, you announce Y" instruction. I keep these in PromptABCD so a new agent inherits the same event discipline, because the habit of describing facts instead of issuing commands is the thing that keeps an event driven multi agent system decoupled, and it's worth reusing the exact framing that gets agents to respect it.

⚡ Pro tip: Start every new agent by writing its two-line contract first - the events it consumes and the events it produces - before writing any of its logic. If you can't state that contract crisply, the agent's role isn't clear enough yet, and adding it will muddy your event vocabulary. The contract is the design; the implementation is just filling it in.