Start where you are. Learn the base. Apply it to real work.
01BuildLearn the eight-step base and the software underneath it.
02TestUse the Gym to practise, evaluate and leave evidence.
03ShipApply the playbook for your role to one real workflow.
Part one · Start here
One road, three ways in.
One eight-step road, three entry points. Each step has a finish line so you know when to move on.
Pick a door to open your steps, or open them one at a time.
01
Understand what the thing actually is
It predicts the next chunk of text. It is not a database or search engine, and looks nothing up unless you give it a tool. That explains confident wrong answers, invented citations and different answers on a second try.
Done whenYou fix a bad answer by changing your question, not by switching tools.
03
Learn when not to believe it
It can be wrong with the same confidence as when it is right. Check names, numbers, dates, legal points and citations every time. Ask for sources and open them.
Done whenYou have caught it being confidently wrong at least once, deliberately.
04
Feed it your own context
Give it your material: the deck, transcript, export or report. Save it in a project or notebook so you do not re-explain every session. Specific input makes specific answers.
Done whenYou have a saved project or notebook you return to, holding your own files.
05
Know what you can and cannot paste
Before prompting, check employer and school policy for client or employee data, unreleased numbers, NDA material and personal data. Know whether your account trains on what you type and how to turn it off.
Done whenYou have finished one full course on one tool, rather than three introductions.
07
Make it do multi-step work
Move from answers to action: tools, files, search, other systems and triggers. Start with one weekly task you resent and take yourself out of the loop.
Pick one real task. Keep the input, prompt and result.
01
Rescue an executive brief
Work scenario: You are a product manager preparing Monday's steering update from Friday's long meeting transcript. Leaders need decisions and risks, not a summary of everything said.
Student scenario: Your case-team has a professor's feedback and a messy meeting transcript. Turn both into a one-page update showing the recommendation, unresolved risks and next decisions.
Run it with a one-line prompt.
Rewrite the prompt with audience, decision, constraints and a sample structure.
Compare omissions, clarity and usable recommendations.
Evidence: The two outputs plus a five-point comparison.
02
Draft a safe customer reply
Work scenario: You manage customer support and an angry customer wants a refund date you cannot guarantee. Your reply must be helpful without inventing policy or making a promise.
Student scenario: A prospective attendee emails your MBA club about an event fee and deadline. Draft a helpful reply using only the public event page, without inventing exceptions.
Choose a real or anonymised support scenario.
Specify tone, known facts and what the model must not promise.
Generate three versions and approve one against your constraints.
Evidence: One approved email and its constraint checklist.
03
Extract decisions, not prose
Work scenario: You lead a cross-functional project and the weekly notes contain decisions, vague commitments and no clear owners. The team needs an action tracker before the next stand-up.
Student scenario: Your group-project notes contain several ideas but no clear commitments. Convert them into decisions, owners and deadlines before the next team meeting.
Use real meeting or project notes.
Request a fixed table with decision, owner, date and open question.
Check every row against the source and repair ambiguous instructions.
Evidence: A validated decision table or JSON file.
Prove itYou fix a bad answer by changing your question, and you wrote the prompt from scratch.
Context engineeringThe model is a CPU; the context window is its RAM.3 challenges · 1 do · 2 read
What this is
Context engineering is choosing the instructions, files, history and tool results a model sees. Its attention is finite: select, compress, update and isolate context.
Use it when a task repeats, spans a long conversation or involves several sources and rules.
In Chroma's context rot study, 18 frontier models all degraded as input grew, some from roughly 95% to 60% accuracy. More context is not better context.
Do
DoAgent prompt
Open a project or chat you actually use. Audit what is in its context: instructions, files, history. Cut it down: remove what the task does not need, compress what it does, and measure tokens before and after. Report both numbers and whether quality held.
Mini challenges
Change only the context. Test whether the task becomes clearer, cheaper or safer.
01
Run a lean-context audit
Work scenario: You inherit a six-month AI project filled with outdated files, duplicate instructions and long chat history. Every answer is slower and sometimes follows last quarter's rules.
Student scenario: Your capstone AI chat contains old drafts, duplicate research and an outdated rubric. Reduce its context, then rerun the same assignment task to see whether quality holds.
Inventory its instructions, files and useful history.
Remove irrelevant material and compress repeated facts.
Run the same task before and after; compare size and quality.
Evidence: Before/after context size and a scored output comparison.
02
Build a portable handoff
Work scenario: A colleague must cover tomorrow's client launch but cannot read your entire project history. They need enough context to make the next decision without calling you.
Student scenario: A teammate joins your case competition halfway through. Create a one-page handoff that lets them challenge the current recommendation in a fresh AI session.
Create a one-page pack: goal, terms, decisions, constraints and sources.
Give it to a completely fresh session.
Ask that session to make the next decision and note what it still lacks.
Evidence: The context pack and the fresh-session result.
03
Test context isolation
Work scenario: Your consulting team serves two competitors in the same sector. An AI workspace must never mix one client's pricing, names or recommendations into the other's work.
Student scenario: You are studying two similar business-school cases. Test mixed versus separate document sets and check whether the model assigns facts to the wrong company.
Prepare two small, clearly labelled document sets.
Ask the same questions with mixed context, then isolated context.
Record wrong-source facts and citation mistakes.
Evidence: A contamination matrix showing both runs.
Prove itA before/after token count where quality held.
RAGHow a model answers from your documents instead of its training data.3 challenges · 2 do · 2 read
What this is
Retrieval-augmented generation (RAG) finds relevant passages in controlled documents, then gives them to the model to answer with evidence. It is retrieval, not training.
Use it when answers depend on private, changing or fact-sensitive knowledge that should be cited.
DoBasic RAG · Reliable RAGTwo Foundational Colab notebooks by Nir Diamant. Linked, never hosted.
DoAgent prompt
I am opening this notebook in Colab: [URL]. Walk me through it cell by cell. Explain what each cell does in plain language before I run it, and stop when I have asked a question about my own uploaded document and had it answered.
Mini challenges
Start with a small document set. Test whether retrieval finds evidence and refuses unsupported answers.
01
Make a policy answerer
Work scenario: You work in People Operations and employees repeatedly ask about leave, expenses and remote work. Answers must come from the current handbook, never the assistant's memory.
Student scenario: Build the same test with your course syllabus, programme handbook or a club constitution. Ask about deadlines and rules, including questions those documents cannot answer.
Load three to five non-sensitive policy documents.
Write ten answerable and five deliberately unanswerable questions.
Require passage citations and “not found” when evidence is absent.
Evidence: A scored 15-question test sheet with citations.
02
Build a competitor evidence desk
Work scenario: You are a product marketer preparing a win/loss meeting. Sales needs a competitor comparison supported by current product pages and release notes, not familiar-sounding claims.
Student scenario: For a strategy class or case competition, compare three companies using only public product pages, annual reports and release notes, with a citation for every claim.
Collect five dated product pages, reports or release notes.
Ask comparison questions about features, positioning and gaps.
Open every cited passage and flag claims the sources do not support.
Evidence: A cited comparison table with source dates.
03
Find decisions across meetings
Work scenario: A programme director asks why a launch slipped and who owns the remaining blockers. The answer is scattered across ten weekly meeting notes.
Student scenario: Use your study group's, club's or project team's notes from the semester to recover decisions, owners and missed deadlines, then verify them against the originals.
Load ten anonymised meeting notes.
Retrieve decisions, owners and deadlines with source references.
Verify each result against the original note and count misses.
Evidence: A verified decision register and accuracy score.
Prove itA bot that answers questions over a document you gave it, and correctly says “not in the document” when the answer is not there.
Agents & tool useThe jump from a model that answers to a system that does.3 challenges · 1 do · 2 read
What this is
An agent is a model in a loop: it can choose tools, observe results, keep state and decide when to stop or escalate. Keep predictable steps as fixed workflows.
Use it when the task requires actions, external information or branching decisions, not just a written answer.
Help me build my first agent: it must take a real input from me, call at least one tool (web search or a file), and return something I would actually use. Set up everything, explain each part as we go, and when it works, help me push it to GitHub.
Mini challenges
Keep permissions narrow and preserve the tool trace. Show what it did and where it stopped.
01
Create a daily briefing agent
Work scenario: You are a strategy lead starting the day with five company priorities and dozens of market updates. You need only the changes that could affect today's decisions.
Student scenario: Start with a shortlist of target employers or an MBA club priority list. Have the agent find current public updates and produce a five-item briefing for recruiting or the next club meeting.
Give the agent one file or feed plus web search.
Ask for a five-item cited briefing ranked by relevance.
Review its tool calls and remove anything you would not act on.
Evidence: The briefing and its complete tool trace.
02
Triage an expense queue
Work scenario: Finance Operations is processing month-end receipts. Most follow simple rules, but missing VAT, duplicate claims and unusual amounts must go to a human before payment.
Student scenario: Create five fake receipts for a student-club event and use the club's published budget rules (or rules you write yourself) to route normal items and exceptions for approval.
Create five synthetic receipts with edge cases.
Extract totals and categories, then route them using explicit rules.
Require human approval before any payment or external write.
Evidence: A routed queue including exceptions and approval gates.
03
Research, draft, then stop
Work scenario: You are an analyst who needs a cited market memo by 3 p.m. The agent may research and draft, but Communications must approve anything before it leaves the company.
Student scenario: Prepare a cited memo or presentation outline for class using three public sources. Make the agent stop for your review before anything is submitted or shared with the team.
Ask the agent to find three authoritative sources.
Have it draft a cited one-page memo for a named audience.
Make it stop for review before sending or publishing anything.
Evidence: The cited draft, tool trace and visible stop point.
Prove itAn agent that took real input, called a tool, returned something useful, pushed to GitHub.
MemoryWhy your agent forgets you, and what to do about it.3 challenges · 1 do · 1 read · 1 watch
What this is
Memory is information deliberately saved and retrieved across steps or sessions: working state, recent conversation and selected long-term facts. It must be writable, selectable, updateable and deletable.
Use it when an assistant must preserve preferences, project decisions or continuity without receiving the full history every time.
Add memory to the agent I built: it should remember one fact about me across separate sessions. Explain where the memory lives, and show me the four ways memory goes wrong: poisoning, overload, token cost, and stale context.
Mini challenges
Store only what is worth carrying forward. Prove the user can inspect, correct and remove it.
01
Remember one preference
Work scenario: An executive wants every weekly update in five bullets with risks first. Their assistant should apply that preference next week without being reminded, and change it when asked.
Student scenario: Ask an assistant to remember how you prefer case notes, study plans or recruiting updates formatted. Test the preference in a fresh session, then change and delete it.
Save one explicit preference, such as format or tone.
Start a fresh session and request a relevant output.
Change the preference, retest it, then delete it.
Evidence: Screenshots showing remember, update and delete.
02
Keep a decision memory
Work scenario: A product team returns to a pricing launch after two weeks. They need the chosen price, rationale and owners, not every conversation that led there.
Student scenario: Your group returns to a semester project after exams. Store only the chosen research question, recommendation, rationale and owners, then recover them in a new session.
Store three decisions with date, rationale and owner.
Do not store the full conversation.
In a new session, ask what was decided and verify every answer.
Evidence: The decision ledger and verified retrieval result.
03
Run a memory failure lab
Work scenario: A shared sales agent remembers an old territory owner and a bad instruction copied from a note. Left unchecked, it will route the next lead to the wrong person.
Student scenario: In a sandbox assistant, save a wrong course deadline, an outdated team role and an irrelevant preference. Test the mistakes safely, then add expiry and deletion rules.
Add one wrong fact, one expired fact and several irrelevant facts.
Run a task that might retrieve them and record the failures.
Add review, expiry or deletion rules and rerun the task.
Evidence: A failure log and the corrected second run.
Prove itYour agent remembers something you told it last session.
EvalsThe difference between “it seems to work” and knowing it works.3 challenges · 1 do · 2 read · 1 watch
What this is
Evals are repeatable inputs, expected behaviours, result grading and an acceptable-quality threshold. They turn “this seems good” into evidence.
Use them when choosing a prompt or model, releasing a workflow, or checking that a change did not break known cases.
Start
ReadYour AI product needs evalsHamel Husain's reference guide: build the measurement loop before you tune anything.
The eval rule: write an eval suite, deliberately break the agent, then prove the evals catch it. That is the test. A green run on its own proves very little.
Do
DoAgent prompt
Write an evaluation suite for my agent: 5 test cases with known-correct outcomes. Then help me deliberately break the agent (degrade its prompt or remove a tool) and run the evals to show they catch the failure. I will screen-record the run.
Mini challenges
A useful eval is repeatable and fails when you deliberately damage the system.
01
Test a prompt regression
Work scenario: Support Operations rewrote the prompt that summarises customer tickets. Before rollout, you must prove it improves useful details without losing urgency or account names.
Student scenario: Compare two prompts that summarise case articles, give case-interview feedback or turn lecture notes into revision cards. Score both on the same ten examples.
Collect ten representative inputs and define a simple rubric.
Run prompt version one and version two on the same cases.
Count improvements, ties and regressions before choosing.
Evidence: A scored side-by-side comparison of both prompts.
02
Break a RAG truth test
Work scenario: A compliance knowledge bot has just received new policy documents. It must answer supported questions and refuse the rest before employees are allowed to rely on it.
Student scenario: Test a syllabus or course-pack question bot with known answers and impossible questions. Remove a key page and prove your eval catches the unsupported responses.
Create answerable and unanswerable questions with known results.
Check correctness, citation support and abstention.
Remove a key document or damage retrieval and prove the eval turns red.
Evidence: A failing run followed by the repaired passing run.
03
Grade tool choice
Work scenario: Your research agent sometimes searches the web for simple arithmetic and sometimes answers current questions from memory. You need proof it chooses the right tool for each job.
Student scenario: Give a study assistant tasks requiring a calculator, a current web search, an uploaded case and no tool. Check whether it chooses correctly before trusting the answer.
Write eight cases with the expected tool choice.
Run the agent and score tool selection plus final result.
Remove a tool or weaken its description and check that the eval catches it.
Evidence: A tool-choice matrix and its regression result.
Prove itA screen recording of your evals catching a break you introduced on purpose.
MCP & SkillsMCP connects AI to systems. Skills teach it workflows.3 challenges · 2 do · 2 read
What this is
MCP gives AI access to external tools and data. A Skill is reusable workflow instruction. MCP provides access; Skills standardise behaviour.
Use them together when a recurring workflow needs both a reliable procedure and permission to reach a real system.
Help me package one workflow I repeat every week into a Claude Skill: ask me clarifying questions about the workflow, then produce the skill folder with its instructions file, and explain how to install it.
DoRun an idea through idea-reality-mcpBefore you build, scan GitHub, HN, npm, PyPI and Stack Overflow for a 0–100 reality score and named competitors. Market validation and what MCP is for, in one move.
Mini challenges
Start read-only. Make the boundary between data access and workflow instruction visible.
01
Package a weekly report Skill
Work scenario: Every Monday, Sales Operations turns a new pipeline export into the same leadership report. The procedure and quality bar stay fixed while the data changes.
Student scenario: Turn a weekly recruiting tracker, study log or club-membership spreadsheet into the same summary each week. Package the steps and quality checklist as a reusable Skill.
Write the inputs, steps, output template and quality checklist.
Package them as one reusable Skill.
Run it on two different weeks of sample data and compare consistency.
Evidence: The installed Skill and two completed reports.
02
Audit a read-only connector
Work scenario: An HR analyst wants an assistant to answer from a shared policy folder. It may read selected files but must never edit, delete or browse unrelated employee records.
Student scenario: Connect a read-only test folder containing public course material or synthetic club data. Retrieve one item and confirm the assistant cannot edit or browse anything else.
Connect a safe folder or test data source through MCP.
List the exact permissions and retrieve one document or row.
Ask a question and require the answer to cite the retrieved item.
Evidence: A permission note, data-flow sketch and cited answer.
03
Separate access from method
Work scenario: An operations lead runs a monthly business review: CRM data changes every month, but the scorecard, analysis steps and presentation format should not.
Student scenario: Run a student-club event review from a new survey or attendance export each month. Let MCP fetch the data while a Skill applies the same scorecard and output format.
Use MCP to fetch a small real or test dataset.
Use a Skill to analyse it with a fixed procedure and output format.
Swap in new data and rerun without changing the procedure.
Evidence: A one-page boundary diagram and both successful runs.
Prove itOne installed Skill you actually reuse, and a reality score for one idea you were about to build.
HarnessMost agent failures are not model failures.3 challenges · 1 do · 2 read
What this is
The harness is everything wrapped around the model that turns it into an agent: the tools it can call, how those tools are described, the loop that runs them, what happens on an error, and what it is allowed to touch. The term is borrowed from software testing, where a harness is the scaffolding that runs code under controlled conditions.
Work on it when you keep blaming the model for failures that are really a missing tool, a vague tool description or an unhandled error.
Take one assistant, custom GPT or agent I already use. Interview me until you can write down its harness: every tool it can call, what each tool description says, what it does when a tool fails, what data it may touch, and where it needs my approval. Then name the single weakest part and rewrite it.
Mini challenges
Change the scaffolding, not the model. Keep the before and after.
01
Map a harness you already use
Work scenario: Your team relies on an assistant nobody can fully describe. When it produces a bad answer, the debate is about which model to switch to rather than what the thing can actually reach.
Student scenario: Take the AI tool you lean on most for coursework and write down exactly what it can read, run and remember. Most people discover they were guessing.
List its tools, permissions, memory and stop conditions on one page.
Collect three recent bad outputs.
Label each as a model problem or a harness problem, with a reason.
Evidence: The one-page harness map and three labelled failures.
02
Rewrite one tool description
Work scenario: An internal agent keeps calling the wrong lookup, because two tools are described in nearly the same words and neither says when to prefer it.
Student scenario: Give an assistant two similar sources, a course reader and a public web search, with sloppy descriptions. Watch it pick the wrong one, then fix the wording.
Run ten realistic requests and record which tool it chose.
Rewrite one description with purpose, inputs and when not to use it.
Rerun the same ten and count wrong-tool calls before and after.
Evidence: Both descriptions and the two counts.
03
Give it a safe failure path
Work scenario: A finance agent hits an empty export and confidently invents plausible numbers instead of stopping. Nobody notices until the figures reach a deck.
Student scenario: Point an assistant at a file that is missing, empty or in the wrong format and see whether it admits the problem or fabricates its way past it.
Break one input on purpose: empty, missing or malformed.
Write the rule for what it must do instead, including when to stop and ask.
Rerun until it fails loudly rather than quietly.
Evidence: The broken-input run before and after your rule.
Prove itYou fixed a real agent failure without changing the model or the prompt.
Loops & graphsOne loop optimises. Connected loops keep each other honest.3 challenges · 1 do · 3 read
What this is
A loop is one cycle that repeats: plan, act, check, adjust. A graph is several of them wired together, where the connections carry the intelligence: one part does the work, another watches it, and a third owns the target and can change it. A loop is really just a graph with one node pointing back at itself.
Move from loop to graph when the single loop starts optimising its number while the real goal gets worse, or when the work splits into genuinely different jobs that need their own instructions.
ReadGoodhart's lawWhen a measure becomes a target, it stops being a good measure. This is the failure your second loop exists to catch.
The four ways a single loop fails: it games its own metric, it never questions an outdated target, it fights a second loop optimising something else, and its dashboard stays green after the number stops meaning anything. Adding nodes has a price too: every edge is latency and every node is a place to fail, so add one only when you can name the signal that earned it.
Do
DoAgent prompt
Help me draw one automation or habit I already run as a loop: what it measures, what it adjusts, how often. Then stress it. Ask how I would game that number if I were lazy or dishonest, what would still look fine on the dashboard, and what second loop would catch it. Finish with the anchor that must never be optimised away.
Mini challenges
Draw the loop before you automate it. Then find who watches it.
01
Break your own loop
Work scenario: Support is measured on first response time. Replies get faster and emptier, tickets reopen, and the dashboard has never looked better.
Student scenario: Take a personal metric you track, applications sent, posts published, study hours, and work out how you could hit it this week while learning nothing.
Write the loop: metric, adjustment, cadence.
List three honest ways to game it.
Name the outcome that would quietly get worse each time.
Evidence: The loop sketch and its three gaming paths.
02
Add the watcher loop
Work scenario: A content agent posts on a schedule and reports engagement. Nothing in the system checks whether the output is accurate or on brand.
Student scenario: Your AI study routine summarises readings every week. Add a second pass that samples one summary and checks it against the source.
Define a second loop that only inspects the first one's output.
Give it a sample rate and one clear pass or fail rule.
Run both for a week and record every catch.
Evidence: The watcher's rule and its first week of catches.
03
Set the anchors
Work scenario: Three automations now touch the same customer list and quietly disagree about what a good week looks like. Nobody wrote down which number is allowed to win.
Student scenario: Your job search runs on several AI helpers: sourcing, tailoring, follow-ups. Decide the one real outcome, such as interviews with firms you would actually join, that none of them may optimise away.
List every loop touching the same goal and what each maximises.
Write two or three anchors that stay fixed, including one real-world outcome.
For each loop, state what it reads, what it writes and what watches it.
Evidence: A one-page graph of loops, connections and anchors.
Prove itOne of your loops has a watcher, and you can name the anchor it may never optimise away.
Agent orchestrationMore agents is a cost decision before it is an architecture.3 challenges · 1 do · 2 read
What this is
Orchestration is deciding how several agents divide work and hand it over: a router that picks a specialist, a lead agent that fans work out to workers and merges the results, or a pipeline where each step checks the last. The hard parts are handoffs, shared state and knowing when the run is finished.
Use it when a task splits into genuinely parallel or genuinely specialist pieces. If the steps are sequential and predictable, one agent with good tools is cheaper and easier to debug.
Take a multi-step process I run today. Argue both sides: how it would work as one agent with good tools, and how it would work as a lead agent with specialists. For each, estimate steps, rough token cost, failure points and how I would debug a bad result. Then recommend one and say what evidence would change your mind.
Earn the second agent. Measure what the split costs you.
01
Run the one-agent baseline
Work scenario: A team wants a five-agent pipeline for competitor research before anyone has checked what a single well-equipped agent produces.
Student scenario: Before building an elaborate setup for company research ahead of interviews, run the whole thing as one agent and score the output honestly.
Do the full task with one agent and good tools.
Record time, rough cost and a quality score out of ten.
Write down which specific part was actually weak.
Evidence: The baseline output with its three numbers.
02
Split it and pay the bill
Work scenario: The same research task is rebuilt as a lead agent with two specialists. Leadership wants to know whether the quality gain justifies the spend.
Student scenario: Split your research into a sourcing agent and a synthesis agent, then compare both runs against the baseline you already scored.
Rebuild the weak part as a separate specialist with a clear brief.
Rerun and record the same three numbers.
State the quality gain per extra unit of cost, and whether you would ship it.
Evidence: A side-by-side comparison and your ship or scrap decision.
03
Test the handoff
Work scenario: A qualification agent passes leads to a drafting agent. The draft keeps missing the objection the first agent already uncovered, because it never crossed the handoff.
Student scenario: Have one agent research a company and a second write your cover letter. Check whether the specific detail you cared about survived the transfer.
Write down exactly what should cross the boundary.
Run five cases and inspect what actually arrived.
Fix the handoff contract and rerun the failures.
Evidence: The handoff contract and five before-and-after transfers.
Prove itYou can show a task where one agent won, and a task where the split was worth the extra cost.
Part three
Then it depends on your job.
Base literacy is universal; application is not. Each playbook covers six recurring workflows: the job, AI's role, business value, proof it worked, a real deployment and the judgment that remains yours.
The back end is the server-side part you do not see. It holds logic, checks permissions and keeps secrets out of the browser. An exposed API gives another system selected access, not everything.
A database is where product data lives. Some use rows and tables, some flexible documents, and vector databases find similar meaning. Ask what is stored, who can reach it and how it stays accurate.
An API lets software request data or an action from another system. An API key controls access, limits and billing; keep it secret. Reliability, permissions and cost decide whether an integration works.
The Industry Fellowship is where it stops being a reading list: one semester, a real company and something you build and ship. Most fellows start as beginners.