Why This Matters
In Chapter 1, the agent's dispatch function was a single if statement. That works for one tool. It does not work for ten. Every real coding agent needs dozens of tools — read files, write files, run commands, search code, list directories. Without a registry pattern, adding a new tool means editing the dispatch function, and testing tools means running the entire agent. A tool registry solves both problems by making tools self-describing, pluggable, and independently testable.
What You Will Build
A ToolRegistry class that stores tool definitions and their handler functions. The agent loop will look up tools by name, validate arguments, execute the handler, and return structured results.
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 a pluggable tool system. The agent can use any tool you register, and each tool returns structured data the model can reason about. But the agent still works reactively — it reads the user's request and starts calling tools immediately without a plan.
What happens when the task is complex? "Refactor the authentication module" is not a single tool call. It requires reading multiple files, understanding dependencies, and making changes in the right order.
In Chapter 3: Planner and Task Graph, you will teach the agent to think before it acts — generating a plan of tasks with dependencies before executing any of them.