Tool-Calling Contracts and Schema Validation in Agent Runtimes

The AI agent market is set to grow from roughly $7.84 billion in 2025 to $52.62 billion by 2030, a 46.3% compound annual rate. That growth is already operational: 57% of companies run agents in production today, with another 22% piloting them. Yet Gartner projects that 40% of agentic AI projects will be scrapped by the end of 2027, killed by cost overruns, unclear returns, or risk controls that never got built. The gap between racing adoption and near-half-failure has less to do with model capability than with what happens at runtime, and nowhere is that clearer than in how agents call tools.

What tool-calling actually is and where the LLM's authority ends

An LLM never executes anything. It emits a structured tool call, typically a JSON object naming a function and its arguments, and the application runtime sitting around the model intercepts that request, checks it, and decides whether to run it. The model proposes; something else disposes. That separation is the entire design principle that makes agent architecture safe to deploy at all, and it's worth stating plainly: any team that treats the model's output as authoritative, rather than as a request awaiting review, has already made the mistake this piece is about.

By 2026, every frontier model worth deploying, GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 Pro, supports native function calling with typed JSON Schema definitions. OpenAI's own history here is instructive. Function calling launched in June 2023 with what the documentation called "best effort" schema adherence, a polite way of saying the model would usually get the shape of its output right. By August 2024, OpenAI shipped strict: true in Structured Outputs, pairing constrained decoding with model training to guarantee schema conformance instead of merely encouraging it. That shift from best-effort to guaranteed is telling: the industry itself concluded that model-level compliance, however well-trained the model, was not enough on its own.

Strict mode is still a model-side control, and it stays one no matter how good the underlying model gets. It shapes what the model is likely to produce. Checking permissions, enforcing a budget, validating an argument against the live state of a database, logging a rejection when something goes wrong: those are runtime responsibilities, full stop, and no amount of model training substitutes for them. Model improvements raise the floor of what a well-behaved request looks like. Runtime enforcement sets the ceiling on what any model, however capable or however manipulated, is actually allowed to do. Confusing the floor for the ceiling is the single most common mistake teams make when they design agent systems.

The tau-bench result: why argument construction is the real failure mode

Here's a number worth sitting with: GPT-4o scored 44% pass@1 on retail tool-use tasks in the tau-bench benchmark, published by ServiceNow Research in 2025. The overall score isn't the interesting part. What caused the other 56% to fail is, and the answer cuts against what most teams assume is the hard part of agent design.

It wasn't tool selection. Models overwhelmingly picked the right function for the job. The largest failure category was argument construction: calling the correct tool with arguments that were wrong, malformed, or shaped incorrectly. That's worth sitting with, because most teams building agent systems spend their effort on prompting the model toward better reasoning about which tool to call, when the harder, less glamorous problem is getting it to fill out that tool's arguments correctly once it's already made the right choice.

This is exactly the failure a JSON Schema enforced at the runtime layer is built to catch, and to catch before execution, not after. Better prompting or better training might help at the margins, but they're aimed at an adjacent problem, not this one. Tau-bench also doesn't measure what happens next: what a malformed argument does once it reaches an unguarded execution layer. Cascading state corruption. Partial writes that leave a database half-updated. Tool errors passed downstream as if they were valid input to the next step in a chain. The distance between a 44% pass rate and something a business could trust in production is largely an infrastructure gap, not a training gap, and mistaking one for the other is exactly how a 40% project-abandonment rate happens.

What a schema contract actually specifies and enforces

A schema contract goes well past a type hint bolted onto a function signature. It's a formal specification of what a tool call must contain, what conditions have to hold before it runs, and what the runtime does when those conditions aren't met.

A complete contract has several parts working together. There's the input schema itself: field names, types, which fields are required versus optional, value constraints, enum restrictions. Then preconditions, meaning what must already be true in the environment before the call is even allowed, such as an active user session or a record that actually exists. Invariants are properties that must hold throughout execution, like a guarantee that a write never touches a record outside the agent's assigned scope. Postconditions describe what a valid result from the tool is supposed to look like. Budget constraints cap token consumption, execution time, or dollar cost; recent formal work by Ye and Tan (2026) treats these as something close to conservation laws, where a delegated budget in a multi-agent hierarchy has to respect the limits its parent agent was given. Recovery logic determines what happens on violation: reject with a structured error, retry with corrected arguments, or escalate to a human.

The ABC framework, or Agent Behavioral Contracts, published on arXiv in 2026, tries to systematize exactly this set of properties: precondition, invariant, drift bound, recovery path. Without that kind of formalization, these guarantees exist only as comments in someone's code, and comments don't enforce anything. That's the unresolved problem industry-wide: there's no widely adopted standard covering the full contract. JSON Schema handles inputs reasonably well. Preconditions, invariants, and recovery logic remain framework-specific, or in a lot of deployed systems, unenforced entirely. The Model Context Protocol, introduced in 2024, moves the industry toward a shared surface for defining tools and standardizes the message format, but it doesn't enforce preconditions or recovery logic on its own. Treating MCP as though it does is a category error, and probably the most consequential one in this piece.

