Why Agents Plan — From Chain-of-Thought to Action

Highlights: Thinking step by step is not enough once actions change the world. Here is why agents need explicit plans. Daniel Fried’s lecture in the CMU 11-768 AI Agents course (Fall 2026) examines why purely reactive execution loops break down across complex, long-horizon tasks. We walk through the trade-offs between upfront commitment and dynamic replanning, the shift from classical STRIPS search to grounded verification, and modular architectures that separate abstract planners from low-level execution models.

• Reactive loop failure: Purely sequential execution threads suffer from lossy context compaction and risk triggering irreversible real-world actions without human verification.
• Task dependency graphs: Structuring tasks into dependency graphs allows parallel sub-agent queries and dynamic insertion of evaluation steps when latent constraints emerge.
• Plan Mode: Separating read-only discovery from state-altering tool execution enforces permission barriers and human approval checkpoints before persistent modifications occur.
• Programmatic representations: Generating plans as executable code with loops and conditional checks bridges formal verification and neural API calls.
• Planner-executor decoupling: Isolating high-level language planning from specialized 7B grounding models prevents context bloat and resolves visual action bottlenecks.

Tutorial Overview:

1. Failure Modes of Purely Reactive Execution Loops
2. Workstation Procurement Planning Case Study
3. Plan Mode in Coding Assistants
4. Explicit Plans versus Reusable Skills
5. Chain-of-Thought and Sequential Decomposition
6. Decomposed Prompting and Specialized Sub-Task Handlers
7. Textual Deliberation versus World Action and Irreversibility
8. Classical STRIPS Planning
9. Search to Grounded Verification
10. Programmatic Plan Representations: Code as Policies
11. Dynamic Replanning and Adaptive Execution
12. Modular Architectures: Decoupling Planner and Executor Roles
13. Summary

---

1. Failure Modes of Purely Reactive Execution Loops

In short
– Reactive loops force parallel hardware vendor checks into fragile, sequential execution threads.
– Compacting accumulated interaction traces discards subtle constraints like rack dimensions and power limits.
– Task dependency graphs isolate execution contexts and prevent unverified irreversible purchase requisitions.

1.1 Fragility in Reactive Procurement Loops

Autonomous agents formulating interactive plans face a continuous trade-off between upfront commitment and dynamic operational flexibility.

• ReAct agent (An autonomous agent loop that alternates between reasoning steps and environment actions within a single prompt thread): executes Daniel Fried’s workstation procurement across hundreds of sequential steps.
• 4 vendor sites: evaluated linearly in a single prompt thread instead of queried concurrently.
• Rigid execution momentum: pushes flawed candidate hardware forward when vendor options violate initial expectations.
• Irreversible action (An operation—such as submitting a purchase requisition or deleting files—that permanently alters the external environment and cannot be undone): submits financial purchase requisitions with the same autonomy as exploratory queries.
• Commitment versus flexibility: upfront sequence commitment provides human auditability, while execution flexibility handles unexpected service outages.

Fig 1. Sequential execution causes rigid momentum and risks executing irreversible financial actions unverified.

Purely reactive systems fail to isolate exploratory browsing steps from binding financial commitments. Static plans cannot adapt when runtime observations contradict initial vendor hardware assumptions.

1.2 Context Compaction and Memory Drift

Accumulating raw web observations causes severe context bloat, forcing production harnesses to compress historical interaction traces.

Approach	Direction	Primary Risk	Execution Model
Compacted Trace	Backward-looking	Loss of critical constraints	Sequential thread
Dependency Graph	Forward-looking	Replanning coordination overhead	Parallel sub-agents

• 128k -> 14k tokens: context compaction (Compressing an agent’s long historical interaction trace into a shorter summary to prevent exceeding the model’s token limit) lossily compresses history midway through execution.
• Memory drift: discards subtle cluster prerequisites including power supply limits, rack dimensions, and component lead times.
• Task dependency graph (A structured map defining which subtasks can execute concurrently and which must wait for the completion of prerequisite steps): isolates Vendor A through Vendor D queries across concurrent sub-agents.
• 20-week lead time: discovered at Vendor D, triggering structured replanning to evaluate a fifth vendor.

Fig 2. Compacted context discards critical constraints, whereas dependency graphs isolate subtasks and replanning.

Lossy summarization erases low-level technical prerequisites needed to verify downstream cluster compatibility. Structured task graphs prevent memory drift by isolating vendor queries into clean contexts.

---

2. Workstation Procurement Planning Case Study

In short
– Task dependency graphs enable parallel vendor searches and dynamic replanning when hardware fails.
– Plan Mode separates read-only discovery from irreversible purchase requisitions through explicit human approval.
– Dynamic sub-task insertion overcomes latent physical constraints without discarding prior evaluation progress.

