Planner-Worker-Solver

Overview

This paradigm combines a multi-step planner and variable substitution for efficient tool use. It improves upon the ReACT-style agent architecture by reducing token consumption, execution time, and simplifying the fine-tuning process. It was introduced in ReWOO.

Code Examples

Planner-worker-solver architecture

Architecture

Planner-worker-solver architecture consists of three main modules:

1. Planner

The Planner module generates a plan in the following format:

plan: <reasoning>
tool: Google
input: <query>
step_name: step#1

plan: <reasoning>
tool: LLM
input: <query>
step_name: step#2
...

The Planner generates the full chain of tools used in a single pass, thereby reducing the number of LLM calls and avoiding redundant prefixes (system prompt and previous steps) required for each reasoning step in ReACT-style architectures.

2. Worker

The Worker module executes the tools with the provided arguments generated by the Planner. It performs the actual tool invocations and returns the observations.

3. Solver

The Solver module generates the answer for the initial task based on the tool observations obtained by the Worker. This module depends on an LLM call to produce the final answer.

For comparison, see Planner-Worker-Solver Versus Plan-and-Execute.

Benefits

1. Reduced Token Consumption and Execution Time

By generating the full chain of tools in a single pass, this paradigm reduces the number of LLM calls and eliminates the need for redundant prefixes (system prompt and previous steps) at each reasoning step. This leads to reduced token consumption and faster execution compared to ReACT-style architectures.

2. Simplified Fine-tuning Process

The planning data does not depend on the outputs of the tools. This allows for fine-tuning the models without actually invoking the tools, simplifying the fine-tuning process compared to ReACT-style architectures.

3. Variable Substitution

This paradigm employs variable substitution to avoid redundant calls to the Planner LLM. The arguments for subsequent tools can reference the outputs of previous tools using variables (e.g., step#1), which are substituted with their actual values during execution.