Prompting techniques

A clear prompt resembles a useful work request: it states the job, supplies the relevant information and describes what a satisfactory result looks like. Prompting techniques are ways of organising those ingredients. They are not secret phrases that make a model reliable, and adding every technique to every request usually creates unnecessary work.

Consider a team that sorts incoming customer messages. The team wants the assistant to label each message as a delivery question, a billing question or something else. It may need only a short instruction. If the categories overlap, examples may help. If software must read the answer, an agreed data format becomes important. Start with the problem you are solving, not with the most elaborate prompt you have seen.

Choose a technique for a reason #

The word shot in prompting means a demonstrated example of the task. A zero-shot prompt gives no examples; a few-shot prompt supplies a small set of inputs and their desired outputs. Both still need a clear instruction. An example without an explanation can leave the model guessing which pattern matters.

The tabs below use fictional support tasks. Read them as alternative starting points, not a checklist of ingredients that must all be combined. Each technique changes a different part of the briefing.

Begin without examples, then add useful ones #

Zero-shot prompting is a sensible first experiment for a familiar task such as summarising a short letter. It keeps the input compact and makes the instruction easy to inspect. If the answer fails, first ask whether the goal, evidence or output requirements were missing. An example cannot repair a task whose definition keeps changing.

Few-shot prompting is especially helpful when your organisation uses unusual categories or a distinctive writing style. Show cases that reveal important boundaries, not many copies of the same easy case. For the support sorter, include a message that mentions an invoice but is really asking about where a parcel was delivered. Explain which concern determines the category, or allow multiple categories if that reflects the business process.

Examples guide the current request; they do not normally retrain the model or permanently teach the service. Include them again when they are needed. Check that each example follows the written rules. A demonstration labelled “delivery” for a payment dispute teaches the opposite of the instruction, even if it was simply a copy-and-paste mistake.

To see whether examples help your task, hold back a set of messages that are not in the prompt. Test the short prompt and the example-based prompt on those same messages. Compare incorrect categories, missing fields and cases that should have gone to a human. A pleasing answer to one sample is not evidence that the technique improved the workflow.

Ask for useful reasoning, not an internal transcript #

Chain-of-thought prompting is commonly used to describe requests for intermediate reasoning, often expressed as “think step by step.” It can help some standard models organise a multi-step problem. However, longer explanations can still contain mistakes, and a confident explanation is not proof that the conclusion is correct.

Reasoning models are designed to spend additional computation working through a problem before returning an answer. Repeatedly telling such a model to think harder or display every thought may be unnecessary and can interfere with the intended use. Prefer a clear goal, the relevant evidence and an explicit description of the result you need. See reasoning versus standard models for that distinction.

Ask for a brief rationale, cited evidence or a reproducible calculation when those help someone check the answer. These are useful work products, not access to the model’s private reasoning. For arithmetic or business rules that must be exact, use an appropriate calculation or validation tool rather than treating a long written explanation as a substitute.

Make machine-readable answers explicit #

JSON, short for JavaScript Object Notation, is a text format that represents named fields, values and lists. A schema is a specification for that structure: which fields exist, which are required and what values they may contain. Think of JSON as a completed form and the schema as the blank form plus its completion rules.

“Return JSON” is weaker than defining the form. A downstream application needs to know whether a missing amount becomes an empty string, an omitted field or a special value such as null, which means no value. It also needs to handle a refusal, an interrupted answer or a response that fails validation. Decide those cases before connecting the result to a business action.

Related: on AIVAX, this capability is documented as Structured responses. Supported options provide schema-based output handling, with behaviour depending on the chosen mode and model. Valid structure does not establish factual truth: a perfectly formatted object can still contain an incorrect category or an unsupported amount. Check the business meaning as well as the format.

Combine only what earns its place #

Role prompting can make a message more appropriate for its audience, while delimiters make source boundaries easier to read. Neither adds knowledge the model was not given. Neither prevents a malicious document from trying to redirect the assistant. Access controls and validation still belong in the surrounding application.

For the support sorter, a concise instruction, a few boundary examples and a schema may be enough. For drafting a friendly internal note, ordinary prose may be better than JSON. The right technique is the simplest one that improves the measured outcome without adding unnecessary input or maintenance.

What’s next: Learn how context windows, tokens and cost management put a practical budget around every prompt.