AI products: Planner, Executor, and Tool Handler

In the field of artificial intelligence, especially in the design of agent architectures, how to achieve efficient task planning, execution, and tool calling is a key issue. This article delves into the three core components of agent architecture: Planner, Executor, and Tool Handler, and analyzes their roles in decoupling and collaboration mechanisms in detail.

Planner, Executor, and Tool Handler These three core components are in the Agent architecturedecoupling and collaboration mechanisms。 Understanding how they work together is key to building robust, efficient agents.

These three are like a highly specialized project team, each performing their own duties and working closely together to complete complex tasks.

1. Planner: The “brain” and “strategist” of the agent

Core Responsibilities: The main task of Planner is to break down a complex, high-level user goal or system goal into a series of clear, executable, atomized subtasks (Steps) and determine the logical order or dependencies of these subtasks. It is responsible for “figuring out” how to do it.

How to achieve complex task decomposition?

1) Goal Understanding and Clarification:

Planner starts by taking vague or complex goals from the user (e.g., “Help me plan a trip to Osaka next week, budget-friendly, but experienced, and avoid popular attractions”).

It will take advantage of its underlying LLM’s ability to understand and knowledge of the worldto parse the objectives and extract key entities, constraints, and expectations.

Product Manager Perspective: Ensure that Planner’s prompt design adequately guides the LLM to understand the target, even when the understanding is unclearTake the initiative to ask questions and clarify from users(This is the performance of a good agent).

2) Knowledge and ability matching:

Planner “looks at” everything that the Agent hasAvailable Tools, and what it hasInternal Knowledge (Memory)。

It assesses: What tools can I use to accomplish this goal? What inside information do I have? What tools can handle what types of subtasks?

Product Manager Perspective: Clearly define each toolTool Description and Input Schema, which is the basis for the Planner selection tool. The clearer the tool description, the more accurately Planner can match.

3) Chain-of-Thought / Tree-of-Thought:

This is the core intelligence of Planner. Planner calls its underlying LLM, adopting Chain-of-Thought (CoT)、Tree-of-Thought (ToT)、ReAct (Reasoning and Acting) and other reasoning strategies.

• CoT： Simple task breakdown, step by step list of execution steps.
• ToT： Complex task breakdown, Planner may explore multiple possible paths, and proceedForward-thinking, assessing the probability of success of each path, even when a dead end is foundBacktracking。
• ReAct： Planner may start by performing some initial “observation” actions (calling search tools, querying databases) to dynamically adjust its planning based on observations.

Product Manager Perspective: When designing your prompts for Planner, encourage themOutput thought process(Thought: Plan: Sub-task: etc.), which helps to debug and understand agent behavior, and also helps with user trust.

After 10 years of interaction design, why did I transfer to product manager?
After the real job transfer, I found that many jobs were still beyond my imagination. The work of a product manager is indeed more complicated. Theoretically, the work of a product manager includes all aspects of the product, from market research, user research, data analysis…

View details >

4) Generate a list of subtasks that can be executed:

Eventually, Planner outputs a structured plan, usually oneList of subtasks, each subtask is specific enough to be directly handed over to the Executor for execution.

Each subtask may contain:Task description, expected inputs, expected outputs, required tools (or internal operations), dependencies。

Example breakdown: “Planning a trip to Osaka”

• Sub-task 1: Check popular attractions and opening hours in Osaka (Tool: Tourist Information API)
• Sub-task 2: Querying Osaka Budget Accommodation Information (Tool: Hotel Reservation API)
• Subtask 3: Querying Osaka Specialty Food Recommendations (Tool: Food Review API)
• Subtask 4: Avoid peak periods and popular attractions and generate personalized itinerary drafts (internal logic/LLM reasoning)
• Subtask 5: Evaluate the economics and experience of draft itinerary (internal logic/LLM reasoning)
• Subtask 6: Provide a final recommended itinerary and rationale (output)

2. Executor: The “hands and feet” and “doer” of the agent

Core Responsibilities: The Executor receives a list of subtasks generated by Planner and is responsible for executing them one by one in the order they were planned. It is responsible for “doing things” and feeding back the results of execution to Planner (or Memory).

