Prompt Engineering

A prompt is the instruction a language model receives. In a chat, you type it on the fly and adjust until the answer fits. In a business workflow, by contrast, the same instruction runs hundreds or thousands of times, with new input every time and nobody fixing it along the way. Prompt engineering turns the off-the-cuff question into a working tool: an instruction that is systematically designed and tested and holds up across many cases.

A good instruction names the task, the context, the sources the model may use and the result you want. If one of these is missing, the model fills the gap with assumptions that are hard to check. Examples help show what a usable answer can look like, and a rule such as “If a fact is not in the source, write: not supported” makes gaps visible.

Prompt engineering matters to executives for two reasons. It is the fastest and cheapest starting point: the model stays unchanged, only the instruction changes, and that takes minutes. And prompts are operational knowledge. They capture how a company wants a task done. They should therefore be documented, versioned and tested like any other work instruction.

The building blocks of a good instruction.

The task names the action, the scope and the audience. “Summarize the text in five sentences for the executive team, without jargon” leaves the model less room than “Summarize the text.”

The context says who the result is for and why: audience, occasion, what readers already know. How much context fits is limited by the model's context window, measured in tokens. More context is not automatically better. Research such as “Lost in the Middle” (Liu and colleagues, 2023) shows that models make worse use of information in the middle of long inputs than at the beginning or end.

The sources it may use define what the model can rely on, for example only the text supplied, and what is off-limits, such as figures from the model's memory.

The result you want describes the form, length and structure of the answer, often as a fixed data format when the output feeds into another system. This is also where handling gaps belongs.

Examples complement the four building blocks, especially for tone and format. When examples contradict the instruction, results suffer; OpenAI's guide for reasoning models points this out explicitly.

Zero-shot, few-shot and chain-of-thought.

Three common techniques differ in how much guidance the instruction gives. Zero-shot states only the task, with no example; that is enough for well-defined routine tasks. Few-shot adds a few examples of the desired answer. That language models can learn from a handful of examples in the input was shown by OpenAI researchers in 2020 in the GPT-3 paper, “Language Models are Few-Shot Learners.”

Chain-of-thought asks the model to lay out intermediate steps before answering. Google researchers showed in 2022 that this can improve results on multi-step tasks such as arithmetic or weighing options. Visible intermediate steps make review easier, but they do not guarantee a correct answer: a study by Miles Turpin and colleagues (NeurIPS 2023) shows that such explanations can systematically misrepresent the actual reason behind a model's answer.

These techniques age along with the models. Newer models with built-in reasoning break tasks down on their own. In its documentation for these models, OpenAI explicitly advises against asking them to think step by step, and recommends starting without examples and adding them only if needed.

System prompts, templates and prompt chains.

In applications, a prompt is rarely a single piece of text. The system prompt is the standing framing instruction that applies before every request: role, tone, rules, forbidden content. The user prompt carries the specific request or the data being processed at the moment. Because the system prompt is sent with every call, its length adds up quickly when a task runs tens of thousands of times a month.

For recurring tasks, applications work with templates. The instruction stays the same, and only placeholders such as customer name, product data or source text are filled in for each case. That way the same tested instruction can run at scale, and an improvement takes effect in every case at once.

Complex tasks can be split into several steps that run in sequence: first extract the facts from a document, then write a draft, then check the draft against the facts. These prompt chains are easier to test than one long instruction, because each step can be judged on its own. And when something goes wrong, it is clear where.

How to test whether a prompt works.

Whether an instruction works does not show in one successful example. Its effect is judged across different cases. A useful approach is a fixed test set with at least four kinds of cases: a simple one, an awkward one, one with missing information and one with conflicting sources. The last two in particular show whether the model discloses gaps or fills them with invented content.

Before testing comes the question of what a good result is. Anthropic's documentation lists three prerequisites before prompt engineering begins: clearly defined success criteria, a way to test against them empirically, and a first draft. Without criteria, people argue about taste instead of results.

Every change to the instruction runs against the same test set, so that an improvement in one place does not quietly cause a regression somewhere else. The same goes for switching models: a prompt that works well with one model can behave differently with another.

The test set does not replace review in day-to-day operations. For everything else, the person who passes the result on remains responsible.

Treat prompts as operational knowledge.

In many companies, prompts are scattered across personal notes, chat histories, spreadsheets and the code of individual applications. People who wrote good instructions take them along when they leave, and nobody knows which version is running in which application.

Prompts deserve the same care as other work instructions. That means one fixed place where every prompt in production use lives. It means versioning that shows what changed, when and why. And it means clear responsibility for upkeep and approval, so that changes do not happen on the side.

Documentation has another benefit. A good prompt records how a task should be done: which sources count, which wording is off-limits, how to handle exceptions. That puts knowledge in writing that used to exist only in people's heads.

Conversely, a prompt that is hard to write often points to an unresolved business question. If nobody can agree on what the model should do in an edge case, the ambiguity usually lies in the process itself, not in the wording.

Security: prompt injection and data leakage.

The OWASP project ranks prompt injection first on its list of the top ten risks for such applications (2025 edition). The term covers input that gets the model to override its instructions.

The indirect variant is especially hard to spot: the malicious instruction does not come from the user but is hidden in content the model processes, such as an email, a web page or an uploaded document. Kai Greshake and colleagues showed in 2023 that such attacks can compromise real-world applications with integrated language models.

Three rules follow. First, the system prompt is not a safe; OWASP lists system prompt leakage as a separate risk. Credentials and confidential rules do not belong in it. Second, rights have to be enforced outside the model: whatever a model must not see or trigger, the application must not make available to it in the first place. Third, any action with consequences, such as an email to customers or a booking, needs approval as long as outside content is involved. Good wording alone does not protect anything.

Where the term stops working

A better prompt replaces neither suitable data nor expert review, and even a good instruction does not reliably stop the model from making things up. Prompt injection adds a further risk: outside input, such as an email or a web page, can contain instructions the model then follows. Prompt engineering is distinct from fine-tuning, which changes the model itself, and from RAG, which brings new knowledge into the input.