2.1 Task Dependency Graphs and Plan Mode

Daniel Fried frames workstation procurement as a task dependency graph [a structured map defining concurrent and prerequisite subtasks].

1. Gather read-only data across vendor sites and repositories.
2. Formulate a step-by-step natural language plan.
3. Submit the plan for human review and approval.
4. Execute approved subtasks across parallel sub-agents.

• 4 initial vendors: searching branch nodes executes concurrently before serial compatibility checks.
• 20-week lead time: excessive delivery delays trigger replanning rather than premature ordering.
• Plan Mode: architecture separating read-only inspection from code execution in Cursor, Claude Code, and Codex.
• Permission mode: Claude Code requires explicit authorization before applying persistent modifications.
• Cost optimization: orchestrate with frontier models while delegating isolated subtasks to cheaper models.
• Value and Representation: balance latency costs against graph, text, or programmatic code formulations.
• Commitment and Oversight: establish execution triggers and human review checkpoints before action.

Fig 3. Dependency graphs coordinate parallel vendor searches before wiki compatibility checks and purchase requisitions.

Mike Tyson noted plans fail when hit. Revisable proposals prevent agents from rigidly executing flawed assumptions.

2.2 Architectural Pressures in Long Tasks

Procurement workflows face environmental friction from physical limits, missing data, and irreversible real-world purchasing actions.

• Modularity: isolate vendor searches to stop irrelevant web data from polluting downstream contexts.
• Feedback: update execution trajectories dynamically when environmental observations contradict initial assumptions.
• 128k to 14k tokens: context compaction [compressing history to prevent exceeding limits] degrades unmanaged reactive histories.
• Control: insert authority barriers before irreversible action [an operation permanently altering environments without undo].
• Purchase requisition: human approval gates prevent multi-thousand-dollar procurement mistakes.

Fig 4. Core architectural pressures map directly across the workstation hardware acquisition and requisition workflow.

Submitting multi-thousand-dollar purchase requisitions cannot be undone. Human authorization gates prevent costly non-reversible mistakes.

2.3 Dynamic Insertion Under Latent Constraints

Agents discover latent constraints [hidden real-world limitations revealed only during runtime execution] that invalidate candidate hardware.

• 4U chassis limits: wiki cluster rules eliminate machines exceeding physical server rack dimensions.
• 1600 W per slot: electrical constraints disqualify otherwise viable candidate workstations.
• Shipping delay: logistical barriers invalidate configurations that satisfy technical hardware specifications.
• 5th vendor node: dynamic sub-task insertion avoids restarting the procurement pipeline.
• Calibrated commitment: balance rigid breaking scripts against unconstrained, unpredictable reactive agents.

Static pipelines break completely when assumptions fail. Dynamic sub-task insertion preserves partial work while exploring alternatives.

---

3. Plan Mode in Coding Assistants

In short
– Plan Mode separates safe read-only context gathering from irreversible tool execution.
– Human plan review builds trust and prevents costly compounding errors.
– Decomposed plans unlock parallel execution and route tasks to cheaper models.

3.1 Read-only investigation and context gathering

Industrial assistants use Plan Mode (an architecture separating read-only gathering from execution) before attempting code modifications.

• Non-destructive inspection: agents query vendor specs and wikis before modifying files or purchasing hardware.
• Permission gating: Claude Code enforces a distinct read-only state before requesting tool execution authority.
• Action protection: non-destructive investigation avoids premature irreversible actions (operations permanently altering external environments).

1. Perform read-only codebase exploration to gather context.
2. Ask clarifying questions to resolve ambiguities.
3. Generate a structured written plan.
4. Submit the plan for human review and refinement.
5. Execute the approved actions across the codebase.

Fig 5. Plan Mode separates read-only investigation and human approval from irreversible execution.

Context gathering establishes accurate situational awareness across the system. It prevents agents from proposing blind file modifications.

3.2 Human review and pre-execution alignment

A written plan acts as a shared scratchpad, externalizing intermediate steps for human verification and trust.

Attribute	Plan	Skill
Scope	Single task or repository	Generalizes across tasks
Guidance	Coordinates specific future actions	Reusable procedural instruction
Certainty	Proposal needing revision	Established capability

• Shared scratchpad: records completed milestones and remaining subgoals in an inspectable, persistent format.
• Error prevention: human plan approval stops compounding execution loops before agents edit target repositories.
• Plan definition: specifies intended actions, ordering constraints, and subtask dependencies as an editable proposal.

Pre-execution review stops irreversible errors before tools run. It bounds context drift across long tasks.

3.3 Structured execution and parallel dispatch

Approved plans trigger structured execution, unlocking model tiering and concurrent sub-agent scheduling.

