Prompting Is Briefing, Not Incantation
Every course that touches AI eventually has to say something about prompting, and most of what gets said is folklore: magic phrases, personas to adopt, a sense that the right incantation unlocks a better model hiding inside the one you have. This lesson covers prompting properly, for the first time in this course, and it earns the word "properly" by refusing every claim it can't justify from what you already know about how an agent works.
The previous lesson built the loop equation: agent = model + loop + tools + context. This lesson picks up exactly where that left off. If the model is a pure function of whatever's in its context window, then the part of that context you author directly is the entire interface you have to it. That reframe is the whole lesson.
The reframe: you're briefing a new hire, not casting a spell
Forget "prompt engineering" as a mystical skill and start from the equation instead. A prompt is simply the portion of the context window that you author directly, sitting alongside the system prompt, the tool definitions, and whatever transcript has already accumulated. Given that, the right mental model isn't a magician muttering the correct words at a black box. It's a manager briefing a very fast, very literal, newly hired employee who has read broadly but knows nothing about your specific situation until you tell it.
That comparison isn't a friendly metaphor bolted on for approachability. It's structurally accurate. A new hire with no memory of your company, no access to your files until you hand them over, and no standing authority to act until you grant it, is functionally identical to a fresh agent session: stateless, contextless, capable, and waiting for a brief. The skill of briefing a new hire well and the skill of writing a prompt well are, underneath the surface vocabulary, the same skill. That's not a coincidence this course treats lightly. It's a large part of why organization theory sits inside a course about agents at all.
The five-part brief
Any task worth handing to an agent deserves five things, and none of them are jargon invented for this course. They're what a competent work order already contains, made explicit so you stop skipping the parts that feel obvious and end up costing you a wasted run instead.
Say exactly which files, and where. "The two CSVs in data/," not a vague pointer at "the data." An agent that has to guess at the universe of relevant files will either guess wrong or spend turns exploring to find out, and every one of those turns is context spent on discovery instead of on the task.
Specify the exact artifact you want, not a category of artifact. "reports/2026-06-reconciliation.md, with a summary table and one row per exception," beats "write a report." A shape you specify is a shape the model optimizes toward. A shape you leave unspecified gets filled in by whatever the model's own prior expectation of "a report" happens to be, which may or may not match what you actually needed.
State the constraints and priorities that matter. "Match on invoice ID, never on names. Don't touch data/." Rules prune the space of things the model has to consider, and they encode the kind of hard-won operational knowledge that, left unstated, gets rediscovered the expensive way.
Specify how the work proves itself. "Include control totals; the gap must be fully explained or the report must say so." Never accept "done" as a self-report. Asking explicitly for evidence, and specifically for what doesn't reconcile, forces the model to actually hunt for its own misses instead of presenting a clean-looking output that quietly skipped the messy parts.
Name where the agent must pause for a human. "Show me the plan first." "Draft, don't send." This is where you encode which decisions are yours to make and which the agent may make on its own, and it's the part most likely to get skipped by someone in a hurry, which is exactly when it matters most.
This isn't folklore dressed up as a checklist. Each of the five parts front-loads context the loop would otherwise have to discover on its own, or worse, guess at and never surface as a guess. Inputs save exploration turns that would otherwise be spent listing directories and reading files just to figure out what exists. Output shape means the model optimizes against your actual acceptance criterion instead of its own prior for what "a report" generically looks like. Rules prune the search space before the model wanders into it. Evidence converts an unverifiable "trust me" into something you can actually check, and asking specifically for exceptions is a real behavioral shift, not a placebo: a model asked to find what doesn't reconcile behaves differently than one asked to produce a summary. Stop encodes exactly where human judgment is non-negotiable, which connects straight back to the governing idea from Class 1 of this course: accountability doesn't transfer, so the brief has to say, explicitly, where it stays with you.
Notice what this actually is, underneath the five labels: a good work order. Nothing about it is specific to language models. The skill transfers cleanly from managing people, which is exactly why it should. A new hire briefed with vague inputs, no output spec, no stated rules, no evidence requirement, and no defined stopping point produces work you can't trust either, for the same structural reasons.
The same task, briefed two ways
Abstractions earn their keep once you watch them apply to a real task, so take one and run it through both a bad brief and a five-part one.
The task: a small consulting firm needs its June invoices reconciled against its bank deposits before month close. Here is the brief most people would actually type, in a hurry, on a Tuesday afternoon:
"Reconcile the invoices against the bank deposits."
Nothing about that sentence is unreasonable as a description of intent. It's also missing all five parts, and each gap has a specific, predictable cost:
| Missing part | What's left unstated | What actually happens |
|---|---|---|
| Inputs | Which files count as "the invoices" and "the bank deposits" | The agent explores the repository to find out, or worse, guesses |
| Output | What artifact "reconciled" is supposed to produce | The agent picks a format from its own prior, possibly a chat summary rather than a reviewable file |
| Rules | How to match one record to the other | The agent may match on client name, which looks reasonable and silently fails when two clients share a similar name |
| Evidence | What proves the work is actually done | "Done" can mean "I looked at it and it seems fine," not a control total that proves the books balance |
| Stop | Whether this should run autonomously at all | A fully autonomous run becomes the default, whether or not that's what you wanted for real financial records |
Now the same task, briefed with all five parts present:
"Reconcile
data/crm_invoices.csvagainstdata/bank_deposits.csvfor June 2026. Output:reports/2026-06-reconciliation.md, with a summary table and one row per exception with evidence. Rules: match on invoice ID from the bank concept field, never on client names; treatdata/as read-only. Include control totals that fully explain the gap, or say plainly that they don't. Show me your plan before executing."
Every sentence in that brief maps to one of the five parts, and every part is doing real work that the vague version left to chance. The inputs name the exact two files. The output names the exact path and the exact shape. The rule about matching on invoice ID, not client names, encodes a lesson someone probably learned the expensive way at some point, the kind of institutional knowledge a new hire has no way to know unless told. The evidence requirement means a gap that doesn't fully reconcile gets reported as a gap, not quietly smoothed over. And the plan-first instruction means you see the approach before any file gets written, at the cost of ten seconds of reading.
Techniques that survive contact with a real agent
Some prompting advice holds up once you actually have tools, a loop, and a context window to reason about. Some of it turns out to be folklore that happened to seem to work in a world of single-shot chatbot replies and stops working, or never worked, once an agent is actually taking actions with consequences.
- Show, don't describe: one example of the output you want beats three paragraphs of adjectives describing it. This is few-shot prompting under a plainer name, and it's a heuristic worth defaulting to rather than a measured ranking: in this course's own experience it's one of the most reliably useful techniques available to you. An example report constrains format, tone, and depth all at once, and it's among the cheapest ways to specify a shape.
- Plan before act: ask the agent to propose its approach before executing anything. Catching a misunderstanding in a written plan costs ten seconds of reading. Catching the same misunderstanding after the agent has already acted on it costs however long the wrong output took to produce, plus the time to notice it was wrong, plus the time to redo it.
- Decompose: one bounded task per session. Chain sessions together rather than piling successive, loosely related asks onto a single growing context. This connects directly to the degrading-context property from the previous lesson: a session doing five things at once is a session whose context is full of material irrelevant to whichever of the five it's currently working on.
- Paste the real thing: actual error messages, actual sample rows, actual screenshots, not descriptions of them. As a rule of thumb, an artifact beats a paraphrase of an artifact, because a paraphrase has already lost whatever detail turns out to matter and you don't get to choose which detail that will be in advance.
- Iterate on the brief, not just the output: if what comes back is wrong, the instinct to fix the output directly is usually the wrong instinct. Fix the instruction that produced it instead. A wrong output patched by hand is a one-time fix. A brief corrected once is a fix that holds for every future run of the same task.
- Magic incantations: "You are the world's best analyst" adds tokens to the context window. It does not add skill to the model. Treat it as a heuristic rather than a measured result: a token spent on flattery is, in effect, a token not spent on the inputs, rules, or evidence that would actually change the output.
- The kitchen sink: pasting everything "just in case" feels safe and is actually a real cost, per the degrading property from the previous lesson. A context window packed with irrelevant material produces worse output than a lean one, not better.
- "Are you sure?" Asking a model to grade its own work, in the same context that produced the error, is asking a student to grade their own exam using the exact reasoning that got the question wrong in the first place. It will often find itself convincing, because the same blind spot that produced the mistake is the one being asked to check for it. The real fix is structural, not verbal: an independent check, in a fresh context that never saw the original reasoning. Hold that thought. It becomes a specific, concrete feature later this class.
- Vague verbs: "analyze," "clean up," "improve," with no output specification attached, hand the decision of what those words mean to the model's own prior, which is exactly the decision the output-spec part of the five-part brief exists to make yours instead.
- Prompt-tweaking a scope problem: if a task is actually unbounded, no amount of clever wording rescues it. The fix is to bound the task, not to keep rewording the same unbounded request in search of a phrasing that magically constrains it.
What the five parts and the two lists have in common
Step back and notice the pattern running through everything in this lesson so far. The five-part brief works because it pre-loads context the loop would otherwise burn turns discovering. The surviving techniques work because they reduce ambiguity, supply real artifacts instead of descriptions, or correct the brief itself rather than patching a symptom. The folklore fails because it either wastes context, or asks the model to verify itself using the exact reasoning that produced the thing being verified. None of this is a separate body of knowledge from the loop equation in the previous lesson. It's the same equation, applied specifically to the piece of context you write yourself.
Where this leaves you
You now have a real, defensible account of what a prompt is and why the techniques that survive actually survive: a prompt is the part of the context window you author directly, and every technique that holds up does so because it manages that window deliberately, either by supplying the model with exactly what it needs to avoid guessing, or by refusing to waste the window on padding, flattery, or a self-check that can't see its own blind spot.
The next lesson takes this same discipline into Claude Code itself: the same model-loop-tools-context equation, hardened into a production tool, with a real permission system standing between the model's requests and anything actually happening on your machine. You've briefed a toy agent in theory. The next lesson briefs a real one, live, inside a repository built to be an organization rather than a demo.
Reply here and it goes straight to Rod. Same as replying to one of his emails.
