Hidden Distributed Monolith (Multi-Agent)

Problem

At runtime the agents are not decoupled at all. They share context — the same artifact or conversation state is rebroadcast to every agent that might need it — they run in synchronous chains where each waits on the previous, and a failure in one is not isolated from the rest. The result has the coupling costs of a monolith and none of the decoupling benefits the microservices framing promised: no agent can be deployed, scaled, or reasoned about in isolation, because in practice they are one tightly-coupled system wearing the appearance of many. Calling it multi-agent hides that it is a distributed monolith.

Solution

Judge the architecture by its runtime coupling, not its framing. Check whether each agent really has isolated state instead of a shared rebroadcast context, whether boundaries are asynchronous instead of synchronous chains, and whether one agent can fail, deploy, and scale independently of the others. Where the multi-agent split is supposed to buy decoupling, actually provide it — bound and scope what state crosses agent boundaries, make handoffs asynchronous, and isolate failures — so the benefits are real. Where decoupling is not provided, name the system a distributed monolith and design it as one, rather than paying the coordination cost of many agents for the reliability of one tightly-coupled process. The test is isolated state, asynchronous boundaries, and independent deployability, not the number of agents.

When to use

• Recognising this failure when a system described as decoupled agents is, at runtime, shared-state, synchronous, and not failure-isolated.
• Reviewing a multi-agent design that claims microservices benefits without isolated state or asynchronous boundaries.
• Diagnosing why one agent cannot be deployed, scaled, or fail independently of the rest.