Tool Schema Contracts
Every tool an agent uses comes with a precise, versioned form describing exactly what goes in and what comes out — so nothing changes shape quietly and breaks your workflows.
Think of a signed order form between you and a supplier. Both sides know exactly which boxes exist and what belongs in each one. If the supplier wants to change the form, they publish a new version and give you time to adapt — they don't sneak a new box in overnight and hope you notice.
The problem, in plain words
One of your workflows depends on a tool — say, the one that looks up an order. One day the team behind that tool renames a field, or changes how dates are written. Nothing announces it. Your agent keeps calling the tool, gets back something slightly different from what it expects, and starts producing wrong answers — quietly. You find out from a confused customer, not from an alert, and then spend a day tracing the weirdness back to a change nobody told you about.
What we set up
Every tool publishes a contract written in JSON Schema (a standard, machine-readable way to describe the exact shape of data): this is what a valid request looks like, this is what a valid answer looks like. The registry — the catalog all tool calls pass through — checks every call against the contract at the boundary, before it reaches the real system. Contracts carry version numbers, so a change is a new version, not a silent edit; each workflow chooses to pin to a version it trusts or always accept the latest. A change that breaks the old form goes through a deprecation window (a notice period before the old version is switched off). And your eval set — the library of test questions the system is graded on — re-runs automatically whenever a tool's contract changes.
How it works, step by step
- Each tool publishes its form
Inputs and outputs described precisely, under a version number. No tool joins the catalog without one.
- Every call is checked at the door
A call that doesn't match the form is rejected before it reaches the real system — a loud, early error instead of a quiet, late one.
- Changes get a new version
An updated form is published as a new version; the old one keeps working. Workflows upgrade on their own schedule.
- Breaking changes get a notice period
The deprecation window lists which workflows are affected and gives their owners time to adapt before the old form is retired.
- Tests re-run on every change
A changed contract automatically re-runs the eval set, so a tool that now behaves differently is caught before deployment, not after.
What changes for you
Before: a tool change was a surprise you discovered in production, usually via a customer. After: it is a tracked event with a version number, a known list of affected workflows, and tests that already ran. Debugging shifts from 'what changed somewhere?' to reading a changelog. What it won't do: a contract checks the shape of the data, not the truth of it. A tool can still return a perfectly well-formed wrong answer — catching that is the job of evals and citations, not schemas.