Standard Prompt Patterns: Zero-Shot, Few-Shot & Chain-of-Thought

A Categorizer That Almost Worked

The support-ticket categorizer from the last phase is live. It works in the demo. Then production traffic arrives, and a switch statement downstream — expecting one of four exact strings, BILLING, TECHNICAL, FRAUD, GENERAL — starts throwing on about 1 in 20 requests. The model didn't misclassify anything; it just phrased the answer differently each time. "Billing". "This looks like a billing issue." Sometimes a full sentence with the category buried in the middle.

Getting the output shape reliable is a separate problem, covered in the next guide. This one is about something that has to come first: getting the model reasoning about the right thing at all, before you worry about how the answer is formatted.

System, user, and assistant — who says what

Every chat request is a list of role-tagged messages, and the roles aren't cosmetic:

• System message — the persona and ground rules, set once by the developer, not the end user. "You are a support-ticket triage assistant. Reply with exactly one category."
• User message — the actual input being acted on. In the categorizer, this is the ticket text.
• Assistant message — prior model replies, resent on every call so a multi-turn conversation has continuity (the model itself remembers nothing between requests).

Zero-Shot: Just Asking

Zero-shot prompting is giving the model an instruction with no examples and trusting it to generalize from what it learned during training:

Classify this support ticket as BILLING, TECHNICAL, FRAUD, or GENERAL.
Reply with only the category name.

Ticket: "My card was charged twice for the same order."

This works surprisingly often for well-known task shapes — sentiment, classification, straightforward extraction — because the model has seen millions of similar patterns during pre-training. It's also the least reliable pattern the moment the task has any house-specific nuance: what counts as FRAUD versus BILLING for a duplicate charge is a judgment call your company makes, not a universal fact the model already knows.

Few-Shot: Showing, Not Just Telling

Few-shot prompting adds a handful of worked examples directly in the prompt, before the real input:

Classify each support ticket as BILLING, TECHNICAL, FRAUD, or GENERAL.

Ticket: "I was charged twice for the same order."
Category: BILLING

Ticket: "Someone logged into my account from a country I've never visited."
Category: FRAUD

Ticket: "The app crashes every time I open the settings page."
Category: TECHNICAL

Ticket: "My card was charged twice for the same order and I never authorized it."
Category:

Notice the last example is deliberately close to the first — a duplicate charge, but one framed as unauthorized. That's the actual value of few-shot: it doesn't just teach the format of the answer, it teaches the boundary between categories using cases that are genuinely ambiguous, which zero-shot has no way to learn from a one-line instruction. This was formalized at scale in the GPT-3 paper, which showed that a handful of in-context examples, with no weight updates at all, could rival fine-tuned models on many tasks — a big part of why prompting became a viable engineering discipline in its own right rather than something you only did before fine-tuning.

Chain-of-Thought: Making the Reasoning Visible

For tasks with more than one logical step — multi-step math, "is this ticket both a billing issue and a security concern," anything requiring the model to weigh evidence — asking it to reason before answering measurably improves accuracy:

A customer reports being charged twice and says their password was
recently changed without their knowledge. Think step by step about
whether this is primarily BILLING or FRAUD, then give your final answer.

This technique, Chain-of-Thought (CoT) prompting, was formalized in Chain-of-Thought Prompting Elicits Reasoning in Large Language Models (Wei et al., 2022) — one of the more surprising findings in the field, because "just ask it to show its work" turned out to unlock real accuracy gains on problems the model would otherwise get wrong in one shot. It isn't free, though: a CoT response spends extra output tokens on the reasoning itself, which costs money and adds latency. As covered in Phase 1, today's reasoning models bake a version of this in automatically at the training level — but for a simple four-way classification task like the categorizer, explicit CoT is usually overkill. Reasoning about whether a duplicate charge is BILLING or FRAUD genuinely benefits from it; reasoning about whether "my password" contains the word "password" does not.

What's Next

Even with the right examples and reasoning pattern, the categorizer still phrases its answer differently every so often — the format bug from the top of this guide is still open. Fixing that isn't a prompting-pattern problem at all; it needs a different kind of guarantee, which the next guide covers.