Most UK service businesses building AI agents make the same expensive mistake: they run every task through the same frontier model. Drafting a client email, processing an invoice, summarising a call transcript, and making a complex analytical judgement — all handled by Claude Opus or GPT-4 at full price. The result is AI bills that grow faster than the value delivered. The planner-executor pattern fixes this. It separates the work that genuinely requires a powerful model from the work that does not — and the economics shift dramatically when you do.
Why Single-Model AI Agents Hit a Cost Wall
When UK businesses first build AI agents, the instinct is to reach for the most capable model available. That instinct is understandable: the best model produces the best output, so surely you use it for everything. In practice, this is the wrong call — not because powerful models produce bad output, but because they are dramatically over-specified for the majority of tasks agents handle.
Consider the task mix of a typical UK consulting firm's AI operating system. In a given week, its agents might handle:
- Classifying 200 incoming emails by type (enquiry, invoice, client question, marketing)
- Extracting 40 line items from supplier invoices into a structured format
- Summarising 15 meeting transcripts into bullet-point action lists
- Drafting 8 client-facing proposal sections that need to match tone, context, and relationship history
- Analysing pipeline data and making a strategic recommendation on which leads to prioritise
The first three tasks — classification, extraction, summarisation — are pattern-matching operations. They require linguistic competence, not deep reasoning. A model one or two tiers below the frontier handles them at 95% of the quality, at 10–20% of the cost, and with significantly lower latency. The last two — proposal drafting with relationship context and strategic pipeline analysis — genuinely benefit from a frontier model's reasoning depth.
A single-model architecture treats all five the same. A planner-executor architecture treats them differently — and that distinction is where the economics change.
A well-designed routing layer cuts LLM costs 30–70% without any reduction in output quality. The saving does not come from doing less. It comes from matching capability to task complexity.
Research published in 2026 tracking 542 live AI agent deployments found that fewer than 8% of production agent tasks require frontier-model reasoning to be completed correctly. The remaining 92% can be handled adequately by smaller, faster, cheaper models. That 92% is where single-model architectures bleed money.
How the Planner-Executor Pattern Works
The planner-executor pattern divides agent work into two distinct layers with a clear boundary between them.
The Planner. A single, capable orchestrator model — typically a frontier model like Claude Sonnet or GPT-4o — receives the incoming task and decides how to handle it. It does not execute the work itself. Instead, it breaks the task into subtasks, classifies each subtask by complexity, selects the appropriate executor for each, and sequences the execution order. For tasks that require its own full reasoning capability, it handles them directly. For everything else, it delegates.
The planner's output is a structured execution plan: a list of subtasks with assigned executors, the data each executor needs, the expected output format, and the conditions under which a subtask result should be escalated back to the planner for review. This plan is passed to the execution layer.
The Executors. A pool of lighter, faster models handles the delegated subtasks. These are purpose-fit: a classification executor, an extraction executor, a summarisation executor, a drafting executor. Each is prompted and configured for its specific task type. They run in parallel where possible, return structured outputs, and escalate to the planner if the task falls outside their defined scope.
The Router. Between the planner and the executors sits a routing layer — in practice, usually a lightweight model or a deterministic classification function — that dispatches subtasks to the correct executor pool and handles retry logic when an executor output fails validation. The router is the engineering layer that makes the system reliable at scale. Without it, you have a planner and executors but no reliable handoff between them.
The result is an AI operating system where the expensive frontier model spends its time on the tasks that actually justify its capability — orchestration, complex reasoning, and quality control — while the bulk of execution work is handled by faster, cheaper models that are entirely sufficient for what they are asked to do.
Building the Pattern in n8n and Claude
The planner-executor pattern is not a theoretical architecture. It is buildable today in n8n with Claude and a mix of models from the same or different providers. Here is how the build works in practice.
Step 1: Define your task taxonomy. List every task your AI operating system handles. For each, score it on two dimensions: reasoning depth required (1–5) and output stakes (1–5, where 5 means the output goes directly to a client). Tasks scoring 4–5 on reasoning depth belong with the planner. Tasks scoring 1–3 on reasoning depth are executor candidates. High-stakes tasks, regardless of complexity, get a human review step — use the human-in-the-loop pattern for these.
Step 2: Build the planner node. In n8n, this is an AI Agent node configured with Claude Sonnet (or equivalent frontier model) and a system prompt that instructs it to: receive the incoming task, output a JSON execution plan with subtask definitions, assigned executor types, required inputs for each subtask, and expected output schemas. The planner does not call tools directly — it produces a structured plan that the workflow parses.
Step 3: Build the router. An n8n Switch node reads the planner's execution plan and routes each subtask to the correct executor sub-workflow. For simple classification-by-type routing, a deterministic switch on the executor_type field is sufficient. For more nuanced routing — where the correct executor depends on input characteristics rather than predefined categories — use a lightweight classification model as the router. The routing decision should be deterministic and fast; this is not a place for expensive reasoning.
Step 4: Build executor sub-workflows. Each executor is a self-contained n8n sub-workflow with its own model configuration, system prompt, and input/output schema validation. Use structured outputs for every executor — if the output does not match the expected schema, the executor should retry once, then escalate to the planner. Executor models are typically Claude Haiku, GPT-4o-mini, or an open-source model running locally. For extraction and classification tasks, open-source models are often sufficient and cost essentially nothing to run at the volumes a UK service firm generates.
Step 5: Wire the aggregator. Once all executors have completed their subtasks, an aggregator node assembles the results according to the planner's sequencing instructions. For sequential tasks — where executor B needs executor A's output — the aggregator manages the dependency chain. For parallel tasks, it merges results once all are returned. The aggregator sends the assembled output back to the planner for a final quality check if the overall task is client-facing.
The full build, including all executor sub-workflows and the routing layer, typically takes four to six weeks for a five-to-fifteen task operating system. The evaluation framework should be applied after the first two weeks to baseline performance before the pattern is fully operational.
The Real Cost Numbers
The cost case for the planner-executor pattern is straightforward when you run the numbers on a real workload.
Take a seven-person management consultancy processing the following monthly agent workload:
- 1,800 emails classified and prioritised
- 240 meeting transcripts summarised into action lists
- 120 supplier invoices extracted into structured data
- 60 client proposal sections drafted
- 18 strategic research briefs generated
Single-model architecture cost (Claude Sonnet for all tasks): approximately £380–420 per month in API tokens at current pricing, based on average token usage per task type across the full workload.
Planner-executor architecture cost: the planner (Claude Sonnet) handles proposal drafting, research briefs, and quality control passes — roughly 20% of the token volume. Executors (Claude Haiku or equivalent) handle email classification, transcription summarisation, and invoice extraction — 80% of the volume at approximately 15% of the cost per token. Total: approximately £95–120 per month. A reduction of 70–75% on the API bill, with no measurable quality difference on the high-volume extraction and classification tasks.
At a growing firm, this is not a marginal saving. As agent task volume scales with client growth — more emails, more meetings, more documents — the single-model cost scales linearly. The planner-executor cost scales the cheap layer, not the expensive one. The cost curve bends in your favour at exactly the point where agent activity is generating the most value.
The three-pillar cost framework from earlier in this series — Cache, Route, Compress — operates at the token level. The planner-executor pattern operates at the architectural level. They compound: applying both to the same system can reduce LLM spend by 85–90% compared to an unconfigured single-model baseline.
When NOT to Use This Pattern
The planner-executor pattern is not always the right choice. There are three scenarios where it adds complexity without proportionate return.
Low-volume, low-frequency agent systems. If your AI operating system handles fewer than 50 agent tasks per day, the overhead of building and maintaining the routing layer and multiple executor sub-workflows is not justified by the token savings. At low volume, a single, well-configured model with clear prompts is simpler to build, easier to debug, and cheaper than the engineering investment required to implement proper routing. Apply the pattern when your agent task volume is growing, not to optimise a system that is already small.
Tasks that require consistent voice across all outputs. Some agent workloads — particularly those producing long-form client-facing documents — benefit from the stylistic consistency that comes from a single model handling the full output. If you split drafting across a planner model and an executor model, the prose can feel inconsistent in ways that require additional editing. For these workloads, use the planner for structure and planning, but pass the full draft back to the frontier model for a single consistent voice pass at the end.
Early-stage operating systems without stable task definitions. The planner-executor pattern requires you to know, in advance, what your task types are and how to classify them. If your operating system is still being defined — new tasks being added weekly, edge cases appearing regularly — the routing layer becomes a maintenance burden rather than a structural asset. Build the multi-agent orchestration foundation first, stabilise your task taxonomy over two to three months of production use, and then introduce the planner-executor separation once you understand what you are routing between.
The Architecture That Scales With Your Business
The pattern's real advantage is not the immediate cost saving. It is the architecture it creates for scaling.
A single-model AI operating system has one dial: you can make the model better or cheaper, but the structure is flat. Every task goes through the same node, and every change to that node affects every task. Debugging is harder. Iteration is slower. Adding a new task type means updating the single system prompt and hoping the new instructions do not interfere with the existing ones.
A planner-executor system is modular. Adding a new task type means adding a new executor sub-workflow — scoped, isolated, independently testable. Changing how a specific task is handled means modifying one executor without touching the others. Performance issues are localised: if the invoice extraction executor is producing errors, you debug that executor in isolation without disrupting email classification or proposal drafting. The system degrades gracefully and improves incrementally rather than requiring full-system changes for every update.
This is how the compounding AI advantage operates at the engineering layer. Each executor you add, tune, and stabilise becomes a permanent asset. The routing intelligence in the planner improves as you add more task types and the planner develops a richer model of what belongs where. After twelve months of operation, a planner-executor system is meaningfully smarter and more efficient than it was at launch — not because the underlying models changed, but because the architecture was built to improve through use.
If you want to assess whether your current agent architecture would benefit from the planner-executor separation — or whether your task volume and taxonomy are ready for the build — book a free 30-minute call. We will map your current task types, estimate the routing logic required, and give you a clear view of the cost and quality case for your specific operating system.