---
title: Planner-Executor Multi-Agent Architecture
url: https://www.emergentmind.com/topics/planner-executor-multi-agent-architecture
type: topic
---

# Planner-Executor Multi-Agent Architecture

A planner-executor multi-agent architecture is a system design pattern wherein a central planning agent decomposes high-level goals into structured sub-tasks and delegates their execution to specialized executor agents. This paradigm provides modularity, explicit separation of concerns, and dynamic workflow adaptation, and has become foundational in scientific automation, complex reasoning, scientific computing, navigation, retrieval-augmented generation, code synthesis, and verification tasks. The architecture is characterized by dynamic task decomposition (often via hierarchical or recursive approaches), runtime instantiation of dedicated executor agents with tailored toolsets, and inter-agent protocols ensuring parallelism, error propagation control, and robust scalability.

## 1. Core Architecture and Workflow

A prototypical planner-executor system consists of a central planning agent and multiple dynamically instantiated executors. The planner receives a user’s root request and leverages a library of tools and agent templates to hierarchically decompose the task via a method such as hierarchical task networks (HTN), topological sort, or recursive goal expansion [2509.14542]. The planner maintains an explicit working-memory file or a dependency graph (DAG) representing subtasks, dependencies, and intermediate results.

Task delegation follows these steps:

1. **Task Decomposition**: The planner applies a recursive decomposition algorithm (e.g., HTN, layered execution graph, or dependency-aware DAG) to partition the root task into atomic or primitive sub-tasks [2509.14542, 2602.01848, 2508.04604, 2605.25233].
2. **Dynamic Executor Instantiation**: For each atomic subtask, the planner configures an executor with a tailored system prompt, specific tool configuration (e.g., tool list, API schema), and a unique I/O contract [2509.14542, 2508.20096].
3. **Parallel and Sequential Scheduling**: Executors may be run in FIFO order, batch-parallel, or according to a dependency-preserving schedule, often determined by the structure of the decomposition tree or DAG [2604.07681, 2602.01848, 2508.04604].
4. **Execution and Result Propagation**: Executors autonomously perform their assigned tasks, invoke external tools (e.g., code execution, simulation engines), and return outputs to the planner. The planner aggregates results, triggers downstream processes, and collates final outputs for the user [2509.14542, 2604.07681, 2605.25233].

Message schemas between agents are typically concise JSON packets containing task IDs, tool descriptions, input payloads, and result metadata. Working-memory structures encode hierarchical task state and execution traces for coordination and debugging.

## 2. Task Decomposition and Planning Algorithms

Planners implement explicit task decomposition, commonly via:

- **Hierarchical Task Networks (HTN)**: Tasks are recursively split into subtasks until only primitives remain. Planning proceeds by topological sorting of leaves subject to dependency constraints. Subtasks inherit context relevant to their branch [2509.14542].
- **Layer Execution Graph (LEG)**: For multi-track reasoning (e.g., scientific workflows), the planner constructs a LEG—a DAG where nodes are agent invocations, layers are synchronization barriers, and tracks encode parallel logical branches [2605.01102]. Barrier semantics ensure that all tasks in layer $k$ are complete before layer $k+1$ begins.
- **Directed Acyclic Graphs (DAG)**: In RAG and search systems, the planner builds a DAG representing sub-queries and their dependencies, optimizing for parallel execution and minimal makespan [2508.04604].
- **Recursive Open Meta-Agent Decomposition**: ROMA uses recursive planner-executor splitting: each node dynamically decides whether to further decompose a subgoal or to delegate it to an executor, maintaining context windows by aggregating only summaries upward [2602.01848].

Decomposition considers tool registry inspection, input/output contract formation, format constraints, and, in some systems, explicit verification predicates and behavioral checks for each node in the decomposition graph [2605.25233]. In some scientific domains, planners incorporate domain-specific heuristics encoded in natural-language prompts for routing and agent selection [2605.01102].

