Prompting guide: 10 techniques that work across eight different AI models

The models in the comparison represented several common categories: OpenAI and Anthropic systems, Google Gemini, Mistral, Cohere, Meta Llama, Qwen and DeepSeek models. Exact model names and behaviour will change over time, but the underlying lessons are surprisingly stable. A prompt that gives the model a clear role, task, context, constraints and output format is more reliable than a theatrical paragraph about “unlocking maximum intelligence”.

This guide focuses on techniques that can be applied in ChatGPT, Claude, Gemini, Mistral Le Chat, Microsoft Copilot, local models running through Ollama and API-based production systems. For background on measured model performance, see our AI Arena benchmark tests.

What we tested across eight models

Each technique was used on comparable tasks: summarising a long document, extracting structured data, rewriting technical copy, generating code, checking an answer against source material and handling an intentionally ambiguous request. The goal was not to produce a leaderboard. Different models have different strengths, context limits, safety policies and tool integrations, so a single score would often disguise the practical trade-off.

Instead, I looked for four things:

• Accuracy: did the answer preserve facts and follow the source?
• Consistency: did the model produce a similar result when the task was repeated?
• Format compliance: did it return valid JSON, a table or the requested sections?
• Correction cost: how much editing was required before the result could be used?

That last metric matters in production. A fast answer that needs ten minutes of manual repair is not necessarily cheaper than a slower but more predictable response.

1. State the task before adding detail

Start with a direct description of what the model must do. Put the main verb near the beginning:

Summarise the following contract in  five bullet points for a non-lawyer.

This is better than beginning with several sentences about the importance of legal clarity. Models can interpret context, but they should not have to excavate the actual assignment from a small essay.

For complex work, use a compact task specification:

Task: Extract all payment deadlines.
Source: The contract below.
Audience: A project manager.
Output: A table with deadline, triggering event and responsible party.
Rule: If the contract does not specify a date, write "Not specified".

Across the eight models, this simple structure improved compliance more consistently than elaborate role-playing instructions.

2. Supply the relevant context—and label it

Even a strong model cannot infer information that is missing. Include the source text, data, error message, target audience or business constraint that actually affects the answer.

Separate instructions from reference material with labels or delimiters:

INSTRUCTIONS
Identify the three most important risks.

REFERENCE DOCUMENT
<document>
...
</document>

This helps reduce a common failure mode: the model treats a sentence inside the supplied document as a new instruction. In applications, the same principle applies to system messages, user input and retrieved documents. Keep trusted instructions separate from untrusted content.

For privacy, remove unnecessary personal data before sending a document to a cloud service. EU organisations should check the provider’s data-processing terms, retention settings, transfer mechanisms and administrator controls. GDPR does not prohibit generative AI, but it does require a lawful basis, data minimisation and appropriate handling of personal data.

3. Define the output format precisely

“Give me a useful answer” is not a format. If the response will be copied into software, define the schema. If a person will read it, define the length and structure.

Return valid JSON only:
{
  "company": "string",
  "country": "string or null",
  "employees": "integer or null",
  "confidence": "low | medium | high"
}

For plain text, specify headings, maximum length, spelling variant and prohibited content. For example:

Write  six bullets, each no longer than 18 words.
Use British English.
Do not introduce facts that are absent from the source.
End with one sentence labelled "Open question:".

JSON mode or structured-output features are preferable when an API offers them. Prompting alone cannot guarantee valid JSON. That distinction is important when building an automated pipeline.

4. Show one good example

A single example often explains a desired style better than a page of adjectives. This is called few-shot prompting. It works particularly well for classification, extraction and tone matching.

Classify each message as billing, technical or sales.

Example:
"Please resend invoice 1042." → billing

Now classify:
"My application crashes after login." →

The example should be representative, not a clever edge case. Include a negative example if the categories are easy to confuse. Several models copied the structure and level of detail from the example more reliably than from abstract instructions such as “be consistent”.

Do not provide examples with accidental errors. Models are excellent imitators of patterns, including bad ones.

5. Ask for a plan when the task has multiple stages

For research, debugging, financial calculations or document analysis, divide the job into stages:

1. Identify the relevant information.
2. Check it against the supplied source.
3. Apply the requested rule.
4. Return the final answer in the required format.

