Most first-generation agents run a single loop: look at the state, pick a tool, call it, repeat. It is simple, and it works for short tasks. But as tasks get longer or the tools get more consequential, the loop has a structural weakness: the decision about *what to do* and the act of *doing it* happen in the same step, so there is no moment where anyone can look at the intended course of action before it starts to take effect.

A common fix is to split the work into two phases. First the model produces a plan; then an executor carries it out. The idea is old, but it is worth being precise about what you gain and what it costs.

What the split buys you

A reviewable artifact. A plan is a small, structured object: an ordered list of steps, each naming a tool, its arguments, and the reason for the step. That is something you can log, diff against previous runs, show to a user for approval, or check with ordinary code. Reviewing a transcript of twenty interleaved tool calls is much harder than reviewing a ten-line plan.

A place for cheap validation. Before anything runs, deterministic code can reject plans that call tools the task does not need, touch resources outside an allowed scope, or exceed a step budget. Those checks cost nothing compared with discovering the problem after a write has happened.

Better testing. You can write eval cases for the planner alone ("given this request, does the plan include the lookup before the update?") without executing any tools, and test the executor with hand-written plans. Two smaller test surfaces are easier to reason about than one large one.

A natural model split. Planning often benefits from a stronger model; executing a well-specified step often does not. Separating them lets you spend where it matters.

What it costs, and how to limit the damage

The obvious cost is rigidity. A plan written before any tool output exists is a guess, and real tasks branch: the search returns nothing, the file is not where expected. If the executor follows the plan blindly, it will confidently do the wrong thing.

Three habits keep the pattern honest:

  1. Let the plan be provisional. Mark which steps depend on earlier results, and have the executor return to the planner when an observation contradicts an assumption, rather than improvising silently.
  2. Plan at the right granularity. "Update the record" is too vague to validate; "call update_record with these exact fields" is too brittle to survive new information. Aim for steps that name the tool and intent, and let arguments be filled in at execution time where they depend on prior output.
  3. Keep the approval gate proportional. Not every plan needs a human. Route plans containing irreversible or externally visible actions to review, and let read-only plans run straight through.

A closing test

Ask of any agent you run: *is there a point, before the first side effect, where the intended actions exist as data that something other than the model can inspect?* If not, your only safety mechanisms are the model's judgment and your logs after the fact. Adding that point does not require a new framework, only a plan format and a willingness to stop between the phases.

AI AgentsAI OrchestrationAgentic AI