• Cost optimization: routes simple subtasks to smaller models while saving reasoning models for planning.
• Parallel dispatch: dispatches independent subgoals simultaneously across sub-agents to slash wall-clock latency.
• Context isolation: confines subtask traces to isolated contexts, preventing error pollution in main threads.

Task decomposition cuts runtime compute costs and speeds execution. Isolating branches protects the primary context window.

---

4. Explicit Plans versus Reusable Skills

In short
– Plans propose explicit, revisable actions for a single task in dynamic environments.
– Skills provide reusable operational guidance that generalizes across different tasks and domains.
– Environmental failures trigger plan revisions without altering the agent’s underlying skill library.

4.1 Plans as Explicit Forward Proposals

A plan explicitly organizes intended actions and subgoals before an agent executes dynamic tasks.
– Explicit proposal: specifies intended actions, subgoals, ordering, and dependencies as a revisable proposal.
– Dynamic replanning: updates proposals when unexpected environment observations contradict initial assumptions.
– Supervisor trade-off: autonomous adaptation increases runtime flexibility but reduces predictability and specifiability for humans.
– Tyson quote: Fried cites Mike Tyson: “Everybody has a plan until they get punched in the mouth.”

Fig 6. An LLM agent plan acts as an explicit, revisable proposal for future actions.

Dynamic environments force agents to revise proposals when runtime observations break assumptions. Autonomous adaptation sacrifices supervisor predictability.

4.2 Task Plans Versus Reusable Skills

Skills generalize across domains whereas plans remain tied to a single execution context.
– Plan specificity: organizes a single task, such as actions for one software repository.
– Skill reusability: provides shared operational patterns that apply across distinct tasks and domains.
– Decoupled updates: revising a context-bound plan leaves the underlying skill library completely unchanged.

Attribute	Plan	Skill
Scope	Single task	Multiple tasks and domains
Generality	Context-bound (e.g., repository)	Generalized operational patterns
Adaptation	Dynamic replanning	Fixed procedural library

Decoupling plans from skills prevents task-specific failures from corrupting reusable procedural knowledge.

4.3 Context-Bound Plan Formulation

Upfront task decomposition structures execution subgoals before dynamic runtime feedback invalidates assumptions.
– Decomposition proverb: weeks of programming can save hours of planning.
– Context-bound limits: plans reflect immediate environment conditions rather than universal general rules.
– Component failure: an unavailable component invalidates initial plan assumptions, triggering replanning.
– Library stability: runtime plan revisions leave the underlying generalized skill library untouched.

Fig 7. Upfront task decomposition balances advance planning time against extended downstream execution effort.

Agents revise localized plans because external environments invalidate initial component assumptions.

---

5. Chain-of-Thought and Sequential Decomposition

In short
– Chain-of-thought prompting allocates test-time compute across intermediate tokens as an uninspected scratchpad.
– Least-to-most decomposition solves complex problems by passing intermediate answers forward through ordered sub-questions.
– Modular subtask routing isolates context, but real-world agent execution requires dynamic feedback and replanning.

5.1 Chain-of-Thought as Latent Plans

Prompting large models to generate step-by-step rationales establishes the foundation for explicit agent planning.

• Reasoning models: OpenAI o1 and DeepSeek-R1 condition on internal reasoning tokens before outputting answers.
• Kojima prompt: NeurIPS 2022 benchmark showed “Let’s think step by step” achieved top zero-shot accuracy.
• Wang prompt: ACL 2023 plan-and-solve prompting instructs models to outline steps before computing solutions.
• Test-time compute (additional computational processing allocated during inference, such as generating intermediate reasoning tokens, before returning a final output): generation traces allocate extra compute to build working scratchpads for derived facts.
• Uninspected execution: single forward passes bundle reasoning and output without external verification of intermediate steps.
• Trajectory optimization: STaR (Zelikman et al., NeurIPS 2022) and DeepSeek-R1 refine traces via reinforcement learning.

Fig 8. Chain-of-thought bundles planning and execution into a single uninspected forward generation pass.

Q: [problem]
A: Let's think step by step.

Q: [problem]
A: Let's first understand the problem and devise a plan to solve the problem. Then, let's carry out the plan and solve the problem step by step.

Externalizing latent plans allows supervisory modules to inspect and validate steps before agents act. This separation prevents unverified reasoning errors from corrupting downstream execution.

5.2 Decomposing Problems into Sub-Questions

Task decomposition separates sub-goal generation from execution to reduce reasoning demand on individual model calls.

1. Decompose the complex problem into an ordered list of independent or conditionally dependent sub-questions.
2. Solve sub-questions sequentially, appending intermediate solutions from earlier stages into subsequent prompt contexts.

