AnthropicClaude Certified Architect – Foundations2026-104.2 Apply few-shot prompting to improve output consistency and quality
Teach decisions with targeted worked examples
Completed by the knowledge check
Learning objective
Use two to four few-shot examples to clarify ambiguous decisions and teach transferable judgment rather than literal case matching.
Core idea
A few-shot example supplies an input and the output you want for it. For an ambiguous decision, add a short explanation of the decisive evidence and why a plausible alternative loses. The example should teach a criterion you can apply to a different case, rather than an association between a familiar phrase and an answer.
Anthropic describes examples, also called multishot prompting, as a reliable way to steer Claude’s format, tone, and structure and improve accuracy and consistency. Its guidance emphasizes relevance, diversity, and clear separation from instructions. Those properties matter more than collecting many routine cases that all teach the same choice.
For this objective, use two to four targeted examples. Three lets you cover both sides of a decision and a boundary case without treating the prompt as a catalog of every possible input. The exam’s count and the documentation’s general recommendation differ; the distinction appears later in this lesson.
How it works
Find the decision the instructions leave open
Start with a real disagreement in the desired behavior. A code-review instruction might say to flag missing tests, but leave unclear whether tests for one path satisfy the requirement for a function with two paths. Another instruction might permit both inline comments and a summary, without explaining which one fits a repeated issue.
Define the criterion before selecting examples. In this review workflow, the team’s policy is to report untested behavior introduced by a change and to group repeated instances of one cause into a summary. These are the example application’s decisions, not built-in Claude policies.
Then choose inputs where two actions look reasonable. Showing a function with no tests at all does little to resolve the harder question about an untested branch inside a tested function. Showing one isolated defect does little to explain how repeated defects should be grouped.
Show the choice and the rejected alternative
The following examples teach three different boundaries in a review prompt:
| Input evidence | Desired decision | Brief justification and rejected alternative |
|---|---|---|
| A token validator adds an expired-token branch; tests exercise only valid tokens | Report a coverage gap for the added branch | Existing function tests do not exercise expiry behavior; do not dismiss the gap because the function has a test file |
| Three callers omit the same prerequisite check introduced by one shared change | Choose the application’s post_summary_comment tool and list all three locations | One shared cause needs one coordinated correction; three duplicate inline comments obscure that relationship |
| One calculation divides by a count that can be zero at a specific line | Choose the application’s post_inline_comment tool | The defect and fix belong to one location; a general summary would lose the actionable anchor |
The two comment-tool names are illustrative application-defined tools. In a Messages integration, their definitions belong in tools, with their name, description, and input_schema. Anthropic documents that Claude selects tools using the request and tool descriptions. Example outputs should use names that match the exposed tools, rather than inventing an operation that the application cannot execute.
For an individual user-defined client tool, input_examples demonstrates inputs valid against its input_schema; use prompt demonstrations to show choices between tools, as distinct from parameter examples for one tool. See 2.1.1.
Keep the explanation short and inspectable: name the evidence, chosen action, and reason the alternative is weaker. Anthropic documents that worked examples influence how Claude approaches similar problems in its own thinking blocks. Structure each demonstration as the situation, the criterion or method to apply, and the expected decision. The useful teaching signal is the distinction between a tested function and a tested behavior, or between a single-location defect and a shared cause.
Separate demonstrations from the live case
Anthropic recommends <example> tags around individual demonstrations and <examples> around the set. Use descriptive tags such as <instructions> and <input> to distinguish the policy and live request. These tags organize prompt text; they are not API fields or an enforcement mechanism.
Place each demonstration’s input next to its desired output. Keep the same interpretation of the criterion across all three examples. If one example groups by shared cause and another groups only by file count, the prompt teaches competing policies.
Vary incidental details while keeping the decision clear. A branch example can involve expiry, retries, or permissions; the criterion concerns introduced behavior that no supplied test exercises. Different filenames and wording discourage an accidental rule such as “only authentication files need branch tests.” See 4.2.2 for contrasting acceptable patterns with defects and 4.2.3 for the report fields themselves.
Key distinctions and trade-offs
A verdict versus a reusable explanation: “Flag this” supplies a label. “Flag the added failure path because the supplied tests only cover success” states the evidence that distinguishes the case. Anthropic’s guidance to provide context and motivation supports explaining why the requested behavior matters.
Example guidance versus execution control: A demonstration can guide tool selection, but it does not make a prerequisite mandatory. See 1.4.1 for enforcing prerequisites before execution. Use examples when the question is which justified choice fits the evidence, rather than whether a required check can be skipped.
Example diversity versus prompt volume: Three distinct boundaries teach more than three paraphrases of a routine success. Adding examples is useful when they cover missing distinctions; an expanding list of near-duplicates can reinforce the wrong incidental association.
Ambiguous intent versus unclear tools: Examples refine decisions among well-described operations. If tool descriptions leave their purposes indistinguishable, repair that contract first; see 2.1.2. Otherwise an example may conceal the ambiguity for one phrase without resolving it for another.
Architecture / decision scenario
A developer-productivity pipeline reviews pull requests. Its detailed prompt still misses untested branches and inconsistently chooses comment placement. The architect adds the three demonstrations from the table, each with a concise explanation, inside <examples>.
The evaluation change contains an untested retry-exhaustion branch, a shared validation omission in two callers, and an isolated zero-denominator defect. None uses the same filenames or wording as the demonstrations. The expected decisions are a branch coverage finding, one summary for the shared cause, and one inline finding for the local calculation.
If Claude reports only the expiry example’s pattern, the examples have not established transfer. Revise the explanation to emphasize the uncovered behavior, rather than adding a special rule for the retry filename. If it chooses a nonexistent tool, align the demonstrations with tools[].name and the descriptions before adding another example. The evidence of improvement is correct handling of these unseen cases, not repetition of the demonstration outputs.
Common exam traps
- Adding more general instructions when detailed rules still leave the same ambiguous cases unresolved.
- Filling the example budget with obvious cases instead of the competing choices.
- Giving only labels and expecting the reader to infer the deciding criterion.
- Treating a demonstrated tool choice as an execution guarantee.
- Measuring success only on the examples already inside the prompt.
Where the exam guide differs
The exam guide specifies “2-4 targeted few-shot examples” for ambiguous scenarios. Anthropic’s prompting documentation recommends 3–5 examples for best results generally. Neither statement defines an API limit. Use the exam’s two-to-four range when interpreting this task statement; three or four also fits the documentation’s general recommendation. Select examples for distinct decisions rather than treating either count as a guarantee of quality.
What to remember
Teach the boundary, not a list of familiar cases. Each targeted example needs the input, chosen action, and a short evidence-based reason that rejects a plausible alternative. Keep examples distinct from the live input, align tool names with their definitions, and check the resulting judgment on unseen cases.
Knowledge check
A review prompt already says “flag missing tests”. When a pull request adds an error branch to a function whose existing tests cover only the success path, the reviewer sometimes flags the gap and sometimes stays silent. What is the most effective change?
A review agent chooses between two application tools, post_inline_comment and post_summary_comment. The prompt’s demonstrations show the summary decision as comment_summary, and some live reviews now answer with text naming comment_summary instead of calling a tool. What should be fixed first?
input_examples to each comment tool’s definitiontoolstool_choice to force post_summary_comment on every review requestinput_examples shows valid inputs for one tool rather than the choice between tools, and forcing one tool removes the decision the examples were meant to teach.After adding three demonstrations with short justifications, a team reruns the review on the same three code changes and sees every expected decision reproduced. Before shipping, what evidence would show the examples taught a transferable judgment?
A team wants its refund agent to verify account ownership before every refund. It adds examples in which the agent always calls verify_owner before issue_refund, and in testing the agent occasionally skips the check. What is the problem with this approach?
References
- Anthropic, Prompting best practices
- Anthropic, Define tools
- Anthropic, Tool use with Claude
- Anthropic, Claude Certified Architect – Foundations Exam Guide