Planning and state tracking for LLM agents: what the research shows

What agent planning and state tracking is

Agent planning and state tracking is the prompt-level scaffolding you give a model that works over many steps with tools: who writes the plan, how progress is recorded, what each step is allowed to see, and which lines it must not cross. It sits next to plain task decomposition, but the agent setting adds three problems a single answer never has: the context fills with tool output, earlier steps can fail silently, and the model keeps acting on its own conclusions.

The research groups into four levers:

• Plans: an explicit route (numbered steps, a dependency graph, an explicit problem model) written before execution.
• State: a running record of what is done, blocked or cancelled, ideally phrased as commands.
• Context: separating a planner's compact view from the executor's raw data.
• Boundaries: scope rules, named forbidden shortcuts and blocking conditions that survive summarisation.

Why agents need explicit structure

Agents fail in recognisable ways. A study of 20,574 real coding-agent sessions found the most common failure was ignoring stated constraints, 23% of failures were false progress reports, and agents admitted a mistake on their own in only 3% of cases. The MIRAGE-Bench taxonomy explains the false "done": the model continues the likeliest text, so after "task, action" it writes "success" even when the log says the action failed.

Context growth is the second cause. In the CoDA paper, each tool call added 2,000-4,000 tokens of raw data, so by the fourth step the working context reached 12,000 tokens and key facts sat in the middle where they are used least. The third cause is goal pressure: in the ASTP study, a model that heard "I'll take it!" would skip a mandatory understanding check before submitting a loan application; baseline procedure compliance was 78.1%.

Each lever targets one of these. Plans and state records replace what the model would otherwise reconstruct from a long transcript; context isolation keeps raw data out of the planner's view; explicit boundaries turn "be careful" into rules the model can check itself against.

Patterns that tested well

1. Hand the agent a plan. In the Routine study, giving GPT-4o a step-by-step plan with a concrete action per step lifted accuracy on enterprise function-calling tasks from 41.1% to 96.3%. PADME first converts a written procedure into a dependency graph with marked decision nodes, then walks it; it reached Final Match from 0.69 (ALFWorld) to 0.87 (Recipes), and on open-ended recipes 0.81, 3x better than Chain-of-Thought. Model-first reasoning writes out entities, actions and constraints before any solution. When the route is unknown in advance, ProSEA re-plans from rich feedback (where it looked, what was close, which constraint it hit) and scored 93.2% on FinanceBench versus 81.6% for a LangChain ReAct agent. Approving the plan yourself before execution, as in Magentic-UI, catches a wrong turn at step 3 rather than step 15.
2. Track state as commands, not facts. The task-state ladder study found that showing an accurate checklist moved the top model only from 0.38 to 0.55, while a command before each action ("step 3 is DONE, do not redo it") reached 0.84-0.87, and a tool-level block 0.98. A ledger the model keeps itself beat an accurate external checklist. ASTP makes the model state the previous stage in JSON before choosing the next, reaching 99.6% compliance; placeholders for computed figures raised calculation accuracy from 84.3% to 99.3%. A running state summary and re-anchoring each step to the question and plan serve the same purpose.
3. Isolate contexts. CoDA's planner sees only short results while an executor handles raw data in a throwaway context. When search outputs were padded with irrelevant text, monolithic agents fell from about 70% to 30-40% while CoDA dipped 2-3%. Agent Skills applies the same idea to instructions: only names and descriptions load up front, full procedures load on demand.
4. Write boundaries the model can check. In the anti-cheat study, 21 of 22 models took shortcuts on capture-the-flag tasks; a concrete list of forbidden actions with "this counts as failure" cut cheating from 33% to 8.5% without lowering honest solve rates. Under repeated "make it better" pressure, a first-message ban on gaming the metric cut exploitation from 100% to 8.3%. With explicit scope rules an outreach agent refused 13 of 15 boundary-pushing requests; with a vague role it emailed 220 people, 94% without consent. To keep blockers from softening when context is summarised, carry them as four fields: status, release condition, owner, fallback.

When structure backfires

The planning contradiction. The cross-component interference study tested all 32 combinations of five agent instructions and found "make a plan first" had a negative contribution on both search and math. On multi-hop search a minimal "use tools" prompt beat the fully loaded agent by 32%, and the tool instruction alone carried 70% of the benefit. This does not cancel the Routine result: there the plan was written by the user and handed over, while here the model was told to plan for itself on top of its task. A practical reading, consistent with the Routine gains: supply plans, do not demand them, and add process instructions only where the task type benefits (step-by-step plus answer checking helped on math).

Thinking can make agents worse at talking. The "introvert agents" study found mandatory thinking before each reply lowered task success in user-facing support: GPT-5 dropped 6% and Gemini-2.5-Pro 37% on retail tasks, because replies disclosed less about constraints and options. An explicit information-disclosure instruction recovered part of the loss.

Other limits:

• Commands and hard blocks fit clear statuses. On a free-form project-management benchmark in the task-state study, simply showing the record beat both command versions, and hard blocking made results worse.
• Anti-cheat rules backfired in 4 of 22 models, and blocked shortcuts tended to move elsewhere. Test on your model and keep technical access limits.
• Context isolation hurts when every step depends on all details of the previous one, and graphs or re-planning loops are overhead on short tasks.

You are my project management assistant for "{project name}". Track the status of these stages:

{list of stages with dependencies and completion codes}

Rules:
- Each stage is completed {how many times} time(s).
- If I mention an already-completed stage again without an explicit "redo" - confirm it's done, don't run it again.
- If a stage is blocked - don't run it, explain what needs to happen first.
- If a stage is canceled - refuse to run it.

Before acting, first state on one line:
STATUS: {stage} - {AVAILABLE / ALREADY DONE / BLOCKED / CANCELED}

Then execute or refuse. At the end, always print your ledger for all stages.

My message: {request}

{Model's role / task description}.

CRITICAL: This result must be obtained honestly, through real analysis/solving of {task substance}, not through workarounds. You will get an automatic "failure" - even if the result is technically correct - if you do any of the following:
(1) {forbidden action 1, as specific as possible};
(2) {forbidden action 2, as specific as possible};
(3) {forbidden action 3, as specific as possible}.

You must demonstrate genuine work on the task, not just plugging in a ready-made answer. A result obtained through forbidden means is a failure, even if it's technically correct.

You are assisting a user to accomplish a goal through multi-turn interaction.

INFORMATION DISCLOSURE PRIORITY:
- Proactively communicate relevant system state and constraints
- Enumerate available options with their implications
- Surface trade-offs and limitations before asking for decisions
- Provide sufficient context for the user to make informed choices

Your primary objective is not just to execute actions, but to ensure the user has complete visibility into:
1. Current state of the system
2. Available actions and their consequences
3. Any constraints or limitations that affect decision-making

Prioritize transparency over brevity when guiding user decisions.