> ## Documentation Index
> Fetch the complete documentation index at: https://agentconcepts.io/llms.txt
> Use this file to discover all available pages before exploring further.
# mediator
> A central hub that coordinates interactions among a set of peers; peers communicate through the mediator rather than directly, reducing the N²-edge tangle to N spokes.
computer-science engineering-and-technology journalism-media-studies-and-communication transportation
# Mediator
## Description
A mediator is a central hub that coordinates interactions among a set of components that would otherwise need to know about each other directly. By interposing itself, the mediator reduces the N²-edge problem (every peer knows every other peer) to N spokes (every peer knows only the mediator). The peers become loosely coupled; the mediator absorbs the coordination logic that would otherwise be smeared across the peers' interaction edges.
The structural commitment is *centralization*. The mediator is a single point of coordination — and, by construction, a single point of failure, contention, and policy. That centralization buys clean decoupling of peers, easier evolution of coordination logic (change one node, not N), and a clear place to enforce cross-cutting rules. It costs scalability beyond the mediator's capacity, complexity at the mediator (which can become a "god node"), and a hub failure that takes down all interactions.
The dual to mediator is multi-hop-routing: distribute the coordination across the peers; each peer knows only its neighbor. Mediator and multi-hop-routing are the two endpoints of a spectrum about how to organize coordination — central authority vs. distributed knowledge.
## Triggers
**User-initiated:** User describes wanting to introduce a "hub" or "coordinator" or "central place" for components that currently know about each other in a tangled web. Vocabulary cues: "hub," "central," "coordinator," "broker," "bus," "switchboard," "router," "orchestrator."
**Agent-initiated:** Agent notices N components with N² edges of direct knowledge of each other, and that coordination logic is being implemented redundantly at multiple endpoints. Candidate inference: "introduce a mediator; peers communicate only through it; consolidate the coordination logic."
**Situation-shape signals:** N²-tangle of mutual references. Cross-cutting coordination rules (ordering, conflict resolution, fan-out) implemented inconsistently across peers. A "god class" forming organically because everyone needs to talk through it — that organic god class is a mediator that wants to be named and designed properly.
## Exclusions
* **Two peers only** — mediator's value comes from reducing N² to N; for N=2 the indirection is overhead with no payoff.
* **Hub becomes a god class** — when the mediator's responsibilities expand uncontrollably (every cross-cutting concern accretes there), the mediator becomes the system's single biggest source of complexity. Either rein the mediator's scope or replace with a distributed coordination scheme.
* **Latency budgets can't afford the hop** — every peer-to-peer communication now requires a round-trip through the mediator; in latency-sensitive contexts (high-frequency trading, real-time control), the hop cost can be prohibitive.
* **Mediator is a single point of failure with no redundancy plan** — centralization without HA / redundancy means every outage is total.
* **Coordination logic is genuinely local** — if "coordination" really only happens between peer A and peer B, with no broader policy, putting it in a mediator just adds indirection without consolidation.
## Structure
## Relationships
* [bottleneck-buffer](/concepts/bottleneck-buffer) — mediators are bottlenecks; every coordination is a bottleneck-buffer pair (the mediator + its queues). Designing for mediator scaling means designing the bottleneck-buffer pair deliberately.
* [observer](/concepts/observer) — many practical "mediator + observer" systems are message buses: the bus is the mediator, observers subscribe to the bus. The two primitives compose into the modern event-bus architecture.
* [multi-channel-ingest](/concepts/multi-channel-ingest) — mediators often sit at the converging point of multi-channel-ingest; each channel is a peer, the mediator is where they meet.
* [active-gate-vs-passive-audit](/concepts/active-gate-vs-passive-audit) — mediators are natural sites for active gates; centralized coordination means centralized enforcement of validation, authorization, and policy.
* [load-bearing](/concepts/load-bearing) — the mediator becomes the most load-bearing piece in any system that uses it; auditing the mediator is the highest-leverage audit in such a system.
## Examples
controllers coordinate aircraft; pilots communicate with ATC, not directly with each other.
the mediator-of-conversation; participants speak through the mediator's turn-taking rules.
The Gang of Four cataloged Mediator as a behavioral pattern: define an object that encapsulates how a set of objects interact, so the participants don't refer to each other directly. Their canonical worked example was a dialog box mediating among its widgets — the buttons, text fields, and lists do not call each other directly; they all route through the dialog object, which knows the policy linking field-validity to button-enabledness. The pattern reduces the dense N×N web of peer-to-peer references that otherwise accumulates as a system grows, replacing it with N references into a single coordinator. The peers become reusable because they no longer carry knowledge of each other's identities — they only know how to talk to the mediator.
The naming choice is itself instructive. The authors imported a word with a long-established meaning in legal and diplomatic contexts — a third party who facilitates communication between disputing peers — and used the prior connotation to do work the formal definition could not. The everyday English meaning already carried the right relational shape: a third party, asymmetric routing through that party, peers who otherwise would not negotiate directly. The technical definition inherited the structure pre-loaded.
**Inference**: The diagnostic is the shape of the dependency graph — if you find yourself adding "object A also needs a reference to object D" wiring on every new peer, the system is gravitating toward a Mediator whether or not anyone has named one. Naming the coordinator explicitly is usually cheaper than continuing to grow the implicit one. More broadly, importing a word whose everyday connotation already carries the right relational shape is cheaper than coining a neologism and explaining it — part of why the GoF catalog's naming choices stuck across a generation of practitioners.
central platform mediates between would-be partners; participants don't see each other until the platform pairs them.
Hohpe and Woolf's *Enterprise Integration Patterns* (2003) generalizes the Mediator pattern from in-process object coordination to inter-process and inter-service messaging. A message bus or event bus is a Mediator at the system boundary: publishers and subscribers don't address each other directly; they route through the bus, which decouples them in identity, in time, and often in protocol.
**Inference**: The Mediator pattern's range is wider than the GoF presentation suggested. The same structural move — replace peer-to-peer wiring with routing through a coordinator — recurs at every system scale, from within a single object graph (GoF Mediator) to between services in a distributed architecture (message bus). The diagnostic question (is the dependency graph densifying?) and the move (introduce a coordinator) are scale-invariant.
UI components dispatch actions to the store (mediator); the store updates state; subscribers receive updates. The store IS the mediator.
central system mediates between supply (hotel rooms, restaurant tables) and demand (guests).
cross-domain reach into telephony / coordination / governance establishes mediator as an organizational primitive that long predates software
central orchestrator mediates among workers.