When AI writes JSON, one bad field can break the workflow
By Greg Nowak. Updated 15 August 2026.
AI-generated JSON looks reassuringly precise. It has field names, tidy nesting, and none of the ambiguity of a paragraph. That makes it useful for updating CRM records, creating support tickets, preparing product data, routing leads, or drafting CMS entries.
It also makes mistakes easier to automate.
A payload can be valid JSON and still assign a lead to the wrong account, send an unsupported status to a billing system, or schedule an action for the wrong date. The operational question is therefore not simply, “Can the model return JSON?” It is, “What must happen before our software trusts it?”
Structured output is a contract, not an approval
Current AI platforms can constrain model output to a defined structure, and JSON Schema provides a standard vocabulary for describing that structure. This is a substantial improvement over asking for JSON in a prompt and hoping that the response parses.
Use the schema to define the expected object, required properties, data types, array contents, and accepted values. Reject unexpected fields where appropriate. Declare the JSON Schema dialect your tooling supports rather than leaving validators to make assumptions.
But schema compliance answers only a structural question. It does not establish that a customer ID exists, an amount is commercially plausible, a user is authorised to perform an action, or a proposed change is safe to execute. Those decisions remain in your application.
| Gate | What it catches | Failure response |
|---|---|---|
| Parse | Truncated or malformed JSON | Reject or retry once |
| Schema | Missing fields, wrong types, extra properties, invalid enums | Return precise validation errors |
| Business rules | Unknown IDs, impossible dates, duplicate records, unsafe amounts | Stop or send for review |
| Permission | Actions the user, workflow, or model may not perform | Deny and log |
| Execution | Duplicate writes and downstream API failures | Use idempotency, rollback where possible, and alerting |
Design the schema around the receiving system
Start with the API or database that will receive the data, not with the answer the model finds easiest to produce. If a support platform accepts only low, normal, and urgent, define that enum. If a publishing workflow needs an ISO-formatted date, require the format your application expects and parse it explicitly. If an amount is monetary, define how currency, precision, and tax treatment are represented.
Be deliberate about optional values. “Missing,” null, and an empty string may trigger different downstream behaviour. Document which one is allowed and what it means. Avoid making every property optional merely to increase the model’s success rate; that transfers uncertainty into operations.
Also decide whether extra fields are allowed. Preventing undeclared properties can catch misspelled keys and stop the model from quietly inventing data your application never requested. Check the schema subset supported by your chosen model provider, because constrained-output implementations do not necessarily support every JSON Schema feature.
Valid JSON can still be commercially wrong
After structural validation, apply rules grounded in your own data and processes. Confirm that identifiers resolve to the right tenant or customer. Check that dates fall within an acceptable window. Verify that a proposed state transition is allowed—for example, that an invoice cannot move directly from “draft” to “refunded.”
Separate descriptive fields from decision fields. A generated summary can usually tolerate variation. A price, account ID, payment status, permission level, or destination email needs much tighter control. For sensitive actions, let the model propose the value while deterministic code retrieves or confirms it.
Cross-field checks matter too. Each field may be valid on its own while the combination is not: a delivery date can precede an order date, a currency may not match the account, or a “closed” ticket may have no resolution.
Keep tool execution under application control
Tool calling does not mean the model should receive unrestricted access to business systems. The model proposes a tool name and arguments; the application decides whether and how to execute them.
Maintain an allowlist of tools for each workflow. Validate arguments even when the provider says the output follows a schema. Apply the user’s real permissions, not a generic service account’s maximum access. Require confirmation for consequential actions such as sending messages, publishing content, changing financial records, or deleting data.
Give read operations and write operations different risk levels. “Look up this customer” and “change this customer’s billing address” should not pass through the same approval path. Where an API supports it, use idempotency keys so a timeout or retry does not create the same ticket, payment, or record twice.
Make failure an ordinary, visible state
A retry is useful when output is malformed or misses a constraint. Return the exact validation errors to the model and request a corrected object. Set a small retry limit, however. Repeating the same request indefinitely increases cost and latency while hiding a design problem.
Classify failures before retrying. A malformed date may be repairable. An unknown customer ID requires fresh data or human input. A denied permission must not be “fixed” by asking the model again.
Log enough to diagnose the workflow: model and version, schema version, correlation ID, validation outcome, retry count, tool requested, execution result, and timing. Avoid placing secrets or unnecessary personal data in logs. Monitor failure rates by field; repeated errors often reveal ambiguous instructions, schema drift, or a changed downstream API.
A practical production checklist
- Version the schema alongside the code that consumes it.
- Test valid payloads, missing fields, wrong types, extra fields, boundary values, and hostile input.
- Run structural and business-rule validation before every write.
- Use least-privilege credentials and action-specific approval rules.
- Cap retries and create a human-review route for unresolved cases.
- Make writes idempotent where the receiving system permits it.
- Alert on recurring validation and execution failures.
For a proof of concept, getting a neat JSON object may feel like success. In production, it is only the first checkpoint. A dependable integration treats model output as untrusted input, makes every consequential action explicit, and leaves an audit trail when something goes wrong.
Need to harden an AI workflow?
If your prototype is about to touch a CRM, CMS, support platform, or finance process, Greg can help map the handoffs, define schemas and controls, and build a failure path your team can operate. Start with a practical conversation about the workflow.
Related on GrN.dk
- A Voice Agent Is Only Ready When the Human Handoff Works
- Structured Outputs Make Intake Automation a Schema Design Job
- Agent-ready APIs need a contract audit before MCP rollout
Need help with this kind of work?
Discuss your AI workflow with Greg Get in touch with Greg.