Photo: iStock.com/marchmeena29 · Edited by the telos journal · Content Credentials certified
Most AI demos work because someone is steering them. A person reads the model’s prose, interprets it, and decides what to do next. That breaks the moment you try to put the model inside a real workflow, where the output has to feed a router, a database, or an approval queue without a human in the loop to translate. The gap between “the model said something reasonable” and “the system did the right thing” is where most AI projects stall. Structured outputs are how you close it. By defining the shape of the answer before the model produces it, you turn an open-ended conversation into something software can reliably act on.
The fundamentals of structured outputs
Asking a business question
Every useful piece of AI starts with a business question. Not a vague prompt, but a specific, answerable question tied to a real decision.
For a commercial airline team, some examples could be:
- Competitive exposure: Which routes in our network are most exposed to competitive re-pricing this week?
- Analyst triage: Which markets should an analyst review first given current load factors and fare trends?
- Inventory: Which flights in the next 14 days are at risk of spoiling capacity if we do not adjust availability or pricing?
The question matters because it defines what a useful answer looks like, and that is the foundation of structured outputs.
Schema design — telling the AI what you want
Once you know the question, you can define the answer. Schema design means specifying the shape of the response before the AI produces it. Rather than asking the model to “tell you about underperforming routes,” you define fields the model must fill such as route identifier, recommended action, confidence, rationale, etc.
Example — informal vs. structured:
This process is sometimes called narrowing the funnel. A general-purpose language model might respond in countless ways to the same prompt, whereas schema design collapses that space into exactly what your workflow needs. The model’s reasoning can stay flexible while the output format does not.
Options for structured outputs
Implementation choices depend on what your system must do with the response, where some options are presented below:
Plain JSON
- What it is: Lightweight, universally readable, easy to pipe between services.
- Good for: Fast API integration and prototypes.
- Trade-off: No built-in validation, i.e. if the model returns an extra field, a wrong type, or free text where you expected an enum, JSON alone will not catch it at the boundary.
Example JSON shape (conceptual):
Pydantic (validation at the boundary)
Pydantic adds validation when the response arrives: field types, required keys, and allowed values.
Example — why it matters for airlines:If your schema says confidence is a float between 0 and 1, Pydantic rejects “high” or “0.9%” immediately. That failure surfaces at the source, before a revenue workflow treats a string as a number or routes a case incorrectly.
LangChain (workflow layer)
Where Pydantic validates a single response, LangChain (or similar orchestration) manages how multiple steps connect. Structured output from step A becomes structured input for step B, without hand-rolled glue between each call. The schema becomes part of the architecture, not an afterthought.
Mental model:
For a production airline system, these layers often work together: format + validation + orchestration.
Tool calling — structuring the tasks, not just the outputs
Structured outputs apply not only to what the AI returns, but to what it does. Tool calling lets an agent invoke defined actions. Instead of generating prose, the agent can query a database, look up a fare filing, enqueue a workflow, etc. This way, tasks become predictable, auditable, and composable.
Example tools an airline-facing agent might expose:
That separation of answers vs. actions is what distinguishes an assistant that can comment on a spreadsheet from one that can participate in an operational workflow.
Why structured outputs matter
Anticipated outputs make branching possible
Applications almost always need to act on model output, with some examples being route work, trigger jobs, update records, etc. Branching in these areas requires predictable values.
Example:
- If recommended_action is constrained to reprice | monitor | escalate, your router can map each value to a queue, an API, or an approval path.
- If the model returns “I would suggest considering a repricing strategy,” you have no stable key to branch on, rather fragile string parsing or a second model call.
Errors that surface are errors you can fix
Free-form text can fail silently. It might be confident wording but have subtle wrong facts or a drifting format. Structured outputs tend to fail loudly when validation fails. That way, you learn which field broke and why. Then retry, log, fallback, or escalate to a human.
Example recovery paths:
Predictable shape on probabilistic technology
Models are probabilistic, where two calls with the same prompt may differ in wording. Even with the LLM temperature set low, variance can still happen. Instead, structured outputs constrain the shape, not necessarily the reasoning path. Your app can still rely on fields, types, and allowed values.
Example expectation: Every successful response includes route_id, recommended_action, confidence, and rationaleThat predictability is what makes it reasonable to treat the model boundary more like an engineered API and less like an informal conversation.
Validating outputs at every layer
Strong systems rarely depend on a single validation gate. Two complementary loops:
- Real-time user feedback catches outputs that were schema-valid but wrong, unclear, or unhelpful in context, and improves the product.
- Benchmarking measures accuracy, consistency, and drift over labeled or reviewed sets, and improves the model and prompts.
Neither replaces the other.
Example benchmarking slice for airlines:
Additional context that strengthens the system
Beyond validation:
- Embeddings & RAG → retrieve relevant docs (internal rules, competitive notes, seasonal playbooks) at generation time so answers are grounded in your data, not only pretraining.
- Memory → carry session or case context forward so the model does not “forget” the market or constraint you established two turns ago.
- External tooling → live feeds, search, or operational APIs so the model reasons over current loads and filings, not a static snapshot.
Together, these move the system from abstract answers to responses that reflect your network and your moment.
Conclusions – structured outputs as trust
Structured outputs are a foundational engineering choice that is often invisible in a demo, but central to whether that demo survives production. Structured outputs create a union between software discipline and domain expertise, where the schema encodes how your airline ultimately decides and routes work.
A system built on structured outputs tends to be more reliable, auditable, and composable. Errors surface where they can be caught, decisions leave a trace, and downstream automation has something solid to bind to.
Trust, in practice, is not pretending the model is always right, rather it is knowing that when something is wrong, you can see it and respond accordingly.
Prompting is a fast way to test product direction, and structured outputs are how you can make it real.
telos builds AI-native commercial intelligence for airlines. This post is part of an ongoing series on how modern AI capabilities translate into operational tools for airline commercial teams.
