Most AI work starts as prose: “Read these notes and tell me what matters.” That is fine when a person will read every word. It becomes fragile the moment the next step is a spreadsheet row, a task creation, a support reply, or a dashboard card. A slightly different heading, a missing priority, or a made-up category turns a useful answer into manual cleanup.
The practical move is to define the smallest object the next step actually needs before you ask the model to write anything. This is not an instruction to make every answer look like JSON. It is a way to turn a fuzzy handoff into an explicit contract: these fields are required, these values are allowed, and this is what “nothing found” looks like.
OpenAI’s Structured Outputs guide distinguishes valid JSON from schema adherence: JSON mode can return parseable JSON, while Structured Outputs is designed to follow the supplied schema.[1] Anthropic’s tool-use documentation describes the same application boundary in a different form: the model returns a structured call with arguments, and the application executes the action.[2] In both cases, the shape is part of the workflow—not decoration on the answer.
Start from the receiving end
Suppose you want AI to triage incoming customer feedback. Do not begin with “summarize this ticket.” Begin by asking what a teammate or automation needs to do next. A sensible minimal handoff might be:
- Is this actionable feedback, or not?
- Which product area is involved?
- How urgent is it?
- What evidence supports that judgment?
- What should happen next?
Each field should earn its place. If nobody reads sentiment_score, leave it out. If the workflow cannot safely proceed without a human decision, make that a field rather than burying it in prose. The goal is not a maximal schema; it is an unambiguous one.
Copy this schema-first prompt
Use the following even in a chat tool that cannot enforce a formal JSON schema. If your API supports structured output or strict tool calls, implement the same object as the schema and validate it before taking an action.
TASK
Classify the supplied customer message for the support triage queue.
ALLOWED EVIDENCE
Use only the supplied message. Do not infer a product area, severity,
or customer promise that is not supported by the text.
RETURN EXACTLY ONE OBJECT
{
"actionable": true | false,
"area": "billing" | "login" | "performance" | "other" | "unknown",
"priority": "urgent" | "normal" | "low" | "needs_review",
"evidence": "short quote or faithful paraphrase from the message",
"next_step": "one concrete action",
"needs_human_review": true | false
}
EMPTY / AMBIGUOUS CASE
If the message does not support a field, use "unknown" or
"needs_review" as applicable. Set needs_human_review to true.
Never invent a value merely to complete the object.
Notice the important part is not the braces. It is the escape hatch. A schema with only confident-looking options pressures a model to force an answer into one of them. Including unknown, needs_review, and a human-review flag makes uncertainty a valid output rather than a formatting failure. OpenAI specifically warns that structured output can still contain mistakes and that an incompatible input can lead a model to try to satisfy the schema anyway; its guidance recommends specifying an empty or fallback result for such cases.[1]
Test the boundary, not just the happy path
Before wiring this into an automation, try five examples: a clear billing complaint, a clear login problem, a vague compliment, a message about an unsupported topic, and a message with conflicting details. Check two things separately:
- Shape: Does every result parse and contain only permitted values?
- Judgment: Does the evidence actually support the chosen area and priority?
A perfect shape does not prove a correct decision. Structured output solves the integration problem—your program knows where to look—not the truth problem. Keep the evidence field so a person can audit important classifications, and route uncertain cases instead of silently assigning them.
When not to use it
Do not force a rich research brief, creative draft, or exploratory analysis into a cramped object too early. Those tasks need room to discover ideas. Use a schema at the boundary where prose becomes action: when you create a record, trigger a workflow, populate a UI, or hand off a decision to someone who needs consistent fields.
The useful habit is simple: before the model answers, write down what the next person or system must receive. Then make “I do not know” a first-class result. You will spend less time repairing format drift—and more time reviewing the decisions that actually matter.