Structured Outputs for AI Agents: Schemas Are Not Safety

JSON is tidy. That is why it is useful. If an agent is handing a decision to another service, a predictable object is much easier to validate than a paragraph that someone has to interpret with a regular expression. A contract can require a decision, a reason, a record ID, and a next step, then give the application a clear way to handle each case.

A shape is not the same as a fact

A schema can tell you that a field exists, that a value has the right type, and that an action belongs to an allowed set. It cannot tell you that a customer qualifies, that a record belongs to the current tenant, or that an email should really be sent. Those questions need authoritative data, business rules, and server-side permission checks.

Give the agent honest ways to be unsure. A contract with only “yes” and “no” encourages confident nonsense. States such as needs_review, insufficient_evidence, and not_authorised often describe reality better.

Check the decision at the last possible moment

Validate the response when it enters the application, and again just before a write or external call. The record may have changed while the model was thinking. Confirm that it still exists, belongs to the right tenant, is in the expected state, and can be changed by this actor. A perfectly valid send_message object must still be stopped when its destination is not allowed.

Do not hide a broken hand-off

If the response is malformed, record the reason and choose a safe recovery: a bounded retry, a correction step, or a person reviewing the case. Quietly guessing a missing field is how a formatting problem becomes a business action. Structured output should make the hand-off clearer, while truth and responsibility remain with the application around the model.