Few-Shot Prompting

Official Exam Guide Objectives

Task 4.2: Apply few-shot prompting to improve output consistency and quality

Knowledge of

• Few-shot examples as the most effective technique for achieving consistently formatted, actionable output when detailed instructions alone produce inconsistent results
• The role of few-shot examples in demonstrating ambiguous-case handling (e.g., tool selection for ambiguous requests, branch-level test coverage gaps)
• How few-shot examples enable the model to generalize judgment to novel patterns rather than matching only pre-specified cases
• The effectiveness of few-shot examples for reducing hallucination in extraction tasks (e.g., handling informal measurements, varied document structures)

Skills in

• Creating 2-4 targeted few-shot examples for ambiguous scenarios that show reasoning for why one action was chosen over plausible alternatives
• Including few-shot examples that demonstrate specific desired output format (location, issue, severity, suggested fix) to achieve consistency
• Providing few-shot examples distinguishing acceptable code patterns from genuine issues to reduce false positives while enabling generalization
• Using few-shot examples to demonstrate correct handling of varied document structures (inline citations vs bibliographies, methodology sections vs embedded details)
• Adding few-shot examples showing correct extraction from documents with varied formats to address empty/null extraction of required fields

What You Need to Know

For consistent, well-formatted output, nothing outperforms few-shot examples. Not longer instructions. Not confidence thresholds. Not temperature adjustments. Where the complaint is inconsistency, examples are the first thing to reach for rather than the last.

The exam states this as a principle and then tests it repeatedly: a scenario describes detailed instructions producing variable results, and the options include writing more instructions or supplying examples. The answer is almost always the examples.

When to Deploy Few-Shot Examples

Three specific triggers tell you few-shot examples are needed:

1. Detailed instructions alone produce inconsistent formatting. The prompt already specifies the output format carefully, and results still arrive shaped differently each time — a bulleted list on one run, a table on the next, prose on the third. Additional specification does not converge on the format, because the description was never the limiting factor. Two or three examples of the actual output shape settle it.

2. The model makes inconsistent judgement calls on ambiguous cases. Variable shadowing is "critical" in one file and "minor" in another. "Check my order" routes to one tool with one phrasing and a different tool with another. These are cases where the correct answer is genuinely arguable, so the model needs to see the call made, with the reasoning attached.

3. Extraction tasks produce empty/null fields for information that exists in the document. The data is present, just not where the model expected — carried in a sentence rather than a table, or spread over several paragraphs. Examples drawn from those awkward structures teach it where else to look.

How to Construct Effective Examples

The rules are tight:

Use 2-4 targeted examples. One example is an instance rather than a pattern; past four the additional cases mostly restate what the earlier ones established while still costing context. Aim them at the specific ambiguous scenarios that are actually failing.

Each example must show reasoning. An input-output pair records a decision; it does not convey why that decision beat the alternatives. Including the reasoning is what lets the model apply the same principle to a case your examples never covered.

