Capstone: Design, Build, And Present A Small AI Assistant

What The Capstone Is

The capstone brings the course together. Over the past eleven weeks you learned what AI is (week 1), how machine learning and neural networks work (weeks 2 and 3), how transformers and large language models produce text (weeks 4 and 5), how to prompt (week 6), how to give models knowledge and tools (weeks 7 and 8), how to evaluate and make them safe (week 9), how to build with an API (week 10), and how AI affects society (week 11).

Now you build one small assistant that uses several of these skills for a real person. Small is the key word. A focused assistant that works reliably for one task beats an ambitious one that fails in front of the audience. Plan for about six to ten hours of work in total, spread over the week after this session, with a short presentation at the end.

The Course In Five Blocks

Weeks	Block	Topics
1 to 4	Foundations	AI, machine learning, neural networks, transformers
5 to 6	Using LLMs	How they work, prompting
7 to 8	Systems	RAG, tools, agents
9 to 11	Responsible building	Evaluation, API, society
12	Capstone	Build and present

Choosing A Project

Pick a user you can name. 'Students' is vague, while 'first-year biology students who need quick revision quizzes from their lecture notes' is concrete. Then pick a single problem for that user and ask whether an assistant could make it clearly easier. Good project types include a question-answering helper over a set of documents, a quiz maker, a summarizer with structured output, a planner that uses a tool, or a writing coach with a strict rubric.

Test your idea with three questions. Can you collect at least twenty realistic inputs? Can you tell whether an answer is good? Can the first version run on your laptop with an API key and free libraries? If any answer is no, shrink the project until all three are yes.

• Document helper: RAG over course notes, with citations.
• Quiz maker: turns notes into questions with answers, in JSON.
• Meeting notes extractor: turns text into tasks and owners.
• Planner: uses a calendar or weather tool to suggest a schedule.
• Coach: gives feedback on short writing against a fixed rubric.

The Project Brief

Write the brief before writing code. It fits on one page and answers eight questions. Share it with a partner for feedback, since a second reader finds gaps quickly.

• User: who they are and what situation they are in.
• Problem: what is hard or slow for them today.
• Solution: what the assistant does, in two sentences.
• Design: prompt, knowledge source (documents or tools), model choice, and why.
• Success criteria: for example, at least 80 percent of 20 test questions answered correctly, and every answer cites a source.
• Risks: the top three, such as wrong answers, private data, or misuse, with a guard for each.
• Cost and speed target: for example, under two cents and under five seconds per answer.
• Out of scope: what the assistant will not do. This protects your schedule.

Build Plan

Build in thin slices so that something works early. First, make a bare call to the model with a good system prompt (weeks 6 and 10) and test it on five inputs. Second, add the knowledge source: retrieval over your documents (week 7) or one tool. Third, add structure where needed, such as JSON output with validation. Fourth, add guards from weeks 8 and 9: a turn cap if you use a loop, a 'not found' answer for missing information, and basic privacy handling.

After each slice, run your test set. Keep a simple log with the date, the change, the score, and the cost. This log becomes the heart of your final report and shows your reasoning. Avoid adding features in the last day. Use that time for testing, fixing, and rehearsing.

If you get stuck, simplify. Replace a hard component with a fixed stand-in, such as a hand-written list of documents instead of a search index, and finish the whole path first. A complete simple system teaches more than a half-finished clever one.

Build In Thin Slices

1. Smallest working version
2. Test with real inputs
3. Add one feature
4. Re-run the test set
5. Demo-ready

Something always works.

Evaluation And The Rubric

Your test set from week 9 is the main evidence. Write at least twenty cases: most realistic, several hard, and at least three that the assistant should decline or answer with 'not found'. Score every case by a rule you wrote before running. Report the final score, the most important failure, and what you changed in response.

Instructors and peers will use the rubric below. Each row is scored from 1 (weak) to 4 (strong), with a total out of 32.

• Problem and user: clear, specific, and realistic.
• Design: fits the problem, with reasons for each choice.
• Working demo: runs live on a prepared input without help.
• Evaluation: fixed test set, honest scores, failures analyzed.
• Safety and privacy: risks named, guards in place, data minimized.
• Responsible use: checklist from week 11 completed with evidence.
• Code and cost: readable, keys protected, tokens and cost reported.
• Presentation: clear story, on time, honest about limits.

