Agentic AI Patterns

Course Content

Agentic AI Patterns

9 sections · 50 lessons

What is the role of LLM-powered planning in Agentic AI?

Planning a 45-person offsiteModel turnsthe requestinto constraintsTools fetch180 liveflight optionsSolver assignstravellers to flightsModel explainsthe trade-offsManager approves;bookings run in orderDirect LLM plans broke the budget in 3 of 10 tests.
The model understands and explains; the solver does the constrained search it is bad at.

What you need to know

Forms of LLM planning

  • Implicit (ReAct): plan one step at a time inside the loop.
  • Plan-and-execute: write the plan first, execute, re-plan on failure.
  • Hierarchical: break into sub-goals, often one per sub-agent.
  • Graph (DAG): plan as dependencies, so independent steps run in parallel.

Classical versus LLM planning

Classical planners and solvers

  • Need a formal model of the domain
  • Guarantee valid, often optimal plans
  • Handle many hard constraints well
  • Brittle when the goal is vague

LLM planners

  • Work from plain-language goals and tools
  • No guarantee a plan is valid
  • Weak on long, constraint-heavy problems
  • Flexible and quick to adapt

The best systems combine them: the LLM understands the request and writes the solver's input; the solver finds the plan; the LLM explains the result.

What changed with reasoning models

Reasoning models think before acting and between tool calls. For many tasks of 5 to 15 steps, a plain tool loop with a reasoning model now matches a hand-built planner, with less code. Build an explicit planner when you need:

  • a plan artefact for human approval or audit;
  • parallel execution from a dependency graph;
  • cost control, with a strong model planning and cheap models executing;
  • a formal solver for hard constraints.

Practical rules

  • Validate the plan against the real tool list and a schema before executing.
  • Execute step by step, with a re-plan path on failure.
  • Cap plan length, re-plans and total steps; add time and spend budgets.
  • Show consequential plans to a human first.
  • If the plan is the same every time, hard-code it as a workflow.

A real-life example

A company's travel-booking agent plans an offsite: 45 employees from Bengaluru, Delhi and Mumbai to Goa, arriving before 2 pm on the 12th, returning after 4 pm on the 14th, total flight budget Rs 6 lakh, no one on a flight with more than one stop.

First version: a reasoning model planned the bookings directly. Plans read well but broke constraints: 3 of 10 test plans went over budget, and one put 12 people on a flight with 9 seats left.

Second version:

  1. The model turns the request into a structured problem: travellers, cities, time windows, budget, stop limits.
  2. Tools fetch live flight options with seat counts (about 180 options).
  3. A small optimisation solver assigns travellers to flights, minimising cost within all constraints.
  4. The model explains the plan and flags trade-offs ("12 Delhi travellers take the 6:10 am flight to save Rs 38,000").
  5. The travel manager approves; bookings run step by step, and a sold-out flight triggers a re-solve for only the affected travellers.

All test plans were now valid, and total fares were about 9% lower than the manual plans. The model did what it is good at, understanding and explaining; the solver did the constrained search.

Follow-up questions to expect

  • "Can LLMs plan?" — Well enough for short, flexible tasks with clear tools. For long or tightly constrained problems, pair them with validators or solvers.
  • "How do you re-plan efficiently?" — Re-plan from the current state for the failed part only, and cap attempts before escalating.
  • "When do you skip a planner?" — When a reasoning model in a simple tool loop already meets the success bar, or when the steps never change.