Prompt engineering for business owners: the five patterns that matter
Most prompt advice expires with the next model. Five patterns keep working: context, examples, constraints, steps, and admitting uncertainty.
The short answer
Most prompt advice is a list of tricks that expire with the next model release. Five patterns do not expire, because they are not tricks; they are how you would brief a capable new colleague who knows nothing about your business. Give the model a role and the context it needs. Show it examples of what good looks like. State the constraints and the format. On hard tasks, ask it to work in steps. And ask it to say what it is unsure about. The largest gains come from context and examples, not clever wording, and a prompt cannot supply facts the model does not have; that is the job of the documents you give it.
The five patterns
| Pattern | What it looks like | What it fixes |
|---|---|---|
| 1. Role and context | ”You are answering for a physiotherapy practice with three locations; the reader is a patient on a phone.” | Generic tone; wrong assumptions about audience |
| 2. Examples | Two or three examples of good output, and one of what to avoid | Inconsistent style and structure |
| 3. Constraints and format | Length, language, what to include, what never to say, the exact output shape | Rambling; missing pieces; unusable output |
| 4. Steps | ”First list the facts from the document, then draft, then check the draft against the facts.” | Errors on multi-part tasks; skipped reasoning |
| 5. Uncertainty | ”If the information is not in the material provided, say so rather than guessing.” | Confident invention |
Writing a prompt that is used repeatedly
- Write the brief with all five patterns, in plain language, as if for a new colleague.
- Collect real cases: twenty to fifty actual inputs with a known good output for each.
- Run and score. Where the output misses, add a constraint, an example or a step; do not add adjectives.
- Version it. Keep the prompt in the repository with a change note; it is company logic.
- Retest when the model changes. A new model version is a new colleague; rerun the cases.
- Keep facts out of the prompt where they change; retrieve them from documents instead.
What a prompt cannot do
It cannot know your prices, your policies or last week’s decision unless they are in the prompt or retrieved from your documents. It cannot make a model reliably accurate about facts it was not given. It cannot replace testing: a prompt that works on three examples may fail on the fourth kind of input nobody thought of. Prompts shape behaviour; documents supply knowledge; tests supply confidence. All three are needed for anything that runs unattended.
What this means for you
Brief the model as you would brief a good new colleague: role, context, examples, constraints, steps, and permission to say “I do not know”. For anything repeated, treat the prompt as an asset: written, tested against real cases, versioned, retested when models change. Skip the tricks. Supply facts through documents, not prompts. Those habits outlast every model release.
Frequently asked questions
Do we need a prompt engineer?
For everyday use, no; the five patterns are enough and anyone can learn them in an hour. For automated workflows where a prompt runs thousands of times, someone must own it like code: write it carefully, test it against real cases, version it and review it when models change. That is a discipline, not a job title.
Why do results vary so much between attempts?
Usually because the prompt left too much open: no role, no example, no format, no constraint. Models fill gaps with defaults that differ per attempt. The more precisely the task, the audience, the format and the boundaries are stated, the more consistent the output. Examples of good output are the fastest way to close the gap.
Will these patterns still work with next year's models?
Yes, because they are not tricks; they are how you would brief a capable new colleague. Role and context, examples, constraints, steps and honesty about uncertainty improve any capable model's output. Specific phrasings and magic words come and go; briefing well does not.