How can I ensure that subtasks are executed in order and error handling?

1) Task scheduling and execution:

Executor maintains oneTask queueto execute the subtasks in the order given by Planner (or based on dependencies).

For each subtask, the Executor determines its type: Is it a call tool? Is it internal logic (like simple text processing)? Or do you need to output to the user?

Product Manager Perspective: Designing an Executor with tasks in mindConcurrency。 Some subtasks can be executed in parallel (e.g., querying hotels and attractions at the same time), while others have strict sequential dependencies (hotel information must be queried before the itinerary can be evaluated).

2) Tool Call and Result Capture:

If the subtask needs to invoke a tool, the Executor passes the request parameters to Tool Handlerand wait for it to return results.

Executor meetingCapture the raw output of the tool calland convert it into a format that the LLM can understand (e.g., convert an API response in JSON format into a natural language summary).

Product Manager Perspective: Make sure that the results returned by the Tool Handler are clearly readable to the Executor. Design the Schema returned by the tool to avoid ambiguity.

3) Error handling and retry mechanism:

This is Executor robustnessThe key to When a subtask fails to execute (e.g., a failed API call, a network error, a tool returns an unexpected result), the Executor needs to have a mechanism in place to handle it:

• Retry: For transient errors, you can set the number of retries and the interval.
• Error Report: Feed back the error message to Planner to re-evaluate the plan or generate a new subtask.
• Fallback: If a tool call fails, can I try an alternative tool?
• Request Human-in-the-Loop: For critical errors that can’t be resolved automatically, throw the problem at humans and provide enough context.

Product Manager Perspective: It needs to be clear with the R&D teamError levels and handling strategies。 What errors can be automatically retried? What needs to be notified to users? Which ones require human intervention? This directly affects user experience and system stability.

4) Status Updates and Feedback:

The Executor updates the execution results (success/failure, and output) of each subtask to the Agent’s Memory or feeds back directly to the Planner.

This allows Planner to proceed based on the latest statusSelf-assessment and adjustment。

Product Manager Perspective: The design of memory should support the recording of detailed execution logs and intermediate results, which is useful for subsequent executionDebugging, optimization, and interpretabilitycritical (e.g., visualization through tools like LangSmith).

3. Tool Handler: The “bridge” and “translator” of the Agent

Core Responsibilities: The Tool Handler is the “gateway” through which the Agent interacts with the outside world. It is responsible for “translating” the high-level instructions of the Planner/Executor into requests that are understandable to the specific tool (API, database, internal function) and “translating” the original response of the tool back into a format that the Agent can understand. It is responsible for “dealing with”.

How to encapsulate external systems so that agents can be “used”?

1) Tool packaging and standardization:

Tool Handler encapsulates various complex and heterogeneous external systems (such as third-party APIs, internal databases, calculators, file systems, etc.) into standard interfaces that can be understood and called by agents.

Each tool should have a clear oneName, function descriptionandSchema for the input parameters(e.g., JSON Schema) to tell the LLM what the tool can do and what input is needed.

Product Manager Perspective: When designing a tool, think from the LLM’s point of view: Is the description of the tool clear enough? Can an LLM easily understand its functions and parameters? Is the granularity of the tool atomized or coarser-grained?

2) Parameter Mapping and Calling:

When the Executor decides to call a tool, it passes parameters that the LLM understands, usually information extracted from natural language, to the Tool Handler.

Tool Handler is responsible for keeping these parameters togethermappingParameter format required to the actual tool API.

Then, the Tool Handler willInitiate the actual API call(HTTP requests, database queries, local function execution, etc.).

Product Manager Perspective: Understand the toolsRate limiting, authentication methods, error codesetc., all of which affect the robustness of the Tool Handler and the overall performance of the Agent.

3) Result parsing and transformation:

Tool Handler receives the return of an external toolOriginal response(usually JSON, XML, or database records).

It is responsible for putting these raw responses togetherParse and transformFormat that makes sense to the agent and is easy for the LLM to understand (e.g., summarizing complex JSON responses into natural language descriptions or key data points).

Product Manager Perspective: The quality of the resulting transformation directly affects the use of information by Planner/Executor. If the conversion is not done properly, the agent may not understand it correctly, even if the tool returns the correct information.

