Course Content
Agentic AI Patterns
9 sections · 50 lessons
What is a planning module in AI agents, and why is it important?
What you need to know
The forms of planning
| Form | How it works | Good for | Weakness |
|---|---|---|---|
| Implicit (ReAct) | Model plans one step ahead each turn | Short, adaptive tasks | Wanders on long tasks |
| Plan-and-execute | Write a full plan, run steps, re-plan on failure | 5 to 20 step tasks; approval | Plan goes stale |
| Hierarchical | Goal becomes sub-goals, each with a sub-plan | Large tasks, sub-agents | More calls and handoffs |
| DAG planning | Plan is a graph of dependencies | Parallel tool calls | Needs a scheduler |
Why planning helps
- Fewer expensive calls. The strong model plans once; cheap calls execute.
- Parallelism. A dependency graph shows which steps can run at the same time.
- Approval. A human can read "I will cancel 3 bookings and refund Rs 18,400" before anything happens.
- Debuggability. You can compare the plan to what actually ran.
How reasoning models changed this
Reasoning models spend hidden "thinking" tokens before answering, and can think again between tool calls. For many tasks they plan well enough inside the loop that a separate planner adds cost without gain. An explicit planner still earns its place when you need a plan artefact: for approval, for parallel execution, for splitting work between models, or for an audit trail.
Validate the plan before running it
LLM plans can name tools that do not exist or put steps in the wrong order. Check them in code:
1TOOLS = {"list_vendors", "get_quote", "normalise_quote", "compare_quotes", "draft_summary"}2MAX_STEPS = 834def validate_plan(plan):5 errors = []6 if len(plan) > MAX_STEPS:7 errors.append(f"plan has {len(plan)} steps; limit is {MAX_STEPS}")8 ids = set()9 for step in plan:10 if step["tool"] not in TOOLS:11 errors.append(f"step {step['id']}: unknown tool {step['tool']}")12 for dep in step.get("needs", []):13 if dep not in ids:14 errors.append(f"step {step['id']}: depends on {dep}, which has not run yet")15 ids.add(step["id"])16 return errorsFor a plan where step 3 needs step 4, and step 5 uses an email_vendor tool that does not exist, this returns two errors. You send them back to the planner to fix before anything runs.
A real-life example
A procurement agent is asked: "Get quotes for 200 laptops from our four approved vendors and recommend one."
The planner writes a graph: list approved vendors (step 1); get each vendor's quote (steps 2 to 5, which do not depend on each other, so run in parallel); normalise each quote to price per unit including GST and delivery (steps 6 to 9); compare (step 10); draft the recommendation (step 11).
Running steps 2 to 5 in parallel took 3 seconds instead of 11. When vendor C's quote API timed out, only that branch was re-planned: the agent used the emailed PDF quote instead. The buyer saw the plan up front and the final comparison table, with each number traced to a source.
Follow-up questions to expect
- "When would you skip planning?" — When the steps are always the same. Hard-code them as a workflow; it is cheaper and testable.
- "How do you handle a plan that fails midway?" — Re-plan from the current state, not from scratch, and cap the number of re-plans (for example 2) before escalating.
- "Are LLMs good planners?" — Good for short, flexible plans with natural-language goals. Weak on long, tightly constrained plans. For scheduling or routing, let the model build the input for a real solver.