10 patterns for this goal
Agents often need to break complex tasks into subtasks, order the steps, and adapt plans when conditions change. Planning-and-decomposition failures occur when agents create invalid plans (missing steps, circular dependencies), hallucinate steps that don’t exist, fail to adapt when circumstances invalidate the plan, or execute subgoals in the wrong order, resulting in wasted effort, impossible tasks, or cascading downstream failures.
Plan Hallucination Is Plausible but Wrong: Agents can generate plans that sound reasonable (all subtasks are listed, logic appears sound) but are fundamentally unachievable or omit critical steps. The agent has no way to validate that a plan is executable without actually attempting it.
Circular Dependencies in Plans Cause Infinite Loops: A plan that requires subtask A to complete before B, and B to complete before A, is circular. The agent may execute indefinitely or timeout without recognizing the cycle. Circular plans must be detected at plan-generation time, not at execution time.
Cost Estimation in Plans Is Wildly Inaccurate: Agents estimate that a plan will cost X tokens or take Y seconds, but execution costs 10x more or takes 100x longer. Plans that looked reasonable based on estimated cost are infeasible under actual costs.
Plan Invalidation Is Silent: Circumstances change (a dependency is no longer available, a constraint is now impossible), but the agent is executing a plan based on old assumptions. Plan invalidation detection requires continuous re-evaluation of preconditions and constraints during execution.
Planning-and-decomposition failures cluster into five categories:
Complex Multi-Step Tasks: Tasks that require ordering (task A must complete before task B), or conditional logic (if X, then do Y, else do Z). Poor planning leads to wasted effort and impossible tasks.
Resource-Constrained Agents: Agents with limited budget (tokens, time, compute). Poor cost estimation causes plans to exceed budget mid-execution.
Dynamic, Changing Environments: Systems where assumptions can be invalidated (a service goes down, a dependency changes). Plans must detect and adapt to changed conditions.
Planning and decomposition is fundamentally about executing complex tasks without actually doing all the work beforehand. An agent can’t feasibly try all possible plans and measure which is best; it must decompose the task, estimate what will work, and execute. But estimates are often wrong, hallucination is common, and environments change. Robust planning requires: (1) validating generated plans for structural soundness (no circular dependencies, required steps are present); (2) continuously re-evaluating plan preconditions during execution (is dependency X still available?); (3) detecting when cost estimates are wildly off (if spent tokens exceed 3x estimated, abort and replan); (4) having a fallback plan or contingency (if plan A fails, what’s plan B?); and (5) regular testing of failure scenarios (chaos engineering for planning). Without these, agents execute plans that are hallucinated, circular, or invalidated, wasting resources and failing to make progress.
How can an agent validate that a generated plan is achievable before executing it? Run a simplified version of the plan to check for obvious failures (circular dependencies, missing preconditions). Use domain-specific validators if available. Estimate the cost to execute the plan; if cost is very high, ask a human or fallback to a simpler plan. Don’t just trust that a plausible-sounding plan is achievable; validate.
What should an agent do if a plan’s cost estimation is wildly wrong (estimated 10 tokens, actually 100)? Detect the divergence early: after the first few steps, measure actual cost vs. estimated cost. If actual cost is >3x estimate, abort the plan and replan. Don’t continue executing a plan that’s proven its estimates wrong; you’ll waste resources trying to complete an infeasible plan.
How can an agent detect that plan preconditions have become invalid? Before each subgoal, re-check the preconditions that were assumed when the plan was generated. For example, if the plan assumed “API X is available,” check that API X is still available before executing a step that depends on it. If a precondition is no longer true, abort or replan.
What is the difference between plan backtracking and plan adaptation? Backtracking: the agent realizes a subgoal failed and returns to a previous step to try a different path. Adaptation: the agent detects that the original plan is no longer achievable (due to changed circumstances) and creates a new plan. Backtracking is recovery within a single plan; adaptation is changing strategies.
Can an agent avoid circular dependencies in plans entirely? Through validation: after generating a plan, construct the dependency graph and check for cycles using standard graph algorithms. If cycles are detected, the plan is invalid and should be rejected before execution. This check must happen before execution, not during.
| Pattern | Description |
|---|---|
| Contingency Plan Missing | Agent has a primary plan but no contingency if the primary fails; when primary fails, agent is stuck. |
| Plan Adaptability Failure | Plan becomes invalid (dependencies no longer available, constraints infeasible); agent doesn’t adapt and continues with invalid plan. |
| Plan Backtracking Failure | Agent needs to backtrack to a previous step after a failed subgoal; backtracking logic fails or leaves state inconsistent. |
| Plan Cost Estimation Failure | Estimated cost to execute plan is wildly inaccurate; plan exceeds budget mid-execution. |
| Plan Dependency Cycle | Plan contains a circular dependency (A must complete before B, B must complete before A); impossible to execute. |
| Plan Hallucination Detection Failure | Plan contains hallucinated steps (steps agent generated but can’t actually execute); agent doesn’t detect and attempts to execute. |
| Plan Invalidation Not Detected | Circumstances change during execution, invalidating plan preconditions; agent continues with invalidated plan. |
| Plan Optimization Pathological | Optimization to improve plan actually makes it worse (slower, more expensive, or infeasible). |
| Plan Parallelization Error | Agent parallelizes subgoals that have undetected dependencies; parallel execution violates the dependencies. |
| Subgoal Ordering Error | Agent executes subgoals in wrong order, violating explicit or implicit dependencies. |
Total: 10 patterns
An agent generates a plan as a single linear sequence of steps with no fallback for what to do if a given step fails, returns an unexpected result, or becomes unavailable. When the primary path breaks partway through execution, the agent has no pre-defined alternative to fall back to and either halts entirely, retries the same failing step indefinitely, or improvises an ungrounded workaround on the spot with no guardrails.
An agent commits to a plan generated at the start of a task and continues executing it step by step even after circumstances relevant to the plan have visibly changed mid-execution — new information arrives, an assumption the plan relied on turns out false, or the user's actual need shifts. Rather than re-planning or adjusting, the agent treats the original plan as fixed, executing later steps that no longer make sense given what's now known.
When a branch of a plan fails or turns out to be a dead end, the agent needs to cleanly undo whatever partial side effects that branch caused and return to a known-good state before trying an alternative. Many agents lack this capability: they either can't identify which prior actions need to be reversed, leave partial side effects in place while proceeding down a new branch, or attempt an undo that itself only partially succeeds, leaving the system in a state that matches neither the old branch nor the new one.
An agent estimates the time, money, compute, or API-call cost a plan will require before executing it, but the estimate is badly wrong — often by an order of magnitude — because the estimation step relies on a shallow heuristic (counting plan steps, or a flat per-step assumption) rather than reasoning about the actual work each step entails. Downstream systems that make decisions based on that estimate (budget approval, scheduling, user-facing time expectations) are then working from a number that bears little relation to reality.
When a planner decomposes a task into subtasks, it sometimes produces a set of dependencies where subtask A requires subtask B to complete first, B requires C, and C requires A — a circular dependency that has no valid execution order. Because the planner reasons about each dependency relationship locally (does this subtask need that one) rather than validating the full dependency graph globally, the cycle isn't caught at planning time, and the executor discovers the plan is structurally unexecutable only when it tries to find a starting point.
The planning step generates a plan that references a tool, API endpoint, file, or capability that does not actually exist — invented because it sounds plausible given the task description, not because the planner verified it against the real set of available tools. Because there is no validation step checking each planned action against the actual tool registry before execution begins, the hallucinated step isn't caught until the executor tries to invoke it and fails, or worse, silently matches it to the wrong real tool with a similar name.
While an agent is mid-execution on a multi-step plan, something in the external world changes in a way that invalidates the plan's premise — a price changes, an item goes out of stock, a policy is updated, a file the plan depends on is deleted — but the agent has no mechanism actively watching for such changes and keeps executing the now-invalid plan exactly as originally generated. Unlike a step that fails outright, an invalidated plan often continues to execute "successfully" step by step, since none of the individual actions error out; the plan simply no longer serves its original purpose.
A planner explicitly optimizes a plan against a proxy objective — fewest steps, lowest estimated cost, fewest tool calls, shortest estimated time — and produces a plan that scores well on that objective while being degenerate, unsafe, or nonsensical with respect to the actual goal. Because the optimization process only sees the proxy metric, it finds and exploits shortcuts the metric doesn't penalize: merging steps that shouldn't be merged, batching a destructive action to save a round trip, or looping a cheap no-op action because it locally minimizes the objective function per unit of apparent progress. The plan is technically "optimal" and structurally valid, but pursuing the metric has traded away something the metric didn't capture.
A planner, in an effort to reduce total execution time, marks two or more subtasks as safe to run in parallel because they don't appear to reference each other's stated inputs or outputs. In reality, the subtasks share a hidden data or resource dependency — one writes to a location the other reads from, both mutate the same underlying state, or one's precondition is silently established by the other's side effect — and the planner's dependency analysis wasn't deep enough to catch it. The plan itself contains no cycle and looks well-formed; the error is a misclassification made at planning time, before execution, that only manifests as a race condition once the two branches actually run concurrently.
A planner decomposes a task into subgoals whose dependency graph is acyclic and individually valid, but sequences those subgoals in the wrong relative order because it reasoned about each subgoal's readiness or priority in isolation rather than against a complete precedence model. Unlike a circular dependency, there is a valid execution order available — the planner simply didn't pick it, instead ordering subgoals by something like generation order, apparent urgency, or estimated ease, and only implicitly (and incorrectly) assuming that order also respects real-world preconditions between subgoals that were never captured as an explicit dependency edge.