Four kinds of work sit behind any agent, and each has a name that sounds harder than the thing it describes: prompt, context, loop and harness engineering. This note is about prompt engineering. The other three have notes of their own, and they can be read in any order.
Picture sending a friend to the shop for you. How you word the request is prompt engineering. What you send with them — the list, the money, a photo of the empty fridge — is context engineering. What they do when the shop has no milk is loop engineering. The bag, the bus fare and the rule about how much they may spend is harness engineering.
So: the words.
In short
- What
- Writing the instruction: the job, who the answer is for, the shape you want it back in, and what not to do.
- Why
- Most disappointing answers are not the model being slow. They are a request that could be read two ways, and the model quietly picking one.
- When
- First, always. It is the cheapest thing to change, so it is the first thing to check when something comes back wrong.
- How
- One sentence for the job, one example of a good answer, one named failure to avoid — then read it back as if you had never seen the task before.
What a prompt actually is
A prompt is the instruction you hand the model. Not the idea in your head, not the conversation you had about it last week — the words, and only the words.
That is the part people find hardest to believe. We are used to talking to colleagues who fill in the rest: they know the project, they remember what you said on Tuesday, they can tell when you are in a hurry. A model gets the text and nothing else. If a detail is not in the words, for that moment it does not exist.
So prompt engineering is a writing job, not a technical one. It is the unglamorous practice of describing a task so clearly that a stranger could carry it out without asking you a single question.
Why a vague request comes back as a guess
Children are very good at catching adults out on this. “Tidy your room” and “put the books on the shelf and the clothes in the basket” are the same request, and only one of them gets done the way you meant. The difference is not effort. It is that the first one left a gap, and the gap got filled by someone else’s idea of tidy.
A model does the same thing, minus the eye-roll. Ask it to “summarise this listing” and it has to decide, silently, how long the summary should be, who is reading it, whether the price matters more than the photos, and whether to keep the owner’s tone or flatten it. You did not choose any of that. The model did, using an average of everything it has ever read.
This is why a bad answer is so often a badly specified question. The model rarely stops to say it does not understand; it produces something plausible instead. Plausible and wrong is a harder problem than obviously stuck.
When you reach for it
First, and always. Before you add data, before you add tools, before you build anything clever around the model, read the instruction once more and ask whether a careful stranger could follow it exactly one way.
It is also the right place to return to whenever something comes back wrong in a way that feels like misunderstanding rather than ignorance. If the answer is about the right subject but the wrong shape, wrong length, wrong audience or wrong level of confidence, the words are usually the fix.
Changing words costs nothing and takes a minute. Everything else on this list costs more. Start here for that reason alone.
How to write one
Say the job in a single sentence, at the top. If you cannot, the task is probably two tasks.
Say who the answer is for. “Explain this to someone who has never used the product” and “explain this to the engineer who built it” produce different writing, and the model cannot tell which you want.
Show one example of a good answer. One is usually worth more than three paragraphs of description, because it settles length, tone and format all at once without you having to name any of them.
Name the failure you are most worried about. “Do not invent a price that is not in the text” is a useful sentence. So is “if a detail is missing, say it is missing rather than guessing” — a model will admit a gap far more readily when admitting it is an allowed answer.
Then read it back cold, as if you had never seen the task. Every place you find yourself thinking “well, obviously it means…” is a place where something obvious to you is invisible to the reader.
Where it stops
Prompting has a ceiling, and it is worth knowing where it is. No wording can supply a fact the model was never given — that is context engineering. No wording makes it check its own work and try again — that is loop engineering. And no wording lets it open a file, call a service or spend money, or reliably stops it doing so — that is harness engineering.
When better and better instructions stop helping, it is usually not a writing problem any more. It is a sign that the fix has moved down a layer.