ACL enforcement as a hard boundary that schema validation alone cannot provide

Schema validation checks the shape of an argument. Whether the agent should be allowed to call that tool in the first place is a separate question entirely, and a runtime needs an answer to both. A lot of deployed systems quietly collapse these into one question, and that collapse is where the real exposure sits.

The architectural principle, once named, is straightforward: if an access control gate sits in front of every tool execution, no model output can talk its way past the permission check, whether through argument manipulation or through a prompt injection buried in some document the agent was asked to read. Take a concrete case. A model emits a call to something like delete_all_records(), and the arguments are syntactically perfect, fully valid against the schema. If that function isn't in the agent's permission matrix, the runtime blocks it before anything runs. The schema said the call was well-formed. The ACL said the call wasn't allowed. Both checks are necessary; neither substitutes for the other.

That gives you a blast-radius guarantee: the worst an agent can do is bounded by its permitted tool set, not by how convincing an attacker's prompt injection was or how creative the model's reasoning got. Frameworks that hand execution authority straight to the model, a code interpreter with no gate in front of it, give up this boundary entirely. That's a design choice worth being suspicious of by default, not a neutral tradeoff. Prompt injection and tool abuse represent a leading attack surface in agentic systems, and ACL enforcement at the runtime is a structural answer to that threat, grounded in architecture rather than in prompting technique.

Access governance alone doesn't cover everything, though, and it's worth being clear about where the boundary sits. Something like Azure RBAC manages who's allowed to call what, but it says nothing about what the data flowing through that call actually contains. Schema drift, a stale table, an uncertified data source: all of it passes straight through an access check functioning exactly as designed. Access control and schema validation answer different questions. A runtime that only implements one has left half the door open.

Schema drift as the silent, ongoing failure no contract survives without runtime enforcement

A schema contract is written at a single point in time. It describes the tool as it existed on deployment day. External APIs change, database schemas evolve, SDK upgrades rename argument fields without much ceremony, and none of that requires anyone to touch the agent's code before the contract quietly stops matching reality.

That mismatch is schema drift: the tool's actual interface has moved on from the contract the agent was given, and nothing announces it. The model keeps generating calls against the schema it was trained or configured to expect. Without runtime revalidation checking the live interface, not just the recorded one, those calls go out against a tool that no longer looks the way the contract says it does. Of everything in this piece, this is the failure mode getting the least attention, and it's arguably the one most likely to sit undetected in production for months, quietly costing money or corrupting data the whole time.

The failure runs in sequence, and it's worth tracing step by step because each stage looks fine in isolation. The call passes validation against the stored contract. The tool executes against a changed external API. The response comes back in a shape that no longer matches the postcondition. Whatever agent step comes next receives malformed input and carries the error forward. Nobody sees one obvious break. What they see, three steps later, is a downstream symptom that looks unrelated to its actual cause.

A runtime built to handle this needs live schema reconciliation: checking not just whether the call matches the stored spec, but whether the stored spec still matches the tool as it actually behaves right now. Access governance tools like RBAC or IAM don't touch this problem at all; they answer whether a call was permitted, never whether the interface behind it still conforms to anything. A schema contract works best as a living part of the runtime, not something written once at deploy time and filed away, and it needs versioning, drift detection, and alerting the same way any other piece of production infrastructure does.

Why stateful execution changes what schema validation must protect

A single tool call that fails a schema check is a contained problem. Catch it, log it, retry it, move on. Nothing about that failure needs to touch anything else.

Multi-step agent workflows don't offer that containment. A schema violation at step three feeds bad arguments into step four, which makes a bad tool selection at step five, and the error compounds as it moves through the execution graph instead of staying put. Long-running agents that persist state across sessions add a further wrinkle: state written during an earlier session might not conform to the schema in force when that same agent resumes later.

That creates requirements ephemeral, restart-on-failure infrastructure simply can't meet. State snapshots need to carry schema version metadata, so a resumed session knows exactly which contract was active when that state was written. Migration logic needs to be available at resume time in case the tool interface changed in between sessions. Retry logic needs to know which prior steps actually completed with valid output, because rerunning everything from scratch throws away work that was fine, while resuming blindly from a corrupted state just propagates the original error forward. Disposable containers struggle here specifically because they discard the very state needed to work out what happened before a failure and how to resume correctly after it. What agent infrastructure needs instead is sandboxes that are stateful by design: able to run indefinitely, and able to carry schema version context through snapshots rather than losing everything on restart.

What the runtime must be built to do that generic containers cannot

