Why I Rejected an Event Bus for My Solo Agent Fleet: State Is Truth, Events Are Rumors

Short summary

The author explains why they rejected an event-bus architecture in favor of a pull-based design for monitoring a solo agent fleet of CLIs, cron jobs, and third-party MCP servers. Push-based event buses require every producer to emit events, making uncontrolled third-party components silently invisible, while pull-based monitoring reads on-disk state and is self-healing. The core principle: state is truth, events are rumors — a monitor should report state, not drive it.

• •Event buses fail silently for third-party components that can't emit events
• •Pull-based monitoring reads on-disk state, converging on reality every cycle
• •Keeping monitoring separate from orchestration avoids duplicated debugging surface

Generated with AI, which can make mistakes.