LangGraph adopts Standard JSON Schema: one schema for Zod, Valibot, and ArkType

LangGraph added support for Standard JSON Schema in mid July, and the LangChain changelog entry is short enough to miss. It shouldn't be. Standard JSON Schema is an open spec implemented by Zod 4, Valibot, ArkType and a growing list of other TypeScript validation libraries, and LangGraph now consumes it directly for state and tooling schemas. The schema you already wrote for your domain objects can now be the schema for nodes, tools and structured output.

What shipped

The change is on the LangGraph side: state and tool schemas can be defined with any library that implements Standard JSON Schema, and LangGraph reads them through the common interface instead of a library-specific adapter. Zod 4, Valibot and ArkType are the three named in the changelog. The practical effect is portability. A schema written in Valibot in one package and a schema written in Zod 4 in another can both feed the same graph, and neither package has to depend on the other's validator to do it.

Why one contract matters

Every agent pipeline I have built in TypeScript ended up with three copies of the same shape. One Zod schema for runtime validation. One JSON Schema for the model's tool definition. One TypeScript type for the code that consumes the result. The three drift. A field gets renamed in the validator, the tool definition keeps the old name, and the model calls the tool with an argument the code silently drops.

A schema that exists in three places is not a contract, it is three opinions about what the data should look like.

Standard JSON Schema collapses those copies into one. The validator library owns the definition, emits the JSON Schema the model sees, and infers the TypeScript type the code uses. LangGraph reading that same definition for node state closes the last gap: the state flowing between nodes is validated by the same object the tools are validated by. That is the single-source-of-truth pattern from LangChain tool calling, with the framework doing the plumbing instead of you.

Where the glue code goes away

• Tool definitions: stop exporting a separate JSON Schema per tool. Define the input schema once in Zod 4, Valibot or ArkType and let it flow into the tool call.
• Structured output: the schema you validate the model's answer against can be the same object you passed as the response format, so a parse failure and a schema mismatch are one error, not two.
• Node state: graph state validation can use the same domain schemas as the rest of the codebase, which keeps the boundary between agent layer and domain layer honest.
• Mixed libraries: if a shared package uses ArkType and your agent uses Zod 4, you no longer need a conversion shim between them. The spec is the interface.

I would start with the tool layer, because that is where drift bites hardest. Pick one tool with a non-trivial input, delete its hand-written JSON Schema, point it at the validator schema, and diff the JSON Schema the model actually receives before and after. If the diff is empty, migrate the rest. If it is not, you just found a bug that was already in production.

What to measure

Schema portability is a correctness and maintenance win, not a latency one, so measure it that way. Count "argument missing" and "unexpected field" errors in your tool-call logs over a week. Add a test that snapshots the JSON Schema emitted for every tool, so a validator upgrade that changes the emitted schema fails CI instead of quietly changing what the model sees. Pair that with the checks in guardrails and output validation and the whole contract is under test.

The honest gap

The changelog entry names the libraries but not the exact LangGraph version, and I have not measured how faithfully each library's JSON Schema output matches what model providers expect for constrained decoding. Zod 4, Valibot and ArkType do not emit identical schemas for the same shape; unions and optional fields in particular differ. Portability across libraries is the promise. Whether your provider accepts every dialect those libraries produce is something to verify per tool, per provider, before you delete the old schemas.