AnthropicClaude Certified Architect – Professional2026-102.3 Apply prompt engineering techniques (zero-shot, few-shot, chain-of-thought)
Choose reasoning without exposing private deliberation
Completed by the knowledge check
Learning objective
Choose among chain-of-thought prompting, explicit task decomposition, and model-native thinking, without relying on raw reasoning text as an interface or audit trail.
Core idea
For an architect designing a multistep Claude decision, distinguish how the model works from what the application can verify. Prompted deliberation, explicit decomposition, and native thinking can all help with intermediate work. Only decomposition gives the application separate intermediate results it can inspect and condition execution on.
The application should consume a decision and its supporting facts. Its audit record should identify the inputs, policy version, result, and validation that justified an action. Neither a verbose explanation nor a visible thinking summary proves that every required check happened. Choose the technique around the control you need, then evaluate the resulting decisions.
How it works
Use prompt guidance for cognitive work
Chain-of-thought prompting asks Claude to consider intermediate steps before answering. Anthropic describes manual prompting as a fallback when thinking is off: encourage consideration before the answer and separate the final answer with <answer> tags. Those tags delimit generated text; they do not expose verified private reasoning or enforce a pipeline.
Manual CoT applies only when the chosen model is running with thinking off. On Claude Fable 5.1, Claude Fable 5, Claude Opus 5.5, Claude Opus 5, and Claude Sonnet 5.5, Anthropic recommends native thinking instead, lowering output_config.effort when cost or latency matters; prompting for written reasoning can be declined.
For a task involving interacting policy clauses, prompt guidance can name the factors that matter: identify applicable clauses, account for exceptions, and return the selected outcome. Do not demand a transcript of each thought. On models with native thinking, Anthropic favors general guidance over a prescribed thought sequence. An exact procedure is justified when it describes required task outputs or business steps, not when it dictates hidden mental narration.
A short explanation remains useful. Ask for the clause and source fact supporting the decision, or a concise explanation of the answer. That is a result the reviewer can check against supplied material. It is different from asking the model to reproduce internal reasoning in <thinking> tags or a JSON trace property.
Decompose when intermediate results require control
Anthropic describes explicit prompt chaining as sequential API calls, useful when you must inspect intermediate outputs or enforce a pipeline structure. Its self-correction pattern separates drafting, review against criteria, and refinement. Each call gives the application a place to evaluate, log, or branch.
For a financial-services eligibility workflow, separate extraction of supported facts from policy application when staff must approve disputed facts before a decision proceeds. The first call returns fact values with source references. The application validates them and holds conflicts for review. Only accepted facts enter the decision call. These are business artifacts, not fragments of chain-of-thought.
Between the two calls, the application holds conflicts for staff review, and only accepted facts enter the decision call.
A single request saying “first extract, then validate, then decide” cannot give an external reviewer a pause between stages. Explicit decomposition costs additional calls and repeated context, and an extraction mistake can still propagate if the application accepts it. Choose it when a boundary has operational value: independent grading, selective retries, human review, or a prerequisite that must be enforced before the next stage. See 1.5.4 for acceptance of recombined results.
Use native thinking for internal multistep work
Model-native thinking separates internal work from the canonical answer using content blocks with type: "thinking" and type: "text". On an eligible Claude API model, thinking: {"type": "adaptive"} lets the model allocate thinking according to the request. output_config.effort steers the amount of work; see 2.1.3 for choosing supported controls and 2.3.4 for measuring their economic effect.
Configuration is model-specific. Claude Opus 5.5 uses adaptive thinking by default and rejects thinking.type: "disabled" and manual budget_tokens. Claude Sonnet 4.6 accepts adaptive thinking; its manual extended-thinking configuration is deprecated. These examples illustrate why an architect must not carry one model’s thinking settings to another unchanged. This lesson’s field names refer to the Claude API; verify the deployment platform and model before using them elsewhere.
Thinking consumes output tokens and shares max_tokens with the answer. Reducing the allowed output can cut off the final result rather than produce a cheaper valid decision. Native thinking is appropriate when internal exploration improves a complete result and there is no requirement for the application to approve each intermediate step.
Keep the application interface separate
The visible thinking field contains a summary, never the raw chain of thought. display: "summarized" requests that summary, while display: "omitted" returns an empty thinking field. Neither setting changes the billed thinking work. Treat summaries as diagnostic material rather than a complete account of the process.
For a supported Claude API model, JSON outputs use output_config.format with type: "json_schema". Define result fields such as the decision, supporting clause identifiers, source references, and a brief explanation. Structured outputs are generally available on supported models, but platform availability differs: the structured-output page excludes Claude in Amazon Bedrock while listing particular models on the legacy Bedrock integration. A schema-shaped answer is still subject to semantic checks against the policy and sources.
Read the response by block type, rather than assuming the first block is the final answer. Check stop_reason before accepting it. Structured output can be incomplete on stop_reason: "max_tokens"; the documented remedy is a higher max_tokens for a complete response, within the application’s retry budget. A stop_reason: "refusal" can also override the schema.
On the models the refusals page lists, stop_details.category: "reasoning_extraction" identifies requests to expose internal deliberation. Anthropic recommends removing that request, asking for a short explanation, and using a thinking summary when needed. It provides no recommended fallback for this category, and a refusal in this category is billed even when it arrives before any output; see 2.3.4 for measuring attempt costs. Check instructions, skills, and tool descriptions for the demand rather than blindly retrying it.
Key distinctions and trade-offs
The deciding boundaries are:
| Technique | What it supplies | What it does not establish |
|---|---|---|
| Prompted deliberation | Guidance about factors to consider | Enforced intermediate acceptance |
| Explicit decomposition | Separate results and application-controlled transitions | Correctness without validating each result |
| Native thinking | Internal exploration before the final answer | A complete, readable audit transcript |
These techniques can coexist. A decomposition stage can use native thinking, and its prompt can name the relevant criteria. Combining them is justified by measured benefit or an operational requirement, not by the assumption that three mechanisms must be safer than one.
Architecture / decision scenario
A financial-services team produces draft eligibility recommendations. Staff must approve conflicting income facts before policy application, and the product allows a 12-second p95 response time. Illustrative tests give a single native-thinking call 96% decision agreement at 4 seconds, while an extraction-review-decision pipeline reaches 97% at 9 seconds.
The tempting proposal asks one call to expose every reasoning step for auditors and chooses it because it is faster. The architect rejects that interface: a transcript is neither a staff approval nor a verified fact record. The explicit pipeline fits the latency target and provides the required review boundary. Native thinking within the final stage helps evaluate interacting exceptions without exposing deliberation.
The prompt names the applicable factors; output_config.format defines the recommendation and supporting references, with no private-reasoning field. The application validates extracted sources, records staff acceptance, and rejects incomplete or refused final responses. The policy owner owns the approval requirement; the architect owns stage orchestration and the result interface. The audit record contains checked facts and the accepted decision, rather than a thinking summary presented as proof.
Common exam traps
- Treating a request for ordered thoughts as an enforced sequence of business operations.
- Parsing
<thinking>text as a stable API or preserving it as the audit record. - Assuming a thinking summary contains all reasoning or that omitted display avoids its cost.
- Using manual
budget_tokenson a model that rejects it. - Retrying a
reasoning_extractionrefusal without removing the extraction request.
Where the exam guide differs
The exam guide names “chain-of-thought” among prompting techniques. Read that as a technique-selection objective, not permission to require private reasoning in the answer. On Claude Fable 5.1, Claude Fable 5, Claude Opus 5.5, Claude Opus 5, and Claude Sonnet 5.5, interpret that technique as native thinking rather than a request for written deliberation. Anthropic warns that output requests for internal reasoning can trigger reasoning_extraction refusals. In an exam item, distinguish encouraging careful consideration from demanding a raw transcript. Select explicit decomposition when intermediate acceptance must be enforced, and an inspectable final result for application and audit use.
What to remember
Use prompting to guide consideration, decomposition to control intermediate results, and native thinking for internal multistep work. Keep the final decision, source support, and operational acceptance record independent of private reasoning. Visible thinking is diagnostic summary material, not an interface or proof of completed checks.
Knowledge check
A bank’s eligibility workflow on the Claude API must let staff approve any disputed income fact before policy is applied. The 12-second p95 target leaves room for several calls. Which design enforces that approval?
On Claude Opus 5.5, an audit team adds a trace property to a JSON output schema and asks Claude to fill it with its full step-by-step reasoning. Requests now end with stop_reason: "refusal" and stop_details.category: "reasoning_extraction". What should the architect change?
trace with a short explanation of the evidence behind the decisionreasoning_extraction refusal comes from asking for internal reasoning in the output, wherever that request sits — a schema field, the system prompt, a skill or a tool description. The remedy is to change the prompt: ask for a short explanation or the evidence behind the result, and read display: "summarized" thinking when diagnosis needs it. This category has no recommended fallback model, and an unchanged retry repeats the cause.An application on the Claude API uses output_config.format with a JSON schema for eligibility recommendations, at the effort level its evaluation approved. One response arrives with stop_reason: "max_tokens", and the retry budget allows another attempt. What should the application do?
output_config.effortmax_tokens valuestop_reason: "max_tokens" the JSON may be incomplete and fail to match the schema. The documented remedy is a higher max_tokens . An identical retry retains the cap that cut this response short, and lowering effort would change a setting the evaluation fixed.A team migrates a classification prompt to Claude Opus 5.5. The old prompt asks Claude to reason step by step inside <thinking> tags before answering in <answer> tags, and latency must stay close to its current level. What should the migrated configuration do?
output_config.effort if needed<thinking> tags and parse their contents as the official reasoning recordbudget_tokens valuebudget_tokens is rejected, so the manual chain-of-thought fallback no longer applies. Anthropic recommends relying on native thinking, at a lower effort level when cost or latency matters; a prompt that asks for written reasoning in <thinking> tags may be declined.References
- Anthropic, Prompting best practices
- Anthropic, Thinking
- Anthropic, Structured outputs
- Anthropic, Refusals and fallback
- Anthropic, Claude Certified Architect – Professional Exam Guide