Module 1 · Foundations of Agentic AI · scripted
Teaching by Example
Start with the imperative
So far, most of our prompting has been imperative: we give the model direct instructions — specific commands that spell out what to do. Imperative is the grammatical mood of a command: "summarize this," "translate to Norwegian," "fix the causal language." You state the operation, the model performs it. It is the most natural way to tell any worker what you want, and it takes you a long way.
Imperative instruction — a few examples
You name the action; the model carries it out. Direct, explicit, and often exactly enough.
But issuing commands is not the only way to teach a model what you want. Sometimes the thing you want is hard to say as a rule and easy to show — and for a machine whose one talent is pattern recognition, showing turns out to be extraordinarily powerful. That second way — teaching by example — is what this lesson is about. To feel its force, first remember what showing a machine a pattern used to cost.
Teaching a machine, the old way
To feel the force of teaching by example, you have to remember what the world was like just a few years ago. Suppose, back then, you wanted a computer to learn a pattern — say, to read a product review and decide whether it's positive or negative. Sentiment analysis: a simple-sounding classification task. Here is what it took:
The assembly line (circa 2018)
The ledger, per classifier
Want it to also detect urgency? Return to the top of the diagram and begin again.
And sentiment was a success story. The genuinely hard cases — sarcasm, implication, tone — sank whole research programs, because annotators couldn't even agree on the labels.
The same machine, rebuilt in six lines
Now watch:
Examples of sentiment classification of reviews:
- "Battery lasts forever, screen is gorgeous." → P4
- "Does what it says. Nothing special." → P1
- "Broke on day two. Never again." → N4
- "I was ready to hate it. I don't." → P2
- "Oh fantastic, another update that moved every button." → N3
- "A bit pricey for what it is." → N1
Classify this one:
"Works great, if you enjoy restarting it hourly."
N3
On-demand model training
What the assembly line did in months, the prompt did in one pass:
Is something like a real model actually assembled, somewhere inside, for an instant? Nobody knows. What we know is that the CAPABILITY is the same — often better — and it is instant, disposable, and retrained by editing text.
The prompt has become the training run.
The research community calls this in-context learning — the discovery, startling at the time, that large models can learn a task from a few examples in the prompt itself (Brown et al., 2020). For you it means something extraordinarily practical: you now carry an on-demand model factory, and its entire engineering interface is showing it things. The rest of this lesson is about wielding that — and the right frame for wielding it turns out to be exactly how you would teach a person.
How would you teach someone to write like Tolstoy?
Suppose that's my assignment: teach you to write like Tolstoy. There are two ways I could go about it, and one of them is the way we instinctively reach for — write it all down. Produce the manual: the complete rules of writing like Tolstoy. Let's try:
How to Write Like Tolstoy — A Complete Manual (vol. 1 of 14)
… continued in volumes 2–14. Exceptions begin in volume 6.
The manual is farce, and not because the rules are wrong — each one is defensible. It's farce because the rules never end, they contradict, and knowing all of them still wouldn't produce a page of Tolstoy. The second way is what anyone would actually do: hand you Anna Karenina and say — like this.
And notice what that choice relies on. Your pattern recognition does the heavy lifting: you extract the rules on the fly, in the context of applying them, keeping only the ones the current sentence needs — most of them rules neither of us could have articulated. For a task like this, examples aren't the lazy option. They are extraordinarily information-dense: a page of Tolstoy carries more of "how to write like Tolstoy" than a volume of rules about it.
Show, don't describe
Now bring that to the machine we have. We just watched the model complete patterns — nursery rhymes it memorized, and a fishermen's scene invented seconds earlier. Pattern recognition is the one thing this machine does — which means the Tolstoy method, teaching by showing, is its native mode of learning. Watch the same contrast on a task-sized problem:
Two ways to teach the same task
| BY IMPERATIVE RULES | BY EXAMPLES |
|---|---|
| "Classify a support ticket as PASSWORD RESET if it concerns authentication credentials, including but not limited to forgotten passwords, expired passwords, locked accounts… unless the issue is billing-related, in which case…" | PASSWORD RESET: "I can't get into my account since the update." BILLING: "I was charged twice this month." BILLING: "How do I get a receipt for my subscription?" PASSWORD RESET: "It says my login expired??" |
| …and you're still writing, and the edge cases are still coming. | Four lines — and the edges are already implied. |
The left column is the imperative approach pushed to its limit — the Tolstoy manual again, in miniature — and it has the same disease: still writing, edge cases still coming. In the right column, each labeled example lays a pattern down in the document. A rule tries to describe the boundary between categories; an example simply sits on the correct side of it, and the model infers the boundary the same way it inferred how Magnus talks. This is the first big lesson of prompting: examples are often denser than rules — and frequently cheaper, word for word, than the rules they replace.
Classification, taught in one prompt
The cleanest demonstration. No definitions, no rules — just labeled examples, then a new case:
Here are support tickets with their correct categories:
- "I can't log in since yesterday's update." → ACCOUNT
- "I was charged twice for March." → BILLING
- "The export button does nothing when I click it." → BUG
- "It would be great if reports could be scheduled." → FEATURE REQUEST
- "My password reset email never arrives." → ACCOUNT
- "Why did my invoice go up this month?" → BILLING
Classify this ticket:
"The app crashes every time I attach a file larger than 10 MB."
BUG
The same pattern reaches problems that don't look like ticket routing at all. Here it is doing qualitative research:
I'm analyzing interview transcripts from ferry crews about a new scheduling system. I code passages with these themes — here are examples of my coding:
- "Nobody asked us before they rolled it out." → EXCLUSION FROM DECISIONS
- "I checked the app and my shift had moved overnight." → LOSS OF PREDICTABILITY
- "The old paper roster, you could see the whole month at once." → LOSS OF OVERVIEW
- "My wife can't plan anything anymore either." → SPILLOVER TO FAMILY LIFE
- "They asked us before, but nothing we said shows up in it." → EXCLUSION FROM DECISIONS
Code this passage:
"You wake up, you look at your phone, and only then do you know if you're working."
LOSS OF PREDICTABILITY
- A surprising amount of knowledge work is secretly classification: triage, grading, screening, routing, diagnosis, relevance. Name one task in your research that is classification wearing a costume.
- In Example 2, what would the rules version of that codebook look like? How long before it matched five examples' worth of nuance?
A gallery of little impossible machines
Once you see the pattern, it's hard to stop building these. Each of the following would have been a funded project a decade ago — a labeled corpus, a custom model, a defended thesis. Each is funny precisely because of how casually it now works. Watch four different kinds of learning, all taught the same way:
Here is what reviewer comments actually mean:
- "This is a solid contribution." → ACCEPT
- "The approach is interesting." → POLITE REJECTION
- "The authors may wish to consider the extensive literature on this topic." → YOU MISSED MY PAPER
- "This raises questions about the validity of the entire framework." → DEATH BLOW, DELIVERED CALMLY
- "Minor comments follow." → THREE PAGES OF MINOR COMMENTS FOLLOW
Decode: "The authors have undertaken an ambitious project."
POLITE REJECTION — "ambitious" in reviewer dialect means the scope exceeded the execution. Brace for the word "however."
Norwegian cabin listings, translated to actual distance from parking:
- "bilvei helt frem" (road all the way) → 0 m
- "kort gåtur fra parkering" (short walk) → 800 m
- "lett adkomst" (easy access) → 1.5 km, uphill
- "gangavstand fra vei" (walking distance) → 2.5 km
Predict: "idyllisk og uforstyrret beliggenhet" (idyllic, undisturbed location)
4–6 km. "Undisturbed" is doing heavy lifting: nothing with a road nearby gets called undisturbed. Pack in by ski or boat; confirm before booking.
Group these seminar-absence excuses into natural clusters and name each cluster:
- "my model was still training"
- "the ferry was delayed"
- "I thought it was next week"
- "my laptop updated overnight"
- "the E39 was closed"
- "I was sure it was online"
- "my experiment segfaulted at 3am"
- "there was weather"
- "calendar sync issue"
- TECHNOLOGY BETRAYED ME: model training, laptop update, segfault
- GEOGRAPHY (NORWAY): ferry, E39, "there was weather"
- CALENDAR MYSTICISM: next week, online, sync issue
Nightly backup log. One line doesn't belong. Which, and why?
- 02:00 backup started (db-main)
- 02:14 snapshot complete, 412 GB
- 02:15 verify: checksums OK
- 02:00 backup started (db-replica)
- 02:11 snapshot complete, 8 GB
- 02:12 verify: checksums OK
The replica snapshot: 8 GB against the main's 412 GB. A replica should be roughly the size of what it replicates — a 50× gap means the replica is nearly empty or the backup captured almost nothing. The checksums passing makes it worse: the backup is faithfully preserving a database that isn't there.
The gallery, priced in 2018
Today: four prompts, a handful of examples or none, zero models trained — or rather, four models trained, used once, and discarded, all before the coffee cooled.
Chain of thought: the trajectory toward correctness
So far the examples taught answers. The next step teaches thinking — and it starts from the trajectory idea. Consider a person: if you have them write down their problem-solving plan first, and the plan is right, the answer that follows the plan is much more likely to be right. The same holds for next-word prediction: words that state a correct solution are far more probable when they follow from a correct chain of reasoning than when they must appear from nowhere. The technique is called chain of thought, and its simplest form is a single instruction — think step by step:
Answer with only the final number. A ferry departs every 45 minutes starting at 06:00. I arrive at the dock at 09:10. How many minutes until the next departure?
20
A ferry departs every 45 minutes starting at 06:00. I arrive at the dock at 09:10. How many minutes until the next departure? Think step by step before answering.
- Departures are 06:00, 06:45, 07:30, 08:15, 09:00, 09:45, …
- I arrive at 09:10, so the 09:00 departure has left.
- The next departure is 09:45.
- 09:45 − 09:10 = 35 minutes.
Answer: 35 minutes.
Teaching the chain itself by example
Now put the two ideas together. "Think step by step" asks for some
reasoning — the model decides what the steps are. But you can go
further: show a worked example of the thinking you want, and the
model will reason your way. Problem, then Think step by step:,
then the reasoning, then the solution — and a new problem after it:
Here's how I assess whether an abstract's conclusion is supported.
Abstract: "We surveyed 40 students at one university about study habits. Students using flashcards reported higher confidence. We conclude flashcards improve exam performance."
Think step by step:
- What is the claim? Flashcards improve exam performance.
- What was measured? Self-reported confidence — not performance.
- Does the sample support generalizing? 40 students, one university — weak.
- Verdict: NOT SUPPORTED — the conclusion changes both the variable and the scope.
Now assess this abstract the same way: "We analyzed 12,000 harbor departures over five years. Departures delayed by weather clustered in October–February. We conclude winter scheduling should include larger buffers."
Think step by step:
- What is the claim? Winter schedules should include larger buffers.
- What was measured? Actual departure delays, 12,000 cases, five years — the relevant variable, directly.
- Does the sample support generalizing? Large sample, long period — reasonable for scheduling policy at similar harbors.
- Verdict: SUPPORTED — the conclusion stays within what was measured, and the recommendation follows from the observed pattern.
Teaching a voice
Now the case where rules fail almost completely. Try to write rules for how you write. "Short sentences. Concrete. Warm but not casual…" — every writer's style guide sounds the same, and none of them captures a voice. But samples do:
Here are three passages of my writing:
"The ferry was late again. Nobody at the quay seemed surprised. There's a lesson in that, and it isn't about ferries."
"I spent a year measuring things nobody cared about. Best year of my career. It taught me the difference between data and evidence."
"You don't need a bigger model. You need a better question. Most of my job is convincing people of the second sentence."
In my style, write a short opening for a talk about why students should learn statistics.
Nobody falls in love with statistics. They fall in love with a question, and then statistics turns out to be the only honest way to answer it. My job today is to get you to the question.
The principle
Examples as teaching material
A rule DESCRIBES the pattern — and leaks at every edge case. An example EXHIBITS the pattern — edges included, for free. The densest teaching often mixes them: a short rule for the intent, examples for everything the rule can't say.
Refining by preference: examples as the steering wheel
So far the examples came first and the output came after. Now reverse it — because this becomes the simplest and most practical way to improve a prompt you already have. The method comes from one of our own papers (Preference-Driven Refinement of Prompts, White et al., 2025), and it works like this:
The preference-driven refinement loop
Each round, the prompt accumulates a gallery of shown-not-told preferences — and the outputs walk toward what you actually want.
Watch one round:
Write a two-sentence course description for a PhD seminar on AI agents.
This cutting-edge seminar empowers doctoral students to leverage the transformative potential of AI agents. Participants will gain hands-on experience with state-of-the-art paradigms and unlock new synergies in their research.
Write a two-sentence course description for a PhD seminar on AI agents.
Preferred — sentences like these:
- "Students build three working agents and break two of them on purpose."
- "By Friday, everyone has watched their own agent fail and knows why."
Not preferred — never sentences like these:
- "This cutting-edge seminar empowers doctoral students to leverage the transformative potential of AI agents."
- "Participants will unlock new synergies."
Students spend five days building AI agents from raw conversations: designing them, breaking them, and reading the transcripts to see exactly why. By the end, each participant has a working agent in their own research domain — and a list of the ways it fooled them.
The refinement loop is worth naming as a habit, because it changes your relationship to a misbehaving prompt. When the model makes a mistake, your first instinct is to explain the mistake in words. Often the stronger move is to capture the mistake itself — paste it into the prompt as an explicit negative example — and to capture the best output you've seen as a positive one. The model never changes; the prompt does. But the effect is the one you wanted: behavior, steered — one example at a time.
The conversation teaches itself
One last thing to carry out of this lesson, and it changes how you read every conversation from here on. You have been placing examples into the prompt deliberately. But the conversation itself becomes a pattern — one that grows as the conversation grows. Every turn adds to the document, and the model learns from all of it, including the parts it wrote. As a conversation lengthens, patterns inside it start to repeat, and repetition is exactly what this machine is built to continue.
The conversation as a self-teaching document
This cuts both ways, and you must watch for both:
Reinforcement, good and bad
The lesson from teaching-by-example is that examples are powerful teachers. The warning is that the conversation is always teaching — whether or not you meant it to. A pattern you let stand early becomes a pattern the model reinforces later, on itself. Later in the course this becomes a design tool: we will deliberately seed and prune the conversation to steer the patterns it reinforces. For now, simply start noticing — a conversation is a pattern that grows, and it will teach the model whatever it is allowed to repeat.
- Think of the last time an AI's output annoyed you. Could you have written the rule for what was wrong? Could you have pointed at it? Which would have been faster — and which more precise?
- What is the risk of folding in too many examples from one round? What might the prompt learn that you didn't intend to teach?
Three small builds from your own research world: (1) a classification task taught purely by labeled examples — including one example that teaches a boundary; (2) a worked chain-of-thought example — problem, "Think step by step:", your reasoning, your solution — followed by a new problem, checking whether the model walks your steps; (3) one round of preference-driven refinement on any prompt you already use, keeping the before and after.