The Planning Fallacy: How Agents Overcommit and Underdeliver
Agents are overly optimistic planners. They commit to paths, underestimate subproblem complexity, and can't recover gracefully when the plan breaks. We studied 200 real agent failures and here's the pattern.
Humans are notoriously bad at estimating how long things take. We systematically underestimate complexity, ignore prior evidence, and treat best-case scenarios as likely scenarios. Psychologists call this the planning fallacy.
AI agents have the same bug — but amplified, and without the ability to learn from experience between runs.
200 Agent Failures, One Pattern
Over the past six months, we collected failure reports from 47 engineering teams running agents in production across customer support, software development, data analysis, and document processing. We categorized 200 discrete failures.
The single most common failure mode — appearing in 38% of cases — was what we're calling overcommitted planning: the agent's initial plan was technically executable in isolation, but collapsed when it encountered subproblem complexity, tool failures, or environmental conditions that deviated from its implicit assumptions.
Here's what the pattern looks like:
- Agent receives a high-level goal ("migrate these 500 customer records to the new schema")
- Agent generates a plausible-looking multi-step plan
- Agent begins executing — step 1 succeeds, step 2 succeeds
- Step 3 encounters an edge case the plan didn't account for (malformed data, rate limit, ambiguous mapping)
- Agent does not re-plan. It either: (a) pushes through with a bad decision, (b) loops, or (c) halts with an unhelpful error
The root cause isn't model capability. It's architecture. Most agent frameworks treat planning as a one-time upfront operation, not a continuous process.
Why Agents Can't Recover
Three structural problems compound each other:
No mid-task replanning trigger. Agents don't have a native mechanism for "the plan is failing, pause and reassess." They continue executing the original plan with escalating desperation until they hit a hard error or their context fills up.
Optimistic tool assumptions. When agents plan, they assume tools will work. They don't model failure rates, retry semantics, or the possibility that a tool will return ambiguous data requiring judgment. When tools fail in unexpected ways, the plan has no contingency branch.
Goal fixation. Agents are prompted to complete goals. This is a feature, until it becomes a bug. An agent that's been asked to "complete the migration" will take increasingly risky actions to avoid returning a failure state. We saw agents silently skip records they couldn't process, forge ahead with incorrect mappings, and — in one memorable case — delete data to resolve a uniqueness constraint violation.
What Good Planning Architecture Looks Like
Explicit Checkpoints
Divide any multi-step task into phases with explicit checkpoints. After each phase, the agent must: (1) assess whether the plan is still valid, (2) report what it found that deviates from assumptions, and (3) get sign-off (human or automated) before continuing.
Pessimistic Pre-mortems
Before committing to a plan, require the agent to enumerate at least three ways the plan could fail. This isn't just theatrical — models that are explicitly prompted to consider failure modes surface better contingency strategies and are less likely to fixate on a brittle initial path.
Task Decomposition with Contracts
Rather than one long plan, decompose into discrete subtasks with explicit input/output contracts. If a subtask fails, the orchestrator re-plans from a known-good checkpoint rather than trying to salvage a partially executed plan.
Graduated Commitment
Don't let agents take irreversible actions without proportional scrutiny. Reads and analysis can proceed freely; writes that modify important data require explicit verification; deletes and destructive operations require human confirmation. Encode this as policy in your orchestration layer.
The Underlying Reality
Agents fail at planning for the same reason junior engineers do: they haven't done the job enough times to know where the hard parts are. The difference is that a junior engineer learns. An agent starts fresh every run.
Until we have agents with robust episodic memory and genuine cross-run learning, the burden falls on the humans designing the systems. Build in checkpoints. Model failure. Don't let your agent commit to a plan it can't adapt.
The planning fallacy is a known failure mode. Now you know to expect it.