Planning Agents vs Execution Agents

Key facts, with sources

• Gartner predicts over 40 percent of agentic AI projects will be canceled by the end of 2027 due to escalating costs, unclear business value, or inadequate risk controls. (Gartner)
• Gartner predicts 33 percent of enterprise software applications will include agentic AI by 2028, up from less than 1 percent in 2024. (Gartner)
• Gartner estimates only about 130 of the thousands of vendors claiming to sell agentic AI are real, with the rest engaged in agent washing of existing chatbots and RPA products. (MarTech)
• McKinsey's State of AI 2025 found 23 percent of organizations are scaling an agentic AI system somewhere in the enterprise and another 39 percent have begun experimenting with agents. (McKinsey)
• Gartner forecasts 40 percent of enterprise applications will embed task-specific AI agents by the end of 2026, up from under 5 percent in 2025. (Joget)

A planner's output is data, not prose

A planner's output should be a machine-readable artifact. I have the planning call emit a JSON structure: numbered steps, the tool each step needs, and an explicit depends_on list. That shape is what unlocks everything downstream — you can validate that every referenced tool exists, estimate cost from step count, detect cycles, and run independent branches in parallel. Free-text plans ("first I will research, then I will write") give you none of that; they are a narrative, not an artifact.

Structured output enforcement matters here. If the plan is parsed with a regex from prose, the whole pipeline inherits that fragility. I use the API's schema-constrained output so the plan parses every time.

import json
from anthropic import Anthropic

MODEL = "claude-opus-4-8"  # use the latest model id

client = Anthropic()

PLAN_SCHEMA = {
    "type": "object",
    "properties": {
        "steps": {
            "type": "array",
            "items": {
                "type": "object",
                "properties": {
                    "id": {"type": "integer"},
                    "goal": {"type": "string"},
                    "tool": {"type": "string"},
                    "depends_on": {"type": "array", "items": {"type": "integer"}},
                },
                "required": ["id", "goal", "tool", "depends_on"],
                "additionalProperties": False,
            },
        }
    },
    "required": ["steps"],
    "additionalProperties": False,
}

response = client.messages.create(
    model=MODEL,
    max_tokens=2048,
    output_config={"format": {"type": "json_schema", "schema": PLAN_SCHEMA}},
    messages=[{"role": "user", "content": f"Plan the steps to complete: {task}"}],
)
plan = json.loads(response.content[0].text)  # validate tools and cycles before running

What the executor owns

The executor gets one step, a fresh or trimmed context, and only the tools that step declares. Deliberately starving the executor of the full plan is a feature: it cannot wander off and helpfully do step six early, and its context stays small enough that quality does not degrade over a long run. Each execution returns a typed result — success with output, or failure with a reason — that the orchestrating code records against the plan.

The executor is also where retries live. A transient tool failure should be retried at the step level with the error in context, not bubbled up to trigger a full replan. In practice most failures are exactly this kind — a timeout, a malformed query — and step-level retry with feedback resolves the majority without touching the plan.

Why the split earns its complexity

The split pays for itself in four ways. First, a validation gate: code or a human reviews the plan before any side effects, which is the cheapest safety mechanism in agentic systems. Second, cost control: a ten-step plan against known per-step budgets gives an estimate before you spend, and a plan that comes back with forty steps is a signal the request needs scoping, not executing. Third, parallelism: the dependency graph tells you which steps can fan out concurrently, often cutting wall-clock time substantially. Fourth, resumability: when step seven fails at midnight, you restart from step seven, not from zero.

None of this is available when planning stays implicit inside a single loop, because the plan only ever exists inside the model's context.

When a single loop is better

For a task that takes two or three tool calls with tight feedback between them — look something up, act on it, confirm — a separate planner is pure overhead. The single loop is also better when the environment shifts under you: debugging, exploratory data work, anything where the result of step one determines what step two even is. A plan written up front goes stale immediately, and you end up replanning every step, which is just the single loop with extra latency.

My rule of thumb: if I cannot describe the task's steps before starting, neither can the planner — use the loop. If I can sketch the steps on paper and they would survive contact with reality, encode that as a planner and buy the control points.

Replanning: the part everyone forgets

Plans fail in two modes: a step fails, or a step succeeds and reveals the plan was wrong. Handle the first with bounded step retries. The second needs a replan path: feed the completed steps, their outputs, and the failure back to the planner and ask for a revised plan covering the remaining work only. Never replan from scratch — you lose the completed work and often repeat the original mistake.

I version plans and log the diff between plan v1 and v2. Over time those diffs tell you where the planner is systematically naive — usually around data quality and access assumptions — and one paragraph of added planning context fixes entire categories of replanning.

When to hire senior help

Senior help is most valuable at the architecture stage, deciding what to automate, where approval gates belong, and how business value will be measured, before any code is written. It is also worth bringing in when a stalled pilot needs risk controls and evaluation rigor to pass security and compliance review. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships AI — Agentic AI Systems projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Buying agent-washed products, since Gartner estimates only around 130 of thousands of self-described agentic AI vendors are genuine rather than rebranded chatbots or RPA
• ✕Deploying autonomy before defining risk controls and human-approval gates, one of the three causes Gartner cites for the 40 percent of projects it expects to be canceled
• ✕Measuring activity like tasks attempted instead of business value, leaving the project unable to justify escalating costs at renewal time
• ✕Wrapping agents around existing processes instead of redesigning the workflow, when McKinsey finds workflow redesign is the single biggest driver of EBIT impact from gen AI

Frequently asked questions

Sources

• Gartner
• MarTech
• McKinsey
• Joget