Project: build an agent loop from scratch
Open your editor and build the thing this module described: a bounded loop with three tools, a finish action, and full logging. About three hours, and you will end with an agent you can point at and a trace you can read.
TL;DR: Three hours, one file, no framework. Build a loop that calls a model, runs the tool it asks for, appends the result, and stops for a reason you chose. Then break it on purpose and watch what it does. Everything in the remaining six modules is easier once you have this running.
Why build it yourself
You have read four lessons about a loop. Reading about a loop and watching your own loop repeat the same call for the fourth time are different kinds of knowing, and only one of them survives an interview.
There is also a practical reason. Every later module in this course is a modification to this program: module 3 changes what the tools return, module 4 changes what the context carries, module 6 makes it survive a crash. If you build it now, the rest of the course is something you do rather than something you read.
Use a coding assistant if you want. Most of us do, and an applied AI engineer who does not is unusual. It will write the loop faster than you will. What matters is that you can read every line and say why it is there, because that is what an interviewer will push on, and it is what makes the next six modules land. Ask it to explain anything it wrote that you would not have written yourself.
What you will have
A command-line program that takes a question, works through it using three tools, and prints both the answer and the trace of how it got there. Roughly a hundred and fifty lines.
Not a product. A thing you built, understand completely, and can talk about for ten minutes.
Before you start
Module 2 of this course, and the tool-call lesson from Applied AI Engineering if you have not met tool calling before. A model API with tool support, and any language you are fluent in.
The stages
Stage 1: one tool, one call
Define one tool the model can call. Something with no side effects and real data: a lookup over a small dictionary you hardcode, a file read, a public read-only API.
Send a question, receive the tool request, print it, run it, send the result back, print the answer.
Check: you have printed the raw tool request before executing it. Look at it. That block of text is the whole mechanism, and seeing it once removes the mental model that the model "ran" anything.
Stage 2: make it a loop
Wrap it. While the model returns tool calls, execute them, append results, go again. Add two more tools so selection is a real decision rather than a formality.
Check: give it a task needing two steps in sequence, where the second depends on the first. Watch it do them in order. If it cannot, your tool descriptions are the problem rather than the model, which is module 3 arriving early.
Stage 3: stop on purpose
This is the stage that separates this from a toy, and it is the argument of the previous lesson made concrete.
Add a finish tool the model calls with its answer. Treat a reply with no tool call as an anomaly and log it loudly. Add three budgets: a step cap, a cumulative token cap, and repeat detection that halts when the same tool is called twice with identical arguments.
Check: four exits, each printing which one fired. finish, no-progress, step budget, token budget.
Stage 4: make the trace readable
Print, for every step: the tool called, its arguments, the result size, tokens so far, and cumulative cost.
Check: run a task and read the trace without re-reading your code. If you cannot tell what happened, neither can you in production, and module 7 is about exactly this.
Stage 5: break it
The most valuable hour. Five deliberate failures:
- Ask something no tool can answer. Does it stop cleanly or spend its whole budget?
- Make a tool throw. Does it recover, or repeat the failing call?
- Return an empty result rather than an error. Does it treat empty as an answer?
- Add a fourth tool that overlaps an existing one. Does selection get worse?
- Ask for something needing eight steps with a cap of five. Does it return partial work with the boundary stated, or claim a complete answer?
Check: you can describe, for each, what your agent does. That paragraph is a better interview answer than anything you could memorise.
Honest scope
About three hours, and stage 5 is where the time goes. Stages 1 to 3 are quick, especially with an assistant.
Deliberately not included: memory, persistence, multiple agents, a web interface, anything running unattended. Those are later modules, and adding them now hides the loop you are trying to see.
Do not use an agent framework. Not because frameworks are bad, but because they implement precisely the parts you are here to understand. Use one afterwards and you will recognise every piece, which is the position your two-a.m. self would like you to be in when a framework behaves unexpectedly.
When it works
Two things worth doing before you move on.
Show it to someone, even a friend outside the field, and narrate the trace. Explaining a run out loud is the exact skill the interview round in module 8 tests, and it is oddly hard the first time.
Keep it. Every remaining module modifies this program. By module 7 it will have shaped tool results, a context budget, checkpointing, and a trajectory report, and you will have built all of it yourself.
Extensions
- Add a tool that writes something, then make it ask for confirmation first.
- Log every run as one JSON line and write a script that reports average steps and repeat rate over twenty runs. That is module 7, early.
- Run the same task ten times and count how often the path differs. The variance surprises people.
Go deeper
- Agents and tool use is the mechanism, if you want it restated while building.
- Agent design patterns names the loop shapes you might reach for in stage 2.
- Practice question: When do you build an agent instead of a single LLM call? is worth re-reading once you have one running; the answer reads differently.
- Practice question: Your agent will not terminate. How do you fix it? is stage 3 as an interview question.
- Practice question: How do you make an agent survive tool failures? is stage 5, done properly.
Key takeaways
- Build it yourself once. Every later module in this course is a modification to this program.
- Stage 3 is the difference between a toy and an agent: it stops for a reason you chose, and prints which one.
- Stage 5 is where the learning is. An agent you have broken on purpose is one you can describe under questioning.
- Use a coding assistant, and be able to explain every line it wrote.
Check yourself before an interviewer does. Answer from memory first.
Why does this project ask you not to use an agent framework?