Structured outputs: how to make LLMs dependable components of real systems

What structured outputs are

You supply a JSON schema, and the provider constrains generation so the response must match it. OpenAI introduced Structured Outputs in August 2024, available through strict function definitions and a JSON schema response format, and reported that its model at the time achieved 100% schema adherence in its own evaluations¹. The approach restricts which tokens the model may produce at each step to those consistent with the schema, building on techniques from open-source constrained generation tools².

Anthropic's documentation describes two related features: JSON outputs that shape the response, and strict tool use that enforces schema compliance on tool inputs through grammar-constrained sampling³⁴. Both providers document limits on which JSON Schema features are supported, and output can still be incomplete if generation stops early, for example at a token limit¹³.

The reasoning trade-off

Constraining format has a cost. In "Let Me Speak Freely?", presented at EMNLP 2024, researchers compared constrained decoding, format instructions in the prompt, and generating free text first then converting it. They found that strict format restrictions such as JSON mode were associated with a significant decline in reasoning performance, with stricter constraints generally doing more harm. On classification tasks, though, strict formats could help by reducing answer selection errors⁵.

The practical lesson is to separate thinking from formatting:

• For extraction and classification, strict schemas are usually a clear win.
• For tasks that need reasoning, give the model room to reason first, either in a free-text field within the schema placed before the answer fields, or in a separate step, then produce the structured result. The paper also found that simple corrective steps, such as reformatting outputs that fail to parse, improve reliability⁵.
• Measure both ways on your own evaluation set before standardising.

Designing schemas that help the model

1. Keep schemas small and flat where possible. Deeply nested, highly optional schemas are harder for models and may hit provider complexity limits.
2. Use enums for categories instead of free strings, so downstream systems never see an unexpected label.
3. Make uncertainty representable. Include an explicit "unknown" or "not found" option and a place for a short reason, so the model isn't forced to invent a value to satisfy a required field.
4. Describe fields clearly. Field descriptions are part of the prompt; vague names produce vague values.
5. Order fields deliberately. Put evidence or reasoning fields before conclusions, so the model generates support before the answer.
6. Version schemas like any interface, with the contract discipline in data contracts.

Validate the content, not just the shape

Once format failures disappear, the remaining failures are about meaning. The checks I put after every structured call:

• Business rules in code: totals add up, dates are in range, referenced IDs exist, a refund doesn't exceed the order value.
• Cross-checks against source: extracted values that should appear in the input document actually do.
• Confidence routing: low-confidence or "unknown" results go to a person instead of straight into the system of record.
• Evaluation on real cases, field by field, as in evaluation sets that predict production. Report accuracy per field, not just "valid JSON rate".

Structured outputs and agents

For agents, strict tool definitions mean every tool call arrives with well-formed arguments, which removes a whole category of runtime errors. It doesn't make those calls safe. Arguments still need authorisation and policy checks outside the model, and the session-level containment described in prompt injection defence and MCP tool annotations. A schema-valid instruction to transfer money to the wrong account is still the wrong instruction.

A note on portability

Providers implement structured outputs differently, with different parameters and supported schema subsets. If you use several models, as in model routing, keep one canonical schema in your codebase and let a gateway translate it per provider, then test each route. Self-hosted models can get similar behaviour from constrained decoding in the serving layer, covered in LLM inference serving.

How I can help

I design LLM integrations that downstream systems can trust, from schemas and validation to evaluation and agent controls. See my AI architecture work, or analyse your challenge and bring the result to a call.