XIV · Anti-PatternsAnti-pattern✕

Hidden Distributed Monolith (Multi-Agent)

also known as False-Decoupling Multi-Agent, Microservices-in-Name Agents

Anti-pattern: a multi-agent system is presented as decoupled, independently deployable agents, but at runtime they share context, run in synchronous chains, and have no failure isolation, so it behaves as a tightly-coupled distributed monolith.

Context

A system is built as multiple agents and described as a set of independent services — each agent its own component, deployable and scalable on its own, communicating over messages. The microservices framing promises the usual benefits: independent deployment, failure isolation, and loose coupling. The team reasons about the agents as if those benefits hold.

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.

Forces

  • The microservices framing is attractive and easy to claim, but the runtime coupling determines the real behaviour, not the diagram.
  • Shared context across agents is convenient for coherence yet recreates the shared mutable state that decoupling was meant to remove.
  • Synchronous chains are simple to build but make each agent block on the others, eliminating independent execution.
  • Genuine decoupling — isolated state, asynchronous boundaries, independent deployability — is real engineering the appearance of agents does not provide for free.

Example

A team ships a multi-agent pipeline of five agents, described in the design doc as independent microservices. In production they share one conversation state the orchestrator rebroadcasts to each agent in turn, every step waits on the one before, and when the third agent errors the whole run hangs. Trying to scale just the slow agent is impossible — it only runs inside the synchronous chain. It is one monolith in five costumes.

Diagram

Solution

Therefore:

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.

What this pattern forbids. A system must not be treated as decoupled merely because it is split into agents; without isolated state, asynchronous boundaries, and independent deployability the coupling is real, and the architecture cannot be reasoned about as independent services.

The patterns that counter or replace it —

  • complementsHidden State Coupling✕— Anti-pattern: agent workflows read or write undeclared shared state (caches, env vars, process globals) instead of explicit inputs and outputs.
  • complementsOrchestrator as Bottleneck✕— Anti-pattern: route all agent runs through a single-process orchestrator that becomes the system-wide concurrency ceiling.
  • complementsMulti-Agent on Sequential Workloads✕— Anti-pattern: split a fundamentally sequential workload across multiple agents, degrading accuracy by 39–70% with no parallelization benefit.
  • complementsCascading Agent Failures✕— Anti-pattern: build a multi-agent system where one agent's failure or hallucination propagates as input to peers, until the whole system has drifted.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

References

Provenance