---
title: Coordinator-Manager-Follower Architecture
url: https://www.emergentmind.com/topics/coordinator-manager-follower-architecture
type: topic
---

# Coordinator-Manager-Follower Architecture

Coordinator-Manager-Follower architecture denotes a family of hierarchical, modular, and often decentralized organizational patterns in which one component interprets goals or system-level state, one or more managing components allocate authority or resources, and follower components execute assigned actions or adapt local behavior. Across the literature, this pattern appears in software coordination middleware, conversational robots, hybrid human-AI teams, LLM-based multi-agent systems, multi-UAV control, and leader-follower satellite clusters. A common design premise is that coordination can be separated from domain functionality or agent logic, whether through activated modules in DECOMAS [1006.1450], peer or hierarchical decision modules in conversational robotics [2303.08470], external delegation policies in hybrid teams [2402.05605], LLM coordinators and supervisors [2512.04695], [2510.01869], or an explicit coordination layer independent of information access and agent implementation [2605.03310].

## 1. Architectural definition and separation of concerns

A central characteristic of the architecture is the separation of concerns between primary task execution and coordination. In DECOMAS, **agent functioning** denotes the primary, domain-related behavior of an agent, while **inter-agent coordination** is encapsulated in dedicated modules attached to the agents but external to their core logic; the architecture is explicitly presented as a two-layered structure with an **Application Layer** containing functional agents and a **Coordination Layer** containing the coordination processes and Endpoints [1006.1450]. The same separation is restated in a more general form by the coordination-layer formulation for LLM-based multi-agent systems, which decomposes systems into an **Information Layer**, a **Coordination Layer** \(C\), and an **Agent Layer**, with the coordination layer defined independently of agent internals and information exposure [2605.03310].

In this formulation, the coordination layer is specified by seven elements: **agent endpoints**, **communication topology** \(G=(V,E)\), **authority distribution**, **synchronization regime**, **aggregation rules**, **termination conditions**, and **failure handling**. This makes coordination a configurable architectural object rather than merely an implementation convenience [2605.03310]. In DECOMAS, the analogous mechanism is the activation of agent modules, whereby modules are converted to software elements that reason about and modify their host agent; the design goal is **minimal-invasive augmentation** of the activities that affect coordination [1006.1450].

A related distinction appears in conversational robotics. There, the comparison between **modular** and **end-to-end** architectures is not phrased in Coordinator-Manager-Follower terminology, but it addresses the same organizational problem: where to place decision authority, how to specify interfaces, and how to interleave multiple control processes. The paper argues that modular architectures remain preferable when developing conversational robots designed to execute complex tasks in collaboration with human users, because explicit decision modules support transparency, designer control, and integration with robotics software ecosystems [2303.08470]. This suggests that Coordinator-Manager-Follower architecture is best understood not as a single fixed blueprint, but as a recurrent architectural strategy for externalizing coordination, delegation, and synchronization.

## 2. Roles, authority distribution, and interaction patterns

The three role labels are instantiated differently across domains, but their functional structure is consistent. In DECOMAS, the **Coordinator** role is realized by agents or Coordination Endpoints charged with synthesizing or disseminating global coordination information, the **Manager** role by agents or Endpoints responsible for managing local resources or configurations, and the **Follower** role by agents or Endpoints that adapt their behavior in response to coordination signals. Importantly, these roles are **dynamically determined by module configuration and agent function, not fixed in code**; an agent can implement multiple roles or switch between them depending on process logic [1006.1450].

In hybrid human-AI teams, the architecture is more restrictive. At any time, only one team member, the **control agent**, is authorized to act as control for the team. The **AI manager** is an external RL-based agent that observes the team and decides which agent becomes the next control agent, and it acts only when a **constraint violation** or terminal condition triggers intervention [2402.05605]. Here, the coordinator and manager functions collapse into a single outside observer, while the follower role is instantiated by whichever agent has delegated authority at the current intervention point.

Conversational robotics presents a non-hierarchical variant. Rather than enforcing a strict coordinator-manager-follower chain, it distinguishes an **action manager** and an **interaction manager** and argues that placing them **on an equal footing** may provide the best path forward. This balanced or multi-manager organization rejects a single command center in favor of coordination through **shared memory** and resource management [2303.08470]. A plausible implication is that Coordinator-Manager-Follower architecture includes both strict hierarchies and side-by-side manager structures, provided that authority allocation and coordination channels are explicit.

