The Capstone

Everything up to here has been reading, listening, and practising moves in isolation. The capstone is where you put them together and produce something a real hiring manager can review. That is deliberate. "I took a course" is evidence of time spent; a deliverable is evidence of capability.

This lesson tells you what to build, what the rubric is, and how to share it so it does useful work for you.

What you are building

Pick a fictional-but-realistic customer. Any domain — fin-serv compliance, healthcare intake triage, a SaaS onboarding assistant, a government constituent-correspondence summariser. The domain should be one where you can defensibly label 30 to 100 examples without needing a specialist, and where the FDE shape of the work (ambiguous problem, narrow tools, measurable outcome) fits.

Four artefacts are what you ship. Each one is small. The rubric is harsh because the pieces are small.

That shape mirrors the engagement you walked in the previous lesson. The hiring managers you want to reach will recognise it.

The rubric

Not every capstone will be great. Here is what "great" looks like, so you can self-assess before you publish.

• Does the eval suite catch a regression you introduced on purpose? Make a specific change — weaken the prompt, remove a tool, shorten the retrieval window — and show that the eval numbers move in the right direction. If the suite cannot see the change you made, it cannot see the changes you did not make.
• Does the MCP server pass a ten-minute security review? Hand it to a friend who has not seen it. Give them ten minutes. They should be able to tell you, at the end of the ten minutes, what the trust boundary is and what an attacker with the agent could do. If they cannot, the server is too complicated.
• Is the memo short enough that a CTO will actually read it? One page. Not one page in six-point font. Three to five hundred words, three to five numbers, one explicit risk. If it needs an appendix, either move the thing in the appendix into the memo or cut it.
• Did you write down what you would do next and what you would not? The discipline that separates a good FDE memo from a design document is the willingness to name what you decided against. "We considered X, and here is why we chose not to do it" reads mature; "we did Y" reads incomplete.

Hitting three of the four is a shippable capstone. Hitting all four is the thing you link in a cold application.

How to actually do this in a week

A capstone can be built in forty concentrated hours. The shape:

1. Step 1

   Monday — pick a problem and label the data

   Fictional customer, workflow written down in half a page, 30 to 100 labelled examples. This is the hardest step and the one everything else depends on. Do not skip ahead.

2. Step 2

   Tuesday — thin end-to-end

   The agent calls one MCP tool, reasons, produces an answer. No polish. The eval harness runs against your labels and prints a baseline number. The judge rubric lives in a markdown file.

3. Step 3

   Wednesday — reach signal

   Iterate the prompt and tool surface against the eval. Keep a note of every change and what it did to the number. Most of the move happens here.

4. Step 4

   Thursday — plant the regression and tighten the boundary

   Introduce a deliberate regression and show the eval catching it. Review the MCP surface honestly — remove any tool that is there for convenience rather than need. Tighten the scopes.

5. Step 5

   Friday — write the memo and publish

   Memo to the fictional CTO, under 500 words. Repo README with how to run it. Push to GitHub. Add the link to your portfolio or CV.

Sharing it

The capstone is only as useful as the number of right people who read it. Four practical things.

• Publish the repo as public. Nothing in a capstone is sensitive — everything is fictional. A private repo is invisible to the people you want reading it.
• Pin it on your GitHub profile. The top of your profile is prime real estate for a hiring manager who has 90 seconds.
• Link the memo first, the repo second. In an application, a one-paragraph pitch and a link to the one-page memo will open the repo for you. A link straight to the repo closes it.
• Use it in interviews. When a loop asks you to walk through a project you are proud of, this is that project. The structure of the memo — what, how it is measured, what the risk is — is the structure of the conversation a real FDE round wants to have anyway.

What to take away

The capstone is where every lesson in the course becomes a thing someone else can review. Four artefacts: an agent, an MCP server, an eval suite, and a one-page memo to a fictional CTO. The rubric is harsh because the artefacts are small — the eval suite has to catch a regression you planted, the MCP server has to survive a ten-minute security review, the memo has to fit on one page without an appendix, and the memo has to say what you decided against as well as what you built. A week of focused work ships all four. Publish the repo, pin it, link the memo first, and bring it to every interview you sit.

If the course got you this far, the FDE Masterclass Certification is the natural next step: one paper across the whole syllabus, the same scenario weighting the course teaches to, sat in a single two-and-a-half-hour sitting. The certificate is a proxy. The capstone is the proof.