The brief

Build an agent that does one job you actually have. Not a demo. Something you will run again
next week.

Good candidates, from what this course has covered:

  • A release-notes agent: reads git log, drafts notes, writes a file
  • A triage agent: reads new issues over MCP, labels and summarises them
  • A test-fixing agent: runs the suite, reads failures, proposes fixes, never commits
  • A research agent: reads a folder of documents, answers questions with citations
  • A data-tidying agent: takes messy CSVs, checks them, writes clean ones

Pick the smallest one that would genuinely save you time.

Requirements

Your agent must have all of these. Each maps to a module, and together they are the course.

Requirement From
A loop you wrote, or the tool runner used deliberately Module 1
At least three tools, with trigger sentences in the descriptions Module 2
A permission layer on anything with side effects Module 3
Path confinement, if it touches files Module 3
A turn limit and full stop-reason handling Module 4
An outcome check — it does not trust its own “done” Module 4
A readable log of decisions and effects Module 4
Prompt caching on, and verified with cache_read_input_tokens Module 6
An eval: at least five cases, five runs each, with a number Module 7
A README saying what it touches Module 7

At least one of these, your choice:

  • An MCP server you wrote, or a third-party one consumed (Module 5)
  • Memory that survives between sessions (Module 6)
  • A sub-agent on a cheaper model, justified with eval numbers (Modules 6 and 7)

What you hand in

The code, packaged so someone else can install it.

The eval output. Your cases, your pass rates, your median turns and tokens. Not a claim
that it works — the number.

A one-page write-up answering four questions:

  1. What does it do, and what did it save you?
  2. What was its most common failure, and what did you do about it?
  3. What does it cost per run, and where does that go?
  4. What would you not trust it with, and why?

Question four is the one that matters most. An engineer who can say precisely where their
agent should not be trusted understands it. One who says “it works well” has not looked hard
enough.

The rubric

Weak Solid Strong
Tools Vague descriptions Trigger sentences, clear boundaries Wrong-choice failures found and fixed
Safety No permission layer Prompts on side effects Boundary tested with an eval case
Recovery Crashes on failure Errors fed back, turn limit Verify step catches false finishes
Context No caching Caching on and verified Measured before and after
Evidence “It works” An eval with a number Numbers drove a decision you can name
Honesty Claims it is reliable Names the failure modes Says what it should not be trusted with

The rightmost column is not about more features. Every entry in it is the same thing: you
measured, and the measurement changed what you did.

What you have actually learned

Look back at Lesson 1.1. Sixty lines: a model, a menu, a loop.

Everything since has been one of two things. Making it safe — permissions, boundaries,
limits, checks. Making it honest — errors that surface, claims that get verified, numbers
instead of impressions.

Nothing in this course made the model smarter. That was never available to you. What was
available was building something around it that fails loudly, costs what you expect, and tells
you the truth about what it did.

That is the job. It is the same job whichever model you use next year, and it is why we built
the loop by hand in Module 1 rather than importing one.

You cannot make the model more reliable. You can build something around it that is honest
about when it was not.

Ship it

One last thing. Run your agent on the job it was built for, for a week.

Not because the code needs it. Because the difference between an agent that demos well and one
that is genuinely useful only shows up on the fifth day, on the task you did not anticipate.

That is where Season 2 starts.

Previous