A prompt is the ask. Context is everything the AI needs to answer it well, and dumping in more is not the fix. What to feed it, what to leave out, and the one file that makes it repeatable.
A prompt is the ask. Context is the ground it stands on: who this is for, what good looks like, the real material, and what to leave alone.
When the AI gives you generic or wrong output, the reflex is to write a cleverer prompt. Usually the prompt was fine and the context was thin.
More context is not better context. Dump everything in and the model loses the thread. Curation is the actual skill.
Write the context down once, in a small file, and every future task starts from ground instead of from a guess. That file is the same muscle as episode 02’s memory folder.
Last time, in put the AI on the work around work, i handed the AI the small jobs that sit around the real work, the ones nobody wants to do. This one goes under all of that, to the piece that decides whether any of it lands: what the model can actually see when it answers you.
A few weeks ago, an AI i built into an app asked a real user to name a beach-party plan. On their first thirty seconds in the product. The app could technically make a plan called that, so it wasn’t a hallucination exactly, it was worse, it was a real feature dragged to the front because the model had nothing better to go on. i had handed it a one-line description of the app and told it to get the user to a concrete first action. A one-line description is an invitation to guess. So it guessed, confidently, in front of someone i was trying to keep.
That was the moment context engineering stopped being a phrase i skimmed past and became a bug with a name.
Here is the distinction i wish someone had drawn for me a year ago.
The prompt is what you want. “Write the launch email.” “Clean up this folder.” “Draft the onboarding.” Short, and you already know how to write one from episode 01.
Context is everything the model needs to answer that well and doesn’t have unless you give it. Who the email is for and the three you sent before it. What “clean” means for this folder and which files are sacred. What the app actually does and who is standing on the other side of that onboarding. The prompt points at a target. Context is whether the model can see the target or is throwing in the dark.
Most bad AI output is not a bad prompt. It is a fine prompt fired into an empty room. Put it another way: most agent failures are not model failures, they are context failures. The model fills the empty room with the most statistically average thing, and average is exactly what makes you close the tab and say it’s overhyped.
When people say “context,” they mean four different things stacked together. It helps to see them apart.
A prompt is the arrow. These four are the ground it lands on.
The goal. Not the task, the outcome. “Turn these contracts into a tracker” is a task. “So i can see at a glance which renewals are risky this quarter” is the goal. Give the model the why and it makes better calls on the hundred small things you didn’t specify.
The ground truth. The real material, not a description of it. This is the one people skip. Don’t tell the AI “our brand is friendly and direct”, paste two emails that sound the way you mean. Examples beat adjectives every time. A model shown three real things you like will out-perform any paragraph describing them.
The constraints. What good looks like and what to never do. The length. The format. The one competitor you can’t mention. The date you can’t get wrong. Constraints are not the AI’s handcuffs, they are how it knows it succeeded instead of guessing at your taste.
The boundary. What to leave out and what not to touch. This is the half nobody talks about, and it’s coming next, because it’s the one that separates people who are good at this from people who just paste more.
Here is the counter-move, and it’s the part that surprised me.
Once you learn that thin context causes bad output, the obvious next step is to feed it everything. The whole folder. The entire history. Every doc, in case it helps. It feels thorough. It is the exact opposite of thorough.
A model has a working memory, and past a point, adding more doesn’t inform it, it distracts it. The signal you actually needed gets buried under fifty pages of nearly-relevant noise, and the answer gets vaguer, not sharper. i have watched a model give a worse answer to the same question after i “helpfully” pasted three more documents. The good rows were in there. It just couldn’t find them anymore.
So context engineering is not “add context until it works.” It is “give it exactly what this task needs, and nothing that competes with that.” Curation, not accumulation. The boundary from the last section is a real tool: telling the model what to ignore is as load-bearing as telling it what to read.
The test i use now is embarrassingly simple. Before i paste something in, i ask: does the model need this to answer, or am i adding it to feel safe? The second kind is the noise.
You don’t need a framework. You need four sentences before the task, roughly in this order.
State the goal, not just the task. One line on the outcome you’re actually after. “so that...” is the most useful phrase in the whole practice.
Show, don’t describe. Paste two or three real examples of what good looks like. A before, an after, a thing you’d be happy to get. This single move fixes most “it sounds generic” complaints.
Name the constraints and the anti-goals. The format, the length, the hard limits, and the one or two things it must never do. Short bullets are fine.
Draw the boundary. Say what to use and what to ignore. “Only this folder.” “Don’t touch the pricing.” “The old draft is background, not a template.”
That’s it. Four sentences turns “write the launch email” from a coin flip into something you’d actually send.
The last move is what makes this compound instead of repeat.
The first time you assemble the context for a recurring job, don’t throw it away. Put it in a small file: what this project is, who it’s for, what good output looks like, what to leave alone. Next time, you point the AI at the file and add one line for today’s task. You’ve turned a five-minute setup into a five-second one, and the output stays consistent because the ground under it stopped moving.
On a real project this isn’t one file, it’s a few, and the names are becoming a standard. PROJECT.md for what the thing is and why. CONTEXT.md for what you’re working on right now. CLAUDE.md and AGENTS.md for the rules you want the AI to follow. README.md for the human who lands cold. And progress.md, the memory file from episode 02, for what happened last. Any AI you point at the folder reads them and knows where it is. None of them are long, half a page each is plenty, and you only write them once.
the context lives in the repo, not in your head. any AI you point at the folder reads it and knows where it is.
If episode 02 sounds like it’s happening again, that’s because it is. A memory folder is context that persists across sessions. A context file is the same instinct pointed at a single project. The AI that invented a beach-party plan does not do that anymore, and the fix was never a cleverer prompt. It was a page of real product context, written once, that told it what the app is actually for and who is on the other side.
Two ways, both worth knowing.
Stale context is worse than no context. A context file that still describes last quarter’s product will make the AI confidently wrong, and confidently wrong is the expensive kind. When the thing changes, change the file. It’s a living note, not a monument.
And context is not a substitute for the check. Grounding the model dramatically raises the floor, it does not remove your job of reading the output before you trust it. That check is its own episode later in this series, and it’s the one that never gets automated away.
The punchline is small and annoying and true: most of the time the AI wasn’t wrong because it’s dumb. It was wrong because it was guessing, and it was guessing because you didn’t tell it the thing you assumed was obvious. Context engineering is just the discipline of saying the obvious thing out loud, once, and then reusing it.
That is context engineering. Follow for more, i write up what i actually run on my own projects.
i’m Malik, i’ve been a mobile engineer for 9 years, and i run my work on the system this series describes. This is episode 04 of Using AI, properly. Episode 02 was give the AI a memory, episode 03 was put the AI on the work around work. Next up: get started with MCP, the plug that lets your AI reach a real tool instead of guessing from a chat window.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.