The previous lesson's checklist is internal: does the system actually work. This one is external: can someone who has never seen your capstone understand what you built, why it mattered, and what you personally decided - in under two minutes of reading, or ninety seconds of you talking.

Write the case-study README

• Problem - one paragraph, plain language, no jargon a hiring manager would not know.
• Architecture - one diagram or a short ordered list: agents, memory, tools, data, and how a request moves through them.
• Stack - name the real tools (FastAPI, LangGraph/ADK, your vector store, your memory store, your eval harness, your host) so a technical reader can place your skill level immediately.
• Evals - what TRACE found, the taxonomy you built, and at least one concrete fix with a before/after number. This is the paragraph that separates you from everyone who shipped a demo with no evidence it works.
• Memory - what you keep, when you write it, where it lives, how you retrieve it, when you forget it. Five short answers, not five paragraphs.
• Live URL and a 30-60 second screen recording, in case the live system is down when someone checks.

Turn it into interview talking points

Pick three decisions you actually made and be ready to defend each one in a single breath: why an agent and not a fixed workflow, what your evals caught that you did not expect, and one memory or security tradeoff you chose deliberately. Interviewers remember specific decisions, not feature lists.

Decision: what you chose.
Why: the tradeoff you weighed (cost, latency, control, risk).
Evidence: what you measured, saw, or shipped that proves it was the right call.

Ship the checklist