Planner–Executor Architectures: The Two-Person Team Your Agent Needs (One Plans, One Does the Dirty Work)

"Delegation is the secret sauce of intelligence — and of avoiding catastrophic hallucinations." — Probably Me, Definitely True

You already saw how to pick the right tools (Tool Selection Prompts) and how to structure inputs with Parameter Schema Design. Now it's time to stitch those pieces into a coordinated machine: the Planner–Executor architecture. If the tool selection is the kitchen and parameter schema design is the recipe format, this is the head chef (Planner) telling the sous-chef (Executor) what to prep and how to plate it — without setting the place on fire.

What is a Planner–Executor architecture? (Short, punchy, useful)

• Planner: High-level reasoning module that breaks a goal into steps, picks tools, sequences actions, and enforces constraints.
• Executor: Low-level action module that performs those steps — calling tools, formatting inputs/outputs, applying parameter schemas, and handling edge cases.

Think of it as: Planner = the movie director; Executor = the production crew. The director decides what scenes are needed and in what order. The crew actually sets up lights and makes sure the camera works.

Why split planning and execution?

• Separation of concerns: Keep strategy (what) separate from implementation (how). Easier to debug and safer to guard.
• Reduced hallucination: The Executor can be required to obey strict parameter schemas and tool selection prompts you already tuned.
• Modularity: Swap Executors or tool plugins without retraining the Planner.
• Auditability: Each step is explicit, so you can log and verify decisions.

Quick thought: If your LLM is trying to do both planning and execution in one shot, it will often invent capabilities it doesn't have (hi, hallucinations). The Planner–Executor split forces accountability.

Core components and how they interact

1. Planner
   • Inputs: user goal, constraints (safety/ethics), tool registry, memory overview
   • Outputs: ordered plan (steps), tool calls with intent, and expected outputs/schema for each step
2. Executor
   • Inputs: single step from planner, parameter schema, access to tools (via stable API bindings)
   • Outputs: validated tool responses, errors, and a concise result.
3. Arbiter / Validator (optional but recommended)
   • Checks tool call safety and schema compliance before and after execution
4. Memory & Logs
   • Store plan history, tool outputs, and decisions for later auditing and iterative planning

Example message flow (simplified)

1. User: "Summarize the attached report and translate the conclusion into Spanish."
2. Planner: Outputs a 3-step plan: [read & extract, summarize, translate]. Assigns tools: document_reader, summarizer, translator. Specifies expected schemas.
3. Executor: Runs document_reader with schema → returns text. Runs summarizer with constraints → returns summary. Runs translator → returns Spanish text.
4. Validator: Confirms none of the outputs violate safety or privacy rules.
5. Planner: (optional) Revises plan if executor reports errors.

Practical prompt templates (starter kit)

Planner prompt (concise)

You are Planner. Given a user request and available tools, return an ordered plan of steps. For each step include: step_id, description, tool_name, expected_output_schema, and safety_constraints. Use JSON only.

User request: "{user_request}"
Available tools: {tool_registry}
Global constraints: {safety_constraints}

Planner should output JSON like:

[
  {"step_id": 1, "description": "Extract main body text from PDF", "tool_name": "document_reader", "expected_output_schema": {"text": "string"}, "safety_constraints": ["redact personal data"]},
  {"step_id": 2, "description": "Summarize in <= 200 words", "tool_name": "summarizer", "expected_output_schema": {"summary": "string"}, "safety_constraints": ["do not invent facts"]}
]

Executor prompt (concise)

You are Executor. Run the given step with the specified tool. Follow the expected_output_schema exactly. If tool fails, return an error with code and brief message. Always include a 'verified' boolean indicating schema compliance.

Step: {single_step}
Tool API: {tool_binding_description}

Executor output (schema):

{"step_id": 1, "result": {"text": "..."}, "verified": true}

Safety, Ethics, and Risk Mitigation — redux (builds on the previous topic)

You've already learned to craft safe prompts. Apply those lessons here:

• Planner-level constraints: Force the Planner to list privacy, legal, or ethical constraints in each plan step (e.g., redact PII, avoid sensitive inferences).
• Executor validators: Ensure Executors strictly validate outputs against the parameter schema. Reject and escalate when mismatches occur.
• Tool gating: The Planner can propose tools, but the Arbiter must approve any tool that handles sensitive data.
• Audit logs: Record every Planner decision and Executor call for later review.

Pro tip: Use the Parameter Schema Design patterns you already created to keep Executor responses machine-checkable. If it fits the schema, it’s probably not hallucinated.

Patterns, pitfalls, and debugging strategies

• Pattern: "Plan small, execute fast." Keep Planner steps granular so Executors can fail gracefully and retry.
• Pitfall: Overconfident Planner. If your Planner proposes a tool that doesn't exist or misuses parameters, you need a Validator that checks the registry first.
• Debugging tip: If results are noisy, log the Planner's expected_output_schema and compare with Executor's verified boolean. If verified=false, inspect the tool binding.
• Performance tradeoff: More steps = better control but higher latency. Balance by grouping safe, deterministic operations in the Executor.

Quick comparison table: Planner vs Executor

Example: From user intent to action (mini case study)

User: "Find the latest stats on EV adoption in Germany and create a 3-slide brief."

Planner output (example):

1. step_id=1: web_search -> find authoritative sources (expected_output: list of URLs)
2. step_id=2: scraper -> fetch pages (expected_output: raw_text)
3. step_id=3: summarizer -> create 3 bullet points per slide (expected_output: slide_text)
4. step_id=4: slide_generator -> create slide files (expected_output: file_urls)

Executor runs each step, validating schemas. If web_search returns low-confidence sources flagged by safety constraints, Planner is notified and revises to request only .gov/.edu/.org domains.

Closing: Key takeaways and next steps

• Planner–Executor = control + clarity. You get safer, more auditable, and more debuggable agentic workflows.
• Use parameter schemas everywhere. Executors live and die by schemas — you built those earlier for a reason.
• Always have a validator. Safety constraints should be enforced both at planning time and execution time.

Homework (for the curious engineer):

1. Build a tiny Planner that outputs 3-step plans for file-processing tasks.
2. Implement a simple Executor that consumes one step and calls a mocked tool with strict schema checks.
3. Add a Validator to reject tool calls that handle sensitive terms (PII). Log and iterate.

Final flourish: The Planner–Executor split doesn't just make your agents better — it forces you to think like an engineer and a policy-maker simultaneously. Which, yes, is exhausting, but also the only way to keep the AI from freelancing.

Version notes: This lesson builds on the earlier modules on Tool Selection Prompts and Parameter Schema Design, and continues the emphasis on Safety, Ethics, and Risk Mitigation: the Planner must list constraints up-front and the Executor must validate against schemas to prevent harm and hallucination.