By the end of this chapter you can take a flat request and load it with the context only you have, so the model stops handing you the average answer.
Last chapter you saw the difference between operating a tool and directing one. The whole gap was context. This chapter is about where that context comes from, and the answer is uncomfortable at first: it comes from you, and supplying it is the job.
People expect the model to be smart enough to fill in what they left out. It is not. It is smart enough to produce something plausible from whatever you gave it, and plausible from almost nothing is generic by definition. The output reflects the incoherence of the input. Thin question, thin answer.
AVATAR OPENER · ~90s
Watch: the same task with no context, then with the context only you have
HeyGen avatar · generated, consistent presenter
Think of it this way. The model has read an enormous amount of the public internet, frozen at a moment in time. That makes it a good average of everything everyone has ever written. What it has never read is your situation: your customer, your last invoice, the thing your competitor does that annoys you, the way you actually talk. None of that is in the training data. It can only come from you, in the request.
The task alone
A verb and a noun. "Write a follow-up email." The model fills the rest with the most likely words.
Result: correct shape, no substance. Could be anyone’s.
VS
The task plus your context
Who it is to, what already happened, what you want next, how you sound. The details only you hold.
Result: specific, usable, recognisably from your desk.
The model brings the average of everything. You bring the specifics of your one situation. That second part is your job, not its.
Thin question, thin answer. The fix is never a cleverer prompt, it is more of what only you know.
TASK VS CONTEXT
Every request has two parts, and beginners only ever send the first one. The task is what you want done. The context is everything the model would need to do it the way you would. Same task, different context, completely different result.
Who and why
The real person on the other end and what they need from this.
What already happened
The backstory the model cannot see. The prior email, the last call, the history.
What you want next
The actual outcome, not just the format. A reply that books the meeting, not just a polite note.
How you sound
Plain, warm, blunt, whatever is you. Otherwise it defaults to corporate.
SEE IT
Here is a real one. A freelancer needs to chase a late invoice. The flat version is what most people send. Drag the handle to see what the same task does once the context is loaded.
Task onlyPrompt: write a follow-up email about an unpaid invoice. Output: a stiff, generic reminder that any business could have sent to anyone, vaguely apologetic, no specifics, easy to ignore.
Task plus contextPrompt carries the context: invoice 412, 18 days overdue, client is a friendly small studio who usually pays fast so this is probably an oversight, you want the money without bruising the relationship, you sound warm and direct. Output: a short, human note that names the invoice, assumes good faith, and makes paying the easy next step.
generic (starved)yours (specific)
Notice what changed. Not the wording skill. The four things from the cards, supplied up front. You did not teach the model to write. You told it the situation only you could know.
The context-loaded request
Write a short follow-up email about an unpaid invoice.
Context: invoice 412, sent 18 days ago, still unpaid.
Who: a small design studio I like, usually pays on time, so this is likely an oversight, not a problem.
What I want: the payment, without making it awkward.
Voice: warm, direct, no guilt-tripping, no corporate stiffness.
Take one real request you will make this week. Before you send the task, write three to five lines of context: who it is for, what already happened, what you actually want, and how you sound. Then send task plus context together and compare it to sending the task alone.
Right if the context-loaded output contains at least one specific detail that the task-alone version could never have guessed.
Show the worked solution
Say the task is "write a caption for my new pottery class." Task alone gives you something true of every pottery class on earth. Now load context: Who (beginners who think they are not creative and are a bit nervous), What already happened (your last class filled in two days, mostly people who had never touched clay), What you want (signups from nervous first-timers, not experienced potters), How you sound (warm, plain, no art-world jargon). The output now speaks directly to the nervous beginner and references that the last class sold out fast. None of that was guessable. That is the whole move: you did not write better, you supplied what only you knew. If your two versions came out nearly identical, you under-supplied context, so add the one detail a stranger could not invent.
WATCH FOR
✗You send the task and wait. The model cannot read your situation. Front-load the context before you hit send.
✗You add adjectives instead of facts. "Make it engaging" is not context. "It is for nervous first-timers" is.
✗You blame the model for a generic answer. A generic answer is almost always a starved question. Feed it more of what only you know.
✗You retype the request five times. You are editing the output. Edit the context instead, once.
WHAT YOU LEARNED
The takeaways
The model is a good average of everything public and frozen in time. It knows nothing about your specific situation unless you tell it.
Every request is a task (what you want done) plus context (what it needs to do it your way). Beginners send only the task.
The four kinds of context that matter most: who and why, what already happened, what you want next, how you sound.
A generic answer is a starved question. The fix is more real detail, not a cleverer prompt.
Your project · step two
Open a plain note for your thread project and write the first paragraph of context about it: what it is, who it is for, and what done looks like. You are not building anything yet. You are starting the pile of context that every later chapter will reuse. Next chapter you turn this into something durable.
The model supplies the average. You supply the truth of your one situation. That has always been the part only you could do.