Structured Output or Free Text for Agent Results

Choose by consumer, not by model

The practical split is by consumer: anything a program reads should be schema-constrained; anything a person reads should not. If both need the result, return a small structured envelope with a free-text explanation that no program uses to make decisions.

That boundary matters because a schema turns a parsing problem into a validation problem. A validation failure stops at a named interface. A parsing failure may survive until some downstream branch interprets an unexpected phrase, missing value, or ambiguous answer. The former is a failure you detect; the latter is one you discover downstream.

This follows the same division already present in the Model Context Protocol specification, retrieved August 26, 2026: program-to-program messages have defined structures, while resources and prompts can carry material intended for a model or person. A schema is useful because software can test it, not because structured prose is inherently better prose.

Criterion	Schema-constrained output	Free text	Structured result plus free-text reasoning
Consumer	Program	Person	Both, through separate paths
Failure point	At validation	During later interpretation	At validation for parsed fields
Expressive range	Limited to the contract	Open	Limited decision plus open explanation
Main cost	Open questions lose room for nuance	Software must parse an unstable form	The reasoning field must remain non-authoritative
Invalid result	Reject	Present to the person as written	Reject if the structured portion is invalid

Schema-constrained output: pick it for executable results

Schema-constrained output is an agent result limited to named fields, declared types, required values, and any allowed alternatives. It suits results that determine what code does next: selecting a branch, naming a target, reporting success, or requesting a retry.

The mechanism is straightforward. The producer has a contract, and the consumer validates the result against it before reading any field. A result either satisfies that contract or it does not. The consumer no longer needs to infer whether “probably retry,” “retry recommended,” and “yes” mean the same thing.

Suppose an agent must decide whether a step should continue. A suitable result might be:

{
  "decision": "retry",
  "reasoning": "The required field was absent."
}

The program reads decision, whose allowed values belong in the schema. It does not search reasoning for words such as “retry.” If decision is absent or contains an undeclared value, validation fails at this boundary.

That early failure is what the schema buys. Without it, parsing logic tends to accumulate special cases for capitalization, synonyms, extra commentary, and partial answers. Even if those cases appear to work, the program has merely moved its contract into scattered parsing rules.

The cost is constraint. The model can say only what fits the declared structure, and every required field consumes part of the result’s expressive budget. That is appropriate when the question is narrow enough to have declared answers. It is the wrong choice for a genuinely open question where qualifications, competing interpretations, or an unexpected framing may be the useful part of the answer.

Free text: pick it for open answers read by people

Free text is an answer written for direct human reading without a machine contract governing its content. It fits explanations, critiques, investigations, and recommendations where the agent may need to introduce a distinction that the caller did not anticipate.

Constrained output narrows what the model can say. On genuinely open questions, that constraint costs quality rather than buying reliability: an answer can satisfy every field while omitting the observation that would have made it useful. Adding more fields does not solve that problem if the missing idea was not known when the schema was written.

Anthropic’s December 19, 2024 guidance on building effective agents separates predictable workflows from agents used where flexibility and model-directed decisions are needed. Its tool-design appendix also notes that some structured formats impose writing overhead, including escaping code inside JSON. The relevant condition is not that JSON is always difficult; it is that format work can compete with the substance when the result is primarily prose.

Open-answer quality also cannot be reduced to structural validity. The MT-Bench and Chatbot Arena paper, revised December 24, 2023, evaluates open-ended answers through preference judgments and reports that a strong model judge exceeded 80% agreement with human preferences, while documenting position, verbosity, self-enhancement, and reasoning biases. The paper does not compare schemas with free text. It does show why an open answer needs evaluation beyond “all required fields were present.”

Free text is the wrong answer when software must act on it. Asking a model for prose and then extracting a status, identifier, or instruction recreates an undeclared schema with a weaker boundary. If a program needs one value, request that value structurally instead of hoping to recover it from a paragraph.

The hybrid: structure the decision, not the explanation

A hybrid result uses a schema for fields the program consumes and permits a free-text field for reasoning. It gets both: a validated decision for software and an explanation with enough room for a person to understand the result.

The separation has to be real. Keep the reasoning field out of the parsed path so it cannot become load-bearing by accident. Do not use a keyword search over the explanation to override the structured decision. Do not treat an especially confident sentence as a substitute for a missing field. The program should behave the same way if the reasoning field is empty, rephrased, or removed.

This design is useful when a person must review an automated decision. The schema can contain the decision and any identifiers required by code; the reasoning field can explain uncertainty, missing evidence, or why no declared action fits comfortably. If that explanation reveals a recurring case that software genuinely needs to distinguish, add a deliberate field and update the schema. Do not quietly promote a phrase from prose into an interface.

The hybrid is the wrong answer when there is only one consumer. For a program-only result, the prose adds a field that cannot affect execution. For a person-only result, the envelope constrains an answer without providing a validation benefit. Use it when both audiences actually exist, not as a default compromise.

Reject invalid output; do not repair it

Validation must reject rather than coerce. A pipeline that repairs malformed output teaches nobody that the output is malformed.

Coercion includes converting a string into a number, replacing a missing value with a guessed default, mapping an unknown label to the nearest allowed label, or extracting a valid-looking object from surrounding prose. Each repair turns a visible contract breach into an apparently valid result. The downstream program then cannot distinguish what the agent returned from what the pipeline invented.

Place strict validation at the first program boundary, alongside the checks described for validating agent tool results before they enter model context. On failure, preserve the original result and the validation error, then stop that path. A retry may ask the same model for a fresh conforming result. Switching models is a separate policy decision covered by fallback model policies for agent runs; it should not be disguised as parsing or repair.

Rejection does not prove that a valid result is correct. It proves only that the result has the shape the consumer agreed to read. Human review, environmental checks, and task-specific evaluation still apply where the decision warrants them. The schema’s job is narrower and valuable: prevent malformed output from masquerading as a usable interface.

Which to pick when

Pick schema-constrained output when a program will read any part of the result. Define only the fields the program needs, validate them before use, and reject the whole result when the contract fails.

Pick free text when a person will read the answer and the question is open enough that an unanticipated distinction could matter. Judge the substance as prose; do not add a schema merely to make the response look orderly.

Pick the hybrid when software needs a decision and a person needs its explanation. Keep the decision in validated fields, allow a free-text reasoning field, and make that field invisible to execution. That consumer-based rule gives structure where it detects failure and freedom where constraint would reduce the answer’s value.