• Least-to-most prompting (a decomposition strategy that splits a complex problem into an ordered sequence of simpler sub-questions, passing intermediate answers forward to subsequent steps): Zhou et al. (ICLR 2023) introduced this two-phase sequential decomposition technique.
• Recursive language models: Zhang et al. (2025) recursively call child model instances on partitioned inputs.
• Isolated reasoning: models resolve one atomic sub-question at a time, avoiding multi-hop logic failures.
• Growing accuracy gaps: decomposition advantages over standard prompting widen as problem length and complexity increase.
• Inspection checkpoint: human operators or automated verifiers inspect decomposed questions before expending execution compute.
• Plan repair: planners edit flawed sub-questions immediately without corrupting the historical execution trace.

Sub-question 1: How long does each individual trip take?
Intermediate answer 1: Each trip takes 5 minutes.

Sub-question 2: Given that each trip takes 5 minutes, how many total trips can occur within an hour?
Final answer: 12 trips.

Dividing compound questions shields language models from compounding arithmetic and logic failures. Verifiers catch incorrect plans early before running expensive downstream execution calls.

5.3 Ordered Sub-Goals for Context Control

Sequential sub-goal execution manages agent context windows during long-horizon environment interactions.

• Context bloat: monolithic agent loops accumulate bulky tool observations, degrading attention across long horizons.
• Isolated vendor queries: workstation agents search Vendor A, extract structured specifications, and purge browsing history.
• Vendor B isolation: the agent inspects the next vendor cleanly without distraction from prior web markup.
• Concise handoffs: aggregation nodes receive only structured hardware summaries to verify cluster wiki compatibility.
• Prerequisite validation: ordered dependency resolution guarantees hardware specs are confirmed before initiating vendor purchase requisition.
• Selective retention: structured extraction prevents context compaction (compressing an agent’s long historical interaction trace into a shorter summary to prevent exceeding the model’s token limit) from discarding nuanced hardware constraints.

Carrying full browser traces across multiple vendor sites causes severe context distraction. Isolating subtasks passes forward only necessary parameters while discarding noisy intermediate observations.

5.4 Multi-Stage Routing and Agentic Execution

Decomposed prompting (a technique that breaks a compound query into specialized subtasks and routes each to a dedicated sub-agent or tool handler) directs partitioned tasks to specialized handlers.