The diversity of realizations can be summarized as follows:

| Setting | Coordinator / manager realization | Follower / worker realization |
|---|---|---|
| DECOMAS | Coordination Endpoints, Service Brokers, Server Managers | Service Endpoint agents adapting to coordination signals |
| Hybrid human-AI teams | AI manager selecting the control agent | Human or autonomous driving agent currently in control |
| Conversational robots | Action manager and interaction manager on an equal footing | Execution modules and effectors subordinate to local decisions |
| Trinity | Lightweight coordinator assigning Thinker, Worker, Verifier roles | Selected LLMs executing assigned roles |
| TACOS | Coordinator and Supervisor | UAVs executing API commands |
| Leader-follower satellites | Leader satellite with control and scheduling capabilities | Simpler follower satellites augmenting coverage and throughput |

The role structure is therefore functional rather than taxonomic. Some systems have a distinct coordinator above managers; some merge coordinator and manager; some replace the follower concept with workers, specialists, or control agents; and some distribute managerial responsibility across multiple first-class modules.

## 3. Formal models and execution semantics

The architecture has been formalized at several levels of abstraction. In DECOMAS, the agent configuration is written as
\[
\langle ag, C, M, T, s \rangle,
\]
where \(ag\) is the agent program, \(C=\langle I,E,A\rangle\) is the circumstance, \(M\) is communication data, \(T\) is temporary information, and \(s\) is the reasoning cycle step. Coordination logic is integrated by introducing a mapping \(m:S\rightarrow D\), from observed trigger events to target actuation events, so that an activated module can inject coordination events during the event-selection phase without entangling the coordination logic in the core code [1006.1450]. The extended event-selection rule is given as
\[
\text{SelEvCEC} \quad \frac{S_E(C_E) = \langle te, i \rangle, \quad te \in S}{\langle ag, C, M, T, SelEv \rangle \longrightarrow \langle ag, C', M, T', RelPl \rangle},
\]
with the injected event present only when the guard \(eval(te,m(te))=true\) [1006.1450].

In collaborative human-AI hybrid teams, the manager’s decision problem is modeled as an **Intervening MDP (IMDP)**
\[
M_I = \langle S = S_R \cup S_Q, A_M, R_M, T_M, D, \beta, \gamma \rangle,
\]
where \(S_R\) are intervention states, \(S_Q\) are operation states, \(A_M\) is the action space of team-agent choices, \(R_M\) is the manager reward, \(T_M\) is determined by the delegated agent’s policy, \(D\) is the agent set, \(\beta\) is the intervention cue function, and \(\gamma\) is the discount factor [2402.05605]. The intervention cue is
\[
\beta(s)=
\begin{cases}
1, & \text{if $s$ violates manager constraints or is terminal state} \\
0, & \text{otherwise}.
\end{cases}
\]
This formalization makes the manager passive during normal operation and active only at intervention states [2402.05605].

The workflow-orchestration vision paper formulates manager-centric coordination as a **Partially Observable Stochastic Game (POSG)**
\[
\langle I, S, b^0, \{A_i\}, \{O_i\}, P, \{R_i\} \rangle,
\]
with \(I=\{M\}\cup W\) for the Manager Agent \(M\) and worker set \(W\), and state \(s=\langle G,W,C,X,U\rangle\) including the workflow task graph, worker registry, communications history, artifacts, and stakeholder preferences [2510.02557]. This makes explicit that coordination is not merely delegation but also graph modification, monitoring, and stakeholder communication under partial observability.

Trinity formalizes the coordinator as a policy over agent-role actions. Its coordinator head implements
\[
f_\theta:\mathcal{H}\rightarrow \mathbb{R}^{|\mathcal{A}|}, \qquad
\pi_\theta(a|s) \propto \exp\big(f_\theta(h(s))_a\big),
\]
with optimization objective
\[
J(\theta) := \mathbb{E}_{\tau \sim \pi_\theta}[R(\tau)].
\]
The policy assigns one of three roles—**Thinker**, **Worker**, or **Verifier**—to a selected LLM at each turn, using the penultimate-token hidden state for contextualization [2512.04695]. This is a direct formalization of multi-turn delegation in a coordinator-managed follower pool.

## 4. Domain-specific realizations

