Planning — Module 15.1

How This Lesson Fits the Module & Volume

Once an AI agent has a goal and bounded autonomy, it still must decide what to do in what order. Planning is that decomposition: turning “onboard this customer” into a sequence of subgoals, tool calls, and checkpoints. It is distinct from reasoning (local inference about the next move) and from the agent loop (the runtime that executes the plan).

Vol. 14 already showed explicit plans as graphs—LangGraph nodes/edges and Haystack pipelines. Agent planning is when the model (or a planner node) writes or revises that graph at runtime.

Learning Objectives

By the end of this lesson, students should be able to:

Define planning as goal decomposition into ordered, checkable subtasks.
Contrast plan-then-execute vs interleaved (ReAct-style) planning.
Write a structured plan (JSON steps) and execute it with tools.
Identify when to replan after a failed or surprising tool result.
Relate agent plans to LangGraph / workflow graphs from Vol. 14.
Avoid over-planning trivial one-tool tasks.

Definition

Planning (in LLM agents) is the process of breaking a goal into a sequence or DAG of subgoals, tool uses, and success checks—optionally revising that structure as new observations arrive. A plan is only useful if steps are executable and verifiable.

Two Dominant Styles

Style	When the plan is written	Strength	Weakness
Plan-then-execute	Up front, then run	Auditable, cacheable, HITL-friendly	Stale if the world changes
Interleaved (ReAct)	One thought + one act at a time	Adapts to tool results	Can wander; harder to preview
Hierarchical	Coarse plan + local replans	Balances both	More moving parts

Production systems often hybridize: a coarse plan the user (or a supervisor) can see, plus interleaved reasoning inside each step. That is also how many agentic workflows look—deterministic skeleton, agentic nodes.

Plan-Then-Execute Sketch

Ask the model for a machine-readable plan, validate it, then execute. Humans can edit the plan before any write tool runs—a natural HITL seam.

import json
from openai import OpenAI

client = OpenAI()
PLAN_SCHEMA_HINT = """Return ONLY JSON:
{"goal": str, "steps": [{"id": int, "action": str, "tool": str|null, "done_when": str}]}
Use tools: search_kb, get_order, create_ticket. Max 6 steps."""

def make_plan(goal: str) -> dict:
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": PLAN_SCHEMA_HINT},
            {"role": "user", "content": goal},
        ],
        response_format={"type": "json_object"},
    )
    plan = json.loads(resp.choices[0].message.content)
    assert 1 <= len(plan["steps"]) <= 6
    return plan

def execute(plan: dict, tools: dict) -> list[str]:
    logs = []
    for step in plan["steps"]:
        tool_name = step.get("tool")
        if tool_name:
            result = tools[tool_name]()  # pass real args in production
            logs.append(f"step {step['id']} {tool_name}: {result}")
            if "not found" in result.lower():
                logs.append("REPLAN needed")
                break
        else:
            logs.append(f"step {step['id']} think: {step['action']}")
    return logs

tools = {
    "search_kb": lambda: "Refunds take 5–7 days after approval.",
    "get_order": lambda: "ORD-1042 shipped",
    "create_ticket": lambda: "TICKET-88 opened",
}
print(make_plan("Customer asks where refund is for ORD-1042"))

When to Replan

Keep the plan

Tool result matches done_when
Only formatting noise
Next step still valid

Replan

Missing entity / 404
Conflicting facts
New user constraint

Stop / escalate

Repeated failure
Policy violation
Ambiguous high-risk goal

Strengths

Makes long tasks inspectable
Enables HITL on the plan itself
Maps cleanly to LangGraph nodes
Improves tool budget discipline

Tradeoffs

Up-front plans go stale
JSON plans can be hallucinated tools
Over-planning wastes tokens
Need validation against allowlists

Common Misconception

“A good agent writes a perfect 20-step plan once and never changes it.” The world (APIs, tickets, user intent) moves. Treat plans as hypotheses: execute, check done_when, replan or halt. A one-tool question should not trigger a novel-length plan.

Knowledge Check

Short Answer: What is planning in an LLM agent? Answer: Decomposing a goal into ordered/checkable subtasks and tool uses.
True/False: Plan-then-execute is always better than ReAct. Answer: False—it can go stale; interleaved adapts better.
Multiple Choice: A natural HITL seam is: (a) editing the plan before writes, (b) training FAISS, (c) CSS. Answer: (a).
Short Answer: Name one Vol. 14 artifact that looks like a pre-written plan. Answer: LangGraph graph or Haystack pipeline (either).
True/False: Plans should be validated against the tool allowlist. Answer: True.
Multiple Choice: Hierarchical planning means: (a) only one giant step, (b) coarse plan + local replans, (c) no tools. Answer: (b).
Short Answer: When should you replan? Answer: Failed/surprising tool results, conflicts, or new constraints.
Short Answer: How does planning differ from reasoning in this module? Answer: Planning structures the task; reasoning decides locally / infers the next move.
Multiple Choice: Max step counts in a plan mainly control: (a) GPU clocks, (b) runaway cost/wander, (c) embeddings. Answer: (b).
True/False: Every FAQ lookup needs a multi-step plan. Answer: False.

Key Takeaways

Planning decomposes goals into executable, verifiable steps.
Use plan-then-execute for auditability; interleaved planning for surprise; hybrid in production.
Validate plans (tools, step limits) and replan on failed observations.
LangGraph/Haystack graphs are compiled plans; agents may write them dynamically.
Next: reasoning—how the model thinks between steps.

Trainer’s Guide

Whiteboard: Convert “migrate this customer from plan A to plan B” into a 5-step plan with done_when checks.

Lab: If get_order returns unknown, force a replan that uses search_kb instead of blindly calling create_ticket.

Recap: Planning turns goals into checkable steps—and revises them. Continue with Reasoning.