Why This Matters
An agent without a plan drifts. Give it a complex request — "Add user authentication to this Express app" — and it will start writing code immediately, hoping each step leads somewhere useful. Sometimes it works. Often it does not: it edits a file before reading it, implements a feature before its dependency exists, or loops in circles without making progress.
A planner fixes this. Before executing anything, the agent generates a structured list of tasks with dependencies. Then it executes them in order. This is the difference between an agent that gets lucky and an agent that reliably completes multi-step work.
What You Will Build
A planning step that takes a user request and produces a task graph — a list of tasks with dependencies between them. The agent then executes tasks in dependency order, tracking which are done, which are pending, and which are blocked.
Story Mode for this chapter is coming soon
We are crafting a fun, code-free explanation with metaphors and interactive mini-games. In the meantime, switch to Builder Mode to start learning.
What You Can Do Next
You now have an agent that plans before it acts. It decomposes complex requests into tasks, respects dependencies, and tracks progress. But there is a problem growing quietly in the background: the message array.
Every LLM call, every tool result, every planning response — they all accumulate in the message array. For a four-task plan where each task takes five turns, that is 40+ messages. Context windows are finite. Eventually, the model will lose track of earlier context or your API calls will fail because the message payload is too large.
In Chapter 4: Memory, Summaries, and Context Control, you will learn to manage context: truncating old messages, summarizing completed work, and saving checkpoints for recovery.