Structured outputs are not enough for reliable agents

What structured outputs actually guarantee

Structured output support in modern LLM APIs is genuinely useful. Constrained decoding means your agent will return valid JSON matching your schema. You won't spend debugging time parsing malformed responses or handling the cases where the model decided to wrap your JSON in a markdown code block. For integration reliability, that matters.

But structured outputs answer the question "does this response have the right shape" and nothing else. They say nothing about whether the content inside the structure is correct, relevant, complete, or honest about what the model doesn't know.

The difference matters as soon as you think about what actually causes user complaints. Users don't complain that your agent returned a non-JSON response. They complain that the summary was missing the key finding, the plan had a step that contradicts the stated constraints, or the extracted data contained a field value that wasn't in the original document. All of those failures pass structured output validation perfectly.

The schema tells you nothing about the field values

Consider a document extraction agent. You've defined a schema: { "title": "string", "summary": "string", "key_facts": ["string"], "risk_level": "low|medium|high" }. Constrained decoding means the model always returns something that matches this type signature.

Now consider the failure modes that can occur inside valid outputs:

• The summary is three sentences that are all tangentially true but miss the core finding entirely.
• The key_facts list contains a fact that isn't in the document but sounds plausible.
• The risk_level is "low" even though the document discusses a regulatory deadline that passed six months ago.
• The title is copied verbatim from the first sentence of the document, not derived from its actual subject matter.

Every one of these responses is a perfectly valid structured output. The schema is satisfied. Your deserialization code won't throw. Your downstream pipeline will process the data without error. And the user relying on that extraction to inform a decision will get wrong information.

Where structured outputs help and where they don't

To be clear about what we're not saying: structured outputs are worth using. Eliminating a class of parsing failures is a real reliability improvement. The point isn't that they're harmful, it's that teams routinely treat them as a reliability solution rather than one layer of a multi-layer approach.

Structured outputs are effective for:

• Preventing integration failures from malformed responses
• Ensuring enumerated fields use valid values from a defined set
• Guaranteeing required fields are always present

Structured outputs do nothing for:

• Whether field values are factually accurate
• Whether the output reflects the actual content of the input
• Whether the agent completed the task it was given, vs. a related but different task
• Whether the model's confidence is appropriate (a high-confidence hallucination is still a hallucination)

The second list is where most real LLM quality failures live. Schema validation can't touch them.

Adding the content layer: rubric-based evals

The check that structured outputs can't do is evaluating the content against the expected behavior for your specific use case. That's what rubric-based evals are for. A rubric articulates what a good output looks like in terms a scorer can apply: "the summary accurately reflects the main conclusion of the input document" is a rubric. "The key_facts list contains no claims not present in the input document" is a rubric.

Rubric-based evals don't replace structured outputs. They sit on top of them. The schema check is a precondition; the rubric check is the real quality gate. Running both means you catch shape failures and content failures, which together cover almost all the ways an agent output can be wrong.

In Orq, you write rubrics once and they're applied to every trace automatically. So every run of your extraction agent gets scored on grounding, not just when you remember to check. That's the difference between knowing your agent is reliable today versus knowing it's been reliable across the last 200 runs.

Downstream failures that schema validation misses

There's another category of failure that structured outputs don't address: side effects in downstream systems. An agent that makes tool calls might return a valid response object while having made a call with incorrect parameters. The response schema can be satisfied even if the tool call targeted the wrong resource or used a parameter value the tool will silently accept but handle incorrectly.

We've seen this in our own instrumentation work. An agent with a calendar booking tool returns a correctly-structured confirmation object. The structured output is valid. What the trace reveals is that the tool call used a time zone offset that was two hours off because the model interpreted ambiguous input differently than the user intended. The schema validation didn't have a field for "is the time zone correct."

Tracing the full agent run, including tool call parameters and responses, is the layer that catches this. Structured output validation happens after the agent has already taken its actions. By then, the side effect is done.

A practical layering for reliable agent outputs

A workable reliability stack for most LLM agents looks like this, from the outside in:

1. Structured output validation: Schema correct, required fields present, enum values valid. Prevents parsing failures. Set up once, runs passively.
2. Rubric-based evals: Grounding, task completion, output quality for your specific domain. Runs on every trace. Needs iteration to calibrate thresholds.
3. Tool call tracing: If your agent makes external calls, capture the parameters and responses. Evals on tool call behavior are separate from evals on the final output.
4. Release gates: Eval scores feed a CI gate that blocks a deploy when scores regress. This is the automation that converts "we have eval data" into "we have a quality control."

The first layer is what most teams have. The remaining three are what transforms a structured-output-validated agent into one you can actually deploy with confidence. Structured outputs are a prerequisite, not a destination.

Starting the right conversation internally

When teams raise quality concerns about an LLM agent, one of the most common responses is "but we're using structured outputs." The schema validation is visible and verifiable in a way that content quality isn't, so it ends conversations that should continue.

The internal conversation worth having is: what does a bad response look like for our specific feature, and would our current eval setup catch it? If the answer is "we'd know from user complaints," the reliability work is incomplete. Structured outputs are the beginning of that work, not the end.

For teams building on LangChain or using the OpenAI or Anthropic SDKs directly, adding eval-level content checking to your pipeline is an extension of what you've already built, not a replacement for it. Schema validation stays in place as the first gate. Rubric-based evals run on top as the content gate. Both are necessary. Only together are they sufficient.