A Canadian agency called Kaxo Technologies ran 4 Claude Code agents for their SMB clients. The bill was $6,500 a year. Then they restructured: one Sonnet orchestrator planning the work, 34 Haiku sub-agents executing it. The new bill: $500 a year. Same output quality. 92% cost reduction.

This isn't a trick. It's an architecture pattern called plan-and-execute, and it's becoming the default way production agent systems get built.

The Pattern in 30 Seconds

You use an expensive, capable model (Opus, Sonnet, GPT-4o) for one thing: deciding what to do. It breaks a complex task into discrete steps, identifies dependencies, and produces a structured plan.

Then you hand each step to a cheap, fast model (Haiku, GPT-4o Mini, Gemini Flash). These models execute bounded tasks with clear inputs and expected outputs. They don't need to reason about the big picture. They just need to follow instructions.

The economics are straightforward. Planning tokens are typically 10-20% of total tokens in a workflow. If you run 80-90% of your tokens through a model that costs 1/5th to 1/25th as much, the math works out to roughly 85-90% savings.

Current Anthropic pricing makes this concrete:

Opus 4.6: $5 / $25 per million tokens (input/output)
Haiku 4.5: $1 / $5 per million tokens

Your planner burns a small number of expensive tokens thinking hard. Your executors burn a large number of cheap tokens doing the work.

Why This Also Makes Your Agent More Reliable

Cost savings are the obvious win. The less obvious win is reliability, and it matters more.

There's a principle from reliability engineering called Lusser's Law: the probability of a system succeeding equals the product of each component's success probability. For sequential agent steps, this means a 98% per-step success rate across 20 steps gives you 66% end-to-end success. At 95% per step over 10 steps, you're at 60%.

That's why complex agents fail so often. Every step that requires open-ended reasoning is another opportunity for the chain to break.

Plan-and-execute attacks this directly. The planning model handles the hard reasoning once, up front. Each execution step becomes narrow and bounded: clear input, clear expected output, minimal ambiguity. Narrow tasks have higher per-step success rates. Higher per-step rates compound into dramatically better end-to-end reliability.

Gartner projects 40% of agentic AI projects will be canceled by end of 2027, primarily due to escalating costs and inadequate risk controls. The plan-and-execute pattern addresses both failure modes simultaneously.

The Three-Role Variant

Production systems are converging on a refinement: planner-worker-evaluator.

Planner (frontier model): Decomposes the task, sets success criteria for each step
Workers (cheap model): Execute individual steps
Evaluator (cheap model): Checks each worker's output against the planner's criteria before passing results forward

The evaluator is cheap to run and catches most execution errors before they propagate. Anthropic's own multi-agent research system uses this exact structure internally.

Building It: The Orchestration Prompt

Here's where this gets practical. The planner prompt is the highest-leverage piece of the entire system. This is where you spend your expensive tokens, so make them count.

The Planner Prompt:

You are a task planner. Given a user's goal, produce a JSON execution plan.

Each step must have:
- "id": unique step identifier
- "action": one of [search, extract, summarize, format, validate]
- "input": exactly what this step receives (reference prior step IDs for dependencies)
- "output_spec": what a correct result looks like
- "success_criteria": how to verify this step worked
- "depends_on": list of step IDs that must complete first

Rules:
- Each step must be completable by a model with NO context about the overall goal
- Never combine two distinct operations in one step
- Include a validation step after any step that produces user-facing output

User goal: {{goal}}

Respond with only the JSON plan.

Why This Works: The prompt forces the planner to make each step self-contained. The output_spec and success_criteria fields give the evaluator model something concrete to check against. The rule about "no context about the overall goal" prevents steps that require big-picture reasoning from the executor.

Expected Output:

json { "steps": [ { "id": "search_1", "action": "search", "input": "Find the 3 most recent CVEs affecting OpenSSH server versions 9.x", "output_spec": "A list of 3 CVE IDs with severity scores and affected versions", "success_criteria": "Each entry has a valid CVE-YYYY-NNNNN format, a CVSS score, and a version range", "depends_on": [] }, { "id": "extract_1", "action": "extract", "input": "For each CVE from search_1, extract: attack vector, required privileges, patch status", "output_spec": "Structured data with three fields per CVE", "success_criteria": "All three fields populated for all three CVEs", "depends_on": ["search_1"] } ] }

The Executor Prompt

Each executor gets a minimal prompt scoped to its single step. No system-level context. No awareness of other steps.

The Executor Prompt:

Complete this task exactly as specified.

Task: {{step.action}}
Input: {{step.input}}
Expected output format: {{step.output_spec}}

Respond with only the requested output. No preamble, no explanation.

Why This Works: Cheap models perform well on bounded tasks with clear specs. By stripping away context about the broader goal, you reduce the surface area for hallucination and off-topic drift. The executor doesn't need to be smart. It needs to be precise within a narrow scope.

The Evaluator Prompt

The Evaluator Prompt:

You are a quality checker. Evaluate whether this output meets the specified criteria.

Step description: {{step.action}} -- {{step.input}}
Success criteria: {{step.success_criteria}}
Expected format: {{step.output_spec}}

Actual output:
{{executor_output}}

Respond with JSON:
{"pass": true/false, "issues": ["list of specific problems if any"]}

Why This Works: Evaluation is easier than generation. A cheap model can reliably check whether output matches a spec, even when it couldn't have produced that output from scratch. This is the same principle behind how code review is easier than code writing. Running this evaluator on Haiku costs almost nothing and catches the majority of executor errors before they compound.

The Anti-Pattern: Cheap Planning

One documented failure mode deserves a callout. Some teams try to save money by using Haiku or a similarly cheap model for the planning step.

This backfires badly. Poor plans produce ambiguous steps, which cause executor failures, which trigger retries, which double or triple total cost. One analysis found that cheap planning led to 2x implementation iterations compared to using a frontier planner. The $0.50 you save on the planning call costs you $10.00 in failed executions.

The rule is simple: invest in the planner, economize on the executors. Planning is 10-20% of your tokens but determines 100% of your success rate.

When to Collapse the Pattern

Here's the honest take: this pattern might be temporary.

Google DeepMind researchers argue that multi-agent architectures are a workaround for current model limitations, not an enduring design. As base models get cheaper and more capable, the price gap between tiers shrinks and the capability gap narrows. Their research shows accuracy gains from multi-agent setups plateau beyond about 4 agents due to coordination overhead.

The practical implication: build plan-and-execute now because the economics demand it, but design your system so you can collapse the layers later. If your planner and executor are the same model at different price points, swapping them for a single model someday is a config change, not a rewrite.

The Decision Framework

Not every agent needs this pattern. Here's when it pays off:

Use plan-and-execute when: - Your workflow has 5+ sequential steps - Total token volume exceeds 100K tokens per run - Tasks can be decomposed into steps with clear input/output specs - You're running the workflow repeatedly (the planning prompt is a fixed cost you amortize)

Use a single model when: - The task requires continuous reasoning across steps (creative writing, complex debugging) - Your workflow is 2-3 steps with low token volume - The overhead of orchestration code exceeds the cost savings

The Kaxo team put it this way: delegate to the cheap model when the task has clear input/output specs and requires no judgment. Escalate to the frontier model when the task requires pattern recognition or architectural decisions.

That decision tree is the entire pattern in two sentences.

Want hands-on training on building multi-model agent architectures for your team? Connect with Kief Studio on Discord or schedule a session.

LLM orchestration

The Plan-and-Execute Pattern: Use a Frontier Model to Plan, a Cheap Model to Execute