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

Flashcard·Medium·4.0 · 0·~30s·Asked atForethought Rephrase Ai Writer

Attempt it

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. Without pruning, it grows into a log and loses its anchoring power.

Your answer

A **plan block** is a short, structured chunk of text that sits at the top of the assistant turn. It lists what the agent is trying to do, broken into steps. Plan then act agents keep this block in context across every loop iteration. In principle, the model could regenerate the plan from the original user request each time. It is worth the tokens for three reasons. First, **consistency**. If the agent re-plans on every step, two consecutive iterations may produce subtly different plans, and the agent flips between approaches and wastes steps. A persisted plan is a commitment device: the agent agrees with its past self. Second, **debuggability**. When something goes wrong, an engineer reads the plan block in the trace to see what the agent thought it was doing. Without it, intent must be pieced together from tool calls. 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 uses tokens every turn, and a stale, unpruned plan is worse than no plan.

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 wasteful, and it is also 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 reduced. 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. In LangGraph, for example, this update is an explicit node that rewrites a plan field in the typed state.

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.

Memory aid

Easy to grasp

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. It is a short list pinned at the top of the conversation. It 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 done. The notepad does not free the cooks from thinking, but it stops them from arguing with their past selves about what dinner is.

Key concepts

Context Engineering Agents

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Plan then act is a common agent design pattern. The agent writes an explicit plan as its first action, then iterates: read the plan, pick the next step, call a tool, observe the result, update the plan, repeat. The persistent plan block is the spine of that loop. Without it, every iteration is a fresh planning problem and the agent thrashes. With it, the agent commits to a trajectory and the engineer can read what it committed to.

What the plan block contains

A well-formed plan block is short and structured. The top line names the overall goal. A sub-list lists the open sub-goals in priority order, and an optional notes line records any constraints the agent has discovered. The plan is not a chain-of-thought log, and it is not a tool call history. It is the agent's current intent, expressed in a form a person can read in five seconds.

The structure matters. A free-form prose plan tends to grow unbounded because there is no obvious place to delete from. A list-structured plan with explicit status markers (open, done, dropped) gives the agent a natural edit interface. It can mark a sub-goal done when it closes, or drop one when it turns out to be unreachable. The whole point of the block is to be edited, so the format should make editing easy.

In practice the plan often coexists with two other context engineering primitives. One is a running summary of the conversation so far (compresses old turns). The other is a memory store for durable facts the agent has learned (survives across sessions). Each one has its own job. The plan is about what the agent is doing now, not about what has happened or what is true.

Why consistency matters more than freshness

The debuggability dividend

Cheaper conditioning and attention focus

Failure mode: plan rot and how to prevent it

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Real products, models, and research that use this idea.

LangGraph's typed state stores the plan as a named field and updates it in-place via reducer functions on each node.
Anthropic's Agent SDK has todo-tracking tools that the model calls to mark items pending, in progress or completed across turns.

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?

Plan rot is when the plan grows without being edited, so it accumulates done sub-goals, dead branches, and stale notes. Detection signals: plan-block token count rising monotonically across iterations, model tool calls starting to ignore the plan, and trace summaries showing the agent re-deriving intent inside its reasoning instead of conditioning on the plan. The fix is to give the model an explicit edit-plan tool or a reducer step that compresses closed sub-goals.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases 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.

60 second bullets to scan on the way to the call.

State what a plan block is and where it sits in the assistant turn
Name the three reasons to persist it across iterations

Primary sources. Browse if you want the original framing.