Prompt Engineering: How to Design, Test and Optimize Prompts for Production AI

A model upgrade ships. Nothing in the prompt repository changes, but outputs start failing validation. The reason for this discrepancy is easy to miss when prompt engineering is treated as a writing project.

In production, the model sees an assembled input: system instructions, retrieved context, examples, tool definitions, schemas and user input, all interpreted by a particular model version. Changes anywhere in that chain affect behavior. When behavior regresses, teams need enough observability to reconstruct the request and identify where it diverged. Testing, versioning and diagnosis are part of the production prompt lifecycle.

Prompt engineering is the practice of designing, testing and maintaining the instructions and input structure supplied to a language model so its output meets the requirements of the application using it.

For a production application, the model input typically contains several components: a system instruction, retrieved context, tool definitions, examples, an output schema and the user request. Those components form the effective prompt presented at inference time, even though an application typically stores them separately.

Prompting as an end-user skill has a different scope. A person asking a chat assistant a onetime question can revise the request after seeing the answer. An application sending thousands of model calls against changing inputs, however, needs defined evaluation criteria and a way to identify regressions before a change impacts users.

The standalone prompt engineer title has declined from its early prominence, while prompt work has moved into AI engineering, data engineering, application development and product roles. This distribution of work follows the architecture of production AI systems. Instructions interact with retrieved data, tool definitions, output schemas, model versions and evaluation logic, so teams often manage prompts alongside the components that assemble and test the rest of the model input.

Improved models have also reduced the amount of specialized wording needed for many tasks. Techniques devised to coax weaker models into following basic instructions have less value when a newer model can handle the same task with a straightforward specification.

Even with more advanced interpretation capabilities, however, models can’t infer organizational context. Institutional rules, edge cases and business definitions still require explicit specification and operational ownership. Arun Agarwal, Snowflake’s Principal Product Marketing Manager, AI/ML, explains: “Capable models still don’t know your company’s definition of revenue, when a decision needs approval or which source to trust when two systems disagree. Someone with the domain and process knowledge has to specify that. And once these instructions affect production behavior, they need an owner, version history, testing, evaluation and monitoring, just like code.”

The division of responsibility varies by system. Domain experts often define acceptable behavior, edge cases and business criteria, while engineers maintain the deployed artifact and its tests. Whatever structure a team chooses, those responsibilities need an explicit owner if prompt changes are going to be reviewed and evaluated consistently.

Watch Snowflake developers build and refine prompts live, with practical examples using Cortex AI capabilities:

A production prompt is usually assembled from components that change on different schedules and serve different purposes:

• System instructions define the task, constraints and instruction hierarchy.
• Few-shot examples demonstrate expected behavior or output patterns.
• Retrieved context supplies information selected for the current request.
• Tool definitions tell the model which functions are available and how to call them.
• Output schemas define the structure expected by downstream software.
• User input supplies the request or data being processed.

Keeping those components separate improves both maintainability and testing. If an application begins returning malformed structured output, the schema and related instructions provide a defined surface to inspect. If tool selection regresses, the team can evaluate the tool definitions without simultaneously rewriting unrelated task instructions.

Model sensitivity makes testing necessary. Performance can shift substantially even when the task and examples stay fixed. Researchers Yao Lu et al. found that changing only the order of examples could move some tasks from near state-of-the-art to random-guess performance, while the research team of Melanie Sclar et al. measured accuracy differences of up to 76 points from meaning-preserving formatting changes.

Output schemas are particularly important when model responses feed another system. A declared structure lets the application validate required fields and data types before the response is used downstream. Free-form output instead leaves the application responsible for interpreting text whose structure can vary between calls.

Structural separation also supports security controls. User input, retrieved documents and tool results contain untrusted content; system instructions have a different trust level. Preserving that distinction in context assembly gives the surrounding application a boundary it can enforce rather than relying on prose inside the prompt to establish one.

Prompting techniques introduce different trade-offs in token use, latency and maintenance. A good guideline is to use the simplest prompt that performs the task reliably against the evaluation set, then look to other techniques when you need to address a measured failure.

Zero-shot prompting

