The Output Feeds a Program, Not a Person: Machine-Readable LLM Output

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

▶ Watch on YouTube & subscribe to The Stack Underflow

You built an extraction pipeline. Claude reads an invoice, pulls out the vendor, the amount, the due date, and hands the result to a downstream service that writes a row to a database. Nobody ever looks at that output with their eyes — no human reads it, skims it, or forgives it for being slightly off. A function call reads it, or it doesn’t parse and the pipeline throws. That distinction — is a person reading this, or is a program reading this — is the single design fork that decides whether your output format is a convenience or a liability. It’s also the last question in the Domain 4 practice set on Prompt Engineering & Structured Output, and it’s the one that ties the other nine together.

The one-sentence version: When the consumer of an LLM’s output is code, the output must be structured (a tool call or a JSON-schema-validated object) — because a program needs a parseable contract, and free text, however well-written, is not one.

The question

The output feeds a downstream program, not a person. Should you ask for free text or structured output?

• A) Free text is fine
• B) Structured (tool / JSON schema) so the program can parse it reliably
• C) Markdown
• D) Whatever the model prefers

Pause here and pick an answer before you keep reading.

The answer

The correct option is B. When the thing consuming the model’s output is a program — a service, a script, a downstream API call, a database write — that output needs to be structured: a tool call with a defined input_schema, or a JSON object validated against a schema. Not prose that happens to contain the right words somewhere in it.

Here’s the mechanism, matching the beat-sheet from the practice set this question comes from:

CONSUMER = PROGRAM                     CONSUMER = PROGRAM
(free text)                            (structured output)
──────────────────                     ──────────────────

Claude:                                Claude:
"The vendor is Acme Corp               tool_call: extract_invoice
and the total comes to                 input: {
$1,204.50, due on the                    "vendor": "Acme Corp",
15th of next month."                     "amount": 1204.50,
        │                                 "due_date": "2026-08-15"
        ▼                               }
YOUR CODE:                                     │
  regex.match(/\$([\d,]+\.\d{2})/)             ▼
  regex.match(/vendor is (\w+...)/)     YOUR CODE:
  date_parser("15th of next month")      json.loads(input)  →  done
        │                               validate(schema)   →  done
        ▼
  works today... until the
  model rephrases the sentence
  next week and every regex
  silently breaks

The rule the episode hangs this on: a machine needs a contract, not prose. A person reading “$1,204.50, due on the 15th of next month” fills in the gaps effortlessly — they know what a due date is, they tolerate a slightly odd phrasing, they’d notice if the amount looked wrong. A program does none of that. It has no judgment to apply; it has a parser, and a parser either matches the expected shape or it doesn’t. Free text asks the consuming code to guess the shape of something that was never guaranteed to have a shape at all.

Structured output — forcing the model through a tool call or a schema-validated JSON object — removes the guessing. The model is required to emit vendor, amount, and due_date as named fields with declared types, in the same place, every single time. Your code doesn’t parse a sentence; it reads a key. That’s not a stylistic preference, it’s the difference between an interface and a hope.

Why the other options fail

• A) Free text is fine. This is the option that works in the demo and breaks in production. Free text has no guaranteed shape — the same fact can be phrased a dozen ways, and every phrasing that isn’t the one your regex expects is a silent failure or a crash three services downstream. It also has no type information: is “the 15th of next month” a date? A string? Your code has to decide, and it will decide wrong on the case you didn’t test.
• C) Markdown. Markdown is a formatting language for humans — headings, bullet lists, bold text. It makes prose easier to read, which is exactly the wrong axis of improvement here, because nothing is reading it. A program parsing Markdown is still parsing text with slightly more punctuation in it; you’ve made the regex marginally more annoying to write, not more reliable.
• D) Whatever the model prefers. This isn’t a design decision at all — it’s the absence of one. Handing the format choice to the model means the shape of your pipeline’s input can drift between calls, between model versions, or between two runs of the exact same prompt at a nonzero temperature. A downstream program cannot be built against a format that isn’t fixed by you.

The concept behind it

Zoom out past invoices and you get the general principle Domain 4 is really testing: the audience determines the format, and “audience” has exactly two possible values — a person or a program — with very different requirements.

