Skip to content
Local LLM Course

Building Agent Systems

Part 24 built an agent by hand and Part 25 used other people’s. This part is about building your own, at the point where one loop and one model stop being enough: a task arrives, and answering it well means deciding where to send it, searching your documents, running a command, and writing an answer that says where each fact came from.

There is a large industry of frameworks for this, and most comparisons of them are written by people who never had to point one at a machine in their own house. So this part compares them on one criterion first: how cleanly the thing takes a base URL and a model name. A framework that assumes a hosted provider is a framework you will spend a weekend fighting.

After that the part is about restraint. Every extra agent in a system is another model call, another few thousand tokens, and another place for the work to go wrong quietly. The patterns lesson does the arithmetic for each shape before recommending any of it, and the evaluation lesson insists you measure the system before you trust it, because an agent that fails plausibly is worse than one that fails loudly.

What you will be able to do

Section titled “What you will be able to do”

By the end of this part you should be able to:

  • apply the base-URL test to any agent framework in an afternoon, and say from its own documentation whether it takes your gateway natively, needs a translating proxy in front, or does not do it at all;
  • say what a framework gives you over the loop from Part 24, and name the cases where the loop is still the better answer;
  • choose between a router, a planner and executor, a critic loop and a parallel fan-out by the token cost each one implies, rather than by which diagram looked best;
  • make retrieval a tool the agent decides to use, with query rewriting, multi-hop and a faithfulness check, and say what that costs against the plain retrieval pipeline in Part 10;
  • write a task suite with checkable outcomes, log trajectories, and report success rate, steps, tokens and cost with the variance across repeated runs;
  • test your own agent for prompt injection through documents, web pages and tool results, reason about a published tool-poisoning case, and put least privilege and approval gates where they are actually enforced;
  • build a four-role system with a small model routing and a large one answering, measure it, and write it up in a note whose numbers you can defend.

What you need first

Section titled “What you need first”

Part 24, all of it. This part uses its vocabulary without redefining it: the loop, tools as typed functions with schemas, the transcript as the thing that grows, MCP servers and clients, compaction, and the levels of autonomy. The reality check runs Part 24’s minimal-agent.py as one of its three scaffolds, so keep that lab’s directory.

Part 9’s gateway, with one more alias than you have needed so far. The project routes with a small model and answers with a large one, so alongside local/chat, local/coder and local/embed you will add an alias for the router and one for the answering model. Part 10’s document index is the retrieval agent’s corpus, and its ask.py is the baseline the agentic retrieval lesson measures against.

Part 23’s cost model, because agent-eval.py reports a cost per task only when you give it your own cost per million tokens, and Part 23 is where that figure comes from.

Part 25 is not a prerequisite, but the safety lesson here assumes you have seen a sandbox, and the Claude Agent SDK’s base-URL mechanism is the one Part 25 configures in detail.

How to work through it

Section titled “How to work through it”

Read the five lessons in order; they build. The first is a survey you will come back to when a new framework appears, and it is written so that the test outlives the table. The second is the one that saves you money. The fifth is the one that stops you doing something you cannot undo.

Then do the project, which is ninety minutes with a terminal open and both models served, and finish with the reality check. Put them in that order and not the other way round: the reality check compares your system with two other scaffolds, so it needs your system to exist.

Keep everything. Part 27 turns the trajectories this part logs into training data, and the capstone asks for exactly this system again, with the numbers.

Part26 of 27Level5 — Agentic EngineerPages7Estimated time4.7 hours

0 / 7 lessons in this part completed