Prompting Is Ordering, Not Asking
A prompt is an ordered chain of facts the model reasons from, not a question with background attached. Once you see it that way, choosing what goes in, and in what order, becomes the part of the job that matters most.
This picks up where Asking for what you actually want leaves off. That lesson covers the four things a good request has. This one is about why they work, and what that means once you are building prompts into a tool rather than typing them by hand.
Why most AI answers are forgettable
Ask for something good and you get the most probable thing. Not the wrong thing, the average thing: the same answer everyone else asking that question gets, because it is the answer the question deserves.
The fix is not a better model. It is a better question, and "better" has a specific meaning worth being precise about.
Two frameworks that are the same framework
There are two prompt structures in wide use, and the useful discovery is that they are the same four slots with different names.
CATS is the short one:
- Context: what the situation actually is.
- Angle: who is answering, and from what expertise.
- Task: the specific thing to produce.
- Style: the shape and tone it should come out in.
The universal content template is the long one:
You are a
[ROLE]who specializes in[NICHE]. You are creating content for[AUDIENCE]who[AUDIENCE SITUATION]. Write a[FORMAT]about[TOPIC]using a[TONE]that[SPECIFIC OUTCOME].
Line them up and they map one to one:
- Angle is Role plus Niche.
- Context is Audience plus Audience Situation.
- Task is Format plus Topic.
- Style is Tone plus Specific Outcome.
That matters for anyone building a tool around this. Offering both is asking the user to choose a vocabulary before they have done any work. One set of fields, with the short names as labels and the long names as the hint text underneath, gives you everything both frameworks have.
Constraints aim the answer, they do not narrow it
The common objection is that structure limits what the model can do. It is backwards. A model with no constraints is not free, it is unaimed: it falls back on the most common completion because nothing in the question separates your situation from the thousand similar ones it has seen.
Each slot you fill removes a whole class of answers you did not want. What is left is smaller, and it is yours.
Here is the difference in practice. The unaimed version:
Write a follow-up email to a client.
The aimed version:
You are an account manager at a small web studio. The client is a family-run bakery that approved a homepage design two weeks ago and has not sent the photos we need to finish it. Write a short follow-up email that asks for the photos by Friday without sounding like a reminder notice. Three sentences, warm, no apology.
The first gets you a template. The second gets you an email you could send.
What a prompt actually is
A prompt is an ordered sequence of described events, facts and constraints, and that sequence is the only thing the model has to reason from. It reads the chain in order, and each link conditions what the next one means.
So two things control the outcome, and neither of them is the question:
- Specificity. A vague description matches everything and therefore distinguishes nothing.
- Order. The same facts in a different sequence produce a different chain, because each one is read in the light of what came before it.
A small example of order. "The deadline is Friday. The client is anxious. Draft the update." reads as a schedule problem. "The client is anxious. The deadline is Friday. Draft the update." reads as a relationship problem. Same three facts; the first one sets the frame.
This is a claim about conditioning, not about understanding. The model has no experiences and no memory of yours. What it has is a distribution over likely continuations, and your ordered description narrows that distribution to the region you want. Being exact about this is more useful than the loose version, and it is the version a technical reader will keep reading.
Choosing the context is the real work
If ordered, specific description is what shapes the answer, then choosing which descriptions go in is the highest-leverage thing you do, and it is a different job from writing the question. Which past decisions are relevant? Which procedures apply? Which of your own notes belong in the room, and which should stay out?
Everything in the prompt is reasoned from. Everything left out is not. That is the whole of context selection in one sentence, and it is why a tool that lets you choose your context beats one that guesses it.
Roles are two decisions, not one
Naming a role is the highest-value slot to fill, and it is usually filled badly: one role, chosen loosely, doing all the work.
Two is better, because they answer different questions:
- A primary role for the judgment: what is worth doing, in what order, and what to leave alone.
- A secondary role for the craft: how the thing actually gets built, and what is wrong with it.
A chief of staff and a senior engineer looking at the same task want different things from it, and an answer that satisfies both is better than one that only ever had a single standard to meet.
One warning for anyone building this into a tool: defaults are personal. Whatever pair works for you is not the pair that works for the next person. Ship them as placeholder text, not as prefilled values. A placeholder invites a decision; a filled field gets accepted without one.
How we use this
This is the thinking behind how [AIOS](../../aios/index.html) talks to a model. Your notes are the context, and you choose which ones go in; what goes out is assembled in a fixed order rather than guessed; and the words stay in a note you own and can edit, not locked inside a tool.
The structure is the product. The words stay yours.