Essay
Paper: Coordination Without Orchestration
A Causal Event Model for Accountable Multi-Agent AI Systems
Coordination Without Orchestration: Read the full paper (PDF).
A common coordination pattern
A very common pattern in multi-agent AI systems is to put an orchestrator in charge of the work. It delegates tasks, collects results, chooses the next agent, and decides when to retry or ask a person for help. This gives us one place to express how the team works.
It also makes the orchestrator’s logic the place we have to examine to understand that coordination. Does every possible result have somewhere to go? What happens when an agent fails? Can work continue while another task waits for a person’s answer? This need for an orchestrator to understand the entire system can lead to a lot of complexity, and code or a prompt that is a struggle for a developer to understand and maintain.
Self-coordination with events
Coordination Without Orchestration examines an alternative. Instead of one coordinator assigning work to each member of the agent team, we use an event-driven design. System participants — members — declare which event types the handle and which they can produce. Events announce what has happened, and members subscribe to and react to those events. After a member finishes their work, they may have one or more events to emit. There is always a “I did a thing!” event. Usually, some other member needs to know when that thing happened. Sometimes, there isn’t a member that needs to react and the event expires to the event database. But the member emitting an event, and the member subscribed to that event, know nothing about each other. Who subscribed to an emitted event is something the emitter never knows.
That is the basis of coordination: we have events and member event-handlers and strict contracts about how events are structured. That structural contract is owned by the emitter and used by the subscriber. No orchestrator is needed to validate the events, route the events, or babysit the events on their way through the system.
Normally, when our code fails to work as expected — for any reason — we throw an exception and either handle it inline or let it bubble up to calling functions. In an evented system, that doesn’t work. We don’t bounce the event back for reconsideration. We don’t handle it inline unless the exception is caused strictly within our domain. And we never drop the event or stop handling it.
Most events originate in the real world, and we need to faithfully process those events so that our models accurately reflect their portion of the real world. If we drop or don’t process an event, we don’t have an accurate view of the world. If we drop an event that cascades into more and more dropped events, we can end up with a model that’s positively schizophrenic.
Instead, we create an exception event. Exceptions are events, and they go to handlers for resolution. The handler may be a product manager, developer, or data operator. Or, we can write a handler for exception events that happen frequently enought to warrant the effort.
Coordination without Orchestration
The paper calls these members agents: participants with declared event types they handle and event types they may produce. An agent can be an AI, ordinary software, or a person. The paper builds a formal coordination model from those declarations, keeping agent behavior separate from the rules governing their interactions. It shows how the resulting subscription graph can be checked for missing handlers, unreachable agents, inconsistent endpoints, and cycles with no route out, without needing to inspect an agent’s internal reasoning.
The paper then describes execution as a causal event tree, recording which event prompted each subsequent event. Revisions and retries create new branches or extend existing ones rather than overwriting earlier attempts. Failures participate in this same structure: an exception event can prompt diagnosis, recovery, or a request for human input. The question, answer, and renewed work remain linked. The paper also explains what must be retained to reconstruct this history, distinguishing reconstruction of recorded decisions from asking agents to make those decisions again.
Finally, the paper distinguishes tree correctness — whether work followed the declared coordination rules — from product correctness, defined relative to the quality gates applied to the work. Passing those gates does not prove that an artifact is correct, but retained results identify which check passed an artifact later found defective. The paper gives conditions for keeping automated work finite, including limits on repetition and branching, and describes EventedAI as a working prototype. Its formal results establish conditional properties of coordination; they do not establish that the agents produce better work or that the prototype satisfies every formal assumption.
Coordination Without Orchestration: Read the full paper (PDF).