Keep the Reasoning, Hide It From Output: Chain of Thought With Clean JSON

July 24, 2026 · Claude Certified Architect (CCA) Prep (part 36)

▶ Watch on YouTube & subscribe to The Stack Underflow

You are building a classifier: feed Claude a support ticket, get back a category, a priority, and a one-line summary as JSON that your queue system consumes directly. The accuracy is mediocre — Claude jumps straight to an answer without working through the ambiguous cases. You know the fix for accuracy is to let it reason first. But the moment you do, your “structured output” turns into three paragraphs of thinking followed by a JSON blob buried at the bottom, and your parser breaks on line one. You need the reasoning’s benefit without the reasoning’s presence in the field your code reads.

The one-sentence version: Let Claude think in a scratchpad or thinking step first, then force the final answer out through a tool call — the reasoning improves the answer, and the tool schema keeps it out of the structured result.

The question

This is CCA practice question 3 of 10 in Domain 4 — Prompt Engineering & Structured Output (20% of the exam).

You want the model’s reasoning to improve the answer, but only the final structured result in output. Best approach?

• A) Forbid reasoning
• B) Let it think first (chain-of-thought / scratchpad), then emit the final answer via a tool
• C) Raise temperature
• D) Two separate models

Pause here and pick before you scroll — the point of this series is reasoning through the mechanism, not recognizing the letter.

The answer

B — let it think first, then emit the final answer via a tool. Reasoning and output are two different jobs with two different destinations, and the trick is separating where each one lands, not choosing one over the other.

The mechanism is a two-stage flow inside a single turn (or a short exchange). Stage one is unconstrained: Claude reasons freely, in prose, working through the ambiguous parts of the problem — this is the chain-of-thought or scratchpad step, and it can be extended thinking, a <scratchpad>-style tag, or just a “think step by step first” instruction. Stage two is constrained: once the reasoning is done, Claude’s final move is a tool call whose input_schema defines exactly the shape your program needs. Your code reads the tool call’s input, not the reasoning text.

STAGE 1 — THINK (unconstrained, free text)
┌─────────────────────────────────────────────┐
│ "This ticket mentions 'down for everyone'    │
│  and 'lost revenue' — that's high urgency    │
│  despite the polite tone. Category is        │
│  outage, not billing, because the payment    │
│  mention is incidental..."                   │
└─────────────────────────────────────────────┘
                    │
                    ▼   reasoning informs the decision,
                        but is never parsed by your code
STAGE 2 — EXTRACT (constrained, via forced tool call)
┌─────────────────────────────────────────────┐
│ tool_call: submit_classification             │
│ input_schema: {                              │
│   category: "outage",                        │
│   priority: "high",                          │
│   summary: "Customer reports full outage"    │
│ }                                             │
└─────────────────────────────────────────────┘
                    │
                    ▼
        YOUR CODE READS ONLY THIS — clean,
        typed, parseable, zero prose leakage

Two implementations of stage one are common on the exam and in production:

Either way, the contract with your downstream system stays identical: the reasoning lives in a place your parser never touches, and the tool call’s input_schema is the only channel your program reads from. This is the same principle behind forcing structured output with tool_choice — you’re not asking the model to format itself correctly, you’re giving it a channel where the format is enforced by the schema, and routing the messy, valuable part of the work somewhere else entirely.

Why the other options fail

• A) Forbid reasoning. This throws away the exact thing that improves accuracy on ambiguous cases. The premise of the question is that reasoning helps — banning it to solve a formatting problem is treating the wrong symptom. You’d trade a parsing headache for a worse answer, which is a bad trade.
• C) Raise temperature. Temperature controls sampling randomness, not whether reasoning appears in your structured output and not how well the model reasons. Raising it makes output less predictable, which is the opposite of what a structured-output pipeline needs. It has nothing to do with separating thought from answer.
• D) Two separate models. This works, technically — one call reasons, a second call (maybe a cheaper model) extracts structure from the first’s output. But it doubles latency and cost for a problem that a single call with a forced tool call already solves cleanly. It’s not wrong so much as it’s solving a one-step problem with two steps and two API bills.

