Emrehan Görgeç
03 / Structured outputs

Structured outputs

Make the handoff explicit

In a chain, each step passes its result to the next one. If that result is free text, the next step has to guess what it means.

Structured output means the model returns data in a shape you defined in advance, usually JSON with named fields.

1. Agree on a shape

Before writing the prompt, decide what the step must return: the fields, their types, and which ones are required.

SAME MESSAGE, TWO OUTPUTS
A support message: “My order is a week late. I want my money back.”
Free text

The customer seems unhappy about a late delivery and probably wants a refund.

Readable for a person. The next step must interpret it.
Structured
{
  "intent": "refund",
  "reason": "late_delivery",
  "urgency": "high"
}
Code can read it directly and check every field.
The content is the same. Only the structured version can be checked automatically.

2. Validate before you pass it on

Parse the output and check it against the schema. A missing field or an unexpected value should stop the step, not travel silently to the next one.

Many model APIs can constrain the output to a JSON schema. That removes most formatting errors, but not wrong values. A well formed answer can still be incorrect.

3. Decide what happens on failure

Retry once and include the validation error, fall back to a simpler path, or stop and report the problem. Choose the rule before you need it.

4. Keep the schema small

Every field is one more thing the model has to get right. Ask only for what the next step actually uses.

Use a fixed list of values for choices, such as intent: refund, question, or complaint. It is easier to validate than open text.

When is it useful?

Whenever code, not a person, reads the result: chains, routing, tool calls, or writing to a database. If a person reads the answer directly, plain text is often better.