Planning: the plan that never ends

A coding agent was asked to fix a red nightly build. It wrote a four-step plan, read the log, and found three failing tests in test_billing.py. Good start. Then it wrote a new plan, five steps now, and read the test file. Then a new plan again, this time to map every file that imports the billing module. At line 8 the framework stopped it: LangGraph's default recursion limit is 25 steps, and the run hit it. Files changed: zero. The build was still red, and the run had spent 25 steps of model calls and file reads to learn nothing it did not know at line 3.

This is the plan that never ends. The agent was never idle and never wrong in any single line. It just never got to step 3.

Line 4 is the first bad move. The model had a plan and a result that matched step 1. The right next action was step 2. Instead it re-planned, and the new plan was wider than the old one. That happened because the plan existed only as text in the model's last message. On every turn the model saw the whole history and was asked what to do next, so it did the thing models do with a lot of context: it summarized and planned again. Nothing said "you are on step 2 of 4". Nothing said "the plan is done when the tests pass".

Each re-plan grew because each new file added things to understand. A 412-line test file suggests reading the module. The module suggests the data model. The data model suggests every importer. The agent was exploring, and exploring has no natural end. ReAct, the 2022 paper that gave this loop its shape, interleaves a thought and an action on every turn, and reports success rates 34 points above imitation learning on ALFWorld and 10 points above it on WebShop. But ReAct says nothing about when to stop. That part is yours.

The only stop condition was the framework's. LangGraph's default is 25 steps, the OpenAI Agents SDK's default max_turns is 10, and both raise an error when hit. A limit like that is a smoke alarm, not a plan. It tells you the run failed. It does not tell the run how to succeed.

Separate the plan from the prompt. Store it as a small list with a status per step: todo, doing, done. The model updates one status per turn through a tool, and the loop reads the list to decide what to show the model next. Re-planning is allowed, but it is an explicit action with a reason, and you count them. A run that re-plans three times without finishing a step is stuck, and the loop can say so and stop.

Write the stop condition before the first step. For this task it is: the three tests in test_billing.py pass, and no other test broke. That is checkable by a tool, so the loop checks it rather than asking the model whether it feels done. Anthropic's guide on building effective agents puts it plainly: the task usually ends on completion, and it is common to add stopping conditions such as a maximum number of iterations to keep control. Note the order. The real stop condition first, the turn limit as a backstop.

Budget the exploration. Reading is cheap and feels productive, so cap it: three files before the first edit, then edit, then run the tests and let the failure tell you what to read next. The test failure is a better guide than a map of 61 files. In the trace, line 3 already pointed at the test file and the three failures. One edit and one test run would have taught the agent more than the next twenty steps did.

Log the plan at every turn. When a run gets stopped at the limit, the first question is which step it was on. If the answer is step 1, for the fourth time, you have found the bug in one look.

"Line 4. The agent had a result for step 1 and re-planned instead of doing step 2, because the plan was only text in its last message and nothing tracked progress. It kept widening the plan until the framework's 25-step limit stopped it. I would keep the plan in state with a status per step, define done as the tests passing, cap reads before the first edit, and count re-plans so a stuck run is caught early." If they ask about the turn limit, say it is a backstop, not the stop condition.