A prompt is everything the model can see when it answers, not just the sentence you typed.
Most people picture a prompt as the line they type into the box. That is one ingredient. What actually reaches the model is a single block of text assembled by the product a fraction of a second before it answers, and your sentence usually sits near the bottom of it. Above it: a system prompt, meaning hidden instructions the company wrote about tone, refusals and formatting. Any file you attached, converted into text. The conversation so far, every earlier message included. Search results if a search ran. And any memory notes the app saved from previous sessions and quietly pasted back in. All of that is the prompt.
This is the reframe worth keeping. When people say a model gave a strange answer, they are almost always describing a prompt they could not see. A file that got truncated during conversion. A memory note from three weeks ago that no longer applies. An earlier message in the same thread that set a direction you have since forgotten about. The model answered the prompt it received, which is not always the prompt you thought you sent.
The reason all of it counts as one thing is mechanical. A model works by continuing text, so it makes no distinction between the words the company put there and the words you did. It is all just text in front of it. The container that holds it is called the context window, and there is a full explanation of how it fills and what falls off the edge in what is an LLM. If the underlying idea of a model that learned from examples rather than rules is new to you, start at what is AI instead.
Once you hold that picture, prompting stops being about clever wording and becomes about what you put in the window on purpose. Everything else on this page follows from that.
The same question, phrased two ways, gives two different answers, and that is not a fault.
Ask for help with a difficult email and you get a competent, slightly bland reply. Describe the client, the history, what you want out of it and the tone you use, and you get something you might actually send. Same model, same day, same subscription. The difference is the raw material.
The mechanism is straightforward once you know the model is continuing text. Your words decide which part of everything it learned gets pulled into play. A vague request lands in the region of vague requests, and in the training data those were followed by generic, hedged, roughly-right text. A specific request with real names, real numbers and a stated format lands somewhere much narrower, where the continuations look like the thing you wanted. It is less like giving an instruction and more like setting a starting position.
Now the honest counterpoint, because the prompting industry rarely offers it. Not all the variation you see is your wording. The model picks each next piece of text from a weighted list of candidates, and how far down that list it reaches is a setting the product chose. So the identical prompt, sent twice, can produce two different answers, and occasionally one of them is clearly better through no skill of yours. That means two things in practice. Judging a phrasing on one attempt tells you very little. And when you get an answer that disappoints, running it again costs nothing and is sometimes the entire fix.
So wording matters, but less than the internet claims and much less than context does. The gains from telling the model who you are and what you are doing are large and repeatable. The gains from rearranging your sentence are small and noisy.
The four lines that change the answer more than any clever phrasing.
Four things carry nearly all the weight. What you do and who you do it for. What you are working on right now, with real names and real dates. The decisions you make most weeks. And how you want the answer back, including the one or two things it must never do. Written out, that is about six lines. It goes above your question, not inside it.
Comes back polite, generic, hedged on the deadline, and opens with a paragraph you would delete.
Comes back knowing it is the third month, gives a real reason, invents no figure, and sounds like her.
Take a real case. A woman runs a small bookkeeping practice for shops and cafes in one town. Her bare version reads: help me write an email to a client who has not sent their receipts. What comes back is polite, generic, and could be from anyone to anyone. It hedges on the deadline because it does not know one, and it opens with a paragraph of throat-clearing she would delete.
Her four lines version puts this above the same question. I do the books for small shops and cafes. This week I am closing June for three clients, and one of them, a bakery, is late sending receipts for the third month running. I decide each month whether to chase, file without, or have the awkward conversation about the fee. Answer in short paragraphs, keep it warm but firm, and never invent a figure or a date I have not given you.
What improves is specific, and worth naming rather than waving at. The reply now knows this is a repeat problem, so it can reference the pattern instead of treating it as a first reminder. It knows the real deadline pressure is a month end close, so it has a reason to give. It stops inventing an amount, because it was told not to. And it comes back in her register rather than in corporate email voice. None of that came from clever phrasing. It came from four lines she wrote once and can paste every time.
That is the whole method, and there is a longer walk through it on how to use AI.
Good and bad prompts, side by side.
Here are five ordinary jobs, each with the version most people type and the version that works, plus one line on what actually changed. Copy them and swap in your own details. They are deliberately plain, because a prompt full of theatrical instructions about acting as a world-class expert adds words without adding information.
Summarise this document.
Summarise this document for a colleague who has not read it and has two minutes. Give me: three bullet points on what it decides, one paragraph on anything that affects cost or timing, and a short list of anything that is unclear or missing. If something is not in the document, say so rather than filling the gap.
Write a reply to this angry email from a customer.
Draft a reply to the email below. Context: they are a customer of two years, the delay was our fault, the part arrives Thursday, and I cannot offer a refund but I can waive the delivery charge. Tone: direct, no grovelling, no corporate phrasing. Four short paragraphs at most. Do not promise a date beyond Thursday. Do not invent a discount.
Can you improve this text?
Do not rewrite this. Critique it. It is a page for prospective clients of a two-person accountancy practice. The reader is a shop owner who has never used an accountant. Tell me the three weakest sentences and why. Tell me anything a shop owner would not understand. Tell me what a sceptical reader would still not believe after reading it. Then, and only then, suggest one rewrite of the opening.
Help me plan a website redesign.
Help me plan a redesign of a five page site for a local garden centre. One person doing the work, evenings only, six weeks, no budget for a designer. Break it into weekly steps. For each week give the outcome, not the activity. Flag anything I am likely to underestimate. Put anything that depends on someone else replying to me as early as possible. Ask me up to three questions first if you need them.
Pull out the important details from these notes.
Extract the following from the notes below, as a table with one row per item: supplier name, invoice date, amount, and whether it is paid. Use exactly the wording in the notes. If a field is missing, write UNKNOWN rather than guessing. If a line is not an invoice, ignore it and list it separately at the end.
A pattern runs through all five. The strong version is not more polite, more elaborate or longer for its own sake. It supplies facts the model could not have known, states the format wanted, and says what to do at the edges, where the honest answer is that something is missing. Those three moves are most of prompting.
Prompt engineering is a real skill and a badly named one.
The name suggests something closer to engineering than it is. There is no hidden syntax and no compiler. What there is, genuinely, is a skill in describing a job well, and some people are much better at it than others. The useful part comes down to four things: supplying context the model had no way to know, stating the format you want, showing an example of a good answer, and breaking a large request into steps small enough to check.
The overhyped part is magic phrasing. Prompt packs sell hundreds of templates built on incantations about acting as a world-class expert or taking a deep breath. What makes the good ones work is not the incantation, it is that someone wrote three paragraphs of context and a clear output format into the template. You can write those yourself in five minutes, about your own work, and they will beat any generic pack because they contain facts about you.
It is also worth knowing that this moves. Techniques that made a real difference a couple of years ago matter much less now. Telling a model to think step by step used to visibly improve hard answers. The current products largely do that internally, and some of them run a reasoning process before they reply whether you ask or not. So advice written in 2023 can be sincere and out of date at the same time. Context and format have stayed useful throughout, which is a decent signal about which parts are fundamental.
A few techniques that reliably work.
Show an example of the output you want. One worked example does more than a paragraph describing the format. This works because the model is continuing text, so an example puts it directly in the neighbourhood of the answer instead of asking it to infer the neighbourhood from a description.
Name the format explicitly. A table with these four columns, three bullet points, under two hundred words, no preamble. Left unsaid, the model defaults to the most common shape in its training, which is a padded essay with a summary at both ends.
Split a complex job into steps. Ask for the outline, check it, then ask for the draft. Errors in a long single-shot answer are hard to find and harder to unpick, and everything after a wrong assumption inherits it. Checking at the joint is cheap.
Say what to do when it does not know. Write UNKNOWN, ask me, leave it blank, flag it. Without that instruction a model trained to be helpful will produce a plausible value, and a plausible value is exactly what a wrong answer is made of.
Ask it to critique its own draft. A second pass asking what is weakest here, or what would a sceptical reader object to, regularly catches things the first pass produced happily. Part of the reason is that these models were graded partly on what people liked reading, which leaves them agreeable, so explicitly asking for the objection is how you get it.
Five parts, in this order. Not every prompt needs all five, and the first four cover most jobs.
None of this applies only to chat. An AI agent works from the same assembled text before every step it takes, so a vague instruction to an agent does not just produce a vague paragraph. It produces vague actions, several of them, in your actual files.
A prompt you retype every week should be a written procedure instead.
Here is the thing almost nobody is told. If you find yourself typing roughly the same instruction every Monday, the problem is not that your phrasing needs work. The problem is that it lives in your head and in your typing fingers instead of in a file.
The difference between a good prompt and a skill is that a skill is written down once, with steps, so the job comes out the same way twice. Same inputs, same order, same output format, same rule about what to do when something is missing. You stop reinventing it, and more importantly you stop getting a slightly different result each week because you happened to phrase it differently on a Tuesday. There is a library of exactly these, written out and free to copy, on /resources/skills.
The same logic applies one level up. Rules you should never have to repeat, who you are, how you want answers, what must never be invented, belong in a file the model reads before anything else, which is what the constitution layer is for. Things you decided last month belong in memory you own rather than in one vendor's saved notes. Most prompt fatigue is a filing problem wearing a phrasing costume.
You rent the model. You should not rent the context.
Every session starts empty. Whatever an app calls memory is a feature bolted around a model that remembers nothing, and it belongs to the app. The subscription is rented and the model behind it will be replaced within the year. The files you wrote about your own work are the part that keeps working, in this product and the next one. The five layers, constitution, memory, skills, tools and focus, are just a tidy way of organising that material, and the whole picture is on /aios.
So the first step is small and it is the same one every page here ends on. Open a plain text editor and write half a page. What you do and who for. What you are working on now, with real names and dates. The decisions you make most weeks. Two or three lines on how you want answers back and what must never be assumed. Save it, then paste it above your next question. Mine is about a page and it goes into nearly everything I ask.
Starter files, including a sample you can edit line by line, are on /resources. Everything there is free and needs no signup.
If you want to know when the next one goes up, there is a waiting list. That one asks for an email, and it is the only thing here that does.
Get the free starter guide
Join the waiting list and you get early access updates now, and the AI Operating System starter guide as soon as it is ready. No pitch, no spam, unsubscribe anytime.
FullDigital is a nonprofit association · Reg. no. 40008303188 · Your data stays in the EU.