You do not always need the model to print a long chain of thought. In fact, asking for hidden reasoning verbatim is usually unnecessary. Ask for a concise working summary, assumptions and checks instead:

Before the final answer, list:
- assumptions you had to make;
- source passages that support the answer;
- unresolved uncertainties.

Then provide the final answer.

This produced more useful audits than demanding an exhaustive stream of internal reasoning. It also keeps the output shorter and easier to review.

6. Make uncertainty explicit

Models often sound certain when the evidence is weak. Add a rule for missing or ambiguous information:

If the answer is not supported by the source, say "Insufficient information".
Do not guess a number, date or legal requirement.
Separate confirmed facts from interpretation.

For extraction tasks, use null values rather than invented placeholders. For research tasks, request links and publication dates, then verify important claims independently. A citation-shaped string is not proof that a source exists.

This is especially important for European compliance work. Ask the model to identify possible GDPR or AI Act issues, but do not treat the response as legal advice. The EU AI Act introduces obligations that depend on the system, provider, deployer and use case; a generic chatbot answer cannot classify your entire deployment correctly.

7. Tell the model what to avoid

Positive instructions are useful, but failure conditions are often clearer when stated directly:

• Do not invent sources.
• Do not repeat the introduction.
• Do not use marketing claims without evidence.
• Do not convert unknown values into zero.
• Do not include markdown when the output must be JSON.

Keep the list short. A prompt containing 30 prohibitions can become harder to follow than the original task. Prioritise the errors that would be expensive or dangerous.

8. Separate generation from checking

One model response can perform the task and then inspect its own work, but a separate verification step is more dependable. In a production pipeline, use two prompts or two model calls:

First call: Extract product names and prices from the document.

Second call: Compare the extracted table with the document.
Report missing items, altered numbers and unsupported entries.

The checker should receive the original source as well as the generated answer. Otherwise it can only judge whether the answer sounds plausible. For high-value workflows, add deterministic validation: JSON schema checks, numerical comparisons, regular expressions and human approval for exceptions.

9. Use retrieval instead of relying on memory

If the question concerns company policy, current pricing, legislation or product documentation, put the relevant, dated material in the context. Do not ask a model to recall facts that change frequently.

A practical retrieval prompt might say:

Answer only from the supplied documents.
Cite the document title and section after each factual claim.
If the documents conflict, show both statements and explain the conflict.
If no document supports the answer, say "Not found in the provided sources".

This technique is more valuable than switching between models. A smaller model with relevant source material can beat a larger model operating from stale memory. It also creates a clearer audit trail for European businesses.

10. Test prompts like software

A prompt is part of an application, not a permanent spell. Save it in version control, create a small test set and rerun that set after changing the model, temperature, retrieval system or output schema.

Record not only whether an answer is correct, but also token usage, latency, refusal rate and manual corrections. Cloud providers charge differently for input and output tokens, while local models shift the cost towards hardware, electricity and maintenance. The cheapest token is the one that prevents a failed workflow.

What did not work consistently?

Several popular techniques were unreliable across the eight-model test:

• Overly dramatic role prompts: “You are the world’s greatest expert” rarely fixed missing context.
• Huge instruction blocks: more words created more opportunities for contradiction.
• “Think step by step” as a universal remedy: it did not solve unclear requirements or bad source data.
• Repeated politeness: “please” is fine, but it does not replace a schema or validation rule.
• One prompt for every model: models differ in tool syntax, context limits, structured-output support and sensitivity to examples.

The strongest general pattern was straightforward: define the job, provide the evidence, specify the result and explain how uncertainty should be handled. That sounds less exciting than a secret prompt formula. It is also much easier to maintain.

A compact prompt template

Role: [relevant expertise, only if it changes the task]
Task: [one clear action]
Context: [facts, audience and source material]
Process: [steps or checks required]
Constraints: [length, language, exclusions and uncertainty rule]
Output: [exact format, schema or headings]
Validation: [what the model must verify before answering]

For European users, add a data-handling check before sending sensitive content. Use an EU-available provider or local deployment where appropriate, confirm the provider’s retention and training settings, and document who can access prompts and outputs. Availability in the EU is broad for major cloud assistants, but specific features, enterprise contracts and data-residency options vary by provider and plan. Check the current official documentation rather than assuming that an American or open-weight model has identical service terms everywhere.

FAQ