Most prompt advice online is written for people chatting with an AI. An automation is different. Nobody is reading the answer. The next step in the workflow is, and it is far less forgiving than a person.
This is how I write prompts that have to work thousands of times without anyone watching.
A different job from chatting
In a chat window, a slightly odd answer is fine. You read it, shrug and ask again. Inside a workflow, a slightly odd answer is a bug:
- The model adds "Sure, here is the JSON:" before the data and your parser fails.
- A field is called "customer_name" today and "name" tomorrow.
- A date arrives as "next Tuesday" when the calendar step expects a date.
- The model politely refuses, and the refusal gets written into your database as if it were data.
Reliability, not cleverness, is the goal.
Give the output a fixed shape
Tell the model exactly what to return, and use the structured-output features your provider offers where they exist. These let you supply a schema that the response must follow.
- Name every field and its type.
- List the allowed values for categories: "category must be one of: billing, delivery, returns, other".
- Say what to do when something is missing: "use null, never invent a value".
- Say there should be no text outside the data.
Anatomy of a production prompt
I structure almost every automation prompt the same way:
ROLE
You classify incoming customer messages for [Business].
TASK
Read the message and return the category and urgency.
OUTPUT
Return only valid JSON with exactly these fields:
- category: one of "billing", "delivery", "returns", "other"
- urgency: one of "low", "normal", "high"
- summary: one sentence, under 25 words
- needs_human: true or false
RULES
- If you are not sure of the category, use "other" and set needs_human to true.
- Never invent order numbers or customer details.
- Anything about legal action, safety or a refund request: needs_human is true.
MESSAGE
{{message}}A few things worth noticing. The rules say what to do when unsure, which is where most failures live. The data to process is clearly separated from the instructions. And the escalation rule is built in, not bolted on later.
Keep instructions and data apart. Put the instructions first and the untrusted content, such as a customer's message, in a clearly marked section. It makes the prompt clearer, and it is the first line of defence against content that tries to give the model orders. The security side is covered in AI agent security.
Show, do not just tell
Descriptions leave room for interpretation. Examples remove it. Two to five well-chosen examples of input and the exact output you want usually fix more problems than adding another paragraph of instructions.
- Include an ordinary case.
- Include an awkward one: vague, badly spelled, or covering two topics.
- Include one where the right answer is "I cannot tell", so the model learns that is allowed.
Validate everything that comes back
However good the prompt, treat the output as untrusted until it passes checks:
- Does it parse? Valid JSON, no extra text.
- Are the required fields present?
- Are the values allowed? The category is one of the four, not a fifth the model made up.
- Are numbers and dates plausible?
- Did it refuse or apologise? Catch phrases that mean the task failed.
If a check fails, retry once, then route the item to a person. Never pass unchecked model output into a system of record. This is the fourth of the nine failure patterns in 9 AI automation mistakes that kill projects.
Test it like software
The most valuable habit is also the least glamorous: keep a test set.
- Collect twenty to fifty real inputs, including the messy ones, with the correct answer for each.
- Run the prompt against all of them whenever you change it.
- Count how many come out right, and look at the ones that do not.
- Only keep a change if the score improves, or at least does not drop.
Without a test set, every prompt tweak is a guess, and a fix for one case quietly breaks three others. With one, you can change models, shorten the prompt to save cost, or add a rule, and know within minutes whether it helped.
Small habits that help
- Keep prompts in version control or a clearly dated document, so you can see what changed when behaviour shifts.
- Use a low temperature for classification and extraction.
- Test again when your model provider updates a model. Behaviour can change.
- Log the input, output and prompt version for every run, so a bad result can be traced.
Clever prompts impress people in demos. Boring, constrained, validated, tested ones are what keep an automation running at 3am, and the second kind is what you are paying for.