The capstone: design, build, defend

In the first lesson of this track, you did something on paper. You picked one real task from your own work and answered four questions about it: is the path predictable, which rules must always hold, one agent or several, and what earns a place in context. Then you kept the sketch. This is the lesson where you take it out.

The capstone has no new machinery in it. Everything you need has been taught: configuration that travels with a project, schemas that cannot fabricate, tools that describe themselves, seams that carry failure without dropping it, escalation rules decided in advance, and an agent that can run with nobody watching. What is new is that nobody hands you the pieces in order anymore. You choose them, you connect them, and then you do the thing that separates an architect from an assembler: you defend your choices in writing.

That last part is not ceremony. Anyone can wire an agent to a tool by following a tutorial. The professional act is being able to say, afterward: here is what the model decides and why that is safe, here is what the code guarantees and why it must, here is the seam I added and what it costs, here is what I deliberately did not build. If you can write that page, you did not just complete a track. You changed how you approach systems.

The assignment

Build a small agentic system in Claude Code, then defend it. Small is a requirement, not a suggestion. The system must have:

One clear job with a beginning and an end, taken from your lesson 1 sketch if it still holds, or a fresh pick if your first idea was too big. Good size: “turn the week’s meeting notes into a structured action list,” “answer questions about our internal style guide,” “research a purchase decision and produce a comparison.” Too big: anything with the word “platform” in it.
A project memory file that makes your standards durable: what the agent must always do, what it must never do, and how output should look. A teammate cloning your project should inherit your rules on their first run.
One custom tool the agent can call, with a description written to the five-part standard from lesson 4: purpose, inputs, outputs, boundaries, and when to use it over alternatives. A small local MCP server is the natural home for it; the official tutorial lesson 4 pointed you at is the scaffold.
Structured output for the system’s final answer, with a schema that keeps the truth legal: fields that may be absent are nullable, categories have an escape hatch, and one semantic check runs in code after the shape check passes.
One must-hold rule enforced in structure, not in the prompt. Pick the rule that would embarrass you most if broken, and make it impossible rather than unlikely.
One escalation path: a condition, decided in advance, where the system stops and asks a person instead of proceeding. Write the condition as an explicit criterion, not a feeling.

Two agents are allowed but not required. If your job genuinely splits, add one subagent and pass its context explicitly, the lesson 5 way. If it does not split, a single well-configured agent with a good tool is the stronger design, and saying so in your defense earns more respect than an unnecessary seam.

Phase one: design on one page

Before touching the keyboard, update your lesson 1 sketch into a one-page design. It needs exactly five sections, and each maps to a question you have practiced:

The job. One sentence. What comes in, what goes out, who reads it.
The path. Workflow or agent, and why. If you can draw the steps and they hold, say so and draw them.
The rules. Two lists: must-hold (with where in the structure each is enforced) and should-usually (living in the prompt).
The seams. One agent or two, what crosses the boundary if two, and what you accept losing at that seam.
The desk. What the agent carries at all times, what it fetches, and what gets written down outside the context window.

If a section is hard to fill, that is the design telling you something. A path you cannot draw might genuinely need an agent. A must-hold list that is empty means you have not thought about failure yet. Write the page; do not skip to the build.

Phase two: build in Claude Code

Work in a fresh project directory, and build in this order. Each step is one lesson coming back.

Step one, configuration first. Write the project memory file before any code exists: the agent’s standards, the output rules, the tone. This feels backward and is not. You are configuring the newest teammate before their first day, and every session you run afterward inherits it. Then add one path-scoped rule if your project has a directory that needs special handling.

Step two, the tool. Build your custom tool on a small MCP server, following the official tutorial’s shape. Spend most of your time on the description and the errors, not the logic. When the tool fails, it should say what kind of failure it was and whether retrying can help. When it finds nothing, it should say “found nothing” in a way the model cannot mistake for “something went wrong.”

Step three, the schema. Define the structured output for the final answer. Walk it once against a real input that is missing information, and watch what comes back. If the schema forces an invention, fix the schema now, before the demo ever looks good.

