Advanced Agent Behaviors: Planner, Formatter & Renderer

By default, an Agent uses only the Orchestrator node — it reads the user's message, reasons about intent, and responds. For complex scenarios, the Vue.ai platform provides three additional optional processing nodes that can be independently toggled on.

All three optional nodes are configured in the Details tab of the Agent Builder, below the Orchestrator section.

1. Enable Planning — The Planner Node

The Planner adds a deliberate reasoning step between the Orchestrator and Action execution. Its sole responsibility is to calculate the optimal sequence of actions needed to fulfill a complex request. It does not interact with the user or handle data collection; those tasks are managed by the Orchestrator.

Without Planning:

User: "Compare my last 3 invoices and flag anomalies"
Orchestrator → Immediately fires the first matching Action → May miss steps

With Planning:

User: "Compare my last 3 invoices and flag anomalies"
Orchestrator → Planner:
  Step 1: Action: Fetch_Invoices
  Step 2: Action: Parse_Invoice
→ Orchestrator executes actions sequentially

How to Enable

1. Open the Agent in the Details tab.
2. Scroll down past the Orchestrator Instructions textarea.
3. Check the ☐ Enable Planning checkbox.
4. A new Planning configuration section appears immediately below.

Planner Configuration Fields

The Planner uses sophisticated internal defaults to calculate action sequences. Providing custom instructions is optional and if provided, are used to refine the default behaviour.

Behavior When Planning is Enabled

When planning is enabled for your agent:

• Plan Presentation:
  After the user submits a request, the planner sub-agent generates a high-level plan (a sequence of action steps). This plan is presented to the user for review.
• User Approval or Modification:
  The user can approve the proposed plan as-is, or modify the plan steps before proceeding.
• Step-by-Step Execution:
  Once the plan is approved, the agent (orchestrator) begins executing the plan steps one by one, handling each action in sequence.

Handling Failures and Deviations

• If an action fails, or if the result of a step is different from what was expected, the orchestrator agent can:
  • Prompt the user for clarification or next steps,
  • Attempt to replan (generate a new plan based on the updated situation),
  • Or gracefully handle the deviation as appropriate.
• This makes the planning system flexible and robust—your agent is not locked into a rigid sequence, but can adapt to real-world failures or changes in user intent.

Planner Instructions vs. Orchestrator Instructions

It’s important to understand the distinction between Planner Instructions and Orchestrator Instructions:

• Planner Instructions are provided to a dedicated LLM (the Planner node) whose sole job is to generate a high-level plan—a sequence of action steps needed to fulfill the user’s request. The planner is not concerned with how these steps are executed, what inputs are required, or how to interact with the user. It simply outputs the optimal order of actions.
  • Think of the planner as the architect, designing the blueprint but not building the house.
• Orchestrator Instructions are used by the main agent (the Orchestrator node) to actually execute the plan. The orchestrator is responsible for:
  • Collecting any required inputs (prompting the user if needed)
  • Invoking each action in the plan
  • Handling responses and managing the conversation flow
  • Ensuring the plan is carried out step by step

Workflow:

1. The Orchestrator receives the user’s request and, if planning is enabled, delegates to the Planner.
2. The Planner generates a plan (sequence of actions) using the Planner Instructions.
3. Once the plan is approved, control returns to the Orchestrator, which executes the plan using the Orchestrator Instructions.

Summary:

• The Planner decides “what should be done” (the steps).
• The Orchestrator decides “how it’s done” (execution, user interaction, and action invocation).

This separation allows for more robust, modular, and maintainable agent behaviors.

Example: Planner vs. Orchestrator Instructions

Suppose your agent needs to flag anomalies in a specific invoice.

• Planner Instructions Example:

  "When the user asks to compare or analyze invoices, use the following sequence:

  1. Use the Fetch_Invoices action to retrieve the candidate list.
  2. Use the Parse_Invoice action for each specific invoice identified.

• Orchestrator Instructions Example:

  "You are a helpful invoice assistant. After fetching the user's invoices, always ask the user which invoice they want to parse before proceeding to the next step in the plan. Then, parse the selected invoice and present the results."

  This highlights the distinction: the planner determines what actions need to be taken by outlining the sequence, while the orchestrator manages how those actions are carried out—handling user interaction, gathering inputs, and executing each step.

2. Format Responses — The Formatter Node

What the Formatter Does

The Formatter is a post-processing node that takes raw responses and converts them into well-structured, human-readable markdown or other clean text formats. It acts as a readability enhancer.

Common use cases:

• Converting raw action output into clean markdown with headings, bullet points, and tables.
• Reformatting verbose LLM responses into concise, well-organized text.
• Standardizing response structure for consistent, polished user-facing output.

How to Enable

1. In the Details tab, scroll down below the Enable Planning checkbox.
2. Check the ☐ Format Responses checkbox.
3. The Formatter Config section appears with its own Model, Temperature, and Instructions.

Formatter Configuration Fields

If left empty, the Formatter relies on default platform logic to clean and structure raw output. Providing custom instructions allows you to refine the default behaviour.

Example Formatter Instructions:

Your job is to convert the raw response into clean, well-structured Markdown:

- Use headings (##) to organize sections.
- Use bullet points for lists of items.
- Use markdown tables for tabular data.
- Keep the tone concise and professional.
- Do not add information that is not present in the raw data.

3. Render Responses — The Renderer Node

What the Renderer Does

The Renderer is the final processing node in the pipeline. It takes raw responses and converts them into rich chat UI components — interactive forms, scrollable cards, data charts, and quick reply buttons.

Key distinction from Formatter:

• The Formatter produces human-readable text (markdown with headings, tables, bullet points).
• The Renderer produces rich interactive UI components (forms, cards, charts, quick replies).

How to Enable

1. In the Details tab, scroll below the Formatter Config section.
2. Check the ☐ Render Responses checkbox.
3. The Renderer Config section appears.

Renderer Configuration Fields

The Renderer has built-in logic for mapping common data structures to UI components. Use custom instructions to refine how specific data is visualized (e.g., "always use line charts for time-series data").

Example Renderer Instructions:

You receive data from the orchestrator or action output. Convert it into rich 
chat UI components using the forced rendering JSON schema:
- Use "card" type for product recommendations or comparisons.
- Use "form" type when collecting structured input from the user.
- Use "chart" type for numerical/statistical data.
- Use "text" type with quickReplies to guide user choices.

Combining All Nodes — Full Pipeline Example

Here is a practical example with all four nodes enabled:

Scenario: A Customer Service Agent that looks up order status.

User flow:

1. User says: "What's the status of my last order?"
2. Orchestrator identifies intent → delegates to Planner.
3. Planner creates plan: Step 1 — ask user for order ID; Step 2 — call Lookup_Order action.
4. Agent asks: "Could you provide your order ID?"
5. User provides: "ORD-12345"
6. Planner proceeds — fires Lookup_Order action with order_id: ORD-12345.
7. Action returns raw data.
8. Formatter converts raw data → clean markdown summary.
9. Renderer converts data → rich card UI displayed in chat.

Best Practices