4) Error and Exception Handling:

The Tool Handler needs to handle various errors that may occur during tool invocation (network connection failure, API return error code, parameter validation failure, etc.).

It will report these error messages to the Executor in a structured or friendly manner.

Product Manager Perspective: Clarify the toolError types and error messagesso that the executor can make the right decisions based on this.

4. The decoupling and cooperation mechanism of the three: a dynamic cycle

The relationship between these three is a dynamic, iterative cycle:

1) User objectives → Submitted to Planner。

2）Planner Think, plan, → generateList of subtasks → handover Executor。

）3Executor Execute the subtasks one by one:

• If an external capability → request is required Tool Handler Call the tool.
• Tool Handler Call the tool → to getOriginal results → Parse and returnStructured resultsTo give Executor。
• Executor Receive Results → Update the results toMemory, or feedback directly Planner。

4）Planner Receive the execution result of the Executor, whether successful or unsuccessful, proceedSelf-Reflection：

• If the task completes→ the final result is output.
• If you find a bug or if it’s not going well→ Replanto generate a new list of subtasks (which may include debugging, retries, or trying new methods).
• If more information is needed, → may generate new subtasks to call the tool or query memory.

This cycle continues until the task is completed or a preset stop condition is reached (e.g., the maximum number of attempts is reached).

Product managers need to understand that:

• Every step can go wrong: Planner may have a planning error, Executor may fail to execute, and Tool Handler may call an error or return gibberish. These points must be taken into account when designing.
• Every aspect is optimisable: Optimizing Planner’s prompts can improve the quality of planning; Optimizing the package of the Tool Handler can improve the efficiency of tool calling. Optimizing Executor’s error handling can improve system robustness.
• Flexibility with decoupling: The decoupling of these three allows you to optimize or replace one of the components independently without affecting the others. For example, replace it with a more powerful Planner LLM or integrate a new tool.

This decoupling and collaboration mechanism is at the heart of building complex and intelligent AI Agents, and understanding it can help you better collaborate with R&D and algorithm teams to jointly promote projects such as your “Smart Form Generation Agent”.

5. The role of the three in the AI form creation robot process

1. The role of the Planner: Understand the requirements and develop a “blueprint” for creating the form

Input: User’s natural language needs: “To create a user registration form for me, you need to collect your name, email, phone number, and a password field, and the password must be entered twice to confirm it, and the phone and email address must be verified format. ”

Core Action: Understanding and Decomposing

Planne, often played by a powerful LLM, performs the following thinking and planning:

1) Intent recognition: The core intent to identify users is “Create form” and the form type is “User registration”.

2) Key information extraction: Key fields required to extract the form: name, email, phone, password.

3) Constraints and Rule Identification:

• The password must have two input confirmations: This is a logical constraint, meaning that two fields, Password and Confirm Password, are required, and both need to be validated for consistency.
• Phone and email to verify format: This means that these two fields need to correspondChecking rules(regular matching or built-in validation).

4) Task decomposition and sequencing: Break down the complex form creation process into a series of orderly, executable subtasks.

Subtask 1: Understand form field requirements (Internal Thinking)

• Identify core fields: Name (text), Email (mailbox format), Phone (phone format), Password (password type).
• Identify password confirmation logic: Add a Confirm password field.

Subtask 2: Plan field attributes and check rules (Internal Thinking)

• Assign each field the appropriate input type (text, email, tel, password).
• Specify format validation rules for email and phone fields.
• Specify the password and confirm the matching rules for the password.

Subtask 3: Invoke the tool to generate the form structure (Tools Required)

Based on the planned fields and rules, call the Form Builder’s API to create JSON or a specific formatting structure for the form.

Subtask 4: Check the logic and integrity of the generated form (Internal thinking/tools may be needed)

• Evaluate whether the generated form structure meets all user requirements and logical rules.
• (Optionally, if an external tool is required) Call the Form Validator for stricter structural checks.

Subtask 5: Output form links or embeddable code (Tools Required)

• If the form is generated successfully and passed, call the Form Publishing Tool to generate a shareable link or embed code.
• Feedback the final result to the user.

