Prompt engineering for real business tasks

Asking a chat assistant to « summarise this text » gives a different result every time. That is harmless for personal use; it is a deal-breaker for a business task, where you expect the same format, rigour and caution for the thousandth document as for the first. Prompt engineering is the craft of writing instructions that make a language model’s behaviour reliable and reproducible. This article presents its principles, as they emerge from the official guides by Anthropic, OpenAI and Google, then applies them to a concrete case.

Learning objectives

• treat a prompt as a specification, with testable success criteria;
• know the components of an effective prompt and how to structure them;
• use examples (few-shot) wisely;
• evaluate and version a prompt the way you test and version code.

1. A prompt is a specification

Anthropic’s guide begins with a step that comes before any technique: define success criteria and a way to test against them. Before writing a single instruction, ask yourself: how will I recognise a good answer? What exact format? What should the model do when information is missing?

A useful image: write your prompt for a brilliant but new colleague who knows nothing about your institution, your conventions or the purpose of the task. Whatever you do not tell them, they will guess, and their guesses will not be yours.

2. The components of an effective prompt

The three guides converge on a small number of elements:

Two formatting tips have a measurable effect. First, separate the parts of the prompt with XML tags (<instructions>, <context>, <example>) or Markdown headings, so the model does not mistake an instruction for data. Second, for long documents, Anthropic recommends putting the documents first and the question last, and reports that this layout can improve response quality by up to 30% in its tests.

Finally, give the reason for your rules. A justified instruction (« answer in short sentences, because the text will be read aloud ») generalises better than a bare one, applied too literally.

3. Examples: the most reliable technique

Showing beats describing. Anthropic’s guides call examples one of the most reliable ways to steer format, tone and structure, and suggest three to five relevant, varied and tagged examples. Google recommends them by default but warns that too many can make the model imitate them slavishly. So choose examples that cover the hard cases, especially those that are easily confused.

4. Worked example: sorting a registrar’s office emails

An office receives dozens of student emails every day. We want to route them automatically to the right desk, without ever answering on staff’s behalf.

<role>
You assist the University's registrar's office. You do not reply
to students: you classify their messages for a human agent.
</role>

<offices>
- registration: enrolment, re-enrolment, fees, student card
- exams: timetable, exam notices, grades, grade appeals
- degrees: certificates, transcripts, diploma collection
- other: anything not clearly belonging to the three offices
</offices>

<instructions>
Reply only with a JSON object:
{"office": "...", "urgency": "high|normal", "summary": "one sentence"}
"urgency" is "high" if a deadline less than 7 days away is
mentioned. If unsure about the office, choose "other": an agent will
reroute the message, whereas a wrong classification would delay it.
</instructions>

<example>
Message: "Hello, my statistics grade is missing and the exam board
meets on Friday."
Output: {"office": "exams", "urgency": "high",
"summary": "Missing grade before Friday's exam board."}
</example>

<message>{{email_text}}</message>

Look at the choices. The output is JSON, which your program validates before any use: OWASP specifically recommends checking the output format with deterministic code. The uncertain case is anticipated and justified. And the student’s message sits in its own tag, so that text such as « ignore your instructions » is treated as data.

5. Reducing hallucinations

For tasks grounded in documents, Anthropic’s documentation offers three basic strategies:

• explicitly allow « I don’t know »;
• have the model extract exact quotes before answering, to anchor the answer in the text;
• require a source for every claim, which makes the answer verifiable.

6. Evaluate and version

A prompt is judged on a fixed set of cases, never on one good answer. Build about thirty real, anonymised messages with their expected output; after every prompt change, rerun the set and compare the success rate. OpenAI also recommends pinning a specific model snapshot in production and building evaluation suites, because even two versions within the same family can behave differently. Keep your prompts in the code repository, alongside the model they were tested on.

Common mistakes

• Fixing a prompt after a single failed example, and silently breaking ten others.
• Mixing instructions and data without delimiters.
• Requiring a format without validating it in code.
• Switching models without rerunning the evaluation.

Key takeaway

A good prompt is a clear, structured specification, illustrated with examples and tested on a fixed set of cases. Creativity comes later; reproducibility comes first.

References

• Anthropic, Prompting best practices.
• Anthropic, Reduce hallucinations.
• OpenAI, Prompt engineering.
• Google, Prompt design strategies.
• OWASP, LLM01:2025 Prompt Injection.