Learn · Explained

What is structured output, and why does an AI agent need it?

Published 31 October 2026

Short answer. Structured output means the AI answers in a fixed format with named fields, such as supplier, invoice date and total, instead of in free text. The format is usually JSON, and a schema describes which fields the answer must have. Because the fields are the same every time, a system can read the answer, and code can check it before anything happens. A correct format does not make the content correct, so the values still need checks and a source.

This guide explains why a chatty answer cannot go into a system, what a schema looks like, how the format is enforced, and how to check what is in the fields.

A chatty answer cannot go into a system

Ask an AI to read an invoice, and it may answer: “This is an invoice from Nordlys Kontor dated 3 October, and the total comes to about 1,250 kroner including VAT.” A person can read that. An accounting system cannot, because it needs the date in one field and the amount in another.

Ask again, and the wording changes: “Total: DKK 1,250.00 (incl. 25% VAT).” Each answer may be right, but nothing downstream can rely on where the date or the amount will be.

The invoice itself is unstructured data: the knowledge sits in text and layout. A system needs structured data: information in fixed fields and columns. Structured output is how an AI turns the one into the other.

A schema says which fields the answer must have

A schema is a description of the answer: which fields it has, what type each field is, which fields are required, and which values are allowed. The usual format is JSON, a plain text format for data with named fields and values that almost every system can read.

A schema for a supplier invoice could say:

Field	Type	Required	Allowed values
supplier	text	yes
invoice_number	text	yes
invoice_date	date	yes	a valid date
currency	text	yes	DKK, EUR, SEK, USD
lines	list	yes	at least one line
each line: description, quantity, unit_price, vat_rate	text, number, number, number	yes	vat_rate 0 or 25
total	number	yes

The AI’s answer then fills in the fields (invented example):

{
  "supplier": "Nordlys Kontor ApS",
  "invoice_number": "10482",
  "invoice_date": "2026-10-03",
  "currency": "DKK",
  "lines": [
    { "description": "Printer paper, A4", "quantity": 10, "unit_price": 100.00, "vat_rate": 25 }
  ],
  "total": 1250.00
}

Every invoice comes back in the same shape, whatever its layout was.

The format is enforced in three places

In the request. The instructions to the AI describe the fields and give the schema.
At the AI provider. OpenAI, Anthropic and Google’s Gemini API each offer a setting where you supply a JSON schema and the model’s answer is made to follow it. Without that setting, the model can still leave out a field or break the format.
In your own code. Before the answer is used, code checks it against the schema again: every required field is there, every value has the right type, every value is one of the allowed ones. An answer that fails is stopped, never passed on.

The third step matters even with the provider’s setting. The providers document cases where the answer does not match the schema: when the model refuses a request, and when the answer is cut off because it reached its length limit. Anthropic also notes that an allowed value can come back with different capital letters.

A correct format is not a correct answer

A schema decides the shape of the answer, not its truth. The total field can hold the wrong total. The supplier field can hold the name of the customer. A date can be read from the wrong place on the page.

The providers say this themselves. OpenAI’s guide states that structured outputs can still contain mistakes, and warns that a model which always follows a schema can make up values when the document does not fit the task. Google’s guide advises you to validate the values in your own application, because a well-formed answer can still be wrong in meaning.

So structured output makes the answer checkable. The checks make it trustworthy.

Check the content before anything happens

Because every value sits in a named field, code can check it. A starting list:

The arithmetic adds up. The lines add up to the total, and the VAT matches the rate.
The values are allowed. The VAT rate is a valid rate, the currency is one you use, the date is not in the future.
The reference data matches. The supplier is in the supplier list, and the account is on the list the job may use.
Every value points to its source. Each field records the page and the place it was read from, so anyone can check it against the document. This is grounding: an answer that shows where it was found.
A failed check stops the item. The document is flagged with the reason, and a person looks at it. The rest go on.

Each check is a named rule, so a failure can be explained, and you can change the rules without changing the AI. The invoice reader case shows these checks on supplier invoices.

Where structured output sits in an agent

An AI agent hands something on at every step. Wherever the receiver is a system or the next step, the handover should be structured.

Step	What is structured
Reading a document	The fields read from the invoice, receipt or order
Using a tool	The fields the agent fills in to ask a system for something, called function calling
Proposing an entry	The account, amount, date, VAT code and the document it is based on
Writing to the logbook	The source, the rule applied, the check results and who approved it

Structured output and checks catch wrong data. Guardrails stop forbidden actions, such as a payment, whatever the data says. Who approves each step is still decided by the three sign-off zones: “acts alone”, “asks first”, or “the operator signs off”. The operator is the person in your company who checks and signs off the agent’s work. When may an AI agent act on its own?

How to start with one document

Pick one document that someone types into a system by hand, such as supplier invoices.
List the fields the receiving system needs, with their type and the values it accepts.
Write the schema from that list, and supply it to the AI provider’s structured output setting.
Write the checks as named rules: the arithmetic, the allowed values, the reference data, the source.
Test on known examples. Run the AI on documents where you already know the right answer, and compare field by field. These repeatable tests are called evals; run them again after every change of model, schema or rules.
Decide what happens on a failure: who sees the flagged document, and where it waits.

When a new kind of document comes along, it gets its own schema and its own checks. The rest of the setup stays the same.