The 5 Prompt Patterns I Use for Every Production AI Agent

Prompt engineering for demos is easy. Prompt engineering for production systems — where the input is unpredictable, the output has to be machine-parseable, and failure has real consequences — is a different discipline.

After building agents that process real inbound calls, classify real leads, and draft real email replies, I've narrowed down to five patterns I reach for on every project. Here's each one and the reasoning behind it.

Pattern 1: Role + Constraint + Format

Every production prompt I write starts with three things: who the model is, what it must not do, and what the output must look like.

You are a call quality analyst evaluating dental clinic front-desk calls.
Your job is to score each call against a structured framework.
You must not make assumptions about information not present in the transcript.
Output only valid JSON matching the schema below. Do not include commentary outside the JSON object.

Schema:
{
  "steps": [{"step": string, "score": 0|1|2, "note": string}],
  "critical_failure": boolean,
  "summary": string
}

The constraint block ("must not") matters as much as the role. Without it, GPT-4 and Gemini will interpolate — filling in information the transcript doesn't contain, especially on short or ambiguous calls. The constraint forces the model to work only with what's there.

The format block eliminates the most common production failure: inconsistent output structure. Every downstream step that parses the model's output depends on a predictable schema. If the model decides to add a field or change a key name, the parse fails. Specifying the exact schema removes that variability.

Pattern 2: Chain-of-Thought Before JSON

When the output requires judgment — not just extraction — the quality improves significantly if you ask the model to reason before it concludes.

First, reason through each step in the scoring framework.
Think about what the transcript says and doesn't say for each step.
After reasoning, output your JSON scores.

Your reasoning should be formatted as:
STEP 1 [Greeting]: <reasoning>
STEP 2 [Active Listening]: <reasoning>
...

Then output the JSON object.

The reasoning block gives the model a scratchpad. On ambiguous calls — where a step is partially met, or where the patient cut the agent off mid-sentence — the model works through the evidence before committing to a score. Without the reasoning step, scores on borderline calls are inconsistent run-to-run.

In production, I strip the reasoning and keep only the JSON. But during development, the reasoning block is invaluable for debugging — you can see exactly why the model scored something the way it did.

Pattern 3: Explicit Handling for Edge Cases

Any real-world data source will have edge cases the prompt doesn't anticipate. You need to specify what the model should do with them, or it will invent something.

For call transcripts:

If the transcript is under 50 words, the call is likely a voicemail or hang-up.
Score all steps as 0 and set "critical_failure" to false.
Set "summary" to "Transcript too short to evaluate."

If the transcript contains content in a language other than English,
evaluate against the same framework and note the language in the summary.
Do not flag non-English calls as failures.

For email classification:

If an email could belong to multiple categories, choose the one
with higher business consequence. When in doubt, escalate rather than auto-resolve.

If an email contains no identifiable business intent, classify as "noise"
and set priority to 0.

The principle: specify every path. If the model hits an edge case with no instruction, it picks the most statistically likely response — which might be right most of the time, but wrong often enough to cause problems.

Pattern 4: Few-Shot with Contrasting Examples

For classification tasks, a well-chosen few-shot set outperforms detailed instructions alone. The key is contrasting examples — cases that look similar on the surface but should produce different outputs.

Classify the following email as one of: [demo_request, pricing_inquiry, partnership, noise].

Examples:
---
Email: "Hi, I saw your demo video and wanted to know if we could set up a quick call"
Classification: demo_request
Reason: Explicit request for a call after seeing demo content.

Email: "Hi, curious what your pricing looks like for a team of 50"
Classification: pricing_inquiry
Reason: Pricing question with team size context — shows intent to evaluate.

Email: "Hi, great work on your blog post"
Classification: noise
Reason: No business intent. Compliment only.

Email: "Hi, I run an agency and would love to explore some synergies"
Classification: partnership
Reason: Agency context + synergy language = partnership inquiry, not sales lead.
---

Now classify: {email_content}

The Reason field in examples is as important as the classification. It shows the model how to think about each case, not just what answer to give. Without reasons, the model learns the labels but not the underlying logic.

Pattern 5: Constrained Reply Drafting

When the agent's output is a draft reply (not just a classification), the biggest failure mode is verbose, generic responses. Production reply drafts need to be specific, short, and on-brand.

Write a reply to the following email as if you are a senior SDR at an AI automation agency.
Tone: direct, professional, no filler phrases.
Length: 3-4 sentences maximum.
Do not use phrases like "I hope this email finds you well", "feel free", or "please don't hesitate".
Reference one specific detail from the email to show you read it.
End with a clear single next step — a specific question or a meeting link.

Email: {email_content}

The negative instructions ("do not use...") eliminate the corporate filler that language models default to. The length constraint prevents the model from treating a 100-word email as an invitation to write 400 words. The "reference one specific detail" instruction produces replies that feel personal rather than templated.

In practice, I give the agent 2-3 reply drafts per email using a temperature of 0.3-0.5, and let the SDR pick the one that fits. This gives some variation without sacrificing consistency.

What These Have in Common

All five patterns share the same underlying principle: reduce the model's degrees of freedom. The more specific the instruction, the less the model has to guess, and the more consistent the output.

This is counterintuitive if you think of LLMs as creative tools. In production, creativity is a reliability risk. The patterns above are designed to make the model predictable — which is exactly what you need when the output feeds into an automated downstream process.

The tradeoff is prompt length. These prompts are long. But token cost is negligible for business-critical workflows, and a long prompt with clear structure vastly outperforms a short prompt that leaves room for interpretation.