Three reasons. First, consistency: re-planning every iteration is wasteful and can produce subtly different plans that thrash the agent's behavior. A persisted plan anchors decisions. Second, debuggability: the plan is the artifact an engineer reads to understand what the agent thought it was doing. Third, cheaper conditioning: the model conditions on the plan instead of re-deriving it, which means smaller and more focused tool calls. The cost is the tokens the plan occupies plus the discipline of pruning the plan when sub-goals are done, otherwise it grows into a log and loses its anchoring power.
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.
Quick reference
TL;DR
A persisted plan block anchors agent behavior, gives engineers a debuggable artifact, and lets the model condition cheaply on a stable trajectory instead of re-deriving intent every iteration.
Picture a kitchen with five cooks who share one notepad. If every cook ripped out the page and rewrote the menu from scratch every minute, the kitchen would never produce a meal. The notepad keeps everyone aligned. Now imagine the notepad as the agent's plan: a short list pinned at the top of the conversation that says what the agent is trying to do and which step it is on. Each new action looks at the notepad, picks up where the last action left off, and updates the page only when a step is genuinely done. The notepad does not free the cooks from thinking, but it stops them from arguing with their past selves about what dinner is.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Single-step or reactive agents where the entire task is one tool call followed by a response. A plan block only earns its tokens when the trajectory spans many iterations. For one-shot work, it is pure overhead and adds latency.
Streaming agents whose state is dominated by external events rather than a fixed user intent. Event-driven agents tend to need per-event scratch state, not a global plan. A plan block can mislead the model by suggesting a fixed trajectory that does not exist.
Tasks where the user reformulates intent every turn, like open-ended chat. A persisted plan becomes stale as user intent shifts. The conditioning win disappears and the plan begins to fight the latest user message.
Quick scan · 2–4 min
Everything important, quickly.
Define the plan block. Give the three reasons to persist it: consistency, debuggability, cheaper conditioning. Explain how each one works mechanically. Name the failure mode (plan rot) and the fix (edit in place). Close with the LangGraph or Anthropic SDK example that operationalizes the pattern.
Real-world examples
Real products, models, and research that use this idea.
1LangGraph's typed state stores the plan as a named field and updates it in-place via reducer functions on each node.
2Anthropic's Claude agent SDK uses an explicit todo-list block that the model can read and edit across turns.
3CrewAI exposes task statuses as a first-class object, and the orchestrator surfaces them back to the model on every step.
4OpenAI's Assistants and Responses APIs persist a thread state that includes the running plan across tool-call iterations.
5Cursor's agent mode shows the plan as a checklist that updates as files are edited and tests pass.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QWhat does plan rot look like in practice, and how do you detect it?
Sign in or go Pro to see the approach for this follow-up.
QWhen should you NOT use a persisted plan block?
Sign in or go Pro to see the approach for this follow-up.
QHow does plan-block placement interact with the lost-in-the-middle curve?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Treating the plan as a write-once header instead of a living document that gets pruned and updated as sub-goals close.