## 3. Executor Agents, Tool Abstraction, and Adaptive Configuration

Executors in this architecture are instantiated per subtask, with stateless, single-use semantics beyond their input payload. They are configured with:

- **System Prompt Templates**: Each executor prepares a domain-specific system prompt framing its responsibility (e.g., "You are an agent tasked with extracting alloy compositions…" or "You are evaluating a simulation workflow for a specific parameter sweep" [2509.14542, 2604.07681]).
- **Tailored Toolsets**: Executors interface with a minimal subset of tools (APIs, wrappers, code execution sandboxes, simulation engines) required for their designated subtask [2509.14542]; tool access is strictly defined by the planner-generated context.
- **Workflow and Control Loop**: Upon receiving an execution request, the executor:
  1. Parses the system prompt and loads available tool endpoints.
  2. Executes a single LLM call, which may generate an action plan, including explicit tool call commands.
  3. Bridges LLM output with real tool invocations via a read–think–act orchestration loop.
  4. Returns structured results on completion or error [2509.14542].

This design robustly accommodates new tools—each tool is added to a central registry and automatically becomes available to the planner's decomposition logic, requiring no code changes in executor instantiation [2509.14542]. Executors are agnostic to memory beyond their immediate context, and their stateless execution ensures scalability.

## 4. Communication Protocols, Memory, and Feedback Mechanisms

Planner-executor systems rely on lightweight communication protocols for agent orchestration:

- **Message Schemas**: All inter-agent messages use compact, well-typed JSON schemas containing task IDs, subtask descriptions, input arguments, tool endpoints, and system prompts. Result messages include success/error status, output payloads, log data, and tool usage metrics [2509.14542, 2604.07681].
- **Working-Memory Models**: The planner maintains a persistent working-memory tree (or file), capturing the root goal, the decomposition hierarchy, individual subtask states, and back-pointers for stateful dependency management [2509.14542].
- **Feedback-Driven Flow**: Results produced by executors immediately update the planner's state, triggering progression to downstream subtasks. Built-in mechanisms handle error propagation, forced replanning, and dynamic adjustment of downstream tasks [2509.14542, 2605.25233].
- **Parallel Agent Orchestration**: Executors are launched as processes or threads to maximize concurrency across independent subbranches of the decomposition tree or DAG [2604.07681].
- **Memory Modules**: Across benchmarks, planner memory is observed to dominate clean-task utility, while executor memory has negligible effect; shared or separate memory models produce similar outcomes [2510.07505]. Experiments show utility improvements of 10–30 percentage points when planners are equipped with comprehensive memory modules.

## 5. Scalability, Performance, and Domain Adaptability

The architecture demonstrates robust scalability in both resource efficiency and domain generality:

- **Parallelism and Critical Path**: Makespan for DAG-scheduled sub-tasks reflects the length of the critical execution path, not the total number of sub-tasks [2508.04604]. Parallel efficiency remains high (e.g., 98% up to 32 nodes, 65% at 256 nodes for scientific screening) [2604.07681]. Speedups achieved by parallel scheduling approach the ideal $L_{\mathrm{seq}}/L_{\mathrm{par}}$ ratio.
- **Executor Pool Scaling**: Planner agents allocate executors according to workload, dynamically partitioning subtasks. Pools of hundreds of executors can be coordinated via Model Context Protocol (MCP) servers or other cluster management backends [2604.07681].
- **Adaptability and Tooling**: The planner-executor pattern is tool-agnostic—backends for DFT, GCMC, molecular dynamics, code evaluation, or web interaction can be swapped in by extending the tool registry and adapting system prompts [2509.14542, 2604.07681].
- **Memory and Token Efficiency**: Semi-centralized protocols (as in Anemoi) dramatically reduce communication cost, shrinking redundant context passing by up to 75% compared to centralized prompt-passing designs, while improving accuracy by up to 9.09 percentage points over centralized baselines [2508.17068].
- **Domain Generalization**: The architecture has been applied to material discovery, web navigation, OS control, adaptive retrieval, GUI automation, scientific reasoning, and claim verification [2604.07681, 2605.02168, 2508.01005, 2508.20096, 2605.01102].