Example: Tool selection for "any update on order #48802?"
Input: "any update on order #48802?"
Selected tool: lookup_order
Reasoning: An order number is present (#48802), which scopes the
request to one order rather than to the account behind it. Phrased
as a general enquiry it could plausibly route to get_customer, but
the identifier is the deciding signal: lookup_order is correct.

Strip the reasoning and what remains is a narrow rule — order numbers imply lookup_order. Keep it and the model has the general form: a specific identifier selects the tool scoped to that identifier.

Cover the failing scenarios. Examples should be drawn from wherever the current behaviour breaks. Extraction that handles tables and fails on narrative needs narrative examples. Code review that wavers on variable shadowing needs shadowing cases classified at several severities, each with its reasoning.

The Hallucination Reduction Effect

Few-shot examples earn a second return in extraction work: they reduce fabrication. Shown correct extraction across varied document structures — inline citations against bibliographies, narrative description against structured tables, headers against text embedded in a paragraph — the model learns that structural variety is expected, and stops treating an unfamiliar layout as an absence of data.

It matters most where formatting is inconsistent within a single document. A financial report may tabulate expenses on one page and describe them in a sentence on the next. Unexampled, the model typically handles the table, returns nothing for the narrative section, and sometimes supplies a plausible figure it has invented. Demonstrate both layouts and extraction quality rises across the document.

Few-Shot for Reducing False Positives

In review and analysis tasks, examples do two jobs at once, because they can demonstrate what to leave alone as readily as what to raise. Showing acceptable patterns beside genuine defects lowers the false positive rate without dulling the model's sensitivity to real problems.

Example: Variable shadowing assessment
Code: function process(items) {
  const result = items.map(item => {
    const result = transform(item);  // shadows outer 'result'
    return result;
  });
  return result;
}
Severity: minor
Reasoning: The shadowing is real but confined to the arrow
function, so the outer binding is never ambiguous at any point a
reader is looking at. Nothing here misbehaves — it reads slightly
worse. That makes it a style call rather than a defect, and worth
raising only where style consistency is in scope for the review.

What the model takes from this is a distinction rather than a verdict: shadowing inside a tightly bounded scope is cosmetic, which leaves it free to treat shadowing that genuinely obscures a bug quite differently.

Few-Shot vs Other Techniques

The exam tests whether you can distinguish when few-shot examples are the right solution versus when another technique applies:

Deep Dive

Examples are "pictures worth a thousand words"

Anthropic's context-engineering guidance frames few-shot examples not as filler but as the highest-density way to convey expected behaviour: "We recommend working to curate a set of diverse, canonical examples that effectively portray the expected behavior of the agent. For an LLM, examples are the 'pictures' worth a thousand words." The word diverse is doing real work here — a set of near-identical examples teaches a narrow pattern, while examples spanning the range of formats you actually see (tables, narrative, mixed) teach the general principle.

Sourceanthropic.com › effective-context-engineering-for-ai-agentsfetched 2026-07-30

Why exhaustive rule lists lose to targeted examples

The same guidance explicitly rules out the instinct to fix inconsistency by adding more prose rules: "We do not recommend... stuffing a laundry list of edge cases into a prompt in an attempt to articulate every possible rule." This is the structural reason the exam's "add more detailed instructions" distractor fails — a longer rule list still asks the model to interpret prose, while a handful of worked examples shows the decision directly. Few-shot examples and exhaustive rule-writing are competing solutions to the same problem, and the guidance names the example-based one as preferred.

Sourceanthropic.com › effective-context-engineering-for-ai-agentsfetched 2026-07-30

Classification tasks: pair examples with an enforced enum

For classification specifically — severity levels, tool routing, document category — the prompting best-practices page recommends going one step further than examples alone: "For classification tasks, use either tools with an enum field containing your valid labels or structured outputs." Few-shot examples teach the model which label is correct for ambiguous cases; an enum on a tool's input_schema then guarantees the model can only emit one of your defined labels. The two techniques solve different halves of the same consistency problem — judgment and structure — and are typically deployed together.

Sourceplatform.claude.com › claude-prompting-best-practicesfetched 2026-07-30

Delegated tasks fail the same way vague prompts fail

Anthropic's multi-agent research write-up found that when a subagent's task description lacks an objective, output format, and boundaries, agents "duplicate work, leave gaps, or fail to find necessary information" — the documented case was two subagents independently investigating the same 2025 supply-chain topic because their assignments overlapped. This is the delegation-level version of the extraction problem few-shot solves: a demonstrated output format (via examples) removes the same ambiguity that a demonstrated task boundary (via explicit delegation) removes for subagents.

Sourceanthropic.com › multi-agent-research-systemfetched 2026-07-30

More tokens is not automatically better — context rot applies to examples too

The context-engineering guidance names "context rot": as the number of tokens in the context window increases, the model's ability to accurately recall information from that context decreases. This is the mechanism behind the example ceiling — piling in 8-10 examples "to be thorough" does not just waste tokens, it can measurably dilute the model's attention on the pattern you actually need it to learn. Fewer, sharper, more diverse examples beat a large undifferentiated set.

Sourceanthropic.com › effective-context-engineering-for-ai-agentsfetched 2026-07-30

Current state: the exam says 2-4, current docs say 3-5

The exam guide's skill statement is "Creating 2-4 targeted few-shot examples for ambiguous scenarios", and 2-4 is the answer to give on the exam. Current prompting guidance states "Include 3-5 examples for best results". The two overlap at 3-4, and the underlying principle is identical — a handful of sharp, diverse examples, not an exhaustive set. Answer 2-4 on the exam; use 3-5 as the working default in production.

Sources: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices (3-5) · exam guide v1.0 Task 4.2 (2-4) (fetched 2026-07-30)

Quick Reference

Exam Traps

Practice Scenario

Build Exercise

Build a Few-Shot Enhanced Extraction Prompt

Difficulty: Intermediate (2/4)

45 minutes

1. Create a base extraction prompt with detailed instructions but no examples and test it against 10 documents with varied structures: tables, narrative paragraphs, mixed formats

Why: Establishing a baseline without examples demonstrates the consistency problem the exam tests. Detailed instructions alone produce inconsistent output across varied document structures, which is the exact trigger for deploying few-shot examples.

You should see: Inconsistent extraction results across the 10 documents: fields extracted correctly from tables but empty or wrong from narrative paragraphs, different output formats across runs, and inconsistent handling of edge cases.

2. Record which fields are consistently empty or inconsistent across document structures

Why: Identifying the specific failure patterns tells you exactly what your few-shot examples need to demonstrate. The exam tests whether you can diagnose the problem before prescribing the solution.

You should see: A table or log showing which fields fail on which document types. Typical pattern: dates extracted correctly from tables but missed in narrative text, amounts inconsistent when written in words rather than digits, line items empty when embedded in paragraphs.

3. Create 3 few-shot examples targeting the failing patterns — each must include reasoning explaining why the extraction was done that way

Why: Examples with reasoning teach the model to generalise to novel patterns, not just match specific cases. Without reasoning, the model learns only surface-level pattern matching. The exam specifically tests that reasoning-included examples outperform input-output pairs.

You should see: Three examples, each showing a different document structure (table, narrative, mixed), with the correct extraction AND a reasoning section explaining how the data was located and why the extraction decisions were made.

4. Re-run the same 10 documents with the few-shot enhanced prompt and compare: empty field rate, format consistency, and extraction accuracy

Why: Quantifying the improvement demonstrates the effectiveness of few-shot examples as the first-choice technique for consistency problems. The exam expects you to know that few-shot examples outperform additional instructions for this class of problem.

You should see: A measurable reduction in empty fields (especially on narrative documents), improved format consistency across document types, and higher overall extraction accuracy. The improvement should be most dramatic on the document types that previously failed.

5. Document which structural patterns benefit most from few-shot examples and which require different techniques like schema changes

Why: The exam tests whether you can match the right technique to the right problem. Few-shot examples fix consistency and structural variety issues, but malformed JSON needs tool_use, fabricated values need nullable schemas, and sum discrepancies need validation loops.

You should see: A decision matrix showing which problem types improved with few-shot examples and which still need other interventions. Narrative extraction and format consistency should improve. Fabrication of missing data should not improve and needs schema changes instead.

Sources

• Claude Certified Architect Foundations Exam Guide — Task Statement 4.2 — Anthropic
• Prompt Engineering Overview — Anthropic
• Building with Claude API (Skilljar) — Anthropic
• Effective Context Engineering for AI Agents — Anthropic
• Claude Prompting Best Practices — Anthropic
• How We Built Our Multi-Agent Research System — Anthropic

Appendix A — Build Exercise Step Hints

Progressive hints revealed by the "Stuck? Get a nudge" control on each step.

Step 1. Create a base extraction prompt with detailed instructions but no examples and test it against 10 documents with varied structures: tables, narrative paragraphs, mixed formats

Why: Establishing a baseline without examples demonstrates the consistency problem the exam tests. Detailed instructions alone produce inconsistent output across varied document structures, which is the exact trigger for deploying few-shot examples.

You should see: Inconsistent extraction results across the 10 documents: fields extracted correctly from tables but empty or wrong from narrative paragraphs, different output formats across runs, and inconsistent handling of edge cases.

const basePrompt = `Extract the following fields from the document:
- vendor_name: The company or person issuing the document
- document_date: Date in ISO 8601 format
- total_amount: Numeric value without currency symbols
- line_items: Array of {description, amount} objects

Return as JSON. Ensure all fields are populated.`;

// Test against varied document structures
const testDocs = [
  { type: "table", content: "| Item | Amount |\n| Widget | 50.00 |" },
  { type: "narrative", content: "We purchased widgets for fifty pounds on March 3rd." },
  { type: "mixed", content: "Invoice #123\nItems as discussed: see below table..." }
];

base_prompt = """Extract the following fields from the document:
- vendor_name: The company or person issuing the document
- document_date: Date in ISO 8601 format
- total_amount: Numeric value without currency symbols
- line_items: Array of {description, amount} objects

Return as JSON. Ensure all fields are populated."""

# Test against varied document structures
test_docs = [
    {"type": "table", "content": "| Item | Amount |\n| Widget | 50.00 |"},
    {"type": "narrative", "content": "We purchased widgets for fifty pounds on March 3rd."},
    {"type": "mixed", "content": "Invoice #123\nItems as discussed: see below table..."},
]

Step 2. Record which fields are consistently empty or inconsistent across document structures

Why: Identifying the specific failure patterns tells you exactly what your few-shot examples need to demonstrate. The exam tests whether you can diagnose the problem before prescribing the solution.

You should see: A table or log showing which fields fail on which document types. Typical pattern: dates extracted correctly from tables but missed in narrative text, amounts inconsistent when written in words rather than digits, line items empty when embedded in paragraphs.

const failureLog = testDocs.map((doc, i) => ({
  docType: doc.type,
  vendor_name: results[i].vendor_name ? "extracted" : "EMPTY",
  document_date: results[i].document_date ? "extracted" : "EMPTY",
  total_amount: results[i].total_amount ? "extracted" : "EMPTY",
  format_consistent: checkFormatConsistency(results[i])
}));

// Identify patterns: which fields fail on which doc types?
const failuresByType = groupBy(failureLog, "docType");

from itertools import groupby

failure_log = [
    {
        "doc_type": doc["type"],
        "vendor_name": "extracted" if results[i].get("vendor_name") else "EMPTY",
        "document_date": "extracted" if results[i].get("document_date") else "EMPTY",
        "total_amount": "extracted" if results[i].get("total_amount") else "EMPTY",
        "format_consistent": check_format_consistency(results[i]),
    }
    for i, doc in enumerate(test_docs)
]

# Identify patterns: which fields fail on which doc types?
failures_by_type = {
    k: list(v)
    for k, v in groupby(sorted(failure_log, key=lambda r: r["doc_type"]),
                        key=lambda r: r["doc_type"])
}

Step 3. Create 3 few-shot examples targeting the failing patterns — each must include reasoning explaining why the extraction was done that way

Why: Examples with reasoning teach the model to generalise to novel patterns, not just match specific cases. Without reasoning, the model learns only surface-level pattern matching. The exam specifically tests that reasoning-included examples outperform input-output pairs.

You should see: Three examples, each showing a different document structure (table, narrative, mixed), with the correct extraction AND a reasoning section explaining how the data was located and why the extraction decisions were made.

const fewShotExamples = [
  {
    input: "We ordered fifty units at ten pounds each on the third of March.",
    output: { vendor_name: null, document_date: "2024-03-03", total_amount: 500.00, line_items: [{ description: "units", amount: 500.00 }] },
    reasoning: "Date was written in natural language (third of March) and converted to ISO 8601. Amount was calculated from quantity (50) times unit price (10). No vendor name present in text so returned null rather than fabricating."
  }
];

few_shot_examples = [
    {
        "input": "We ordered fifty units at ten pounds each on the third of March.",
        "output": {
            "vendor_name": None,
            "document_date": "2024-03-03",
            "total_amount": 500.00,
            "line_items": [{"description": "units", "amount": 500.00}],
        },
        # Reasoning is what makes an example generalise instead of being
        # pattern-matched — it is not optional decoration.
        "reasoning": (
            "Date was written in natural language (third of March) and converted "
            "to ISO 8601. Amount was calculated from quantity (50) times unit "
            "price (10). No vendor name present in text so returned null rather "
            "than fabricating."
        ),
    }
]

Step 4. Re-run the same 10 documents with the few-shot enhanced prompt and compare: empty field rate, format consistency, and extraction accuracy

Why: Quantifying the improvement demonstrates the effectiveness of few-shot examples as the first-choice technique for consistency problems. The exam expects you to know that few-shot examples outperform additional instructions for this class of problem.

You should see: A measurable reduction in empty fields (especially on narrative documents), improved format consistency across document types, and higher overall extraction accuracy. The improvement should be most dramatic on the document types that previously failed.

const comparison = {
  baseline: { emptyFieldRate: 0.35, formatConsistency: 0.60, accuracy: 0.72 },
  fewShot: { emptyFieldRate: 0.08, formatConsistency: 0.92, accuracy: 0.91 }
};

// Per-type comparison
const byType = {
  table: { baseline: 0.95, fewShot: 0.97 },
  narrative: { baseline: 0.45, fewShot: 0.85 },
  mixed: { baseline: 0.60, fewShot: 0.88 }
};

comparison = {
    "baseline": {"empty_field_rate": 0.35, "format_consistency": 0.60, "accuracy": 0.72},
    "few_shot": {"empty_field_rate": 0.08, "format_consistency": 0.92, "accuracy": 0.91},
}

# Per-type comparison
by_type = {
    "table": {"baseline": 0.95, "few_shot": 0.97},
    "narrative": {"baseline": 0.45, "few_shot": 0.85},
    "mixed": {"baseline": 0.60, "few_shot": 0.88},
}

Step 5. Document which structural patterns benefit most from few-shot examples and which require different techniques like schema changes

Why: The exam tests whether you can match the right technique to the right problem. Few-shot examples fix consistency and structural variety issues, but malformed JSON needs tool_use, fabricated values need nullable schemas, and sum discrepancies need validation loops.

You should see: A decision matrix showing which problem types improved with few-shot examples and which still need other interventions. Narrative extraction and format consistency should improve. Fabrication of missing data should not improve and needs schema changes instead.

const techniqueMappings = [
  { problem: "Inconsistent output formatting", technique: "Few-shot examples", improved: true },
  { problem: "Empty fields on narrative text", technique: "Few-shot examples", improved: true },
  { problem: "Fabricated values for missing data", technique: "Optional/nullable schema fields", improved: false },
  { problem: "Malformed JSON output", technique: "tool_use with JSON schemas", improved: false },
  { problem: "Sum does not match total", technique: "Validation-retry loop", improved: false }
];

technique_mappings = [
    {"problem": "Inconsistent output formatting", "technique": "Few-shot examples", "improved": True},
    {"problem": "Empty fields on narrative text", "technique": "Few-shot examples", "improved": True},
    {"problem": "Fabricated values for missing data", "technique": "Optional/nullable schema fields", "improved": False},
    {"problem": "Malformed JSON output", "technique": "tool_use with JSON schemas", "improved": False},
    {"problem": "Sum does not match total", "technique": "Validation-retry loop", "improved": False},
]

Appendix B — Interactive Study Prompts

Two prompts to paste into Claude. B1 drills the judgement the exam actually measures; B3 reviews the prompts you wrote for the Build Exercise above. The exam simulator between them is the interactive quiz on this page.

B1. Concept Check — Discrimination Drill

B2. Exam Simulator

B3. Build Coach — Prompt Review

The Build Exercise and its hint ladder are already on this page. This prompt is for the one thing the page cannot do: review the examples you actually wrote.