TL;DR for devs
- Start from the task, not from a popular reasoning pattern.
- Use a fixed workflow for predictable steps; consider model-generated plans when tasks vary.
- Other patterns: plan then execute, ReAct-style tool use, routing to specialists, parallel work, and draft-evaluate-revise.
- A plan is a proposal, not a guarantee, so validate actions and results.
- Set stopping conditions (max steps, time limits) and let code handle exact arithmetic and rules.
Fixed workflows, plan-then-execute, ReAct, routing, parallel work and draft-evaluate-revise
Ask an AI assistant to “research three project management tools, compare their pricing, and recommend one for a five-person team.” A one-sentence answer may sound confident, but the task involves several pieces: identify suitable products, find current pricing, compare plans, consider the team’s needs, and present a recommendation with caveats.
This is where planning patterns can help. They give an agent a structure for turning a goal into manageable steps. They can also make an application easier to debug: you can see what steps were attempted, what information was used, and where the process failed.
Planning does not make an agent infallible. A model may misunderstand the goal, skip an important step, or rely on poor data. Developers need to choose a pattern that fits the task and add checks around tools and outputs. In this beginner-friendly guide, we’ll cover practical reasoning patterns, use a research example, and show a simple Python approach to a predictable plan.
What Is Planning in an AI Agent?
Planning is the process of deciding what actions may be needed to reach a goal. An agent may decompose a request into subtasks, select tools, gather results, and decide whether it has enough information to finish.
For a research task, a plan might be:
- Identify the team’s requirements from the user’s request.
- Find three candidate products.
- Visit or query reliable sources for current pricing.
- Compare plans that support five users.
- Summarize trade-offs and state what could not be verified.
This plan is useful because it exposes the work behind the final recommendation. It also gives developers opportunities to validate inputs and constrain the agent. The system can require that pricing come from a source and include an “as of” date, for example.
The OpenAI guide to building agents describes orchestration as handling multiple steps, tool use, handoffs, guardrails, and context. Anthropic’s Building Effective Agents distinguishes predefined workflows from more flexible agents. That distinction matters: not every task needs a model to invent its own sequence.
Start With the Task, Not a Reasoning Trend
A common mistake is to choose a popular pattern first and then try to fit a problem into it. Start by examining the task:
- Are the steps predictable?
- Does the next step depend on information returned by the previous one?
- Can independent parts run at the same time?
- What mistakes would matter most?
- Does a human need to approve the outcome?
- How will the system know it is finished?
If the steps are fixed, ordinary code may be the best planner. For example, an invoice-processing workflow could validate the invoice, retrieve the supplier record, check required fields, and route it for review in a fixed order. A model could help extract information from the document, but the application can control the sequence.
Use a model-driven plan when the request varies enough that a fixed path is awkward, or when the agent must adapt based on retrieved information. Keep the model’s options bounded: define available tools, approval rules, and a clear stopping point.
Pattern 1: A Fixed Workflow
A fixed workflow follows steps selected by the developer. It is a strong fit for repeatable processes, such as generating a weekly report or checking an application form.
A report workflow might be:
- Retrieve the latest sales data.
- Calculate totals and percentage changes in code.
- Ask the model to explain the results in plain language.
- Validate the required sections exist.
- Return a draft for review.
The benefit is predictability. If the task always follows the same route, the application can control the order and handle each failure explicitly. The trade-off is flexibility: a fixed workflow may be less convenient when users ask for a task that requires a different sequence.
Pattern 2: Plan, Then Execute
In a plan-and-execute pattern, the model first proposes a series of steps. The application or another model call then carries them out, often with tools. This is useful when tasks vary but can still be decomposed into a list of actions.
For the software comparison, the agent may propose gathering product candidates, retrieving pricing, comparing user limits, and composing a recommendation. The application can inspect the plan before execution. It could reject steps that use unapproved sources, ask for clarification about budget, or require confirmation before creating an account.
A plan is not inherently trustworthy. It may omit a necessary step or include one the application cannot perform. Validate each action against an allowlist and make tool results visible to the final synthesis.
Pattern 3: ReAct-Style Tool Use
A ReAct-style loop alternates between reasoning about the next step and taking an action, such as calling a search tool. The agent observes the result and decides what to do next.
A simplified loop is:
Goal → choose next action → call tool → inspect result → choose another action or provide final answer This can be more adaptive than planning every step up front. If the first search finds that a product has changed its pricing page, the agent can adjust its next query. But the loop can also be less predictable. It may make unnecessary calls or keep searching after it has enough evidence.
For a production system, set limits on iterations, tool types, time, and cost. Log each tool request and result. Define conditions for asking the user a question or handing the task to a person.
Pattern 4: Routing and Specialists
A router classifies a request and sends it to a suitable workflow or specialist. A support system might route billing issues to a billing process and technical questions to a troubleshooting process.
Routing can make instructions clearer and reduce the number of tools available to each path. It can also misclassify requests. Include an “uncertain” route, test borderline examples, and make it easy to hand a case to a human.
Specialists should have a distinct role. If two agents have the same tools and instructions, splitting them may only add complexity. Use specialists when the task genuinely needs different policies, tools, or expertise.
Pattern 5: Parallel Work
Some tasks can be divided into independent subtasks. For example, one process can collect pricing, another can compare collaboration features, and a third can check deployment options. The application can then combine the results.
Parallel work can reduce waiting time or provide multiple perspectives, but it does not guarantee accuracy. The combined output needs a synthesis step that resolves disagreements and checks that sources support claims. Running several copies of a model on the same question can also multiply cost without adding useful diversity.
Use parallelization when the subtasks are genuinely independent and the results can be merged through a clear contract. Keep outputs structured enough for the application to compare.
Pattern 6: Draft, Evaluate, Revise
For tasks where quality can be checked against criteria, an agent can produce a draft, evaluate it, and revise it. A writing assistant might draft a report, check whether every claim has a source, and revise gaps.
This pattern works best when the evaluator has concrete criteria. “Make it better” is vague. “Every pricing claim must include a current source; include at least two trade-offs; mark missing data as unknown” is easier to check.
Even a separate evaluator model can make mistakes. For factual claims, use deterministic checks or verify against source material where possible. Avoid endless critique loops by setting a maximum number of revisions and a fallback when the draft still fails.
A Simple Python Example: A Predictable Research Plan
For a beginner project, you can represent the stages in ordinary Python rather than asking a model to generate an open-ended plan. Here, the research functions are placeholders; a real app would connect them to approved data sources.
from dataclasses import dataclass @dataclass class Product: name: str monthly_price_per_user: float | None source_url: str | None def compare_tools(team_size: int, products: list[Product]) -> list[dict]: if team_size < 1: raise ValueError("team_size must be at least 1") comparisons = [] for product in products: total = ( product.monthly_price_per_user * team_size if product.monthly_price_per_user is not None else None ) comparisons.append({ "name": product.name, "team_monthly_cost": total, "source_url": product.source_url, "price_verified": product.source_url is not None, }) return comparisons The code handles a repeatable calculation, while a model can help interpret the user’s criteria and explain trade-offs. Notice that missing prices remain None instead of being guessed. This is a small example of a useful division of labor: models can help with language and flexible interpretation; ordinary code can perform exact calculations and enforce rules.
Make Plans Observable and Testable
A plan should help the developer understand what happened. Store or trace the steps at a level appropriate to your privacy policy: the selected tool, validated arguments, outcome, and reason for stopping. You do not need to expose private internal reasoning to users to make a system observable. A concise action log can explain that the agent checked three official pricing pages and found one plan without a public price.
Build test cases for:
- Clear requests with enough information.
- Ambiguous goals that should trigger a question.
- Missing or conflicting tool results.
- A tool failure or timeout.
- Unsupported steps in a proposed plan.
- Requests that should require approval.
- Plans that exceed the allowed step limit.
Evaluate the result, not just the plan text. Did the agent use reliable sources? Did it calculate correctly? Did it stop when enough evidence was available? Did it distinguish verified facts from assumptions?
Frequent Planning Mistakes
Overplanning simple tasks
If a task takes one function call, a long agent loop adds latency and failure opportunities. Use a direct call or fixed function when it is enough.
Treating a plan as a guarantee
A plan is a proposal. It can change, fail, or be based on incorrect assumptions. Validate actions and results.
Giving the agent too many choices
A huge tool list makes selection harder and expands the testing surface. Offer only tools relevant to the current task.
Forgetting stopping conditions
Specify maximum steps, time limits, and conditions that trigger a final answer, clarification, or human handoff.
Using a model for exact arithmetic
Let code handle totals, dates, eligibility, and other deterministic rules. The model can explain results but should not be the source of exact calculations when a program can compute them.
Frequently Asked Questions
Does every AI agent need to make a plan?
No. A simple agent may choose a tool and answer in one turn. Planning is useful when a task has multiple steps or dependencies, but it adds overhead and should be used when it improves the outcome.
Is chain-of-thought the same as a plan?
No. A plan is an actionable structure for completing a task. An application can show a concise plan or action summary without exposing private internal reasoning. Focus on observable actions and verifiable results.
Should I use a fixed workflow or a model-generated plan?
Use a fixed workflow when the steps are predictable. Consider a model-generated plan when the task varies and the model needs to choose among bounded options. Many systems combine both.
How do I keep an agent from looping?
Set maximum tool calls, timeouts, and explicit completion conditions. Detect repeated calls where possible and provide a clear fallback when the agent cannot finish.
Can multiple agents improve planning?
They can help when specialists have distinct roles or when independent perspectives are valuable. They also add coordination, latency, and cost. Start with one agent and split only when the workflow benefits from separation.
Conclusion
Planning patterns help an AI agent organize multi-step work, but no single pattern is best for every task. Fixed workflows offer control, plan-and-execute supports flexible decomposition, tool-use loops adapt to new results, and parallel or evaluator patterns can help with independent subtasks and quality checks.
Choose the simplest approach that fits the task. Keep the agent’s tools and decisions bounded, use ordinary code for exact rules, set clear stopping conditions, and evaluate the full outcome. A useful plan is not the one that looks most sophisticated; it is the one that reliably helps the system reach a verifiable result.
References
I write about building AI agents and full-stack AI apps. Follow me for the next one, and tell me in the comments: Which planning pattern does your current agent use, and is it more complex than the task needs?