With zero-shot prompting, the model receives the task without worked examples. It’s generally the appropriate starting point for a model that can handle the task from a clear specification. The advantage is operational simplicity: fewer tokens enter each call, and there are no examples to update as policies, schemas or business definitions change.

Performance varies substantially across models and tasks, so zero-shot should be evaluated on the model that will run in production. A classification prompt that performs reliably on one model, for example, might need examples or tighter output constraints after a model change.

Few-shot prompting

Few-shot prompting includes examples of expected inputs and outputs in the model context. Examples are useful when the task contains formatting conventions, ambiguous categories or edge cases that are cumbersome to express through description alone.

Consider a support-ticket classifier that distinguishes between billing error and billing question. A definition might leave borderline requests ambiguous, while several representative examples show the distinction directly.

The examples themselves are production artifacts. If a business rule changes and the prompt continues to include examples based on the previous rule, the model will receive conflicting instructions. For this reason, testing needs to cover changes to examples as well as changes to the main instruction.

Chain-of-thought prompting

Chain-of-thought prompting asks a model to work through intermediate reasoning steps, either explicitly or through examples. Research by Jason Wei et al. found large improvements on multistep reasoning tasks. On GSM8K, a grade-school math benchmark, accuracy for the PaLM 540B model rose from 17.9% to 56.9% when the prompt included eight worked examples that showed the reasoning process.

The same research showed a much smaller benefit on simpler tasks, with some results declining. The practical implication is task-specific: reasoning tokens have a measurable cost, and the technique should be tested against the task rather than applied across an application by default.

Modern models also differ in their training and reasoning behavior. Results observed on one model family don’t establish a parameter-count threshold or a universal prompting rule for another.

Self-consistency

Self-consistency samples several reasoning paths and selects an answer based on agreement or another scoring method. It’s useful when variation across reasoning paths reveals errors that a single pass would miss.

The cost is straightforward: several inference calls are required instead of just one. For an application with tight latency or throughput requirements, the measured accuracy gain has to justify that additional work.

Structured output

Where a model response feeds software rather than a person, structured output often provides a cleaner contract than free-form text. An application expecting fields such as `account_id`, `priority` and `recommended_action` can validate a response against a schema before storing it or passing it to another component.

This shifts failure handling into ordinary application logic. Missing fields, invalid types and schema violations are detectable before downstream processing continues.

A prompt rewrite only addresses failures rooted in the task specification or input structure. When the model has the wrong information, lacks required information or repeatedly exhibits the wrong behavior across many examples, another intervention is usually more appropriate.

Prompt engineering focuses on the instructions and input structure used for a model call. If a model sees the correct policy but returns the wrong output format, for example, the prompt or schema is a reasonable place to investigate.

Context engineering covers the broader assembly of information presented at inference time: instructions, retrieved material, conversation state, tool definitions, memory and other task-relevant inputs. As LLM applications have grown more complex, the term has increasingly described work that extends beyond the wording of a system prompt.

Retrieval-augmented generation (RAG) is one way to supply that context. A retrieval system selects relevant material from an external source and places it into the model context before inference. For questions about internal policies, current documentation or proprietary data, the quality of that retrieval directly affects the evidence available to the model. RAG reduces reliance on model memory and helps ground answers in supplied evidence, although retrieval doesn’t guarantee correctness. A retriever that selects the wrong passage, misses a relevant document or fills the context window with weakly related material gives the model a poor basis for answering.

Fine-tuning changes model behavior through additional training. It’s worth doing when a desired pattern needs to hold across a broad range of inputs and well-designed instructions, examples and context have not produced sufficient consistency. Teams conduct fine-tuning once they have evidence that the inconsistency is behavioral rather than informational.

Once a team has a representative evaluation set, prompt improvement no longer has to depend entirely on manual rewrites. A typical optimization loop starts with three inputs: the current prompt, a set of test cases and a scoring function. The system generates candidate prompt variants, runs each one against the same test set and compares the results. Variants that improve the target metric move forward; those that don’t are discarded.

That process turns prompt revision into a measurable search problem. Instead of changing wording based on intuition and checking a handful of outputs, teams can evaluate candidate prompts against the same criteria they use for production testing.

