The Five Core Patterns

Most of the prompt engineering advice online covers dozens of techniques. Production experience narrows it down fast. Here are the five patterns that survive, and the ones they replace.

Why Five?

There are hundreds of published prompt patterns. Most are useful in demos. A much smaller set remain reliable when the input distribution widens, the context grows, and the model changes underneath you. The five patterns below share a property: they work because they are explicit rather than implicit. They don’t rely on the model’s default behavior - they override it with specific instructions that hold across conditions.

Pattern 1: Role Anchoring

Assigning the model a role is one of the oldest prompting techniques. The production-grade version goes further than “You are a helpful assistant.” It specifies the role, the audience, the scope, and what the role is not.

You are a helpful customer support agent. Answer the user's question.

You are a customer support agent for [Product]. You help users with:
- Account issues, billing questions, and subscription changes
- Technical troubleshooting for the core product features

You do NOT:
- Answer questions about competitors
- Provide legal or financial advice
- Make promises about future features

Always respond in the same language the user writes in. Keep answers under 200 words unless the issue requires step-by-step instructions.

The “after” version survives because the scope boundary is explicit. Without it, the model will helpfully answer whatever the user asks, including things outside your support scope.

Pattern 2: Explicit Output Constraints

The model’s default output format is whatever seemed best for the input. In production, “whatever seemed best” is a parsing failure waiting to happen. Explicit output constraints are not optional - they are the contract between your prompt and your downstream code.

Classify this support ticket into a category and priority level.

Classify this support ticket.

Return ONLY a JSON object in this exact format, with no additional text before or after:
{
  "category": one of ["billing", "technical", "account", "feature_request", "other"],
  "priority": one of ["low", "medium", "high", "urgent"],
  "confidence": a number between 0 and 1
}

Pattern 3: Chain-of-Thought for Non-Trivial Reasoning

Chain-of-thought (CoT) - asking the model to reason step-by-step before giving an answer - consistently improves accuracy on tasks requiring logic, multi-step inference, or judgment calls. The production caveat: CoT adds tokens and latency. Use it when accuracy matters more than speed, not as a default.

Should this refund request be approved? Customer says the product arrived damaged.

Answer: yes or no.

Should this refund request be approved? Customer says the product arrived damaged.

Think through this step by step:
1. What evidence of damage is described?
2. Is this consistent with our return policy criteria?
3. Are there any red flags (duplicate requests, policy abuse patterns)?
4. What is the appropriate outcome?

After reasoning through these steps, give your final answer as:
DECISION: [approve / deny / escalate]
REASON: [one sentence]

The structured CoT format also makes audit logging useful: you capture the model’s reasoning, not just its conclusion, which is essential for any decision that humans need to review.

Pattern 4: Few-Shot Format Anchoring

Few-shot examples are most valuable when the output format is complex, subtle, or hard to describe precisely in words. They are less valuable (and more expensive) when the format is simple enough to specify explicitly. The production rule: use few-shot when showing is easier than telling.

Extract the key action items from meeting notes. Format each as a task with owner and due date.

Example input:
"Sarah to update the pricing page by Friday. John will schedule the engineering review next week."

Example output:
- Task: Update pricing page | Owner: Sarah | Due: Friday
- Task: Schedule engineering review | Owner: John | Due: next week

Now extract from this input:
{meeting_notes}

The example does two things: it defines the format precisely, and it demonstrates edge-case handling (the model sees how to handle relative dates like “next week”). Lesson 5 covers the full design of few-shot sets at scale.

Pattern 5: Negative-Space Constraints

The most common gap in production prompts is not what you told the model to do - it is what you forgot to tell it not to do. Negative constraints close the behavioral gaps that implicit assumptions leave open.

# Scope constraints
Do NOT answer questions unrelated to [your domain].
Do NOT provide [legal / medical / financial] advice.

# Format constraints
Do NOT include preamble like "Here is the result:" or "Sure!"
Do NOT add caveats or disclaimers unless explicitly requested.
Do NOT use markdown formatting in your response.

# Behavior constraints
Do NOT make up information if you are uncertain - say so.
Do NOT refer to yourself as an AI unless directly asked.

Pattern Applicability Guide

Combining Patterns

The five patterns are not mutually exclusive. A production classification prompt typically uses patterns 1, 2, and 5 together. A decision-making prompt uses patterns 1, 2, 3, and 5. The combination has a compounding effect: each pattern covers failure modes the others leave open. The full combination - role anchoring, explicit constraints, chain-of-thought, few-shot anchoring, negative constraints - is not excessive. It is a prompt that has been hardened against the known failure modes.