Why do plan then act agents keep an explicit plan block in context, even when the model could re-plan from scratch?

A **plan block** is a short, structured chunk of text that sits at the top of the assistant turn and lists what the agent is trying to do, broken into steps. Plan then act agents keep this block in context across every iteration of the loop, even though, in principle, the model could regenerate the plan from the original user request each time. The reason this persistence is worth the tokens comes down to three properties. First, **consistency**. If the agent re-plans on every step, two consecutive iterations may produce subtly different plans, the agent flips between approaches, and the trajectory thrashes. A persisted plan is a commitment device: the agent agrees with its past self. Second, **debuggability**. When something goes wrong, an engineer opens the trace and reads the plan block to understand what the agent thought it was doing. Without it, intent has to be reconstructed from tool calls, which is much harder. Third, **cheaper conditioning**. The model does not have to re-derive intent from scratch on every turn. It reads the plan, picks the next step, and acts. Token spend goes to actions instead of repeated planning. The cost is real: the plan occupies tokens every turn, and a stale plan that is not pruned becomes worse than no plan at all.

A **plan block** is a persisted, structured summary of the agent's intent that lives in the assistant turn across iterations. It typically lists the high-level goal, the current sub-goals, and which step the agent is on. Keeping the plan in context is worth the tokens for three structural reasons. First, it provides **consistency**. Re-planning every iteration is not just wasteful, it is unstable. Two adjacent re-plans can produce slightly different decompositions, the agent oscillates between them, and the trajectory takes longer or fails. The persisted plan anchors the agent to a single interpretation. Second, it provides **debuggability**. The plan is the single artifact an engineer reads to understand what the agent thought it was doing. Tool calls alone do not reveal intent; the plan does. Third, it provides **cheaper conditioning**. The model conditions on the plan instead of re-deriving it from the user request and the tool history. This means the next-action prediction has a tighter context to attend to, tool calls are smaller and more focused, and lost-in-the-middle effects across the long trajectory are mitigated. The cost is the tokens the plan occupies and the discipline of pruning it. A plan that is never updated as sub-goals close grows into a log and loses its anchoring power. The right pattern is to update the plan in-place when a step completes, mark closed sub-goals as done, and trim stale branches. Production agent frameworks like LangGraph and CrewAI bake this update step into the loop.