Output: A structured execution plan with multiple subtasks and their dependencies.

2. The role of the executor: to advance according to the plan and coordinate tool calls

Input: A list of subtasks generated by Planner.

Core actions: scheduling and execution

The Executor follows the Planner’s plan, executing the subtasks step by step and interacting with the Tool Handler.

Execute subtasks 1 and 2 (internal logic): The Executor knows that these two are the result of Planner’s internal thinking, not external calls, just Planner’s output.

Execute subtask 3 (invoke tool):

The Executor recognizes the task of “Invoking the Tool to Generate Form Structure”.

It will be ready to call the parameters required by the Form Builder, such as:

JSON

{
“form_name”: “User Registration Form”,

“fields”: [

{“name”: “name”, “type”: “text”},

{“name”: “email”, “type”: “email”, “validation”: “email_format”},

{“name”: “phone”, “type”: “tel”, “validation”: “phone_format”},

{“name”: “password”, “type”: “password”},

{“name”: “Confirm password”, “type”: “password”, “validation”: “match_password”}

]

}

The Executor then passes these parameters to Tool Handlerto request a call to the create_form tool.

Receiving tool results and error handling:

The Executor receives the execution results of create_form tools from the Tool Handler (for example, the ID or error message of a successfully generated form).

• Error Handling: If create_form fails (e.g., API error, incorrect parameters), the Executor catches the error.
• Simple error: Try to retry a few times.
• Complex errors: Feed back error messages to Planner for re-evaluation, possibly adjusting the generation logic or providing user-friendly error prompts.

Perform subtask 4 (Check and Check): When the Executor receives a message that the form is generated, it may trigger an internal logic check, or if Planner has planned, call a “form validation tool” again.

Perform subtask 5 (Release Tool):

• If the check passes, the Executor prepares the parameters and calls the Form Publishing Tool API to request a shareable link.
• After receiving the link, Executor takes the final link information as the result.

Output: Intermediate execution status, tool call results, and the final form link.

3. The role of Tool Handler: Realize the interaction between the Agent and the “form system”

Input: Tool call requests (tool names, parameters) made by the Executor.

Core action: encapsulation and transformation

The Tool Handler is responsible for actually interacting with the form generation platform (or your internal form system API) behind you.

1) Tool definition and encapsulation:

Your form system exposes a range of APIs, such as:

• create_form (form_definition): Create a form based on the form definition.
• validate_form_structure (form_id): Verify that the form structure is valid.
• publish_form (form_id): Publish the form and return the share link.

The Tool Handler encapsulates these APIs as “tools” that the Agent can call and defines themFeature description and parameter schemafor Planner to identify and use.

For example, define a tool called create_form, described as “used to create a new form based on a given field definition,” with the parameter form_definition (JSON object).

2) Parameter mapping and actual calls:

When the Executor requests to call the create_form tool and passes the form definition JSON:

The Tool Handler takes this JSON, uses it as a request body, and sends an HTTP request to your form system API POST /forms.

Example request (HTTP POST):

POST /api/v1/forms

Content-Type: application/json

{
“name”: “User Registration Form”,

“elements”: [ // Let’s say your form system is called elements

{“type”: “text”, “label”: “name”},

{“type”: “email”, “label”: “email”, “validation_regex”: “^\\S+@\\S+\\.\\S+$”},

{“type”: “phone”, “label”: “phone”, “validation_regex”: “^\\d{11}$”},

{“type”: “password”, “label”: “password”},

{“type”: “password_confirm”, “label”: “confirm password”, “match_field”: “password”}

]

}

3) Result parsing and returning:

• The Tool Handler receives a response from the form system API (e.g., { “form_id”: “FORM123”, “status”: “created” }).
• It parses this response and converts it into a more concise or structured form that the Agent (Executor) can understand.

The example returns to the Executor:{“status”: “success”, “form_id”: “FORM123”, “message”: “Form created successfully”}

4) Error and exception delivery:

If the form system API returns an error (such as a 400 Bad Request), Tool Handler catches these errors and converts them into exceptions or error messages that the Executor can handle, rather than throwing the original API error directly.

Output: The success/failure status of the tool execution, and the corresponding return value.