Most people write prompts the way they'd ask a colleague for a favour: conversational, vague, and hopeful the other side will fill the gaps.
Engineers write tickets differently. A good ticket says what input the system gets, what constraints apply, and what a passing output looks like. You can test against it, and you know when the work is done.
That shift is what separates prompts that work once from prompts that work at scale.
Why vague prompts fail at scale
A vague prompt works in a chat because you can steer it: "no, more like this", and the model adjusts. A production pipeline has no steering. The prompt runs 500 times the same way, and the vagueness compounds into inconsistency.
"Write a product description for this skincare brand" will produce 500 different ideas of what a product description is, how long it should be, what tone it takes and how it ends. Some will be fine. Many won't. None will be reliably consistent.
The output is only as predictable as the input. Vague spec, variable output. Tight spec, predictable output.
The three-part structure
The structure that holds up in production borrows straight from engineering tickets.
Input: what the model receives. Be explicit. "You will receive a product name, a list of five benefits, a description of the target customer and one call-to-action phrase." Don't make the model guess the shape of the data. Name every part of it.
Constraints: what the output must and mustn't do. Length in words or characters. Tone, written as rules rather than adjectives: "professional" is an adjective, while "second person, present tense, no passive voice, no exclamation marks" is a constraint. What to avoid, and the format you want back: JSON, prose or a list.
Acceptance criteria: what a passing output looks like. Most prompts skip this part entirely. "A good description names the main benefit in the first sentence, includes one proof point, stays under 80 words and ends with the exact call-to-action phrase." That's testable. You can hold any output up against each line.
A before and after
Before:
- "Write a product description for this serum. Make it engaging and on-brand."
After:
- Input: product name, five benefits, the target customer in one sentence, and a call-to-action phrase.
- Constraints: second person, present tense, under 80 words, no exclamation marks, no medical claims.
- Acceptance criteria: the main benefit is in the first sentence, there's one proof point, and it ends with the exact call-to-action phrase.
The second version takes two minutes longer to write and saves hours of fixing inconsistent output.
Checking output against the spec
Once you have explicit acceptance criteria, you can evaluate output systematically, which is what LLM evaluation frameworks do at scale: run each output against the spec and flag the failures.
Even manual review gets faster. You're no longer reading copy and asking whether it feels right. You're ticking a list: main benefit in the first sentence, yes or no. Proof point present, yes or no. Under 80 words: count them. Call-to-action phrase included: exact match.
The same goes for agents. When an agent does a multi-step task (classify this record, look up that reference, write this output), each step needs its own acceptance criteria. Without them, you have no way of knowing whether the task worked.
Agent prompts are different
A one-shot prompt is self-contained. Input goes in, output comes out, done. The three parts map onto it cleanly.
An agent prompt isn't specifying one output. The model takes an action, sees the result, and decides the next one, so the prompt is describing behaviour across an unknown number of steps.
So an agent prompt also has to define which tools the agent can use and when, what counts as finished, what to do in a situation it wasn't designed for, and how to report failure. An agent with no clear end state will either claim it's finished when it isn't or loop forever.
The usual mistake is a prompt that says what the agent is but not what done looks like. "You are a research assistant that finds information about companies." Fine, but when does it stop? What does it return? What counts as relevant? Without those answers, it will either do too much or too little.
Prompts are production code
In a production AI system, prompts are code. They need version control, testing before deployment, and a review whenever the model changes, because a prompt tuned for one model version can behave differently on the next.
Teams that treat prompts as quick text, pasted into a tool, tweaked now and then and never tracked, are the ones who wake up to failures they can't diagnose, because they don't know which prompt was running.
Version your prompts like code. Keep the input, constraints and acceptance criteria structure so every prompt is readable and testable. Check output against the spec whenever you change something. Write each prompt like a ticket for a senior engineer: specific enough that they could do the work without asking you five questions first. It's the same discipline we use when we put Claude Code to work on codebases.
