How AI Agents Plan Multi-Step Work and Where Plans Fail

AI agents plan by turning a request into a short list of intended steps, then choosing each action in a loop and revising the list as tool results come back. The plan is usually a working note the model rewrites as it goes, not a fixed document agreed in advance, which is why it can drift. Making the plan visible, checkable and bounded is what lets a person supervise it instead of trusting it.

Key takeaways

• An agent's plan is a living outline that changes after every tool result, not a contract it signed at the start.
• Plans fail in a small number of repeatable ways: goal drift, unverified assumptions, skipped steps, stale outlines, lost context and false completion.
• Failures often go unnoticed because the final message reads fluently even when the middle of the work went wrong.
• The fix is structural: a saved plan, step status, logged assumptions, approval gates and a final report that maps each step to evidence.
• The more freedom an agent has to rewrite its own plan, the more inspection it needs.

What does it mean when an AI agent plans?

An agent does not plan the way a project manager does, with a document approved before work begins. A language model reads the request, the instructions it was given and whatever context the surrounding system supplies, then produces a next move. Often that includes a short outline of intended steps. When a tool returns something, the model reads the new situation and decides again. The cycle is explained in more depth in Agent Loop Explained: How an AI Agent Decides What to Do Next.

In practice a plan takes one of three forms:

• Implicit: the plan exists only in the model's reasoning for the current move, and nobody can inspect it afterwards.
• Written note: the agent keeps an outline in its working context or in a file and updates it as it goes.
• Structured: a list of steps with a status for each, stored and checked by the system around the model, not by the model alone.

The further down that list, the easier the work is to supervise. Anthropic's guidance on building effective agents separates workflows, where code defines the path, from agents, where the model directs its own process. Planning risk grows with the second kind, because the path itself is a decision the model keeps making.

How does an agent break a request into steps?

The sequence below is what a well-behaved agent does for a request that needs more than one action. Not every agent does every step explicitly, and that gap is where problems start.

• Step one, restate the goal: the agent paraphrases what it believes the request means and what a finished result looks like.
• Step two, find what is missing: it identifies facts it needs, such as a customer record, a date range or a policy, and decides where to get them.
• Step three, decompose: it splits the goal into smaller actions and notes which depend on others.
• Step four, match tools to steps: for each action it picks a tool, such as a search, a database read or a draft in an email system. What Is Tool Calling in AI? covers how that choice works.
• Step five, act and read: it performs the first action and reads the result closely, including errors.
• Step six, revise: it adds, removes or reorders steps based on what it learned.
• Step seven, check the finish line: it compares the result with the goal from step one and either stops or continues.

Steps one and seven are the ones most often compressed or skipped. Without a stated goal and a stated finish line, the agent has nothing to compare its own work against, and neither does the person reviewing it.

Where do multi-step plans drift?

Drift is gradual. No single move looks wrong, but the sum ends up somewhere the request did not point. These are the points where it most often happens.

• Goal drift: the agent reinterprets a hard request as an easier neighboring one, then completes the easier one well.
• Assumption drift: a guess made early, such as which customer or which period was meant, quietly becomes treated as fact in later steps.
• Scope creep: the agent adds helpful extras nobody asked for, such as notifying a third party or updating a second record.
• Skipped steps: a step is dropped because it looked redundant, or because a tool failed and the agent routed around the failure without saying so.
• Stale plan: a surprising result arrives, but the agent keeps following the outline it wrote before the surprise.
• Context loss: in a long run, early decisions and constraints fall out of what the model can see. What Is a Context Window in AI? explains why this happens.
• False completion: the agent declares the work done on partial evidence, such as a draft saved but never sent, or a record changed but never confirmed.

None of these require a weak model. They follow from a system that makes sequential decisions with incomplete information and no outside check.

Why do plan failures go unnoticed?

The main reason is that fluent language hides process. A final message such as "I have reviewed the records and updated the schedule" reads the same whether every step ran or half were skipped. A reviewer who sees only the end of the work cannot tell the difference.

Three other things make it worse. Tool errors are sometimes absorbed: the agent retries, gets a different result and continues without recording that anything went wrong. Retries can repeat side effects, so a step that looked like it failed may have partly happened. And the longer a run, the less anyone reads the middle of it.