In distributed software systems, DECOMAS realizes the architecture through **Coordination Endpoints** attached to agents, each containing a **Communication Module**, **Agent State Interpreter**, and **Coordination Information Interpreter**. These modules observe agent state, publish and perceive coordination events or data, and determine local actions or modifications inside the agent. The architecture is exemplified with decentralized management of web service infrastructures involving **Service Brokers**, **Server Manager agents**, and **Service Endpoint agents**, using publish/subscribe communication to manage server utilization and service demand balancing [1006.1450].

In conversational robots, the same architectural problem is recast as the organization of decision modules responsible for physical and conversational action. The **action manager** is responsible for task execution, motion planning, and low-level control, while the **interaction manager** handles dialogue state tracking, policy selection, and communicative action. The paper distinguishes **robot-centric**, **dialogue-centric**, and **balanced / multi-manager** architectures; the balanced design lets the two managers operate as **first-class citizens** through shared memory and common resources, enabling flexible interleaving and synchronization of linguistic and non-linguistic actions [2303.08470].

In TACOS, the pattern is explicitly hierarchical. The **Coordinator (LLM 1)** receives the user’s natural language instruction \(\mathcal{I}\), current swarm state \(\mathcal{S}_d\), world state \(\mathcal{S}_{\mathcal{W}}\), and available drone action set \(\mathcal{A}\), and outputs **Reasoning** \(\mathcal{R}\) and a **Task plan** \(\mathcal{P}\). The **Supervisor (LLM 2)** then sequences low-level actions in closed loop, using bounded task-specific command history and current feedback from the swarm, while the UAVs execute platform-agnostic primitives such as
\[
\mathcal{A}=\{\text{arm\_takeoff}(),\ \text{goto}(x,y,z),\ \text{land}()\}.
\]
The swarm state is written as
\[
\mathcal{S}_d=\{\mathbf{p}_i,\mathbf{v}_i\}_{i=1}^N
\]
for positions and velocities of UAVs [2510.01869].

In LLM-based orchestration, Trinity introduces a lightweight coordinator comprising a compact language model of approximately \(0.6\)B parameters and a lightweight head of approximately \(10\)K parameters, with **under 20K** total learnable parameters. It processes a transcript over multiple turns, selects an agent-role pair, constructs a role-specific prompt, appends the output to the transcript, and terminates if a Verifier signals `ACCEPT` or if the maximum turn budget is reached [2512.04695].

In LEO satellite networks, the role split is physical rather than software-modular. Each cluster contains one **leader** satellite with full processing and control capabilities and multiple simpler **follower** satellites uniformly distributed within a spherical cap centered at the leader. The leader handles routing, scheduling, and resource allocation, while followers augment coverage and throughput through leader–follower–user relaying [2604.01265]. This is a Coordinator-Manager-Follower analogue in which coordination is embedded in cluster geometry and communication scheduling.

## 5. Empirical behavior, performance, and trade-offs

Empirical studies show that Coordinator-Manager-Follower variants can improve task performance, but they also introduce distinctive failure modes. In collaborative human-AI hybrid teams, the RL-based manager improved team performance in a simulated driving scenario with interfering vehicles. Reported results indicate that the learned manager at least matched the best solo agent’s task completion rates, and in some mixed-error settings yielded **up to ~187%** of the best solo agent performance while minimizing unnecessary interventions through reward penalties on velocity, proximity, and collision events [2402.05605].

In Trinity, the lightweight coordinator consistently outperformed individual models and existing methods across coding, math, reasoning, and domain knowledge tasks and achieved a score of **86.2% on LiveCodeBench**. The paper attributes performance to two factors: the coordinator’s hidden-state representations provide rich contextualization of inputs, and under high dimensionality and strict budget constraints, **sep-CMA-ES** offers advantages over reinforcement learning, imitation learning, and random search by exploiting potential **block-\(\epsilon\)-separability** [2512.04695].

TACOS reports that the full architecture outperforms ablated versions in complex tasks. In simulation, **Task 2** is reported at **>95% success, fewer steps**, while removing the Coordinator or reasoning reduces temporal correctness or interpretability; the summary states that the **Manager (Supervisor) cannot infer sequencing correctly without Coordinator's reasoning** [2510.01869]. In the real-world “Find the Dog” mission, the Coordinator infers that parks are more likely locations, the Supervisor dispatches drones and updates commands based on feedback, and the mission is completed with **minimal pilot commands** [2510.01869].

