Planning is a loop, not a step
Agents that re-plan after every tool call recover from failures that one-shot planners never notice. Here is how the loop works in practice.
The plan that never looked back
Most early agent frameworks treat planning as a single step. The model reads the request, writes a list of actions and then executes them in order. It is tidy, easy to trace and wrong about one in five times on anything longer than three steps.
We learned this from our own support agent. Asked to move a customer to an annual plan, it planned four calls: look up the account in Relay, find the current subscription in Payly, issue a prorated credit, create the new plan. The second call returned two subscriptions, one of them already cancelled. The plan had no room for that, so the agent credited the cancelled one and carried on as if nothing had happened.
What re-planning means in practice
In a loop, the agent writes a plan, takes one action, reads the result and decides whether the plan still holds. If it does, it takes the next step. If it does not, it rewrites the remaining steps before doing anything else.
That sounds expensive. It is less expensive than it looks, because most checks are short. Across 40,000 production runs last quarter, the median re-plan added 310 tokens and 0.4 seconds per step. The change in outcomes was much larger.
- Task success on multi-step support work rose from 78% to 91%.
- Silent failures, where the agent finished but did the wrong thing, fell by two thirds.
- Escalations to a human went up slightly, from 6% to 8%, which we count as a win. Those were cases the old agent would have guessed at.
A one-shot planner is confident about a world it has not seen yet. A loop only has to be right about the next step.
Three questions after every tool call
We do not ask the model to reconsider everything after each step. That invites drift. Instead the loop asks three narrow questions, in order.
- Did the call succeed? Not just a 200 response, but the outcome the step expected. A Bookwise search that returns zero rooms is a success at the HTTP level and a failure for the plan.
- Did I learn something that changes the goal? Two matching customers, a policy flag, a balance lower than expected.
- Is the next step still the cheapest safe move? Sometimes the answer is to ask a human rather than push on.
If all three answers are boring, the agent moves on without rewriting anything. About 82% of steps take this path.
Where loops go wrong
Loops have their own failure mode: the agent keeps re-planning and never finishes. We cap re-plans at three per task by default and treat the cap as a signal, not a failure. When an agent hits it, the run pauses and routes to a person with the full trace attached. In practice that happens on 1.2% of runs, and almost every one points to a missing tool or an unclear policy.
How we test it
Re-planning only helps if the agent meets surprises during evaluation, not just in production. Our eval suites now inject faults on purpose: timeouts, partial records, duplicate results, stale prices. Each injected fault has a rubric check for whether the agent noticed. You can read more about the suite itself in how we evaluate agents before they touch production.
The short version for your own agents: let the plan be wrong, as long as the agent finds out quickly.
More posts.
Ship your first agent today.
Free up to 10,000 steps a month. No credit card needed.