The Problem with Message-Passing Agents
The standard playbook for multi-agent architecture is well rehearsed in engineering blog posts: give each agent its own context, memory, and decision loop, then wire them together with a message bus and let them pass structured payloads back and forth. The pattern is sound for many distributed systems and scales beautifully when the problem decomposes cleanly into independent workers. It is also completely wrong for an intelligence system, and we learned that the only way it can be learned, which is by shipping the wrong thing first.
The trouble is that any message Agent A hands to Agent B is by definition a snapshot of the world at the moment the message was composed. By the time Agent B picks it up the world has already moved on: a deal has advanced or stalled, a support ticket has escalated, the tone of a customer's last reply has shifted in a direction nobody on either side has noticed yet. Agent B is making a decision on data that is already a few seconds stale, and a few seconds is plenty of time for the decision to be wrong.
We built the message-passing version first and it lasted about two weeks. The latency between signal and response made the intelligence useless in the cases where it mattered most, the cases where speed was the entire point. A support ticket that should have triggered urgency on an active deal arrived in the sales-side agent four minutes later, by which point the rep had already sent the tone-deaf follow-up the urgency was meant to prevent. The architecture was technically correct and practically broken, and we threw it away.
Shared State Is the Hard Problem
The alternative is shared state, with every agent reading from and writing to one intelligence layer. When one agent processes a signal, every other agent already sees the consequence without anyone serialising a message or waiting on a queue, because the consequence is the state, not a notification about it.
This sounds simple until you try to build it. The engineering challenges are substantial. How do you handle concurrent writes from every department without race conditions corrupting the intelligence? How do you propagate a signal from customer support to sales pipeline health without creating circular dependencies? How do you maintain sub-second response times when the intelligence layer is processing thousands of entity updates per minute?
- Signal propagation must be real-time, not eventually consistent. A support escalation that takes thirty seconds to affect deal health is thirty seconds too slow.
- Every agent must see the full organisational picture, not just its own domain. Sales intelligence that ignores product usage data is half-blind.
- Cross-agent effects need deterministic ordering. If a contract renewal and a support ticket arrive simultaneously for the same account, the system must resolve them in a predictable sequence.
- The shared layer must be tenant-isolated at every boundary. One organisation's intelligence must never bleed into another's, even under concurrent load.
Traditional microservice patterns actively work against you here. Service boundaries create information boundaries. The whole point of organisation-wide intelligence is that information boundaries don't exist inside the organisation. You need isolation between tenants and transparency within them. Most distributed systems frameworks give you the opposite.
“We spent more time on the signal propagation architecture than on any individual component. The components are smart, but the layer that connects them is what makes the system intelligent. That's the distinction most multi-agent platforms miss.”
Why This Matters for the Product
The practical result is what we call organisational omnipotence. RIBA, RevSprint's Intuitive Business Assistant, doesn't just know about sales or support or product. It knows about all of them simultaneously, in real time. A support ticket filed at 9:01 affects the deal health score visible to the sales team at 9:01, not 9:15 when a batch job catches up.
This is the difference between a Symbiotic Intelligent Operating System and a collection of AI tools that happen to share a database. The intelligence compounds because the layer compounds. Every signal makes the whole system smarter, not just the part that received it.
For engineering teams evaluating multi-agent architectures: the hard problem isn't making agents smart. It's making them connected. If your system can't share real-time intelligence without message-passing latency, you've built a handful of smart individuals instead of one intelligent system.
We pick up the live-intelligence engineering layer in Engineering for Organisational Omnipotence, and McKinsey QuantumBlack's work on AI orchestration in the enterprise consistently finds that systems built for real-time, structurally shared intelligence outperform message-passing alternatives. To see one shared intelligence layer on your own stack, get early access.
