AI Agent Planning: How AI Agents Break Goals into Executable Steps

LongDS-Bench, a May 2026 benchmark based on real-world Kaggle notebooks, found that AI agents struggled most as analytical tasks stretched across multiple turns. The finding points to a practical problem in agent planning: an agent can generate next steps without preserving the analytical state needed to complete the larger goal.

The tasks in the study required agents to maintain intermediate results, revise earlier work, combine evolving analytical states and carry dependencies from one step to the next. The best-performing model reached 48.45% average accuracy, with performance dropping nearly 47 points from early to late turns.

For enterprise teams, this problem is familiar. A business user might ask one question, but the work behind the answer often involves several smaller decisions: which metric definition applies, which data source is authoritative, which tool should run first, which intermediate result should constrain the next step and when the agent should revise its approach. Complex goals fail when an agent moves through those decisions without a plan.

Effective agent planning turns a high-level goal into ordered subtasks, maps those subtasks to tools or actions and gives the agent a way to update the plan as new information arrives.

Agent planning is the process an AI agent uses to decompose a goal into ordered subtasks, select tools, perform each step and revise the plan as it learns from intermediate results.

An agent might retrieve documents, query data, call an API, inspect metadata, ask for clarification or use a tool to complete part of a task. Planning is the control layer that organizes those actions into a goal-directed sequence designed to complete the task successfully.

At a basic level, the planning loop follows a repeated pattern:

1. Decompose the goal into smaller steps.
2. Sequence the steps based on dependencies.
3. Select the right tool or action for each step.
4. Perform the work.
5. Inspect the result.
6. Replan when the result changes the path forward.

Arun Agarwal, Principal Product Marketing Manager, AI/ML at Snowflake, describes agent planning as a question of both sequence and judgment: “Did it use the right tools in the right order? Did it ask the right follow-up questions to elicit information? Proactively gathering what it needs, from the user or from the systems it works with, is what sets agents apart.”

Optimizing this loop is especially important for long-horizon tasks, where the correct answer depends on decisions made across several steps. An agent investigating a data anomaly, for example, may need to identify the affected metric, inspect recent pipeline changes, compare historical patterns, retrieve business context and summarize the likely cause. Each step depends on the previous one. If the agent starts with the wrong assumption or skips a dependency, the final answer can still sound coherent while resting on the wrong work.

Planning helps reduce that risk by making the task structure explicit. Instead of treating each action as an isolated next move, the agent works against a plan that reflects the larger goal, the current state of the task and the constraints around the available tools.

Task decomposition is the core mechanism behind agent planning. The agent breaks a high-level goal into smaller subtasks until each one maps to a specific action, tool call or decision point.

For a simple request, decomposition may be almost invisible. If a user asks an agent to summarize a document, the plan might involve retrieving the document, extracting the relevant sections and producing a concise summary.

For a more complex request, the task has to be divided more carefully. A request such as “Explain why customer churn increased last quarter” could require the agent to identify the approved churn definition, query customer status data, compare cohorts, inspect changes in support tickets or product usage and distinguish correlation from likely cause.

In some systems, those steps are implemented through prompt chaining, where the output of one model call becomes the input to the next, so each stage can carry forward the context needed for the next decision.

Agents can be prompted or architected for decomposition in several ways:

Zero-shot planning

With zero-shot planning, the agent receives a goal and generates a plan without examples. This approach is simple to implement and useful for general tasks, but the quality of the plan depends heavily on the model’s ability to infer the right structure from the request alone.

Few-shot planning

With few-shot planning, the prompt includes examples of strong plans. Those examples give the model a pattern to follow, such as how to break a business question into data retrieval, validation, analysis and synthesis steps. Few-shot planning is often useful when agents need to follow a repeatable style of work across similar tasks.

LLM-as-planner

With an LLM-as-planner approach, one model or component is responsible for creating the plan, while another carries out the steps. This separation gives teams more control over the plan itself. The planning layer can be inspected, evaluated and adjusted without treating the full agent run as a black box.

The plan representation also affects outcomes. A linear plan works when steps happen in a fixed order. A hierarchical plan is useful when a goal contains subgoals that need their own smaller plans. A directed acyclic graph (DAG) is better suited to work with branching dependencies or parallelizable steps, such as retrieving data from several sources before combining the results.

For enterprise agents, decomposition has to account for state. After each step, the agent needs to preserve what happened: which data was retrieved, which tool was used, which assumptions were confirmed and which results changed the task. Replanning starts when the current state no longer matches the original plan. If a query returns incomplete data, if a policy prevents access or if a metric definition conflicts with the user’s wording, the agent needs a way to adjust the path instead of continuing as if the original plan still applies.