Frameworks such as DSPy, along with optimizers including MIPRO and GEPA, automate parts of that workflow. Depending on the system, the optimizer may revise instructions, select or generate few-shot examples, or change how a larger LLM program is composed.

The prerequisite is the evaluation layer. Without representative test cases and a score that reflects the behavior the application actually needs, the optimizer has no reliable signal for deciding whether one candidate is better than another.

Research has shown that automated search can outperform manually written prompts on some benchmarks. OPRO, for example, generated prompts that exceeded human-designed prompts by up to 8% on GSM8K and up to 50% on selected Big-Bench Hard tasks. DSPy research has likewise reported substantial gains after automatically compiling and optimizing language model pipelines against task-specific metrics.

Automated optimization changes where the engineering work sits. The system searches candidate variants, while the team still defines the test set, scoring criteria, constraints and acceptable trade-offs.

Prompt evaluation compares a versioned prompt against a representative, fixed test set using defined criteria for correctness, format, safety and task-specific behavior. Teams record the model and prompt versions, review failures, approve changes against the same evaluation set and maintain a rollback path for regressions.

A production prompt should have enough metadata to reconstruct what ran, including a version identifier, change notes, deployment stage and owner. For dynamically assembled prompts, traces should also capture the final model input so teams can reproduce and investigate individual calls.

1. Build a representative evaluation set

The evaluation set should include normal requests, boundary cases and examples drawn from actual failures. If every test resembles the cases the prompt already handles well, a passing score provides little evidence about production behavior.

Keeping a frozen set provides a stable regression baseline. New failures can be added over time, while the existing cases remain available for comparison across prompt and model versions.

2. Define what gets scored

A single pass/fail metric often hides useful distinctions. Depending on the application, evaluation criteria might include:

• Answer correctness
• Compliance with an output schema
• Citation or grounding quality
• Tool selection
• Logical consistency
• Policy adherence
• Completeness

Research on chain-of-thought failures illustrates why categorization helps. In an analysis of 50 incorrect answers, Wei et al. found that 46% contained reasoning that was nearly correct, with errors such as a missed step or calculation mistake, while 54% contained larger semantic or coherence problems. Those two failure classes suggest different interventions even though both receive the same final “incorrect” label.

3. Automate repeatable scoring

Human review remains necessary for ambiguous or high-value cases, but manual inspection alone limits how often a team can run regressions. LLM-as-a-judge evaluation provides a scalable option when the scoring criteria are well defined and calibrated. Snowflake’s Agent GPA judges, for example, identified 95% of human-annotated errors on the TRAIL/GAIA test set, and localized 86% of those errors to specific spans in the agent trace.

4. Test model upgrades as prompt changes

A model upgrade changes the execution environment even when the prompt file itself shows no change. Suppose a production prompt requires the model to return an array of objects containing product, region and revenue. Version A of the model consistently returns that schema. After an upgrade, the same prompt occasionally adds an explanatory sentence before the JSON object. The prompt repository shows no change, yet downstream validation now fails.

Running the frozen evaluation set against the candidate model version exposes that regression before rollout. The team can then revise the prompt, tighten the schema constraint or keep the previous model while the issue is investigated.

5. Keep rollback independent of an application release

If prompt changes ship only when application code ships, reverting a bad prompt also requires a code deployment. Storing and versioning the prompt separately gives the team a narrower rollback path.

That separation is particularly useful when prompt iterations happen more frequently than application releases. The deployed application still records which prompt version it used, preserving traceability without coupling every instruction change to a new build.

In an AI agent, prompting happens repeatedly rather than once. A typical sequence includes planning, selecting a tool, receiving the tool result and deciding what to do next, with each step contributing new information to later model calls.

An agent produces a sequence of model calls whose context evolves as the workflow progresses. Eventually, the model may see prior plans, retrieved passages, tool results and intermediate outputs that were absent at the beginning. Teams need policies for what remains in context, what gets summarized and what’s discarded as the workflow continues.

Tool definitions are part of the prompt surface

The model relies on tool names, descriptions, argument schemas and surrounding instructions to decide which function to call. If two tools have overlapping descriptions, the model may select the wrong one consistently even when its reasoning about the task is otherwise sound.