The concept behind it

The generalizable idea is that reasoning and output are different artifacts with different consumers. Reasoning is for the model — it’s scaffolding that improves the quality of the next token predictions. Structured output is for your program — it’s a contract that has to parse, validate, and route without a human or a regex trying to fish the real answer out of a paragraph. Conflating the two channels is the root cause of “the JSON is buried under three paragraphs of explanation” bugs.

Once you see it as two channels, the design question becomes: where does each channel terminate? The reasoning channel terminates in a thinking block, a scratchpad section, or extended-thinking output — somewhere your downstream code has no reason to look. The structured channel terminates in a tool call’s input, validated against a JSON schema. This is the same separation-of-concerns instinct that shows up across all of Domain 4: forcing the shape with tool_choice rather than asking nicely (see guaranteeing valid JSON output), tightening schema types so a number can’t silently arrive as a string (see structured output type validation), and making sure the final payload is something a program can actually consume without a human reading it first.

There’s a cost dimension too: reasoning tokens are not free, and a scratchpad or extended-thinking block adds tokens to every call. For high-accuracy, low-volume use cases (medical triage, legal classification, anything where a wrong category is expensive) that trade is obviously worth it. For high-volume, low-ambiguity extraction (parsing a well-formed invoice for the thousandth time) the reasoning step may add cost without adding accuracy — which is a signal to test with and without it rather than assume chain-of-thought is always the right call.

FAQ

Does the reasoning step slow down the response? Yes — a scratchpad or extended-thinking block adds generation time and tokens before the tool call happens, because the model has to produce that text before it produces the structured answer. For latency-sensitive paths, benchmark whether the accuracy gain from reasoning is worth the added time; for offline or batch workloads (see batch processing for cost-sensitive jobs) the latency cost matters much less.

Can I just ask the model to put reasoning in one JSON field and the answer in another? You can, and it works for some cases, but it couples the two channels into one schema — your parser now has to know to ignore the reasoning field, and it’s easy for a downstream consumer to accidentally read the wrong one. Separating reasoning into its own block (scratchpad, thinking, or a preceding message) rather than a sibling field keeps the tool schema itself minimal and unambiguous.

Does this apply to extended thinking specifically, or just prompted scratchpads? Both are the same pattern at different levels of the stack. A prompted scratchpad is you instructing the model to reason in a tagged section before calling a tool. Extended thinking is Claude’s native mechanism for the same separation — a distinct thinking block outside the final response. Either way, the tool call is still the only place your code reads from.

What if the model puts part of its reasoning inside the tool call arguments anyway? That’s a schema discipline problem, not a reasoning problem — tighten the input_schema so there’s no free-text field wide enough to hold a paragraph of justification. If a summary or notes field is too permissive, the model will use it as overflow space for reasoning it didn’t finish externalizing. Keep structured fields narrow and typed.

Not affiliated with, authorized, or endorsed by Anthropic. “Claude” and “Claude Certified Architect” are trademarks of Anthropic. These are original practice questions for study, not real exam content — verify current exam details on Anthropic’s official pages.

Where this fits in the CCA series

This is question 3 of 10 in the Domain 4 practice set. Start with the CCA Exam Guide for all five domains on one diagram, and if tool calls and schemas are new territory, MCP Explained on One Diagram covers the tool-use mechanics this pattern depends on.

Staying in Domain 4: question 1 covers forcing valid JSON with tool_choice, question 2 covers tightening schema types so extraction doesn’t silently mistype a field, and question 10 covers why a program-facing output should be structured, not prose — the same “reasoning vs. output” separation applies once you’re past this question and into forced tool choice more broadly, covered in tool_choice explained.

As of mid-2026, the CCA-F exam runs on Pearson VUE, costs $125, allows retakes, and is 60 questions in 120 minutes with a pass mark of 720/1000 across five domains — verify current logistics on Anthropic’s official pages before you register.

Browse all tutorials for the full series.