Structured output vs tool-calling: two jobs people keep conflating
The output you want from a model comes in two flavors that get lumped together: "give me data in a shape I define" and "go do things and bring back the result." Structured output handles the first. Tool-calling handles the second. Reaching for the wrong one is a common reason an agent is harder to build than it should be.
Structured output: constrain the shape, in one shot
Structured output means you hand the model a schema and it returns an object that conforms, validated before your code ever sees it. There is no side effect and no second round-trip; the model's whole job is to fill the shape. We use it for intent classification: a single call returns an object with a couple dozen fields (the user's intent, the scope, the time range, which chart type if any, which tools look relevant) defined by a Zod schema. Downstream code reads those fields directly, with no re-parsing and no null-guarding, because the schema already guaranteed they are present. The classification is a contract, and structured output is how you enforce it.
JSON mode is the weak cousin here. It guarantees the output parses as JSON, not that it matches your schema, so the model can still omit a required field or invent an extra one. Schema-constrained structured output is what you actually want when downstream code depends on the shape.
Tool-calling: capabilities, not shape
Tool-calling is the other job. During its reasoning the model decides to invoke functions you have given it, with arguments it chooses, and reacts to what comes back. Those functions have side effects or fetch live data: list the alarms, pull a time series, create a work order. The model is choosing what to do and when, often several times in a loop. The output you care about is the effect of the calls and the data they return, not a shape the model produced from nothing.
Where people conflate them
Forcing a single structured-output call to also "fetch the data" pushes the model to hallucinate values into the schema, because you asked it to produce data it does not have instead of calling a tool to get it. Going the other way, wrapping a pure shape transformation as a "tool" adds a round-trip and a failure mode to something that should have been one constrained call. The test is whether the result needs an external fact or a side effect. If it does, that is tool-calling. If it is purely rearranging what the model already knows into a defined shape, that is structured output.
Using both together
A real agent uses both in sequence. We classify the turn with one structured-output call, which hands the routing layer a typed contract to switch on, and the routing then decides which tools to call to actually answer. Structured output sets up the plan and tool-calling executes it. Keeping the two stages distinct is what lets each stay simple and testable on its own.
Where AgentKick fits
We build production AI agents that use structured output for the parts that are shape and tool-calling for the parts that are capability, each kept testable in isolation. If the model keeps hallucinating data into a schema, or your tool layer has grown a job it should not have, that is the work we do, usually as a fixed-scope AI Agent Production-Readiness Review into a phased build.