Manager–Worker Pattern

The Manager–Worker pattern (also called supervisor-worker or hierarchical orchestration) is one of the simplest and most effective ways to coordinate multiple agents.

In this architecture:

• A Manager Agent acts as the central coordinator.
• Multiple Worker Agents are specialized for specific capabilities.
• Workers do not communicate directly with each other — all communication flows through the manager.

User Request
     ↓
 Manager Agent (Coordinator)
     ↓
 ┌─────────────┬─────────────┬─────────────┐
 │             │             │
Researcher    Coder         Analyst       Tester

The manager is responsible for:

• Task decomposition
• Worker selection and assignment
• Result integration and quality control
• Deciding when the task is complete

How the Manager–Worker Pattern Works

The typical execution flow is:

1. User submits a high-level goal.
2. Manager decomposes the goal into subtasks.
3. Manager assigns each subtask to the most suitable worker.
4. Worker executes the subtask (using tools via MCP, memory, and its specialized logic).
5. Worker returns results to the manager.
6. Manager evaluates results, updates shared state, and decides the next step.
7. Process repeats until the goal is achieved.

This creates a clear, centralized control flow while allowing parallel or sequential execution of subtasks.

Example: AI Chip Market Research System

Goal: “Produce a comprehensive report on the 2026 AI chip market, including key players, performance trends, and investment recommendations.”

Manager breakdown:

• Assigns Research Worker → gather latest papers, benchmarks, and news.
• Assigns Analysis Worker → extract trends, compare H100/MI300X/Blackwell, analyze market share.
• Assigns Writer Worker → synthesize findings into a polished report with citations.

The manager maintains shared context (using semantic + episodic memory) and can call workers multiple times if needed.

Key Components

Workers are usually lighter and more focused, while the manager is given stronger reasoning capabilities and access to the full conversation history.

Task Decomposition and Decision Making

The manager typically uses an LLM to:

• Break down complex goals
• Choose the right worker based on task requirements
• Evaluate returned results
• Decide whether to continue or terminate

Modern implementations often combine this with procedural memory (predefined decomposition templates) and reflection steps.

Example Implementation (Simplified)

from langgraph.graph import StateGraph, END

def manager_node(state):
    # Use LLM to decide next action or worker
    decision = llm.invoke(
        f"Goal: {state['goal']}\nCurrent state: {state}\n"
        f"Available workers: {list(workers.keys())}\nNext step?"
    )

    if "final_answer" in decision.lower():
        return {"final_output": state["accumulated_results"]}

    # Assign to worker
    worker_name = extract_worker(decision)
    result = workers[worker_name].execute(state)

    state["accumulated_results"].append(result)
    return state

# The graph runs the manager in a loop until termination condition

async fn manager_loop(
    goal: String,
    workers: HashMap<String, Box<dyn Worker>>,
    llm: LLMClient,
) -> String {
    let mut state = AgentState::new(goal);

    loop {
        let decision = llm.invoke(format!(
            "Goal: {}\nState: {:?}\nChoose next worker or finish.",
            state.goal, state
        )).await;

        if decision.contains("FINISH") {
            return synthesize_final_answer(&state);
        }

        let worker_name = parse_worker_name(&decision);
        if let Some(worker) = workers.get(&worker_name) {
            let result = worker.execute(&mut state).await;
            state.add_result(result);
        }
    }
}

Real systems often add reflection, retry logic, and shared memory between steps.

Advantages of the Manager–Worker Pattern

• Clear accountability — One agent is responsible for the overall outcome.
• Simplicity — Easy to implement, debug, and monitor.
• Structured execution — Natural support for sequential and conditional workflows.
• Flexibility — New specialized workers can be added with minimal changes.
• Good for hierarchical tasks — Works well when clear decomposition is possible.

Limitations and Trade-offs

• Manager bottleneck — The manager can become overloaded with too many workers or complex state.
• Limited parallelism — Workers usually execute sequentially unless the manager explicitly parallelizes.
• Single point of failure — If the manager makes poor decisions, the entire system suffers.
• Scalability limits — Very complex tasks may require flatter or more decentralized architectures.

Best practices:

• Give the manager access to strong memory (episodic + semantic).
• Use procedural memory for common decomposition patterns.
• Implement timeout and cost controls.
• Allow the manager to reflect on past executions to improve future decompositions.

When to Choose Manager–Worker

Use this pattern when:

• Tasks have clear hierarchical structure.
• You need strong oversight and traceability.
• The domain allows reliable task decomposition.
• You are building document generation, research, or structured workflow systems.

For more dynamic or exploratory tasks, flatter patterns (like Handoff/Swarm) often perform better.

Looking Ahead

In this article we explored the Manager–Worker pattern — a centralized orchestration model where a manager agent decomposes goals and coordinates specialized workers.

In the next article we will examine the Handoff Pattern (Swarm), a more decentralized architecture where agents can directly delegate tasks to one another without a permanent central coordinator.

→ Continue to 6.3 — Handoff Pattern (Swarm)