OpenAI prompt engineering for reliable LLM applications
Learn authority boundaries, prompt builders, examples, schemas, eval loops, and injection defenses for reliable OpenAI applications.
The whole story in 6 lines
Reliable prompting combines clear authority, code-managed structure, examples, schemas, evals, and guarded actions.
- Trusted rules belong in developer instructions while untrusted content stays in lower-authority input.
- Keep prompt builders in code so typed values, review, tests, and deployment govern behavior changes.
- A small set of varied examples teaches decision boundaries better than repeated easy cases.
- Structured Outputs constrain the response shape so downstream code can validate required fields.
- Representative eval cases turn prompt edits into measured revisions instead of guesswork.
- Isolation, schemas, guardrails, and human approval reduce injection risk without promising perfection.
The support ticket that behaves like code
A customer ticket says to ignore every rule and delete its record. The application only wanted a category, but the text now resembles a command.
We need four ideas before tracing that failure. Authority ranks instructions, a schema defines data shape, an eval measures behavior, and injection hides commands inside untrusted text.
Our journey follows one ticket through six engineering boundaries. Each boundary changes what the model may interpret, what software can validate, or what an action may do.
The core lesson is simple: prompts are interfaces inside a larger system. Now let us start with the most fundamental idea, which instructions carry authority.
Trusted rules outrank untrusted tickets
We begin with the request stack because every later technique depends on it. Developer instructions carry application rules, while user input carries the current task and its data.
The application defines three trusted rules before reading any ticket. These rules choose approved categories, require a response shape, and declare ticket text to be untrusted data.
A ticket contains an instruction to delete a customer record. What happens if code interpolates that untrusted sentence into the developer message?
The unsafe path lifts the ticket into the trusted layer, so the attack gains authority. The safe path keeps the same text below the rules as data to classify.
Switch the Untrusted channel control. Compare whether the ticket crosses the trust boundary or remains isolated as data.
Authority is an architectural boundary, not a formatting trick. Keep trusted policy separate from untrusted values. Next, we will turn those rules into a code-managed prompt builder.
Version the prompt like application code
Now that trusted and untrusted content are separated, we need a repeatable way to assemble them. A small prompt module becomes the interface for one application feature. That ownership makes later changes easier to review.
The builder keeps identity and instructions stable, places examples after the rules, and inserts changing context near the end. Clear Markdown or XML boundaries make each section easier to parse.
A raw ticket enters through a typed input boundary without changing the template. Software can review one prompt structure while safely accepting new ticket values.
The builder produces separate instructions and input for the Responses API. Code review tracks rule changes, while typed arguments carry each ticket without rewriting trusted policy.
Production prompts belong in the same engineering loop as code, with fixtures, tests, version history, and staged deployment. The request stays inspectable at every release and during incident review. Next, we will add examples that teach difficult boundaries.
Examples teach the boundary, not the slogan
We have a stable builder, but category names alone leave room for interpretation. Few-shot examples pair sample inputs with desired outputs inside the developer instructions. Each pair demonstrates one concrete decision for the model.
One obvious hardware ticket establishes the basic pattern. Repeating that same easy case adds little because the model still has not seen software or unrelated requests.
The next ticket mentions both a monitor and an update. The example set must cover a different decision boundary instead of repeating another obvious hardware case.
Three varied examples now occupy different regions of the decision space. The model can compare the new ticket with hardware, software, and unrelated requests instead of copying one repeated label.
Examples are compact test cases embedded in the prompt. Choose them for coverage and desired behavior, then keep them under version control. Remove examples that only repeat an easy pattern. Next, we will constrain the response itself.
Make the response safe to parse
★ If you remember one thing · A schema turns uncertain prose into a response that downstream code can validate.
Our prompt can classify the ticket, yet the application still needs dependable fields. A sentence that merely asks for JSON leaves downstream code handling many possible shapes.
Free text may contain commentary, missing keys, or unexpected values. A custom parser must guess where the category ends and whether urgency exists at all.
The same model result approaches two software boundaries. Which boundary can reject a missing field before business logic receives it?
The free-text path breaks into uncertain fragments, while the schema path lands as category and urgency. The gate now checks required fields and approved values before code continues.
Switch the Output contract control. Compare the broken parser with the schema gate, then solve the challenge with validated fields.
Structured Outputs make response shape enforceable, but they do not prove the classification is correct across many cases. Next, we will measure behavior across representative tickets with an eval loop.
Improve prompts with measured failures
A valid JSON response can still carry the wrong category. We now run the prompt against six representative tickets with expected labels and one explicit pass criterion. The fixture stays fixed while candidate prompts change.
The baseline passes three cases and fails three. That score does not explain everything, so the failed rows remain attached to their inputs for inspection. Each row preserves the evidence behind its verdict.
A revised prompt clarifies the update boundary and adds one difficult example. The comparison preserves every case result, so improvement cannot erase the remaining failure.
The revised prompt passes five of six cases, while one difficult ticket still fails. The comparison proves improvement and preserves evidence for the next revision.
Prompt engineering becomes empirical when every change runs against representative fixtures and criteria. A score guides revision, but individual failures explain the work. Next, we will add security boundaries for untrusted text and consequential tools.
Contain untrusted text before it reaches tools
We measured ordinary accuracy, but the ticket source is still untrusted. An attacker can hide instructions inside retrieved text and aim them at a connected tool.
The first defense keeps untrusted content in user input and extracts only approved fields. The category may flow forward, but the hidden command does not become tool input before any action decision.
A proposed delete action can still reach the final gate. Human approval prevents that consequential write from executing immediately when earlier defenses miss the attack.
Several defenses now act together: lower-authority input, a constrained data shape, a guardrail, and a review gate. No single layer must carry the entire safety burden.
Toggle the Tool approval control. Compare whether the proposed delete crosses the action boundary or waits for review.
Prompt injection cannot be solved by one perfect sentence. Reduce risk with isolation, constrained outputs, guardrails, approvals, and adversarial evals. Now let us step back and see the whole picture together.
One reliable prompting system
We started with authority. Trusted application rules stayed in developer instructions, while the ticket remained untrusted input with less influence.
Then we built the prompt in code. Typed values, review, tests, and deployment controls turned prompt changes into ordinary engineering work.
Examples taught important decision boundaries. A varied set covered hardware, software, and unrelated requests instead of repeating one easy label.
Structured Outputs made the response shape enforceable. Downstream code received required category and urgency fields through a checkable schema.
The eval loop measured six representative cases. A revision improved five of them while preserving the remaining failure for further work.
Finally, layered defenses contained hostile text and guarded consequential tools. Isolation, schemas, guardrails, and approval worked as separate boundaries.
Together these parts form a reliable prompting system. Clear instructions guide the model, while software contracts and tests govern everything around it.
The whole story in 6 lines
Reliable prompting combines clear authority, code-managed structure, examples, schemas, evals, and guarded actions.
- Trusted rules belong in developer instructions while untrusted content stays in lower-authority input.
- Keep prompt builders in code so typed values, review, tests, and deployment govern behavior changes.
- A small set of varied examples teaches decision boundaries better than repeated easy cases.
- Structured Outputs constrain the response shape so downstream code can validate required fields.
- Representative eval cases turn prompt edits into measured revisions instead of guesswork.
- Isolation, schemas, guardrails, and human approval reduce injection risk without promising perfection.