• General question answering: routes factual queries like “Who was born in 1910?” to standard models.
• Relational queries: directs cross-referencing lookups like “Which movies did [Answer #1] produce?” to relational retrievers.
• External tool calls: dispatches mathematical computations and live web lookups to dedicated symbolic calculators.
• Cost optimization: routes simple subtasks to smaller, cheaper models while reserving large models for orchestration.
• Programmatic control: Python code coordinates sub-agent execution pipelines in frameworks like RAO and MACU.
• Real-world divergence: verbal backtracking cannot undo physical state modifications made during live agent deployment.

Fig 9. Decomposed prompting routes specialized sub-questions to dedicated tool handlers and sub-agents.

Attribute	Pure Verbal Reasoning	Agentic Environment Execution
State visibility	Full internal visibility	Latent constraints (hidden real-world limitations discovered at runtime)
Action reversibility	Erase text with “never mind”	Irreversible action (operations permanently altering external environments)
Tool reliability	Deterministic token steps	Unpredictable network and vendor API failures
Plan validation	Static language coherence	Environmental grounding (verifying feasibility against dynamic tool feedback)

Text-based reasoning easily reverses mistakes because intermediate generation steps alter only scratchpad tokens. Physical actions like submitting non-refundable procurement orders alter external states permanently.

---

6. Decomposed Prompting and Specialized Sub-Task Handlers

In short
– Decomposed prompting routes typed sub-tasks to specialized model handlers.
– Isolated handlers reduce token costs and assign cheaper models to sub-problems.
– Programmatic control sequences handlers, anticipating recursive frameworks like RAO, RLM, and MACU.

6.1 Modular Handler Routing

A central decomposer splits reasoning problems into sub-questions paired with dedicated model handlers.
– 2023 Khot foundation: decomposed prompting [A technique that breaks a compound query into specialized subtasks and routes each to a dedicated sub-agent or tool handler.] routes sub-tasks to handlers.
– 1910 birth query: retrieves isolated historical facts via a general QA handler.
– Relational QA handler: maps related entities, such as produced films.
– Aggregation handler: computes combined properties like total award counts across results.
– Procurement routing: divides vendor queries, wiki compatibility checks, and requisition filing.

Fig 10. Decomposing complex queries into typed sub-tasks routes distinct steps to dedicated handlers.

Dedicated handlers isolate sub-goals from global reasoning traces.

6.2 Isolated Handler Optimization

Handlers operate with targeted few-shot prompts and dedicated tools without global context bloat.
– Context reduction: Fried notes sub-tasks need far less context than complex problems.
– Cost allocation: assigns cheaper models to simple lookups, reserving high-capacity models for difficulty.
– Isolated tuning: optimizes demonstrations and tools per handler without polluting global memory.

Specialized prompts lower token costs and prevent tool interference.

6.3 Programmatic Control and Fine-Tuning

Workflows use code to sequence execution and pass intermediate outputs into downstream calls.
– Independent fine-tuning: developers train handler models separately on domain-specific data.
– Programmatic control: enforces execution order and passes intermediate outputs as arguments.
– Framework bridge: chaining states forward anticipates recursive frameworks like RAO, RLM, and MACU.

Explicit code orchestration prevents compound reasoning failures across dependent sub-tasks.

---

7. Textual Deliberation versus World Action and Irreversibility

In short
– Language model deliberation mutates scratchpad text, whereas agent actions mutate external environments.
– Irreversible actions like purchase requisitions require strict precondition verification to prevent catastrophic failures.
– Pretrained models propose plans, using environmental grounding instead of exhaustive combinatorial search.

7.1 Divergence Between Deliberation and Action

Fried contrasts pure textual deliberation with world action across state modification, information revelation, execution failure, and irreversibility.
– State modification: tool actions alter external reality, unlike scratchpad tokens that modify only internal prompt context.
– Information discovery: actions uncover unobserved data, such as querying vendor sites for GPU pricing and inventory.
– Execution failure: tool calls fail at runtime from network errors, missing parameters, or physical constraints.
– Irreversible action: irreversible actions (operations that permanently alter the external environment and cannot be undone) cannot retract.
– Token revocability: text deliberation is completely revocable by generating correction tokens like “never mind”.

Fig 11. World actions mutate external state and create unrecoverable side effects unlike text reasoning.

Attribute	Pure Text Deliberation	Environmental Action
Target State	Modifies scratchpad context tokens	Mutates external environment state
Latent Data	Cannot discover unobserved information	Gathers live vendor data
Recovery	Revocable by generating corrections	Permanent once irreversible actions execute

External systems enforce physical constraints that token generation escapes. Agents must anticipate runtime failures and unrecoverable side effects.

7.2 State Feedback and Irreversible Actions

Classical planning formalisms guarantee execution safety by validating environmental preconditions before firing actions.
– Logical predicates: truth values over domain objects evaluate whether blocks are clear or resting on tables.
– Action preconditions: formal prerequisites that must evaluate to true before an operation can execute.
– Deterministic effects: successful executions assert positive predicates and retract negated predicates from the state.
– 1971 STRIPS: Fikes and Nilsson introduced STRIPS (a classical planning formalism using preconditions and effects).
– Block world search: finds valid sequences transitioning from initial on(blue, orange) to goal on(orange, blue).
– 2023 PlanBench: Valmeekam benchmarks whether models evaluate action applicability and plan validity in PDDL.

pick-up(x): on-table(x) ∧ clear(x) ∧ hand-empty -> holding(x) ∧ ¬on-table(x) ∧ ¬hand-empty

Submitting an erroneous purchase requisition cannot be undone. Verifying preconditions prevents unrecoverable procurement mistakes.

7.3 Search versus Environmental Grounding

LLM agents replace combinatorial state graph search by dynamically grounding candidate plans with tool feedback.
– Algorithmic search: classical BFS, DFS, and A struggle with exponential open-domain state spaces.
– Zero-shot proposals: pretrained models propose sensible plans, from rearranging blocks to procurement or code debugging.
– Implicit dynamics: models lack explicit transition functions or predicate tables for web environments and software repositories.
– Runtime feedback: observing tool execution results inspects whether internal wiki hardware compatibility assumptions held.
– Environmental grounding: environmental grounding (verifying candidate plans against dynamic runtime feedback rather than static proofs) guides execution.
– Adaptive replanning:* unexpected tool observations, such as out-of-stock GPUs, trigger dynamic plan revisions.

Fig 12. Modern agents replace exhaustive algorithmic search by grounding candidate plans in environmental feedback.

Open-domain environments lack explicit transition matrices. Agents must uncover dynamic rules by testing actions.

---

8. Classical STRIPS Planning

In short
– STRIPS represents environments through grounded logical predicates over symbolic domain objects.
– Action schemas strictly gate transitions behind verified preconditions, preventing illegal operations.
– Classical planners synthesize provable plans using heuristic graph search over state spaces.

8.1 Formal state space as predicates

Classical planning represents world configurations through grounded symbolic predicates evaluated over domain entities.

• 5 core predicates: on-table(x), on(x, y), clear(x), holding(x), and hand-empty define blocks world.
• Relational truths: predicates describe exact physical object relations at each discrete time step.
• Closed-world assumption: planners evaluate any unlisted predicate as logically false.
• Benchmark standard: PlanBench (Valmeekam et al., NeurIPS 2023) tests models against formal STRIPS (a classical planning formalism that defines world states with logical predicates and governs transitions using actions with explicit preconditions and effects.) and PDDL standards.
• Procurement state example: tracking budget-approved(), vendor-in-stock(GPU), and compatible(GPU, cluster) before ordering.

Explicit predicate sets let systems verify logical consistency before any physical intervention occurs.

8.2 Action schemas govern state transitions

Deterministic action schemas enforce logical preconditions that must hold before executing transitions.

• Precondition checks: pick-up(x) requires clear(x), on-table(x), and hand-empty to be true.
• Positive effects: successful actions explicitly assert newly true predicates like holding(x).
• Negative effects: transitions explicitly retract invalidated predicates such as hand-empty and on-table(x).
• Preventing invalid actions: strict logical gates stop robots from grasping obstructed or nonexistent items.
• Procurement action rule: purchase actions require verified cluster compatibility and financial approval before submitting.

Fig 13. Blocks world action schemas deterministically update world predicates through preconditions and effects.

Explicit preconditions prevent costly real-world failures by blocking actions during invalid states.

8.3 Planning through graph search

Planners frame task execution as finding valid transition paths bridging initial and goal states.

1. Evaluate state: check current true predicates against the desired goal state.
2. Expand transitions: identify action schemas whose preconditions evaluate to true.
3. Apply effects: generate successor states by asserting and retracting predicates.
4. Search path: repeat until reaching the goal state, such as on(orange, blue).

Fig 14. A synthesized four-step plan systematically clears prerequisite block obstructions to reach goals.

Attribute	Classical STRIPS Planning	Modern LLM Agents
World model	Explicit, complete predicate sets	Implicit, probabilistic text representations
Action validity	Provable symbolic preconditions	Heuristic tool calls and prompts
Search method	Systematic BFS, DFS, A* search	Autoregressive sampling and prompting

• Graph search algorithms: planners find paths with breadth-first search, depth-first search, and A*.
• Domain heuristics: domain-independent heuristics guide A* graph search through large problem spaces.

Systematic state space search guarantees sound, executable sequences without relying on trial-and-error execution. Daniel Fried notes that classical methods provide formal guarantees that implicit language models lack.

---

9. Search to Grounded Verification

In short
– LLM agents replace symbolic search with empirical environmental verification and dynamic recovery.
– Programmatic plans use executable code and APIs to combine verifiability with expressiveness.

9.1 Shift to environmental grounding

Agents pivot from classical state search to runtime tool feedback and error recovery.

• Classical planning: searches explicit states and preconditions using algorithmic methods like $A^*$.
• Implicit models: LLMs easily generate candidate plans, but cannot internally verify world accuracy.
• Environmental grounding (verifying feasibility via runtime feedback): agents validate actions dynamically against external tools.
• Dynamic recovery: agents observe runtime execution failures and adapt when actions fail.

Fig 15. LLM planning trades combinatorial search for empirical verification and runtime error recovery.

Procurement environments hide real-time vendor constraints. Runtime tool feedback catches unexpected execution failures immediately.

9.2 Plan verifiability and execution

Agent plans balance formal verifiability with broad generality across different task formats.

Plan format	Verifiability	Generality
Formal (STRIPS [classical logic planning])	Symbolic predicates	Low
Natural language	None	Maximum
Programmatic	Executable code	High

• 2023 systems: Binder, ProgPrompt, and Code as Policies generate code calling APIs.
• Code as Policies (generating code as plans): LLMs call perception and actuation APIs.
• Robotics example: code invokes object detectors to locate blocks and manipulators to move them.
• Modular control: programmatic structures enable loops, retries, and delegation to specialized neural models.

Executable code provides verifiable control flow. Specialized neural APIs handle flexible real-world perception.

---

10. Programmatic Plan Representations: Code as Policies

In short
– Code plans combine verifiable programmatic structure with expressive natural language model capabilities.
– Executable loops, conditionals, and API calls handle state verification, retries, and sub-agent routing.
– Static workflows cut costs, while adaptive agents dynamically modify plans when executions fail.

10.1 Transitioning to Executable Code Plans

Code representations bridge formal verification and natural language by translating user prompts directly into executable programs.

• STRIPS [A classical planning formalism that defines world states with logical predicates and governs transitions using actions with explicit preconditions and effects.]: guarantees checkable, logically grounded state transitions.
• Natural language plans: provide broad semantic flexibility without structural execution guarantees.
• Code as Policies [An approach where a language model generates executable code containing control flow, loops, and API calls to serve as the agent’s plan.]: translates high-level prompts directly into executable Python code (Liang et al., 2023).
• ProgPrompt and Binder: generate programs interfacing with perception APIs and controllers (Singh et al., 2023; Cheng et al., 2023).
• Pretrained code models: create contextually valid execution scripts without costly symbolic state search.

Fig 16. Programmatic plans bridge formal logic and natural language by querying domain APIs.

Code generation replaces expensive symbolic state searches with pretrained syntax distributions.

10.2 Control Flow and Dynamic Execution

Native programming constructs manage execution state, runtime retries, and subtask delegation to specialized tools.

• Dynamic while loops: implement postcondition checks and retry failed steps automatically.
• Specialized modules: delegate perception subtasks to ResNet detectors or auxiliary LLMs.
• CodeAct: confirms programmatic representations provide a natural substrate for tool manipulation.

Fig 17. Programmatic control loops wrap deterministic logic around specialized neural endpoints.

Executable code catches errors early and triggers retries before trajectory failures compound.

10.3 Spectrum of Planning Strategies

Fried categorizes planning strategies by when the agent commits to its execution path.

Strategy	Commitment Timing	Execution Replanning
Developer workflow	Fixed upfront	No replanning allowed
Plan-then-execute	Entire sequence upfront	No mid-trajectory revisions
Adaptive agent	Dynamic during execution	Active replanning on feedback

for v in VENDORS:               # fixed list
    specs[v] = read_specs(v)    # model call
ok = [v for v in specs if fits(v)]
requisition(cheapest(ok))

• Agentless architecture: hardcodes control flow while using model calls for discrete subtasks.
• Upfront planning: lowers inference costs by executing predictable subtasks on smaller models.
• 4 vendor failures: break static scripts, requiring adaptive agents like RAO or MACU to search a fifth.

Static workflows ensure low latency, but adaptive replanning handles unexpected vendor failures.

---

11. Dynamic Replanning and Adaptive Execution

In short
– Systems balance fixed code procedures against dynamic replanning when environmental assumptions fail.
– Decoupling high-level language planning from motor execution optimizes token cost and grounding accuracy.

11.1 Planning and Execution Spectrum

Agent systems balance upfront decision control against dynamic runtime environmental grounding [verifying candidate plans and action feasibility against dynamic runtime feedback from external tools rather than through static proofs].

Architecture	Decision timing	Flexibility	Failure response
Developer workflow	Before execution	Rigid candidate lists	Halts if all candidates fail
Plan-then-execute	Before execution	Model selects candidates	Commits to failing batch
Adaptive agent	During execution	Dynamic candidate discovery	Replans upon tool errors

for v in VENDORS:               # fixed list
    specs[v] = read_specs(v)    # model call
ok = [v for v in specs if fits(v)]
requisition(cheapest(ok))

• Developer-defined workflow: static scripts run isolated model calls over predetermined vendor arrays.
• Plan-then-execute agent: the model selects candidate vendors upfront but commits before executing queries.
• Adaptive agent: dynamic replanning triggers a search for new vendors when initial candidates fail.
• Latent constraints [hidden real-world limitations—such as physical dimensions or vendor lead times—that only become evident after querying external systems during execution]: missing cluster space forces the agent to alter its purchasing strategy.

Fig 18. Trade-offs between upfront static procedural choices and dynamic execution replanning.

Fixed procedures run predictably with small models. Environmental failures require runtime replanning to uncover viable paths.

11.2 Scaffolding Versus Model Capability

Engineering choices trade strict programmatic guardrails against the flexible problem-solving capacity of frontier models.

• Rigid scaffolding: hardcoded harnesses prevent wild model deviations in unverified domains.
• Model autonomy: frontier foundation models solve open-ended coding challenges better without restrictive harnesses.
• Agentless harness: fixed scaffolding provided early success but constrained newer, stronger foundation models.
• Policy adherence: strict workflows guarantee compliance when evaluating GPU cluster power limitations.
• Evaluation gap: unconstrained autonomous agents risk silent failures without robust domain-specific evaluation benchmarks.

Developers start with fixed workflows when reliability matters most. Autonomous replanning becomes viable as evaluation improves.

11.3 Drivers for Planning Structure

Four system pressures determine whether an agent requires explicit plan representations over reactive execution.

• Modularity: decomposition isolates subtasks and routes specialized queries to distinct model backends.
• Runtime feedback: tool errors trigger subgoal revisions instead of repeating failed web interactions.
• Long horizons: structured plan artifacts prevent early requisition errors from corrupting long interaction histories.
• System control: explicit plans establish review checkpoints before executing an irreversible action [an operation—such as submitting a purchase requisition or deleting files—that permanently alters the external environment and cannot be undone].
• Task dependency graph [a structured map defining which subtasks can execute concurrently and which must wait for the completion of prerequisite steps]: dependencies schedule hardware wiki verification before issuing financial purchase orders.

Structured plans bound context growth across hundred-step runs. Human intervention checkpoints protect external systems from irreversible errors.

11.4 Planner-Executor Modularity in Practice

Separating abstract reasoning from low-level motor execution prevents context bloat and resolves visual action bottlenecks.

• 7-billion parameter executor: 7B grounding models translate natural language subgoals into exact pixel coordinates.
• Two-stage separation: high-level planners write visual goals without wasting context on numeric screen coordinates.
• UGround pipeline: modular architectures delegate screen parsing to models trained specifically on synthetic interactions.

1. High-level planner inspects the vendor website screenshot to formulate an abstract action description.
2. Low-level 7B executor receives the instruction and outputs precise click coordinates.

Fig 19. Two-stage pipelines decouple visual language planning from low-level screen coordinate grounding.

Generalist models lack visual grounding precision. Modular executors optimize coordinate generation using specialized training data.

---

12. Modular Architectures: Decoupling Planner and Executor Roles

In short
– Planners generate natural language subgoals while dedicated executors handle pixel coordinates.
– Modular isolation prevents context bloat across long horizons and improves interface grounding.

12.1 High-Level Planning and Low-Level Action

Planner models inspect user interfaces and generate goals instead of emitting precise pixel coordinates.

• Reasoning split: models excel at abstract reasoning but struggle with fine-grained motor control.
• Planner role: GPT-4o inspects the page to generate natural language subgoals instead of coordinates.
• Web search example: finding the cheapest 4K monitors relies on decoupled high-level planning.

Fig 20. Planners generate natural language subgoals while low-level models execute raw pixel coordinates.

Separating planning from execution prevents fine-grained motor noise from corrupting abstract reasoning.

12.2 Context Isolation and Grounded Execution

Modular agent systems isolate task context by routing subgoals directly to specialized execution modules.

• Context isolation: Fried shows modular sub-agents prevent context explosion over long horizons.
• Targeted dispatch: routes abstract steps, like typing into a search bar, to execution stages.
• 7B parameter models: UGround (Gou et al., ICLR 2025) and Agent S (Agashe et al., ICLR 2025).
• Synthetic data training: dedicated executors learn to map text descriptions directly to screen coordinates.
• Independent optimization: planners maintain task context while specialized executors master interface grounding.

Isolating execution stages keeps low-level interface interaction from exhausting the planner’s context window.

---

13. Summary

• Reactive fragility: Pure reactive loops cause context compaction and risk executing irreversible actions without verification.
• Explicit plans: Inspectable, context-bound plans isolate dependencies and require verification before triggering non-reversible operations.
• Modular decomposition: Decomposed prompting routes typed subtasks to specialized handlers, reducing token bloat and inference costs.
• Environmental grounding: Agents replace classical symbolic search by validating candidate actions dynamically against external runtime feedback.
• Programmatic policies: Representing plans as executable code enables control flow, dynamic retries, and modular API delegation.
• Decoupled execution: Separating abstract language planners from low-level grounded executors bounds context and sharpens motor precision.

Structuring agent architectures around explicit plans, grounded verification, and decoupled execution transforms fragile reactive systems into robust, reliable autonomous workflows.

---

Source

Lecture: Planning, Task Decomposition, and Multi-Agent Coordination by Daniel Fried, Carnegie Mellon University.
Course: CMU 11-768 AI Agents (Fall 2026), Lecture 5, first half.
Video: YouTube · Slides: PDF · Course page: cmu-agents.com

Further reading referenced in the lecture:

• Cursor · “Introducing Plan Mode,” 2025
• Claude Code permission modes
• OpenAI model guidance
• Kojima et al. · NeurIPS 2022
• Wang et al. · ACL 2023
• Zelikman et al. (STaR) · NeurIPS 2022
• DeepSeek-AI (DeepSeek-R1), 2025
• Least-to-Most · Zhou et al., ICLR 2023 · Figure 1
• Recursive Language Models · Zhang et al., 2025
• Decomposed Prompting · Khot et al., ICLR 2023 · Figure 1
• PlanBench · Valmeekam et al., NeurIPS 2023 Datasets & Benchmarks · p. 6
• STRIPS · Fikes and Nilsson, Artificial Intelligence 1971
• Code as Policies · Liang et al., ICRA 2023
• ProgPrompt · Singh et al., ICRA 2023
• Binder · Cheng et al., ICLR 2023
• Anthropic · “Building effective agents,” 2024
• UGround · Gou et al., ICLR 2025 · Figure 2
• Agent S · Agashe et al., ICLR 2025

---

dataHacker.rs — LLM_log #034: From Chain-of-Thought to World Action — Why and How LLM Agents Plan. By Vladimir Matic.