Capstone Rubric

Criterion	Strong	Needs work
Problem	Named user, clear need	Vague audience
Working demo	Runs live, handles errors	Only a mockup
Evaluation	Test set, results shown	Anecdotes only
Safety and privacy	Risks named and handled	Not addressed
Presentation	Five clear minutes	Over time, unclear

Demo Script And Presentation

You present for five minutes, followed by three minutes of questions. A good demo tells a story. Use the structure below and rehearse it twice with a timer. Keep the demo input ready in a text file so you can paste it without typing mistakes, and have a recorded backup in case the network fails.

Showing one failure on purpose raises trust. Say what happened, why you think it happened, and what you would do next. Audiences remember honesty more than a flawless run.

• 0:00 to 0:30, the user and the problem, in one story.
• 0:30 to 1:00, what the assistant does, in one sentence and one diagram.
• 1:00 to 2:30, live demo of the happy path with a realistic input.
• 2:30 to 3:15, one failure shown on purpose, with a diagnosis.
• 3:15 to 4:15, results: test score, cost, speed, and the biggest lesson.
• 4:15 to 5:00, risks and guards, and one next step.

Peer Review Checklist

Each learner reviews one other project. A review states what works, what is unclear, and one concrete suggestion. Use the checklist and write short, kind, specific comments. 'The citation format in answer 3 is hard to read' helps more than 'good job'.

Reviewers should try to break the assistant with two inputs of their own: one off-topic request and one attempt to extract private data or to inject instructions. Record the outcome in the review. The author then answers each point in two lines and decides what to change.

• Is the user and problem clear after 30 seconds?
• Does the live demo run on a fresh input?
• Do answers cite sources, or say 'not found' when needed?
• Is the test set realistic, and are scores believable?
• Do the guards work against the reviewer's two attacks?
• Is the API key kept out of the code and screenshots?
• Are cost and speed reported with numbers?
• Could a new user understand what the assistant cannot do?

After The Course

You now hold the full chain: concepts, prompting, knowledge, agents, evaluation, a working API app, and a sense of responsibility. The field moves quickly, so build a habit of learning slowly and deliberately. Re-run your eval set whenever a new model appears. Read one paper or one provider's changelog each month. Keep a small project going, since building keeps your understanding honest.

Share your capstone with real users. Their first reaction teaches more than any test set. Finally, keep asking the questions from week 11 about who benefits, who could be harmed, and who is responsible. Those questions stay useful, whatever the tools become.

Key Terms

Capstone

A final project that combines the skills learned across a whole course.

Project brief

A one-page plan stating the user, problem, design, success criteria, and risks.

Success criteria

Measurable conditions that show whether the project works.

Thin slice

A small working version of the whole system, improved step by step.

Test set

A fixed list of inputs with expected results used to score the assistant.

Rubric

A scoring guide that lists criteria and describes levels of quality.

Happy path

The ordinary case in which the system receives expected input and works well.

Scope

The boundary of what a project will and will not do.

Peer review

Structured feedback on a project from another learner.

Exercise: Capstone: Brief, Build, Present

1. Write the one-page project brief with the eight parts from the document and get feedback from a partner.
2. Build a bare version in an hour: system prompt plus API call, tested on five inputs.
3. Add your knowledge source (retrieval or one tool) and structured output if needed.
4. Write the test set of at least 20 cases with expected answers and run it. Record score, cost, and speed in a log.
5. Improve twice, changing one thing at a time, and rerun the test set after each change.
6. Complete the week 11 responsible-use checklist for your assistant with one line of evidence per item.
7. Prepare the five-minute demo using the script, rehearse twice with a timer, and record a backup video. Then present, complete one peer review, and reply to the review you receive.

Further Reading

• Building effective agents, Schluntz and Zhang, Anthropic, 2024
• Your AI Product Needs Evals, Hamel Husain, blog post, 2024
• Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST, 2023
• Designing Machine Learning Systems, Chip Huyen, O'Reilly, 2022
• Made to Stick: Why Some Ideas Survive and Others Die, Chip Heath and Dan Heath, Random House, 2007