## 6. Robustness, Vulnerabilities, and Verification

Despite improved reliability over single-agent protocols, planner-executor architectures expose several vulnerabilities:

- **Sensitivity to Planner Quality**: Clean-task utility and robustness are dominated by planner quality. Weak planners in otherwise strong systems cause sharper utility drop than the inverse, with utility performance differing by 20–30 percentage points in ablations [2510.07505].
- **Attack Surfaces**: Robustness benchmarks reveal that planner-stage prompt injections, system prompt attacks, or communication payload manipulations can lead to high attack success rates—routinely ASR ≥ 70%, with planner prompt corruption propagating failures through the execution tree [2510.07505, 2605.11514].
- **Workflow Steering Attacks**: Unique to this architecture, attacks on workflow formation (such as FlowSteer) exploit planning-time vulnerabilities, crafting prompt perturbations that bias the planner into structurally amplifying malicious signals; corresponding defenses (FlowGuard) reduce attack success rates by 18–34 percentage points, with minimal impact on utility [2605.11514].
- **Verification and Error Attribution**: Modern frameworks (Meta-Agent, ROMA) integrate construction-time and execution-time verification predicates, explicit input/output contracts per agent, and three-way error attribution (local, upstream, structural) to contain error propagation and support targeted remediation (replan, partial redo, or system re-synthesis) [2605.25233, 2602.01848].
- **Interpretability**: Zero-shot, chain-of-thought planners (e.g., “MACE”) produce explicit reasoning explanations and step-by-step plans, with execution and verification traces formatted as structured blocks for auditability [2604.17225].

## 7. Design Principles and Extensions

Key architectural principles emerging from recent work include:

1. **Separation of Concerns**: Explicit bifurcation between “what to do” (planner) and “how to do it” (executor), enabling modular reasoning and division of labor [2509.14542].
2. **Hierarchical Decomposition**: Recursive partitioning yields depth-limited trees or DAGs with bounded context footprint and scalable parallel execution [2602.01848].
3. **Tool Abstraction**: Every actuator or environment interface is encapsulated as a tool with a standard API, facilitating planner-driven task-tool binding at runtime [2509.14542].
4. **Dynamic Agent Configuration**: Executors are instantiated at runtime using prompt templates and tool configurations specific to the subtask [2509.14542, 2508.20096].
5. **Feedback-Driven Control Flow**: Results and errors propagate through the planner state, gating downstream actions and supporting robust error recovery [2605.25233].
6. **Verification and Attribution**: Integration of format, behavioral, and logical verification at construction and runtime, with fine-grained error labeling and remediation [2605.25233].
7. **Memory and Self-Evolution**: Bidirectional conversion between parametric (planner-trained) and non-parametric (experience memory) supports on-the-fly self-improvement and test-time adaptation [2604.04503].

Design generalizes across domains; by substituting domain-specific toolkits and workflows, the core architecture remains applicable for scientific modeling, RAG, navigation, cyberdefense, and knowledge-intensive procedural tasks [2509.14542, 2502.10931, 2508.01005, 2604.07681].

---

In summary, the planner-executor multi-agent architecture has proven to be a robust, extensible, and high-performance design for orchestrating complex automation with deep reasoning, explicit verification, and multi-tool integration. Its principled modularity, based on hierarchical task decomposition, dynamic executor instantiation, and rigorous feedback channels, underlies advances in robust scientific workflows, adaptive reasoning, scalable retrieval, and practical multi-agent collaboration across a range of specialized and generalist applications [2509.14542, 2602.01848, 2605.25233, 2604.07681].

Source: https://www.emergentmind.com/topics/planner-executor-multi-agent-architecture