That third row is worth sitting with, because it’s the case people get wrong even after they’ve internalized “programs need structure.” If your pipeline extracts data and needs to show a friendly confirmation message to a user, the answer isn’t to pick one format — it’s to put a human-readable field inside the structured object:

{
  "vendor": "Acme Corp",
  "amount": 1204.50,
  "due_date": "2026-08-15",
  "display_text": "Invoice from Acme Corp — $1,204.50 due Aug 15"
}

The program reads vendor, amount, and due_date directly. The UI renders display_text. One schema call served both audiences, because the schema itself made room for the human-facing string as just another typed field — it didn’t ask the program to parse prose to get it.

This is also why “structured output” as a Domain 4 topic isn’t really about JSON syntax — it’s about forcing the shape rather than requesting it. Anthropic’s tool-use mechanism is the enforcement layer: you define an input_schema for a tool, set tool_choice to force that tool, and the model’s response is constrained to match. Ask nicely in the prompt (“please respond only in JSON”) and you get compliance most of the time, which is a much worse guarantee than “the shape is structurally forced.” The mechanism behind forcing a schema is covered in more depth in How Do You Guarantee Valid JSON?, and the four tool_choice modes that control when to force versus let the model decide are covered in Force the Tool, or Let It Decide?

Forcing the shape only gets you halfway, though — a forced schema guarantees the keys exist, not that the values are the right type. "amount": "1204.50" (a string) satisfies a naive schema just as easily as "amount": 1204.50 (a number), and a downstream arithmetic operation will fail on the former in a way that’s much harder to trace than a missing field. That failure mode, and how to close it with tight schema typing plus validation, is exactly the subject of A Number Comes Back as a String.

One more wrinkle worth knowing before it bites you: structured output and reasoning aren’t in tension, even though it can look that way at first. You can let the model think through a problem step by step and still hand a program a clean structured result — the thinking happens first, in a scratchpad or a chain-of-thought pass, and only the final answer gets extracted into the schema. Keep the Reasoning, Hide It From Output walks through that two-phase pattern in detail.

FAQ

Is Markdown ever the right choice for an LLM’s output? Yes — when a person is the consumer. A chat reply, a generated report, a summary email: all of these benefit from Markdown’s readability. The test isn’t “is Markdown good or bad,” it’s “who reads this next.” The moment the answer is “a parser,” Markdown stops helping and starts adding noise a regex has to strip out.

What if I need both a program AND a person to see the result? Use one structured object with a human-readable field inside it (see the display_text example above) rather than choosing one format and making the other consumer work around it. The schema is still the source of truth; the human-facing string is just one more typed field in it.

Doesn’t forcing structured output make responses feel more robotic? Not if you design the schema well — the model can still write natural, well-phrased text inside a string field of a structured object. Forcing structure constrains the shape of the response, not the quality of the prose within any given field. You lose nothing on the writing; you gain a contract your code can trust.

Does this apply to multi-agent systems too, where one agent’s output feeds another agent? Yes, and arguably more so — an agent-to-agent handoff is a program-to-program consumer relationship even though both ends happen to be LLMs. If Agent A’s output is Agent B’s input, that boundary needs the same structured contract as any other program consumer, for the same reason: Agent B can’t apply human judgment to parse a stray sentence any better than your database-write code could.

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 10 of 10 in the Domain 4 (Prompt Engineering & Structured Output, ~20% of the exam) practice set — as of mid-2026 the CCA-F runs on Pearson VUE, costs $125, allows retakes, and the exam itself is 60 questions in 120 minutes with a passing scaled score of 720/1000 across five domains; verify these logistics on Anthropic’s official pages before you register. For the full map of all five domains, start with the Claude Certified Architect (CCA) Exam Guide.

Staying inside Domain 4, this question is the closing argument for everything else in the set: How Do You Guarantee Valid JSON? covers the forcing mechanism, A Number Comes Back as a String covers getting the types right once you’re forcing a shape, and Force the Tool, or Let It Decide? covers when to force versus when to leave the model in auto. If you’re still building intuition for how a tool’s schema gets wired to Claude at all, MCP Explained on One Diagram is the place to start. Browse all tutorials for the rest of the series.