Planner-Actor Architecture

The architecture enforces a strict division between two distinct cognitive modules. The Planner is responsible for high-level task decomposition, strategy formulation, and subgoal generation. It reasons abstractly about the 'what' and 'why.' The Actor module handles the 'how,' focusing on low-level action execution, parameter binding for specific tools, and immediate environment interaction. This separation allows for specialization, where a large, reasoning-optimized model can be used for planning, while a faster, smaller, or more deterministic model handles execution.

A core advantage is the ability to use different AI models optimized for each role, a concept known as model specialization. Common patterns include:

• Using a large, general-purpose model (e.g., GPT-4, Claude 3) as the Planner for complex reasoning.
• Employing a smaller, faster, or fine-tuned model as the Actor for reliable, low-latency tool calling.
• Incorporating domain-specific models (e.g., for code, math, or logistics) into either role. This orchestration optimizes for both cost-efficiency and task performance, as expensive planner tokens are used sparingly for strategy, while cheaper actor tokens handle frequent execution.

The Planner performs iterative task decomposition, breaking a high-level user instruction into a tree or sequence of executable subgoals. This is not a single-step prompt but a dynamic planning process. The Planner may create a partial plan, dispatch a subgoal to the Actor, and then re-plan based on the Actor's observations. This enables handling of complex, multi-step tasks like 'Build a web dashboard' by decomposing it into subgoals for data fetching, API design, UI component generation, and deployment, each executed by the Actor.

Unlike static scripted workflows, Planner-Actor systems feature a closed-loop feedback mechanism. After the Actor executes an action and returns an observation (e.g., tool output, error, state change), this information is fed back to the Planner. The Planner then engages in dynamic re-planning, assessing whether the original plan remains valid or needs adjustment. This allows the system to recover from failures, adapt to unexpected outcomes, and incorporate new information, making it robust in non-deterministic environments.

The architecture necessitates clear state management to maintain coherence. The Planner often maintains a working memory or plan state that includes:

• The original goal and high-level plan.
• Completed subgoals and their results.
• Current environmental context from Actor observations.
• Constraints and policy rules. This explicit state is passed between planning cycles, preventing the Actor from losing context and enabling the Planner to make informed decisions. This differs from a single-model agent where state is implicitly held within a long, monolithic context window.

Communication between the Planner and Actor is governed by a structured interface protocol or plan specification language. This is often a JSON-based schema that defines subgoals. A typical plan object includes:

• subgoal_id: A unique identifier.
• objective: A clear, actionable instruction for the Actor.
• required_tools: The capabilities the Actor must use.
• success_criteria: Conditions for the subgoal's completion.
• dependencies: Other subgoals that must be completed first. This structured interface ensures deterministic parsing and execution by the Actor, reducing ambiguity compared to natural language instructions.

This is a prompting technique rather than a framework, but it implements the pattern within a single model. A meta-prompt instructs the LLM to first act as a planner, outputting a step-by-step strategy. In a subsequent call or continuation, the same model is instructed to act as an actor, following its own generated plan. This demonstrates the conceptual separation can be enforced purely through context and instruction design.

• Planner: LLM under a "generate a plan" system prompt.
• Actor: The same LLM under a "execute this plan" prompt.
• Key Feature: No specialized infrastructure required; pattern enforced via prompt chaining and context management.

ReAct is a foundational framework that formalizes the interleaving of reasoning traces (Thought) with external actions (Action) and environmental feedback (Observation). It provides the basic loop structure upon which many planner-actor systems are built, explicitly modeling the step-by-step deliberation required for tool use.

• Core Cycle: Thought → Action → Observation.
• Foundation: Establishes the pattern of grounding LLM reasoning in real-world data via tools.
• Relation to Planner-Actor: A Planner often generates the 'Thought' steps, while an Actor executes the 'Action' steps.

The Thought-Action-Observation cycle is the atomic execution unit within a ReAct-style agent. It represents a single iteration of internal reasoning, external execution, and result integration.

• Thought: The agent's internal reasoning or planning step.
• Action: The structured call to an external tool or API.
• Observation: The parsed result returned from the tool.
• Architectural Role: In a planner-actor system, this cycle is the interface between the two components. The Planner outputs Thoughts and intended Actions; the Actor fulfills the Actions and returns Observations.

Hierarchical Reinforcement Learning is a classical machine learning paradigm that strongly inspires the planner-actor pattern. It decomposes a complex task into a hierarchy of subtasks, where a high-level policy (the planner) selects subgoals, and low-level policies (the actors) execute sequences of primitive actions to achieve them.

• Key Analogy: The high-level policy is analogous to the Planner module; the low-level policies are analogous to specialized Actor modules.
• Temporal Abstraction: Enables reasoning and planning over extended time horizons.
• Foundation: Provides a rigorous mathematical framework for the separation of concerns central to planner-actor design.

Tool selection and parameter binding are critical low-level execution tasks typically handled by the Actor component. They translate abstract plans into concrete, executable commands.

• Tool Selection: Choosing the correct function or API from a library of capabilities to achieve a subgoal.
• Parameter Binding: Mapping the outputs of reasoning or previous observations into the specific input schema required by the selected tool.
• Actor's Responsibility: The Actor must reliably perform these steps based on the Planner's intent, often requiring precise understanding of tool documentation and schemas.

Iterative task decomposition is the core planning strategy where a complex objective is broken down into a sequence of simpler sub-tasks. This is the primary function of the Planner module.

• Dynamic Planning: The decomposition often happens step-by-step, reacting to observations rather than being fully pre-defined.
• Subgoal Generation: The Planner outputs these intermediate objectives (subgoals) for the Actor to execute.
• Relation to Architecture: This process exemplifies the 'planning' in planner-actor, transforming a user's ambiguous request into an actionable procedure.

Dynamic re-planning is the Planner's ability to revise its strategy and subgoal sequence in response to unexpected failures, new information, or changing conditions reported by the Actor via Observations.

• Feedback Loop: Critical for robustness. When an Action fails or an Observation invalidates the current plan, the Planner must generate a new one.
• Architectural Necessity: Highlights the need for a dedicated Planner component that can perform meta-reasoning on the overall task state, separate from the Actor's focus on immediate execution.
• Error Recovery: A key mechanism for implementing resilient error correction loops within an agent.