Context Is the Whole Game
By the end of this module you can tell the difference between output that is weak because the tool is limited and output that is weak because you withheld the facts. You can explain what a context window is without using the word "memory". You have at least two reusable context files sitting in ai-kit/context/, so you stop re-explaining your job, your audience and your situation for the ninth time. And you can tell when a long conversation has gone stale and starting fresh is cheaper than pushing on.
what it knows about your task, right now
┌─────────────────────────────────────────┐
│ THE DESK │
│ │
│ ┌────────┐ ┌──────────┐ ┌────────┐ │
│ │ about │ │ the │ │ what │ │
│ │ you │ │ material │ │ good │ │
│ └────────┘ └──────────┘ │ looks │ │
│ │ like │ │
│ ┌───────────────────────┐ └────────┘ │
│ │ your instruction │ │
│ └───────────────────────┘ │
└─────────────────────────────────────────┘
▲ │
│ you put it there, │ cleared when
│ every single time │ you close the tab
│ ▼
┌──────────────┐ ┌──────────────┐
│ your files, │ │ nothing │
│ your head │ │ carried │
└──────────────┘ └──────────────┘It answers from what is on the desk, not from what you know — and the desk is cleared between sessions.
- Say what a context window is in one sentence, without using the word "memory".
- Sort the context a request needs into three kinds: about you, about the material, about what good looks like.
- Ground a request by handing over the source instead of asking it to recall the source.
- Name the signal that tells you a long conversation has degraded, and start a fresh one on purpose.
- Cut a context pack down when the instruction that matters is getting buried in it.
- Order a long request so the material comes first and the instruction comes last.
ai-kit/context/ — a folder holding two reusable files: ai-kit/context/audience.md, describing who your output is for and what they already know, and ai-kit/context/project.md, describing the situation you work in most often. You paste one or both at the top of a task instead of retyping the same background.
This is the most common complaint about AI output, and almost every time it is an accurate description of something else: what the person did not say.
Here is the shape it takes. Someone asks for a follow-up email to a customer. What comes back is competent, warm and useless: it thanks the customer for their time, mentions the value of the partnership, and offers to answer any questions. The person concludes that the tool does not understand their business. But look at what it had. A request for a follow-up email. It did not have the customer's name, what was actually discussed, the fact that the account has been stalled since March, the rule that nobody promises a delivery date before the build call, or the detail that this customer hates being called a partner. None of that was withheld deliberately. It never got typed, because to the person typing it is not information. It is the air they breathe.
That is the whole trap. The context you are least likely to supply is the context you find most obvious. The things that make your work yours stopped being facts to you years ago and became background, so you type the visible part, leave out the load-bearing part, and then judge the output against a brief that only ever existed in your head.
Test it before you believe it. Take the last output that disappointed you and ask what a competent new hire would have produced from exactly the words you sent, on their first morning, having met nobody. If the new hire would have written roughly the same disappointing thing, the problem was the brief. That is not a comforting answer, but it is an actionable one, and "the tool is not smart enough" is not.
Key insight: most of the time, "it doesn't understand my business" means "I did not tell it about my business, because I forgot my business was information."
Context is not one thing you either give or withhold. It comes in three kinds, and they fail in different ways, which is why it helps to name them separately.
About you. Your role, your constraints, who you answer to, what you are allowed to promise, what you never do. You wrote the first version of this in Module 01 as ai-kit/about-me.md. Missing it produces output aimed at nobody in particular: technically fine, positioned wrong.
About the material. The document, the numbers, the thread, the history. What actually happened, who said what, what the current state is. Missing it produces output that is plausible in general and false in particular — the customer's situation described the way such situations usually go, rather than the way this one went.
About what good looks like. Length, format, tone, the thing you always cut, the bit your boss always asks for. Missing it produces output that is right and unusable: a five-paragraph essay when you needed three lines.
Most disappointing output is missing exactly one of the three, and the way it is wrong tells you which. Wrong facts point at material. Right facts aimed at the wrong reader point at you. Right facts, right reader, unusable shape points at standards. Module 02's ai-kit/requests.md gives you the five-part brief; these three kinds fill its material and constraints parts when the task is one you repeat.
Here is the mental model that fixes most of the confusion. The context window is a desk, not a filing cabinet.
Everything it can use for your answer is on the desk at once: your instruction, whatever you pasted, whatever it said earlier in this conversation, and any standing instructions the tool loads for you. It reads the desk fresh every time it answers. It does not walk to a cabinet and retrieve the file about your Q3 launch. There is no cabinet, only what you laid out.
The desk has an edge. It holds a lot, and more every year, but it is finite, and past the edge the earliest material falls off. Some tools quietly drop the oldest turns, some summarise them, some refuse. The effect on you is the same: something you established at the start is no longer reliably present, and nothing announces its departure.
And the desk is cleared when you leave. A new conversation starts empty. This is the part that catches people, because it contradicts everything else on a computer: you expect an app that knew something yesterday to know it today. It does not, unless a feature specifically put it there. Persistent-instruction surfaces, project spaces and memory features all do one job, which is to put something back on the desk at the start of every session so you do not have to. They sit on top of the desk. They are not an escape from it.
Remember: every mainstream tool now ships some version of a memory or project feature, and their names and limits change every few months. What they do underneath does not change. If you can say what got loaded onto the desk and what did not, you can use any of them, including the ones that do not exist yet.
A conversation that has run for forty turns is a desk worked on all day: your original brief, three abandoned drafts, a tangent about formatting, a correction made twice, and a document you pasted an hour ago and no longer care about. All of it is still being read as input.
Two things go wrong. First, contradiction. You said "keep it formal" at turn four and "loosen it up" at turn twenty-six, and both are still sitting there. You know the second supersedes the first; the desk has no concept of superseding, only two instructions with equal claim. Second, dilution. Your actual question is one small item among thousands of words of history, and the draft you rejected is still shaping what comes next.
The signal to start fresh is concrete, and you should learn to notice it: you have corrected the same thing twice and it came back a third time. Not "the output got a bit worse", which is too vague to act on. A repeated correction that does not stick means the conversation is arguing with itself, and no further correction inside it will win. Two other tells: the output drifts back toward a version you had moved past, or it refers to something you decided against as though it were still the plan.
When you see it, do not push harder. Open a new conversation, paste the current best version of the material, state the instruction cleanly once, and continue. It takes ninety seconds, because you are handing over a clean desk. This is also why context packs pay for themselves: restarting is cheap when the background is a file you can paste, and expensive when it is forty turns of history you would have to rebuild by hand.
The single highest-return habit in this module: when the answer depends on a specific document, paste the document.
Asking "what does my company's refund policy say about damaged goods" without providing the policy is asking it to produce a plausible refund policy. It will. It will read well, resemble a real policy, and be a composite of every refund policy it has seen rather than yours. Paste the policy and the job changes completely: from generating something policy-shaped to finding the relevant part of a document in front of it. Finding and summarising is something it is genuinely good at. Recalling your document is something it cannot do at all.
The smaller cases are where people slip. "Summarise the thread from yesterday": there is no yesterday. "Use the tone from the last one you wrote": there is no last one. "Follow the format you used before": there is no before, only the words in front of it right now. Each feels reasonable to type because it would be reasonable to say to a colleague. A colleague has a filing cabinet.
The rule: if the answer depends on a specific thing, the specific thing goes on the desk. Upload it, paste it, or quote the part that matters. If the source is too long, paste the sections that bear on the question rather than describing it from memory. Your description of a document is not a substitute for the document, because it was written by the same person whose assumptions caused the problem.
This is the part almost nobody teaches, and it is why "add more context" is bad advice on its own.
Everything on the desk competes for attention. Paste forty pages of background and end with a one-line instruction, and that instruction is a small object in a large room. What comes back tends to answer the general subject of your material rather than your specific question: a good summary of the forty pages when you asked for one decision, or an answer shaped by the concerns of page thirty-one because page thirty-one was long and emphatic.
You notice it as a particular kind of wrongness: on-topic, well-informed, clearly derived from what you sent, and not an answer to what you asked. That combination is diagnostic. Wrong and uninformed means missing context. Right and beside the point means too much of it.
The fix is not to strip context back to nothing. Send the context that bears on this question and leave out the context that merely relates to the topic. Before pasting a long document, ask which sections a careful colleague would actually read to answer this, and paste those. If the honest answer is "all of it", put the instruction where it cannot be missed, which brings you to order.
Warning: dilution costs more than missing context, because it looks like success. Missing context produces something obviously off. Too much produces something well-researched and subtly beside the point, and that is the kind of thing that gets forwarded.
Put the material first and the instruction last.
The practical version: paste your context pack, then the document, then — at the very bottom — the thing you actually want done. Rather than opening with "summarise the following into three bullets for my board" and then dropping in twelve pages, drop in the twelve pages and finish with "summarise the above into three bullets for my board, each one a decision the board has to make."
Two reasons this helps. The obvious one is human: an instruction at the end is the last thing read, by you when you check the request and by it when it answers. The less obvious one is that these systems handle the beginning and the end of an input more reliably than the middle. An instruction buried in the middle of pasted material is the most easily lost item in the request.
Be clear about the status of this advice. It is a practical observation about how these systems tend to weight long inputs, not a law and not a specification any vendor publishes. It varies by tool and by version of the same tool. Treat it as a default that costs nothing to follow and often saves a round trip, not as a rule you defend. Stating the instruction at the top and repeating it at the bottom also works, and is worth trying when a long request goes sideways.
Context packs are for work you do more than once. Reach for one when the same background would have to be retyped, and skip it otherwise.
Two cases where building one is a waste or worse. First, a situation that happens once, or that moves week to week. If you will never do this again, writing a reusable file about it is procrastination with a productive shape. If the details change between one week and the next — the account owner, the current blocker, what the client has already been promised — the file is stale before you get to reuse it, and a stale pack is worse than no pack, because it supplies wrong facts confidently while looking like preparation. Type the context inline and move on. Second, tasks where the output must not be coloured by your framing. If you are stress-testing your own plan, your carefully written context pack is the bias you are trying to defeat. Give it the material and withhold the framing on purpose.
There is also a maintenance cost. A file naming your title, your team and your current priority is accurate the day you write it. Six months on, half of it describes a job you no longer have, and it is producing wrong output while looking like diligence. Small files, short lives, a date at the top.
Fifteen minutes. Use one task you genuinely did this week.
- Your two context files exist at
ai-kit/context/audience.mdandai-kit/context/project.md, and each carries a date. - Each file contains at least one fact you would not have thought to type, because it was too obvious to say out loud.
- The warm output differs from the cold in ways you can attribute to specific lines you added, not just "it seems better".
- Neither file is longer than one screen.
- You can point at one thing you deliberately left out of the pack, and say why leaving it out was correct.
Use this once per recurring task, when you know the background matters but cannot face writing it out cold. It interviews you rather than guessing, then drafts the two files. Answer the questions in one pass and edit what comes back; the corrections you make are usually the most valuable lines in the finished file.
This prompt also lives on its own at prompts/context-pack-builder.md.
<task> Interview me, then draft two reusable context files for a task I do repeatedly. </task> <context> This is my standing description of myself and my work: [paste the full contents of your ai-kit/about-me.md here] </context> <input> The recurring task I want context files for: [describe the task in two or three sentences: what you produce, who receives it, how often] </input> <instructions> First, ask me up to eight questions, numbered, one line each. Ask only about things you cannot infer from what I have already given you. Prioritise the background a competent new hire would need on their first morning and would have no way to guess: names, current state, decisions already made, things nobody is allowed to say, and the reason work in this area usually gets rejected. Stop and wait for my answers. Then produce the two files. </instructions> <output_format> Round one: a numbered list of questions only. No draft, no preamble. Round two, after my answers, two fenced code blocks and nothing else: Block 1, headed audience.md — under 200 words, covering who the output is for, what they already know, what they do not care about, and what makes them reject something. Block 2, headed project.md — under 300 words, covering the situation, names, current state, settled decisions, and standing prohibitions. Each block starts with a line reading: Last updated: [today's date] </output_format> <rules> - Do not attempt the underlying task. You are writing background, not output. - Do not invent any fact. If something is needed and I did not supply it, write it as a line beginning "TO CONFIRM:" so I can fill it in. - No adjectives about quality or tone. Facts and constraints only. - Do not include anything I could look up in ten seconds. - Do not exceed the word limits. If you run out of room, cut the most general material first. </rules>
Use this before an important request, not after a bad one. You paste what you were about to send and it tells you what is missing, which is an easier question for it than the task itself. The value sits in the questions you cannot answer: those are the ones you were about to assume your way past.
This prompt also lives on its own at prompts/what-else-do-you-need.md.
<task> Tell me what context is missing from the request below. Do not carry out the request. </task> <input> The request I am about to send, in full, exactly as written: [paste the entire request you were about to send, including any material you attached] </input> <instructions> Read the request as though you were a competent new colleague on your first morning, with no knowledge of me, my organisation, or anything not written above. Identify what you would need to ask before you could do this well. Separate what would block you entirely from what would merely improve the result. For each item, say in one clause why it changes the output. </instructions> <output_format> Two headed lists, nothing else. BLOCKING — up to five items. Format: question — why it changes the output. HELPFUL — up to five items. Same format. Then one final line beginning "BEST GUESS IF UNANSWERED:" stating what you would assume for each blocking item if I sent the request unchanged. </output_format> <rules> - Do not answer the request or produce any part of the deliverable. - Do not ask for anything already stated in the request above. - Do not ask more than ten questions in total. - No compliments, no summary of the request back to me, no closing offer. - Every item must be a question I could answer in one sentence. </rules>
Read your request out loud and stop at every noun that only means something inside your organisation. Each one is a missing line of context. Then hand the request, with nothing else, to someone who does not do your job, and ask what they would need before they could start. Their questions are your context pack.
Both files stay in the folder, not in a chat window. You paste them at the top of tasks for the rest of the course, and rewrite them roughly every quarter, when the date at the top starts to look old.
Save as: ai-kit/context/audience.md and ai-kit/context/project.md — read again in Module 05 and Module 11.
Say these out loud. If you cannot, reread the section named after each.
- I can say what a context window is without using the word "memory". (The Desk, Not the Filing Cabinet)
- I can open my two context files and name one fact in them I would never have thought to type. (Three Kinds of Context)
- I can name the signal that tells me to abandon a conversation and start fresh. (Why Long Conversations Rot)
Module 04, Assume It's Confident and Wrong, takes your improved output and asks the harder question: it now sounds exactly like your business, which makes it more convincing and no more true, so you build ai-kit/checks.md to check it before you trust it.