Validate the boundary, not your own code
Technology
A TypeScript type is a claim the compiler checks about code it can see. It says nothing about the JSON that just arrived from a third party API, a form post, or a model that was asked to return an object. Zod is the check at that edge, and it hands back a type rather than a boolean.
We reach for it where data crosses in from outside, and the boundary that matters most now is a model. One schema declares a tool's arguments, generates the machine readable description the model is shown, and parses the object that comes back, so a wrong field fails at the edge instead of three functions later.
The edge
Where a runtime schema pays for itself
- Types stop at the edge of your code
Inside your own modules the compiler already proved the shape, and a second check at runtime buys nothing. At the point data arrives from a service, a browser, or a model, the annotation is a guess. Parse once there and everything downstream can trust itself.
- One schema, both directions of a tool call
An agent tool needs a machine readable description going out and a parsed object coming back. Written as a schema, the description is generated from the same declaration that validates the response, so what the model was shown and what the code enforces cannot drift apart.
- Parse at the entrance, then stop
Schemas are runtime cost and a second copy of a shape you already declared. What keeps that trade honest is one parse where the data lands, with the type inferred from the schema afterward, instead of a validation call at every layer it passes through.
