Robust Prompt Engineering

Prompts that survive input you did not imagine

Prompt engineering covers getting a prompt to work. This page covers keeping it working when the input is nothing like the examples you tested.

The distinction matters because the two are optimised differently. A prompt tuned on twenty clean cases can fail on the twenty-first in a way that looks like a model problem and is a specification problem: you never said what to do with an empty field, a contradictory instruction, or six pages where you expected a sentence.

Constrain the topic and the shape

OpenAI's guidance is to structure prompts so they "constrain the topic and tone of output text", and to provide "high-quality examples of desired behavior prior to the new input".

Both are about narrowing what counts as a valid answer. A prompt that says what the output is for, what it must not cover, and what form it takes has fewer ways to go wrong than one that asks a question and hopes.

The examples do more work than the instructions. A rule stated once competes with everything else in the window; two examples of the shape you want are read as the pattern. Few-shot covers choosing them, and the robustness point is to pick examples at the edges rather than in the middle, since the middle is what the model would have done anyway.

Name the awkward cases

Most fragility comes from cases the prompt does not mention.

Four worth handling explicitly in almost any prompt:

Missing information. Say what to do when the input lacks what the task needs. Without it the model will invent the missing part, competently.

Nothing to report. Give it a way to return empty. A prompt asking for "the action items" will produce action items from a meeting that had none.

Conflicting input. Two sources disagree. Say which wins, or say to report the conflict rather than resolving it silently. Context sources covers why this arises more often than people expect.

Out of scope. The request is not what this feature does. Say what to answer, because the default is to try.

Each of these costs a sentence and removes a class of failure. They are also the cases your evaluation set should contain, which is where you find out whether the sentence worked.

Mark where the untrusted text starts

Text you did not write reaches the model through retrieved documents and tool results. The structural defence is to keep it separable, which context isolation makes the case for.

In the prompt itself that means delimiting it and saying what it is: this is a document to answer from, not instructions to follow. Providers' own guidance for limiting injection risk points the same way, and prompt injection is clear that this reduces the risk rather than removing it.

Treat it as one layer. A delimiter is not a boundary the model enforces; it is a hint that makes the intended reading more likely.

The prompt is not where limits belong

The most common robustness mistake is asking the prompt to do a job only code can do.

"Keep the answer under 200 words" is a request. max_tokens is a limit. "Only choose from these categories" is a request; validating the response against the list is a limit. Constraining inputs and outputs covers where a constraint has to live to be one, and the rule generalises: if a violation would be a problem, the prompt is the wrong place to prevent it.

Use the prompt to make the right answer likely, and code to make the wrong one impossible.

Find the edge before your users do

A robust prompt is one you have tried to break.

Take your evaluation set and add the cases nobody wrote: empty input, enormous input, input in another language, input that is already an answer, input containing instructions. Run them and read what comes back. Conducting adversarial testing covers doing this systematically against your own surface, and the findings belong in the set permanently rather than being fixed and forgotten.

Further reading

• OpenAI, Safety best practices: constraining topic and tone, and leading with examples.
• Prompt engineering: getting it working in the first place.
• Constraining inputs and outputs: where a limit has to live.
• Conducting adversarial testing: breaking it on purpose.