Step four, the guarantee. Implement your must-hold rule in structure. Then try to break it, honestly, at least three ways. The rule that survives your own sabotage is the rule you can defend.

Step five, the escalation. Wire the stop-and-ask condition. Test it by constructing the exact situation it exists for, and confirm the system stops rather than improvising.

Step six, one unattended run. Run the whole job once in non-interactive mode, the lesson 7 way, and read the output as if you were not the author. That run is your architecture’s first honest trial: nobody was there to catch it.

Phase three: the defense

Now write the page that makes this a capstone. One page, four headings, written for a skeptical senior colleague:

Where judgment lives. What the model decides, what the code guarantees, what waits for a human, and why each item is in the pile it is in.
What I traded away. Every design gives something up: flexibility for predictability, capability for cost, speed for a review step. Name your trades explicitly. A defense with no admitted costs is a sales pitch.
What breaks first. The weakest point in the system, named by you before anyone else finds it, with what would fail and what the failure would look like from outside.
What I did not build. The features you declined and why. This is where “this does not need an agent” or “this did not need a second agent” earns its place as the most senior sentence in the field.

Then put your lesson 1 sketch next to the finished design and read them together. The distance between those two pages is the most honest measure of what this track taught you. Most people find their first sketch trusted the model too much, enforced too little, and put far too much on the desk.

The rubric

Score yourself before you show anyone. Every “no” is the next thing to fix.

The job fits in one sentence, and the output has a reader.
A teammate cloning the project inherits every standard without being told anything.
The tool’s description answers: purpose, inputs, outputs, boundaries, when to use it.
A failed tool call and an empty result are distinguishable in the response.
Absent information comes back null; you verified this against a real gap.
The must-hold rule survived three honest attempts to break it.
The escalation criterion is written as a condition, not a vibe, and it fired in a test.
The system completed one unattended run whose output you would sign.
The defense names at least one real cost and one thing you refused to build.
Anyone reading the defense could predict how the system fails, not just how it works.

Why this matters when you use AI

The defense is a portable professional artifact. The system you built is a practice exercise; the page defending it is the shape of a real design review, the document teams argue over before anything ships. Practicing it on a small system you fully understand is the cheapest rehearsal you will ever get.
You now have a working reference implementation. Every future “should we agent this?” conversation goes better when you can open a small system where every decision was deliberate, point at the seams, and reason from something real instead of a vendor diagram.
The questions outlive the stack. The tools in this track will be replaced; the four headings of your defense will not. Where judgment lives, what was traded, what breaks first, what was refused: those questions have governed good engineering since before software existed.

Common pitfalls

Building big to impress. The capstone measures judgment, not surface area. A tight single-agent system with an honest defense beats a sprawling five-agent demo with an empty one, every time, in this track and in production.

Skipping the defense. It feels optional because the system already runs. It is the least optional part. An undefended system is a liability with a demo; the defense is where the learning consolidates.

Polishing the happy path. The rubric deliberately weights failure: broken rules, empty results, escalations, unattended runs. If you spent all your time making the good case prettier, you built a demo, and you know what this track thinks about demos.

Treating the sketch comparison as nostalgia. Reading your lesson 1 sketch against the finished design is the assessment. If nothing changed between them, either your first sketch was remarkable or your build was on autopilot. Be honest about which.

What you should remember

The capstone is design, build, defend, and the defense is the part that makes you an architect.
Small is a requirement. One job, one tool, one guarantee, one escalation path, one unattended run.
Configuration comes first, before code, because every later session inherits it.
Test the system where it is weakest: the missing field, the broken rule, the escalation trigger, the run with nobody watching.
The distance between your lesson 1 sketch and your final design is what this track taught you.

What’s next

This track is complete, and so is a ladder. You learned to build the parts in Building with Claude, you read a real team in AI Agent Teams, and you have now designed, built, and defended a system of your own. From here the path is depth: Anthropic’s documentation and free Academy courses go further on every surface this track touched, and the best next system to design is the real one waiting at your work. Take the defense format with you. It works on systems of every size.

If you remember one thing

Anyone can assemble an agent.
An architect can defend one.
Write the defense.