Your Agent's Tool Calls Are Syntactically Perfect and Still Wrong

The failure mode moved, it didn't disappear

Two years ago, if you asked an engineer what broke most often in an AI agent that called tools, the honest answer was usually "the JSON." Models would return a function call with a trailing comma, a missing closing brace, an argument that was supposed to be an integer and came back as the string "five". You'd write a regex to patch it, retry on parse failure, and move on.

That problem is mostly solved. Constrained decoding — masking the model's next-token choices at each step so the output is forced to match a grammar or schema — means a tool call that violates its own schema is now close to structurally impossible, not just unlikely. OpenAI's strict: true flag on tool definitions is one implementation of this; the company reported 100% schema adherence on an internal complex-schema evaluation for gpt-4o-2024-08-06. Other vendors ship equivalent machinery. Teams that added schema validation on top of this have reported parsing-error rates dropping from double digits to near zero.

So the part of tool-calling that used to eat a sprint of debugging — malformed, unparseable output — is close to a solved problem at the infrastructure layer. If you're still losing agent runs to broken JSON in 2026, that's a configuration gap, not a frontier research problem.

That's the good news, and it's also why "we use structured outputs" is not the reassurance vendors sometimes present it as. Constrained decoding guarantees the shape of a tool call. It says nothing about whether the call is the right one, with the right arguments, pointed at the right tool. A call can be perfectly valid JSON, pass schema validation cleanly, and still be wrong — the agent calls cancel_subscription with a plausible-looking customer ID instead of pause_subscription, because the user's phrasing was ambiguous and the model picked a semantically wrong but structurally flawless function.

Researchers studying agent reliability this year have started calling this class of error a "functional hallucination": a well-formed call that is factually or semantically incorrect. A review of 27 agent benchmark and audit papers grouped failures into clusters, and put tool invocation and parameter-level errors first — ahead of planning failures, ahead of reasoning failures. The shape problem got fixed. The judgment problem didn't move.

What the benchmarks actually measure now

The Berkeley Function-Calling Leaderboard (BFCL) is the closest thing the field has to a standard for this, and it's worth understanding what it actually scores. Its "Parallel" and "Parallel & Multiple" categories — where one query should trigger several calls, or where the model has to pick the right function out of several candidates — are graded by comparing the structure of the predicted call against ground truth (AST matching), with a smaller execution-graded subset that actually runs the function. The published pattern from BFCL's own research is consistent: frontier models are strong on single-turn, single-tool calls, and the open problems are long-horizon, multi-step tasks where the model has to track state across turns and decide when a tool is even warranted.

A newer benchmark built specifically to separate out failure types, rather than report one aggregate pass rate, found a best "clean tool-use rate" of about 86% across 19 models on a thousand single-turn tasks — and, more usefully, broke out how the other roughly 14% failed: skipping a tool the task actually required, ignoring the tool's returned result and answering from the model's own assumption instead, fabricating a plausible-looking result when a call wasn't made, and calling tools the task didn't need at all. None of those four failure types produce malformed JSON. All four look fine in a quick glance at a trace.

That last point is the one that should change how you build. If you're spot-checking agent traces for "does the call look right," you will systematically miss the failures that matter most, because they look right.

What this means if you're building or buying an agent

Stop treating schema validation as reliability testing. It's a necessary floor, not a measure of correctness. An agent that never produces malformed calls can still have a 15-20% rate of wrong, skipped, or unnecessary calls. Ask a vendor for their tool-call accuracy on held-out tasks with known-correct answers, not their schema-compliance rate.

Test the four specific failure types, not just "does it work." For any agent that calls tools against real systems — booking, billing, data lookups, anything with side effects — build a small eval set that specifically probes: does it call the right tool when one is clearly needed; does it skip a tool and guess instead; does it actually use the tool's returned data, or ignore an inconvenient result; does it call tools when the task didn't ask for one. Four narrow test categories catch more real failures than fifty generic "does the agent seem smart" prompts.

Put verification on the result, not just the call. Because "ignores the tool's own output" is a documented failure mode, logging that a tool was called correctly isn't enough — you need to confirm the agent's final answer is actually consistent with what the tool returned. This is a cheap check (a simple comparison or a second small model call) that catches a failure class schema validation structurally cannot see.

Reserve human review for the failures structured outputs can't prevent. If you've already eliminated malformed calls at the decoding layer, your approval gates and spot-checks should concentrate on the cases most likely to produce functional hallucinations: ambiguous user phrasing, tools with similarly-named functions, and multi-step tasks where state has to persist across turns — exactly where BFCL and the newer failure-taxonomy research say current models are weakest.

The takeaway

Structured outputs and constrained decoding solved the problem that used to show up as a stack trace. The problem that's left shows up as a clean, valid, confidently wrong tool call — and it won't surface in a parser error or a schema check. If your agent testing stops at "did the call validate," you're measuring the half of the reliability problem that's already been solved, and missing the half that's actually costing you.