The Integration Bottleneck Is Structured Output, Not Reasoning

When a language model is embedded in a working system, it stops being a text generator and becomes a component that must hand structured values to other components: a JSON object matching a schema, a function call with correctly typed arguments, a field that will be written to a database column with a constraint on it. Post-mortems on these systems are consistently less exciting than expected. The model usually understood the task. What broke was the boundary — a field omitted, a type coerced, an enumeration answered with a plausible synonym that the receiving code had never heard of. Constrained decoding has improved this substantially. By restricting generation so that only tokens consistent with a schema can be emitted, output can be made syntactically valid by construction rather than by hope. That eliminates a whole class of parse failure, and it is now widely available. What it does not eliminate is semantic error: a response can validate perfectly against a schema and still name a customer identifier that does not exist, select a unit that was never offered, or fill a required field with a confidently invented value because the schema said the field was required and said nothing about honesty. The second-order design question is what the system does when the model cannot produce a good answer. Schemas that make every field mandatory guarantee fabrication, because the only way to satisfy the contract is to produce something. Schemas that permit an explicit unknown, or a refusal with a reason, give the model a correct move and give the calling code something actionable to branch on. This is the same lesson software learned about error handling generally, arriving late in a new context: a contract with no way to express failure will be satisfied by a lie. The practical shape that works is layered — constrain the syntax, validate the semantics against the systems of record, cap retries at a small number, and route the remainder to a path that a person or a fallback rule can handle. The unglamorous part is the last one. Most of the reliability in a production AI integration comes from what happens on the failed attempts, and that logic is written by ordinary engineering rather than by the model.