Function calling gives that interaction a structured contract. The model returns a function name and arguments that the application can validate before the call proceeds.

For agents working with governed enterprise data, authorization should remain outside model decisions. Semantic definitions, row- and column-level access rules, and other data controls are more reliably enforced by the platform than repeated as natural-language instructions inside each prompt.

Evaluate the trace, not only the answer

Traces expose intermediate decisions the agent makes: tool selection, arguments, returned data and subsequent model calls. If it makes a poor decision, teams can follow the trace back to locate where behavior diverged. That trace-level view is especially useful when the apparent prompt problem originates elsewhere.

Prompt injection is when untrusted content is interpreted as instruction. Direct prompt injection enters through user input. Indirect prompt injection happens through material the system retrieves or receives from a tool, such as a document containing instructions intended to influence the model.

The risk increases when a model has access to tools. An injected instruction that changes a text response has limited impact, but an instruction that causes an agent to query restricted data or invoke an disallowed tool can have serious consequences.

Prompt instructions can reduce some unwanted behavior, but they shouldn’t be relied on as a security boundary. An instruction such as “ignore malicious instructions in retrieved content” is still just an instruction processed alongside the untrusted content. Execution privileges must sit outside the prompt context.

Agarwal emphasizes this point: “We have to be careful, because there's a chance that the model can request the wrong action. The system executing it must check permissions, the allowed tool, its arguments and where data is being sent. Reading data shouldn’t automatically grant permission to change it.”

The following controls live at the application level:

• Privilege separation: System instructions and untrusted content remain structurally distinct in the context.
• Tool permissions: The agent receives only the tools and operations required for its task.
• Argument and output validation: Application logic checks a proposed tool call before running it.
• Data access controls: Row-, column- and object-level policies apply regardless of what the model requests.
• Guardrails: Input and output controls inspect behavior against defined security and safety policies.

Recent adversarial research reinforces the distinction between instruction and enforcement. In one study covering more than 20,000 adaptive attacks, every defense that relied on the model to protect itself was eventually bypassed, while application-level output filtering held at zero leaks across 15,000 attacks.

The production objective is containment as well as detection. Even when an injection attempt influences model behavior, the surrounding system should restrict what that behavior is authorized to do.

The production prompt lifecycle depends heavily on the data and controls surrounding the model call. When prompts operate against governed data in Snowflake, semantic context, access policies and evaluation stay close to the data the application uses rather than being reimplemented separately for each AI workflow.

With Cortex AI Functions,* model calls run directly from SQL. A prompt used to classify, extract or generate text can therefore be evaluated against data in a table, incorporated into a repeatable transformation and tracked alongside the logic that supplies its inputs. Structured outputs give downstream SQL or application logic a declared contract to validate.

For conversational and multistep applications, Cortex Agents orchestrates interactions with structured and unstructured data and available tools. Semantic context provides the business definitions needed to interpret structured data, while governed access remains enforced by Snowflake rather than encoded as instructions the model is expected to honor.

Cortex Agent Evaluations supports testing agent behavior against ground-truth and reference-free metrics, including answer quality and tool-selection behavior. Traces provide a view into the intermediate steps that produced an answer, which helps separate a prompt problem from a retrieval, tool or orchestration problem.

Security controls also operate at different points in the system. Cortex Guard filters model responses for harmful content, while Cortex AI Guardrails addresses prompt-injection and jailbreak risk at the application level. Keeping those functions distinct is important: output safety and instruction integrity are separate control surfaces.

Taken together, those capabilities support the broader operating model described throughout this article. Prompts are versioned and evaluated, context comes from governed sources, agents expose traces for diagnosis and access controls remain enforceable outside natural-language instructions.

As models improve, the amount of specialized wording required for many tasks will continue to change. But the production responsibilities around those instructions are less dependent on any one model generation. A team still needs to know what context entered the model, which prompt version ran, how the output was scored and where a regression originated. Some failures will trace back to the instruction. Others will point to retrieval, semantic context, tool definitions, model behavior or the controls around an agent.

* Some individual Cortex AI Functions features are in public and private preview.