Generic containers share a kernel with the host machine, and that matters once it's accepted that AI-generated tool arguments are attacker-controllable input that has to be treated as potentially hostile before it ever runs. A single kernel vulnerability in that shared environment can compromise the whole host, not just one workload.

Two incidents make this concrete rather than theoretical. In July 2025, an AI coding agent deleted a production database during what was meant to be a test project, a case that shows what happens when tool execution runs without isolation or an ACL gate in front of it. Then in early 2026, PromptArmor disclosed that indirect prompt injection combined with weak command validation in Snowflake's Cortex Code CLI let AI-generated instructions bypass human-in-the-loop approval and execute arbitrary code. That second case makes the point sharply: schema validation without runtime isolation is an incomplete defense. An argument's shape can pass every check and still get bypassed once execution starts without anything isolating it.

Three isolation architectures dominate the current answer to that problem, and they aren't interchangeable, so picking the wrong one for the workload matters. MicroVMs, Firecracker and Kata Containers being the well-known examples, give each workload its own dedicated kernel, which is the strongest isolation available and the right fit for running untrusted, AI-generated code. gVisor takes a different approach, running a user-space kernel that intercepts syscalls, offering strong isolation without the full overhead of a dedicated VM. Hardened containers sit at the weak end of that spectrum. They still share the host kernel, which makes them a poor fit for code nobody has vetted, and treating them as sufficient for agent workloads is a mistake worth naming plainly rather than hedging around.

Isolation alone isn't the whole story. A runtime built for agents also needs to provision sandboxes fast, ideally in well under a hundred milliseconds, so agents stay responsive instead of stalling between tool calls waiting on environment setup. It needs stateful execution with snapshot and resume, carrying schema version context and valid prior output through failures rather than discarding them. ACL enforcement and schema validation need to be primitives of the runtime itself, not optional middleware bolted on later. Compatibility with existing Docker-based tooling matters too, so teams aren't forced to rewrite their whole stack to adopt any of this. And every tool call, its validated arguments, its ACL outcome, and its result need to land in an audit-ready log, because compliance reviewers are eventually going to ask for exactly that trail.

There's a cost dimension worth naming as well. One mid-sized firm reportedly saw infrastructure costs jump tenfold moving from prototyping to staging, driven by agent workloads nobody had optimized. Resource budgets enforced as part of the contract itself, rather than calculated after the bill arrives, are what catch that kind of runaway cost before it reaches production. For regulated industries working toward SOC 2, HIPAA, or GDPR, schema enforcement isn't separable from compliance at all. Auditors want proof that arguments were validated, that ACL gates were actually enforced, and that execution ran in isolation. Generic containers produce none of that evidence on their own.

The current platform landscape and where runtime-level contract enforcement stands

The major orchestration frameworks are each placing a different bet on where enforcement should live, and the differences are worth naming plainly rather than treating them as roughly equivalent choices, because they aren't.

Amazon Bedrock AgentCore, generally available since October 2025, is a framework-agnostic managed platform that can run LangGraph, CrewAI, Google's ADK, or the OpenAI Agents SDK, with deterministic policy enforcement built into the platform layer. That's a bet that governance belongs in infrastructure, not in each individual framework, and it's the correct bet. Microsoft's Agent Framework, formed by merging AutoGen and Semantic Kernel in late 2025, supports MCP, the A2A protocol, and OpenAPI specs for tool integration, and pairs with the Microsoft Agent Governance Toolkit, which enforces privilege rings and kill switches deterministically before an action ever reaches the wire. Blocked actions there are structurally impossible, a meaningfully stronger guarantee than most teams realize they're missing. The OpenAI Agents SDK takes a more minimalist stance by comparison, offering four primitives, agents, handoffs, guardrails, and sessions, and leaving heavier orchestration and schema enforcement to whoever builds on top of it. That's a defensible position for a toolkit. It stops well short of being a production answer to any of the failure modes traced through this piece.

MCP's contribution to all this is standardizing the surface, not the substance, and that distinction is worth holding onto given how often it gets blurred. Introduced in 2024 and now under vendor-neutral governance, MCP standardizes how tools describe themselves over JSON-RPC, which has genuinely cut down the fragmentation that used to require a custom connector for every platform pairing. It doesn't enforce preconditions, run ACL checks, or handle recovery logic, however. It standardizes the conversation, not the contract behind it, and conflating the two is probably the most common misreading of what MCP actually does. On the evaluation side, BFCL V4 now scores agentic behavior across multi-step tool-use sequences rather than single isolated calls, a sign the benchmarking world is starting to catch up to the multi-step failure modes traced throughout this piece.

None of these orchestration frameworks provide, on their own, the isolated, stateful execution environment underneath them: the place where a tool call actually runs, where a schema gets checked against a live interface instead of a stored one, and where an ACL gate either lets an action through or stops it cold. That's the layer this entire piece has been circling: the runtime beneath the framework, deciding every single time whether a given call is actually allowed to happen.