This is the same problem that observability addresses in ordinary software. The OpenTelemetry observability primer describes traces as the recorded path of a request through a system. An agent run needs the equivalent: a record of which step was attempted, with which tool, and what came back, so a person can follow the path after the fact.

How can you make an agent's plan visible?

Visibility is a design choice in the harness, the system around the model, and not a favor the model does for you. If you want an overview of that layer, see What is an AI harness?. The checklist below works for most business agents.

• Save the plan before the first action, in a stable place outside the model's working memory.
• Give every step a status: not started, in progress, done, blocked or skipped, with a reason for the last two.
• Keep assumptions in their own list, labeled as assumptions, so they cannot pass as facts.
• Tie every tool call to the step it serves, so a log line can be traced back to the plan.
• Record every change to the plan with a short reason, such as "supplier record missing, added lookup step."
• Place approval gates before steps that send messages, spend money, delete data or touch external parties.
• Write a checkpoint after each meaningful step so interrupted work can resume. See AI agent checkpoints: how to resume unfinished work.
• Require the final report to list each planned step with the evidence that it happened, not just a summary.

That last item connects to the idea of a finish line. A definition of done for AI agents: demand evidence argues that the agent should prove completion with artifacts a person can check, and the plan is the natural structure for presenting that proof.

There is a balance to keep. A plan that is too rigid stops the agent from adapting when reality differs from expectation, which is the reason to use an agent at all. A plan that is too loose gives you nothing to inspect. A workable middle is a fixed goal, a fixed finish line and fixed approval gates, with the steps in between free to change as long as every change is recorded.

An illustrative scenario: a delayed supplier order

This scenario is illustrative, not a description of a real engagement.

An operations manager asks an agent: "Find out why the order from our packaging supplier is late and tell the warehouse what to expect." The agent writes this plan: look up the order, read recent supplier messages, check the carrier status, draft a note to the warehouse.

The order lookup returns two open orders from the same supplier. The agent assumes the larger one is meant and continues. This is assumption drift. In a visible system, that assumption lands in the assumptions list, and the report to the manager says "I assumed the larger order; please confirm."

Next, the carrier lookup fails because of a temporary tool error. The agent skips it and writes the warehouse note using only the supplier's message. In a system with step status, the carrier step shows as blocked with a reason, and the draft is marked as incomplete. The note waits at an approval gate instead of going out.

The manager reviews the plan, sees the assumption and the blocked step, corrects the order choice and asks for a retry. The agent resumes from its last checkpoint, completes the carrier step and produces a final report that lists each step with its evidence. The visible plan did not make the agent smarter. It made two quiet errors easy to see before they reached the warehouse.

How does Be Human handle planning in managed agents?

Be Human designs the harness so that an agent's plan is a stored object, not a private thought. A first engagement defines one role, the memory and tools it needs, the approval boundaries and an observable success criterion. The success criterion becomes the finish line each plan is checked against. Plans, step status, assumptions and tool calls are recorded, and approval gates are placed before actions with external effects. In managed operations, the team reviews those records on a recurring basis, looks for drift patterns such as repeated skipped steps, and proposes controlled changes to instructions, tools or permissions instead of changing behavior ad hoc.

Frequently asked questions

Do AI agents plan everything before they act, or as they go? Most do both. They often write an initial outline, then revise it after each tool result. That is useful for messy real-world work, but it means the first plan is a starting hypothesis, not a commitment.

Can I force an agent to follow a fixed plan? You can, by moving the path into code so the model fills in only the individual steps. That is a deterministic workflow, and it is the right choice when the steps never vary. AI agent or deterministic workflow? A decision guide helps you decide which fits a given task.

Should every task have a written plan? Not necessarily. A one-step lookup does not need a plan record, and adding one is overhead. Plans earn their keep when a task has several steps, uses more than one tool, takes a long time, or ends in an action that is hard to undo.

What should I review first when an agent's plan fails? Start with the assumptions list and the step statuses, because they show where the agent guessed or skipped. Then compare the final report with the finish line that was set at the start. If the failure was a wrong goal or a missing boundary, change the instructions or the approval gates, not just the prompt wording.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.