Why do AI apps need structured output?

AI apps need structured output because software cannot read a friendly paragraph reliably; it needs the same fields, with the same names and types, every time. One extra sentence or a missing field can break the next step of your app.

Picture a fictional 12-person logistics start-up, Parcelwise. Its developer, Sana, is building a tool that reads customer emails and fills a delivery change form: order reference, requested date, new address, and whether the customer is asking for a refund. A typical email reads: 'Hi, order PW-88213, I won't be in on Thurs, can you bring it Sat instead? Or leave with no. 14. If not just cancel and refund pls.' Her first version asks the model to 'reply in JSON'. Most replies parse, but some begin with 'Sure, here is the JSON', some name the field 'date' instead of 'requested_date', and one returns the date as 'Saturday'.

What is a JSON schema and why does it help?

A JSON schema is a formal description of the data you expect: which fields exist, which are required, what type each one is and which values are allowed. Giving the model a schema turns 'please reply in JSON' into a contract your code can check.

For Sana, the schema says: order_reference is a required string; requested_date is a required string in date format, or null if no date was given; new_address is a string or null; refund_requested is a required boolean; and no other fields are allowed. That last rule stops the model adding commentary fields.

How do model APIs support structured output?

Major model APIs let you pass a JSON schema with the request, and the model's output is constrained to match it.

OpenAI

OpenAI's Structured Outputs feature constrains responses to a supplied JSON schema when strict mode is on. Its documentation distinguishes this from the older JSON mode, which only ensures valid JSON, not adherence to your schema, and recommends Structured Outputs where available.

Anthropic

Claude's API offers JSON outputs that match a schema you provide, plus a strict option on tool definitions so tool inputs are validated against the tool's schema. Its documentation lists which schema features are supported and which return an error.

Google

The Gemini API accepts a JSON schema for responses and supports a defined subset of schema keywords. Its documentation says that while output is syntactically correct JSON, you should still validate the values in your application.

Why do you still need validation and retries?

You still need validation because a schema controls the shape of the data, not whether the values are right. A perfectly formed reply can still carry the wrong date, an invented order reference or a refund flag the customer never asked for.

Validate in two layers. First, check the shape with a schema library, such as Pydantic in Python or Zod in JavaScript, which the OpenAI, Anthropic and Google documentation all show in examples. Second, check business rules: does the order reference match the pattern and exist in the system, is the date in the future and a delivery day, and is the address in a delivery area? Also handle the cases the providers document: a refusal, which may not follow your schema, and a reply cut off by the maximum token limit, which leaves incomplete JSON.

Retry carefully. If a check fails, send one retry that includes the specific error, such as 'requested_date must be a date; the email says Saturday, and the order date is 14 October'. Cap retries at one or two, then route the email to a person.

What does weak and robust structured output look like?

Weak version: the prompt says 'Extract the details and reply in JSON.' The app reads whatever comes back. For the email above it receives fields called order and date, a date value of 'Saturday', and a refund value of true, because the model treated 'if not just cancel' as a firm request. The form fills wrongly and the customer gets a refund they did not want.

Robust version: the request includes Sana's schema with strict mode, and the prompt explains each field, including 'refund_requested is true only if the customer asks for a refund unconditionally'. The model returns order_reference PW-88213, requested_date as the next Saturday's date, new_address null, refund_requested false and conditional_request, a field Sana added to the schema for exactly this case, set to 'refund if Saturday or neighbour is not possible'. Validation confirms the order exists and Saturday is a delivery day. Because the email contains a conditional request, the rules send it to a person for the final call.

What are the common structured output mistakes?

The most common mistake is trusting valid JSON as correct data. Others: relying on prompt instructions alone when the API offers schema enforcement, using vague field names without descriptions, forcing a value when the honest answer is null, ignoring refusals and truncated replies, and retrying without telling the model what was wrong.

Where does structured output fit in the Tosheo.ai catalogue?

Structured output is a Code lesson in the build AI apps course, in the Building AI Apps category. The full hands-on version with code, where you define a schema, call an API, validate replies and add a retry, is in the Code track after sign-up, with rubric feedback on each step.

Sources and scope

OpenAI API documentation, Structured Outputs guide, JSON mode comparison and refusals (checked 19 October 2026) ↗

Anthropic Claude documentation, structured outputs and strict tool use (checked 19 October 2026) ↗

Google Gemini API documentation, structured output and validation advice (checked 19 October 2026) ↗