Different agent planning patterns organize the relationship between planning, tool use and revision in different ways. The best pattern choice depends on the task, the acceptable level of flexibility and the need for predictability.

Plan-and-execute

In a plan-and-execute pattern, the agent creates the full plan before performing the work. The plan defines the major steps, the likely tools and the expected order of operations.

This pattern is useful for long-horizon tasks that benefit from structure up front. If an agent has to investigate a pipeline issue, reconcile data across systems or answer a complex analytical question, a full plan gives the system a stable path to follow. It also makes the work easier to inspect because the planned sequence exists before the agent starts acting.

The trade-off is flexibility. If the task changes significantly after the first few steps, the agent needs explicit replanning logic. Otherwise, it may continue following a plan that no longer reflects the state of the work.

ReAct

ReAct, short for reasoning and acting, interleaves reasoning steps with actions. Instead of relying only on a full upfront plan, the agent decides what to do next, takes an action, observes the result and uses that result to guide the next step.

This pattern works well for tasks where the agent needs to adapt as information arrives. For example, an agent answering a support or analytics question may not know which source is relevant until it retrieves the first piece of context. ReAct gives the agent a way to move through the task one step at a time while keeping each action tied to the current observation.

Because ReAct is flexible, it also needs guardrails. Without constraints on tool selection, state management and stopping criteria, the agent can spend too many steps exploring paths that do not improve the answer.

Reflection and Reflexion

Reflection patterns ask the agent to critique its own work before returning a final answer or moving to the next step. In Reflexion-style approaches, the agent uses feedback from previous attempts to revise its plan or improve later runs.

This pattern is useful when the first answer is likely to need review. An agent might check whether it answered the user’s actual question, whether it used the right data source or whether it missed a required constraint. In analytical work, reflection can also help the agent compare its conclusion against intermediate evidence before producing a final response.

Reflection doesn’t replace evaluation, however. An agent grading its own work inherits its own blind spots, so production systems pair reflection with external checks: reference answers, policy rules and task-specific rubrics, along with trace inspection to see how the agent actually got there. As Agarwal says, “You want to evaluate whether the goal was met, and whether it was met without unnecessary turns.”

Tree-of-Thoughts

Tree-of-Thoughts expands planning by allowing the agent to explore multiple possible reasoning paths before committing to one. Instead of moving through a single linear path, the agent considers several branches, evaluates them and chooses the most promising direction.

Tree-of-Thoughts is useful for tasks with ambiguous strategies or several plausible solution paths. In data analysis, an agent might compare different hypotheses for a metric change before deciding which one to investigate first. In planning-heavy tasks, branch exploration can improve the chances that the agent selects a useful path.

The cost is higher complexity. Exploring multiple branches can increase latency and tool usage, so this pattern is usually better suited to high-value tasks where better planning justifies the additional work.

Planner-executor split

In a planner-executor architecture, one component creates the plan and another performs the steps. The planner focuses on decomposition, sequencing and tool selection. The executor carries out the actions, observes results and returns state updates.

This split gives engineering teams clearer control points. The planner’s output can be inspected before tools run. The executor can be constrained to approved tools. Evaluation can measure whether failures came from the plan, the execution step or the final synthesis.

For enterprise AI agents, this separation is often helpful because the agent is working near governed data and business systems. The system needs to know not only whether the final answer was useful, but how the agent decided what to do.

Enterprise agents need plans that respect the data, permissions and business context around the task. For a data agent, the task is rarely just generating a fluent answer. The agent has to work through governed sources, semantic definitions, access controls and intermediate results without losing the thread of the original request.

Snowflake Cortex Agents are designed to plan and perform work within Snowflake’s governed environment, bringing agentic reasoning to enterprise data while preserving the access controls that determine what data each user can use. That architecture is important for analytical and operational tasks because the planning layer can use context from the environment where the work already happens.

In a Snowflake internal experiment, adding a plain-text data ontology — including join keys, table grains and cardinality or fanout hints — was associated with a 20% improvement in final-answer accuracy, approximately 39% fewer average tool calls and approximately 20% lower end-to-end latency relative to the baseline used in that experiment.

The result is a good reminder that planning quality is tied to context quality. An agent can’t reliably choose the right next step if it lacks the definitions, relationships, constraints and provenance needed to understand the task. With governed context available to the agent, planning can become more efficient because the system has better information about which objects to use, which relationships are valid and which steps are required before an answer is ready.

Planning also connects directly to agent evaluation and agent orchestration. Evaluation helps teams inspect whether the plan, tool choices and intermediate steps advanced the task. Orchestration coordinates how the plan runs across tools, systems or multiple agents. Together, these layers determine whether an agent can complete multi-step work in a way that is accurate, efficient and consistent with enterprise governance.