Learning objectives
- State, for any prompt, what is actually inside the context window: the question, the injected sources, the attached files, and the persistent memory.
- Predict which failure mode a given surface produces — stale recall, unfaithful summarization, or an unverified computation.
- Choose the cheapest surface that can answer a question correctly, instead of defaulting to the most capable one.
- Verify a retrieval-backed answer by opening its citations and labelling each claim supported, unsupported, or unverifiable.
- Read an emitted program as the reviewable artifact of a computation rather than trusting the printed number.
- Estimate the relative cost of a long-context turn and explain why pasting an entire document is rarely free.
- Audit persistent memory and custom instructions as a privacy surface, not merely a convenience feature.
Materials
- One device per participant with access to at least two different LLM surfaces (a plain chat and a retrieval-enabled one).
- A question whose correct answer changed within the last six months — prepared by the instructor in advance.
- The tokenizer interactive (linked from the learner course page) for the context-budget segment.
- A short CSV or table of numbers for the code-execution lab (20-40 rows is enough).
- A whiteboard for the "what is in the window?" diagram.
- Offline fallback: pre-captured screenshots of a retrieval answer with its citation list, so the verification lab still runs without network access.
Minute-by-minute plan
| Time | Duration | Segment |
|---|---|---|
| 0:00 | 10 min | Framing: the same model, four different surfaces — what actually changes? |
| 0:10 | 15 min | Concept 1: a surface is a context policy. Whiteboard the window. |
| 0:25 | 20 min | Lab A: the knowledge-cutoff experiment (no-retrieval vs retrieval). |
| 0:45 | 10 min | Concept 2: retrieval moves the failure mode. Debrief Lab A. |
| 0:55 | 5 min | Break. |
| 1:00 | 20 min | Lab B: delegated computation — read the program, not the number. |
| 1:20 | 15 min | Concept 3: operating cost, context budget, and the tokenizer interactive. |
| 1:35 | 15 min | Concept 4: persistence and privacy. Audit a memory panel live. |
| 1:50 | 10 min | Review: the surface-selection checklist and the honest boundary. |
Key messages to land
- The model is often the same; the surface decides what enters the context window. Choosing a surface is an engineering decision, not a UI preference.
- Retrieval does not make an answer true. It exchanges the risk of stale recall for the risk of bad sources and unfaithful summarization.
- A citation is a promise, not proof. The claim is verified only once a human opens the source.
- When a surface executes code, the reviewable artifact is the program. A correct-looking number can come from wrong code.
- Context is metered. Longer windows cost more and decode more slowly, so bound what you paste.
- Memory and custom instructions persist beyond the session. Review them as you would review any stored personal data.
Common pitfalls
Learners conclude that "the search one is simply better".
Force a counter-example: ask a stable, well-known fact where retrieval adds latency, cost, and a mediocre source without improving the answer. The point is fit, not ranking.
The knowledge-cutoff demo silently succeeds because the plain chat surface also has retrieval enabled.
Check the surface configuration before the session and disable tools explicitly. If you cannot, use the prepared screenshots instead of improvising.
Participants verify citations by reading only the snippet shown in the answer.
Require the source to be opened in a new tab. The snippet is generated text; the page is the evidence.
The code-execution lab turns into a debugging session.
Keep the dataset tiny and the task arithmetic. The learning objective is reading the emitted program, not writing one.
Vendor comparisons become the session.
State up front that consumer features change monthly and that any comparison is dated. Teach the selection criteria, not the current leaderboard.
Learners paste confidential material into a surface with persistent memory during the labs.
Announce before Lab A that all lab inputs must be non-sensitive, and demonstrate where memory is disabled or cleared.