A simple example
Ask a model to explain a product using approved facts, a named audience and a defined format. Then check that it has not invented a feature or claim.
Write a task that can be judged
Specify the reader, purpose and required evidence. Provide the relevant source material and say what the model should do when information is missing. Separate input material from instructions, especially when the task includes web pages or other third-party text.
A practical content-brief pattern
- Task: explain one customer decision in plain language.
- Context: the approved offer and supplied source material.
- Constraints: no invented results, credentials or unsupported comparisons.
- Output: answer, conditions, examples and supporting sources.
- Review: factual accuracy, omissions, clarity and brand suitability.
Test against difficult examples
Include ambiguous requests, incomplete evidence and inputs that contain misleading instructions. Compare the output with a defined rubric. Keep prompt and model versions together so a later change can be evaluated on the same examples. These are our recommended quality controls, not a guarantee of model accuracy.
Know when prompting is insufficient
A prompt cannot give the model facts it has not received or reliably replace a qualified review. A task requiring current product details needs current sources. A task involving an external action needs appropriate permissions and checks around the system, not merely a request to be careful.
Write the task and acceptance criteria together
A prompt that asks for better marketing copy leaves many decisions unstated. Specify the audience, offer, source facts, output format and constraints. For example, a draft product explanation may need to use an approved product brief, avoid unsupported health claims and answer a particular buyer objection. The reviewer should know what a successful draft looks like before generation begins.
Treat the output as a draft that needs checking against its source material. A fluent sentence can still introduce an incorrect fact or unsuitable promise. Keep a small set of representative tasks and compare whether prompt changes improve accuracy and usefulness on those tasks. Record failures as well as good examples. Do not place confidential customer material into a tool merely because it can accept it; use the data handling and access arrangements the business has approved.
- Provide the relevant facts and say which information must not be invented.
- Define the required structure and the human checks before publication.
- Test revisions against several representative tasks rather than one pleasing answer.
Choose a suitable AI operating approach →
Frequently asked questions
What is prompt engineering?
Prompt engineering is the practice of specifying a task, context, constraints and expected output for an AI model, then testing whether the result meets the task. A good-looking answer is not sufficient evidence of reliability.
Will a longer prompt always work better?
No. Clear requirements, relevant context and an inspectable output matter more than length alone. Test prompts against representative difficult examples.
When is prompting insufficient?
When the task needs missing evidence, reliable system access or a controlled workflow, wording alone will not solve it. Choose the implementation that fits the requirement.
Sources and further reading
Primary material for the concepts discussed here. Our practical checklists and illustrative examples are editorial recommendations. Source links open in a new tab.