Part 1 of 5 · 2 min read
Overview
In this module you will
- Break a goal into steps with dependencies and see which steps can run together.
- Choose between adaptive (ReAct), plan then execute, and plan with replanning, and say why.
- Recognise tasks whose plan cannot be written up front because it depends on something not yet discovered.
- Add replanning triggers so one failure does not sink the whole run.
- Measure the trade between cost, speed and robustness instead of arguing about it.
Module 1 built a loop that decides one step at a time. That is flexible but costs a model call per step, and the model re-reads a growing history each time. The alternative is to ask the model for a plan first (a list of steps with their dependencies), run it with ordinary code, and call the model again only when needed. Plans are cheaper, can run steps in parallel, and can be read and checked by a person before anything happens. They are also brittle: a plan written before the facts are known can be wrong, and a plain executor has no way to notice. Most real agents sit somewhere between the two, and the interview question is knowing where.
About the examples
Everything here is an offline imitation. The "planner" is a rule program that reads each question and writes a correct plan; it never writes a bad one. The "adaptive" agent is the same program revealing the same steps one model call at a time. So the experiment isolates structure (when model calls happen, what can run together, what happens on failure) and says nothing about whether a real model plans well. The tools are a tiny invented knowledge base of six countries, and failures are random "service busy" errors that go away on retry. Real models write incomplete, over-long and plain wrong plans, and real failures are less tidy. Read the numbers as direction only. No real model or service was called.