The coordination-layer study provides a broader architectural evaluation. It reports that multi-agent LLM systems fail in production at rates between **41% and 87%**, mostly due to coordination defects rather than base-model capability, and evaluates five reference configurations under fixed information and fixed agent layers: **Independent Ensemble**, **Peer-Critique Debate**, **Orchestrator-Specialist**, **Sequential Pipeline**, and **Consensus Alignment** [2605.03310]. On **100 Polymarket binary markets** resolved after the model’s training cutoff, only **independent ensemble** and **sequential pipeline** lie on the cost-quality Pareto frontier within that regime, while the **orchestrator-specialist** configuration is dominated. The study uses the Murphy decomposition
\[
B = UNC + REL - RES
\]
to show that different coordination configurations leave distinguishable **Murphy signatures** even when aggregate Brier scores coincide [2605.03310].

Manager-centric workflow orchestration also remains difficult. In MA-Gym, GPT-5-based Manager Agents evaluated across **20 workflows** struggle to jointly optimize goal completion, constraint adherence, and workflow runtime. The reported summary gives **CoT** goal completion at **~0.31**, **Random** at **~0.14**, and **Assign-All** at **~0.5**, with trade-offs between compliance, runtime, and delegation overhead. GPT-5 is described as using a richer action set than GPT-4.1, with **14x more decompositions** and **26x more dependency links**, but neither model reliably achieves robust preference adherence, constraint satisfaction, or stakeholder engagement [2510.02557].

In the leader-follower satellite setting, numerical results demonstrate performance advantages of clustered coordination over a single leader satellite. The summary reports that outage probability can be reduced by **more than 10×** with **10 followers per leader**, and that clusters with **20 followers** achieve **more than 5×** the average data rate of a single leader satellite, although the paper also emphasizes deployment trade-offs involving cluster radius, power allocation, and the diminishing returns of larger follower sets [2604.01265].

## 6. Limitations, misconceptions, and research directions

A common misconception is that Coordinator-Manager-Follower architecture necessarily implies a single centralized command center. The literature does not support that simplification. DECOMAS emphasizes **decentralized coordination** through localized interactions and activated modules [1006.1450]; conversational robotics argues for **balanced / multi-manager** structures with no strict hierarchy between action and interaction management [2303.08470]; and the coordination-layer framework treats authority distribution, communication topology, and synchronization regime as independently variable architectural dimensions rather than fixed hierarchical constants [2605.03310].

Another misconception is that better coordination can be reduced to more information or larger base models. The information-controlled design explicitly holds the agent layer and information layer fixed while varying only coordination, precisely to avoid conflating coordination improvements with increased information access [2605.03310]. Trinity similarly frames the coordinator as lightweight and offloads complex skill acquisition to delegated LLMs rather than expanding the coordinator itself [2512.04695]. This suggests that architectural organization can be an independent source of both performance gains and failure signatures.

The limitations are equally consistent across domains. In hybrid teams, performance depends on well-designed **constraints**; the method is limited to **one active controller at a time**, and extending it to concurrent control would require architectural adaptations [2402.05605]. In workflow orchestration, four foundational challenges are identified: **compositional reasoning for hierarchical decomposition**, **multi-objective optimization under shifting preferences**, **coordination and planning in ad hoc teams**, and **governance and compliance by design** [2510.02557]. In LLM multi-agent systems, forced agreement and centralized orchestration can suppress diversity, induce **minority-collapse**, or propagate **false confidence** through sequential dependencies [2605.03310]. In satellite clusters, larger follower sets introduce cost, collision, and interference risks, and the best deployment depends on a balance among **cluster cap angle**, **number of followers**, and **power allocation** [2604.01265].

The current research trajectory therefore treats coordination not as a secondary implementation detail but as a first-class architectural variable. The released artifacts associated with this line of work—**MA-Gym** for multi-agent workflow orchestration and the coordination-layer experiment harness, trace dataset, and production agents—indicate a shift toward controlled comparison of coordination patterns under fixed agent and information conditions [2510.02557], [2605.03310]. A plausible implication is that future Coordinator-Manager-Follower systems will be evaluated less by generic “agentic” rhetoric and more by explicit mappings from authority structure, communication regime, and aggregation policy to measurable performance, cost, and failure-mode signatures.

Source: https://www.emergentmind.com/topics/coordinator-manager-follower-architecture