Daniel sent us this one — he wants us to go deep on tool-calling evaluation, specifically three benchmarks that each take a fundamentally different approach to measuring whether models actually call tools correctly. The Berkeley Function Calling Leaderboard, tau-bench, and Nexus. He's asking us to contrast BFCL's AST-based scoring against its executable mode, explain why tau-bench grades on final database state instead of tool-call sequences, and what Nexus reveals about long-tail and rare APIs. Then he wants us to spend real time on the failure modes that hit production — hallucinated tool names, parallel call ordering errors, schema drift across model versions, and sycophantic confirmation of wrong arguments. There's a lot to unpack here.
I'm genuinely excited about this one, because most of what people read about tool calling is leaderboard top-line numbers, and those numbers are hiding more than they're revealing. By the way, quick note — DeepSeek V four Pro is writing our script today, so if anything comes out unusually coherent, that's why.
I was going to say, you seem suspiciously well-organized. But let's start with BFCL, because it's the one most people see. The Berkeley Function Calling Leaderboard — it's become the go-to public benchmark, but most people don't realize it's actually running two completely different evaluation modes under the hood. AST evaluation and executable evaluation. They're measuring different things.
Right, and the distinction matters enormously if you're trying to figure out whether your agent will actually work. AST evaluation — Abstract Syntax Tree — parses the model's generated function call into a tree structure and checks structural conformance. Is the function name correct? Are required parameters present? Do the parameter types match? Are the values in the right format? It's purely structural. The BFCL team uses this for their large-scale evaluation — we're talking four hundred Python simple-function samples, two hundred multiple-function, two hundred parallel, two hundred parallel-multiple, plus a hundred Java and fifty JavaScript samples. The scale is impressive because you don't need to actually execute anything.
It's essentially a syntax checker for function calls. Which catches real problems — hallucinated parameters that don't exist in the function doc, type mismatches, structural errors in nested types like List of Dict where ordering matters. But it's also completely blind to whether the call actually does the right thing.
And that's where executable evaluation comes in. They take a smaller subset — a hundred Python simple, fifty multiple, fifty parallel, forty parallel-multiple, plus seventy REST API calls — and actually run the generated calls in real environments. Then they check the output against ground truth. Exact match, real-time match within a twenty percent threshold for numerical results, or structural match checking correct data type and key presence.
What's an example of something AST catches that execution misses?
Java type strictness is a perfect case. If a Java function expects a float and the model generates an integer, AST evaluation flags that immediately — it sees the type mismatch in the tree. But if you were only doing executable evaluation, a lot of Java runtimes will silently coerce that integer to a float, the code runs fine, and the executable evaluator says "pass." You'd never know the model got the type wrong. Similarly, AST catches hallucinated optional parameters — fields the model invented that don't exist in the schema. Executable evaluation might ignore those because the runtime just discards unknown fields.
The reverse — what does execution catch that AST misses?
The classic case is REST API evaluation. A call can be structurally perfect — right endpoint name, right parameter types, everything validates — but it hits the wrong API endpoint and gets back data that looks plausible but is completely wrong. AST says "one hundred percent correct." Executable evaluation compares the actual API response against ground truth and catches that the data is wrong. Or think about side effects — a call that updates a database record with structurally correct but semantically wrong values. The syntax tree looks beautiful. The database is now corrupted.
That gap between structural correctness and actual correctness is where a lot of production agents silently fail. And BFCL V four, which launched this month actually, extends this further — they've added web search, memory, multi-turn interactions, and hallucination measurement. The top model, Claude Opus four point five, scores about seventy-seven percent overall accuracy. But even the best models show significant drops in what they call "Miss Func" and "Miss Param" sub-categories.
Miss Func is when the model completely fails to call a function that was clearly needed. Miss Param is when it calls the right function but omits a required parameter. Those are the failures that kill real workflows. A seventy-seven percent overall accuracy sounds decent until you realize that in a ten-step agent workflow, a twenty-three percent per-step failure rate compounds to almost certain failure across the full trajectory. That's the math people miss when they look at leaderboard numbers.
Which brings us to tau-bench. This is the one from Sierra Research, and it takes a fundamentally different approach. Instead of grading individual function calls, it grades outcomes. They set up multi-turn dialogues in airline, retail, and telecom domains, use an LLM-based user simulator to generate natural requests, and then — here's the key insight — they compare the final database state against a goal state. If the database ends up correct, the agent passed. They don't care what sequence of tool calls got it there.
I think this is more honest, as Daniel put it, for a reason that's subtle but important. When you grade on tool-call sequences, you're implicitly saying there's one correct path. But real tasks often have multiple valid paths. An agent might take a different route to the same outcome — maybe it checks availability before looking up a loyalty number, when the "reference" sequence does it the other way. Sequence-based grading penalizes that. Database-state grading doesn't.
It also catches something sequence grading misses entirely. An agent can make all the "correct" calls in the "correct" order and still produce the wrong final state — maybe it applied a discount wrong, or booked the wrong flight segment. Sequence grading says "perfect." Database-state grading says "you failed.
Tau-bench has this metric called pass-k that I think is one of the most important innovations in agent evaluation. It's not just single-trial success — pass at one. It's consistency across k repeated trials. Even GPT-four-o scored under fifty percent pass at one, and pass at eight — meaning the same model succeeded on all eight attempts — was under twenty-five percent in retail. That's brutal. The model can do the task sometimes, but it can't do it reliably. And reliability is what production systems need.
That pass-k metric exposes something that single-shot benchmarks completely hide. You look at a leaderboard, you see a seventy percent score, you think "that's pretty good." But if pass at eight is under twenty-five percent, it means your agent is going to fail most of the time on multi-step tasks. You just won't know which time.
Anthropic now reports tau-bench pass-k in their model cards, which is a good sign — it means the industry is starting to take reliability seriously as a separate dimension from raw capability. Claude three point seven Sonnet was announced as the top performer when it launched. But even top performers show enormous variance. The same model, same task, same prompt — different outcomes on different runs. That non-determinism is a production nightmare.
BFCL tells you whether your model can produce structurally correct function calls at scale. Tau-bench tells you whether your agent can reliably achieve correct outcomes in multi-turn dialogues. Neither of them tells you much about what happens when you deploy on APIs the model has never seen before. That's where Nexus comes in.
Nexus is from Nexusflow, and it's a zero-shot function-calling benchmark focused on cybersecurity tools and API interactions. They test on things like the NVDLibraryBenchmark — that's National Vulnerability Database — VirusTotalBenchmark, and various IT and ticket tracking benchmarks. These are specialized, domain-specific APIs that models are extremely unlikely to have seen in training.
The scores are... The top score on the Nexus leaderboard is about zero point five nine — that's from Llama three point one four hundred five B Instruct. The four-model average is zero point four seven. So even the best models are getting less than sixty percent on zero-shot generalization to niche security APIs.
This is the long-tail problem. Models overfit to common API patterns — search, weather, math, calendar. They've seen thousands of examples of those in training. But enterprise deployment is all about the long tail — proprietary internal APIs, specialized industry tools, security infrastructure. The patterns are different. The parameter names are domain jargon. The expected behaviors are non-obvious. And the models just collapse.
There's a related benchmark called NESTFUL that tests nested API sequences — where you call one API, take the output, feed it into another API, and so on. GPT-four-o scored twenty-eight percent on full-match accuracy. Twenty-eight percent. That's not a typo. These are multi-step chains of specialized tools, and the models can't maintain coherence across the sequence.
NESTFUL is testing the exact pattern that production agents use constantly. Look up a user by email, get their account ID, use that to query their permissions, use that to check access on a resource, use that to generate a report. Four nested calls. Each depends on the previous one. If any call returns something unexpected, the whole chain breaks. The twenty-eight percent number tells you that GPT-four-o gets the full chain correct less than a third of the time.
We've got three benchmarks, each catching different failure modes. BFCL catches structural errors at scale but misses semantic wrongness. Tau-bench catches outcome failures and reliability problems but only in simulated environments with known domains. Nexus catches the long-tail generalization problem but is limited to specific security APIs. And none of them — none of them — test for the failure modes that actually kill production systems.
Let's go through those production failure modes one by one, because this is where the benchmarks and reality really diverge. First one: hallucinated tool names. The model invents a function that doesn't exist. It decides it needs a "send email" tool, or a "query database" tool, and just... makes one up. This is especially common with open-source models that haven't been fine-tuned for accurate tool calling. There's a GitHub issue in the CrewAI repo — issue number seven sixty-three — where models like Llama three were observed generating calls to tools that don't exist in the provided schema, causing infinite loops.
The infinite loop part is what makes this particularly nasty. The agent calls a hallucinated tool, gets back an error or nothing, and then... Or tries a different hallucinated tool. It doesn't know it's hallucinating — from the model's perspective, it's making perfectly reasonable function calls. The schema says there's a search tool, so why wouldn't there be a "send notification" tool? It pattern-matches from its training data.
No benchmark really tests for this systematically. BFCL gives the model a fixed set of functions and checks whether it calls the right ones — but the set is provided, and the model isn't tested on whether it invents functions outside that set. Tau-bench has a closed tool environment. Nexus has a defined API surface. Hallucinated tool names are a phenomenon that emerges in open-ended agent deployments where the model has more freedom, and the benchmarks don't capture it.
Second failure mode: parallel tool-call ordering errors. When a model needs to make multiple independent calls — say, checking weather in three cities simultaneously — it often gets the parallelism wrong. Either it makes redundant duplicate calls because it forgets it already fetched a piece of data, or it executes calls sequentially that should be parallel, doubling or tripling latency. The BFCL V four leaderboard shows that "Parallel Multiple" sub-scores are consistently lower than simple or single-parallel scores across all models.
The cost implications are real. If your agent is making sequential calls where parallel calls would work, you're paying for the extra round-trips in both latency and API costs. There was a piece on the CodeAnt blog about this — poor tool-calling behavior directly inflates costs and slows down response times. A sequential call pattern that should be parallel can easily double your per-task cost and make the user wait twice as long.
The ordering errors are even worse when there are dependencies between calls. The model needs to call tool A, get the result, then call tool B with that result. But it tries to call both in parallel, tool B fails because it's missing the input from tool A, and the whole workflow collapses. Or it calls them in the wrong order, gets an error from tool B, and doesn't understand why.
Third failure mode, and this one is insidious because it's silent: schema drift across model versions. As model providers update their APIs, the tool-calling schema changes. Parameter names shift. Required fields become optional. Type constraints relax or tighten. An agent that worked perfectly on GPT-four zero six one three breaks on GPT-four zero one two five Preview because the model interprets the same schema differently.
This is the M-by-N problem, as it's been called. Every model version times every tool schema is a new compatibility surface. You have M models and N tool definitions, and any update to either one can break previously working integrations. And it's not like the model throws an error — it just starts producing slightly different function calls. Maybe it capitalizes parameter names differently. Maybe it changes the order of fields. Maybe it starts including optional parameters it previously omitted. The calls still look valid, but the downstream tool parser rejects them.
No benchmark currently measures this. BFCL evaluates models against a fixed schema set. Tau-bench has a fixed tool environment. Nexus has fixed APIs. Nobody is testing "did this model's tool-calling behavior change between versions when given the exact same schema?" It's an infrastructure problem — schema versioning, compatibility layers — that the evaluation community hasn't addressed.
I think the industry eventually needs a standardized tool-calling protocol. Something like OpenAPI but specifically for LLM agents. A way to declare tool schemas that's versioned, validated, and consistent across model providers. Right now every provider does it differently — OpenAI uses JSON Schema, Anthropic has its own format, open-source models are all over the map. It's a Tower of Babel situation.
The fourth failure mode is the one that worries me: sycophantic confirmation of clearly wrong arguments. This is when the model calls a tool, gets back an error or an unexpected result, and then... proceeds as if everything is fine. It swallows the error. Or worse, it confirms incorrect arguments back to the user. "Yes, I've booked your flight for February thirtieth." The tool returned an error saying that date doesn't exist, but the model saw the error, ignored it, and told the user everything is fine.
This is what makes it the most insidious failure mode. There's no exception thrown at the agent framework level. The tool call succeeded — it returned a response. The response happens to contain an error message, but the model treats it as valid data and moves on. The failure is entirely in the model's reasoning, and it's invisible to monitoring systems unless you're specifically parsing tool responses for error patterns.
Research from last year found that error propagation was the most common failure pattern in LLM agent trajectories, with memory and reflection errors being the most frequent cascade sources. The Future AGI piece on how tool chaining fails in production cites this directly. The model gets an error, doesn't recognize it as an error, stores it in memory as a fact, and then makes downstream decisions based on that corrupted state.
Here's the thing — tau-bench's database-state grading would catch the outcome failure. If the model books the wrong date, the database state is wrong, and the agent fails the task. But it doesn't distinguish between "the agent knew it was wrong and tried anyway" versus "the agent thought it was right." Those are very different failure modes with very different fixes. Sycophancy requires training interventions. Genuine confusion requires better reasoning. Same benchmark score, completely different solutions.
We probably need adversarial evaluation specifically for this. Deliberately give agents bad tool results — error codes, unexpected nulls, malformed responses — and measure whether they detect and escalate the error. Does the agent say "I received an error from the booking system, let me try again" or does it say "your flight is confirmed"? That distinction is critical for safety, and nobody's benchmarking it.
There's one more production failure mode that ties all of this together, and it's what's been called the hundredth tool call problem. Agents degrade over long runs. Context windows overflow and critical details get compressed or forgotten. State gets corrupted. One timeout cascades into a dozen downstream failures. There was a case documented by a researcher named Hugo Nogueira — a production agent ran for an hour and forty minutes, made three hundred sixty-nine tool calls, consumed nine point seven million tokens, hit context limits twice, had to recover from a corrupted checkpoint once, and nearly published an incomplete analysis before a guardrail caught it.
Three hundred sixty-nine tool calls. Nine point seven million tokens. And that's not an extreme outlier — that's what happens when you let an agent run autonomously on a complex task. The benchmarks we've been discussing test single calls or short sequences. BFCL's longest test is maybe a few parallel calls. Tau-bench has multi-turn dialogues but they're constrained. Nexus is single-shot. Nobody is testing what happens at call number two hundred.
The degradation isn't linear. It's not like the agent is ninety percent as good at call two hundred as it was at call ten. There are phase transitions. The context window fills up, the model starts losing details from early in the trajectory, and suddenly it's making decisions based on incomplete information. It forgets that it already tried an approach and it didn't work. It repeats itself. It loses track of what it was trying to accomplish.
This is where I think we need a new class of benchmark entirely. Not per-call accuracy, not even multi-turn task completion, but durability over long trajectories. How many calls can the agent make before its success rate drops below some threshold? What's the half-life of its reasoning quality? These are the metrics that actually matter for production deployment, and we have essentially no standardized way to measure them.
Let's pull back and talk about what this means for someone actually building on these models. If you're deploying a tool-calling agent in production, what do you actually do with all this information?
First, you ignore top-line leaderboard numbers. A seventy-seven percent on BFCL or a pass-at-one score on tau-bench tells you almost nothing about whether your specific agent will work on your specific tools. You need to evaluate on your own tool schemas, with your own task distributions, over realistic trajectory lengths.
Second, you build defense in depth against these failure modes. For hallucinated tool names, you validate every function call against your actual tool registry before executing it — never trust the model's output directly. For parallel call ordering, you implement a call scheduler that analyzes dependencies and parallelizes where safe. For schema drift, you version your tool schemas and test every model update against them before deploying. For sycophantic confirmation, you parse tool responses for error patterns and flag anything that looks like the model is ignoring a failure.
Third, you monitor everything. Tool call success rates, error propagation rates, trajectory lengths, context window utilization. If your agent's average trajectory length is creeping up, that's a warning sign — it might be getting stuck in loops. If error propagation is increasing, your model might be getting worse at recognizing failures. These are leading indicators of problems that will eventually surface as user-facing failures.
Fourth, you design for graceful degradation. Assume your agent will fail eventually — what happens then? Can it checkpoint its state and resume? Can it escalate to a human? Can it fail safely without corrupting data or sending wrong information to users? The hundredth tool call problem isn't solvable by making models better — it's solvable by building systems that are resilient to model degradation.
I think there's also a deeper architectural question here that the field is going to have to grapple with. The current paradigm — generate a JSON function call, execute it, feed the result back into the context window, repeat — has fundamental scaling limits. Context windows aren't infinite. Attention quality degrades with length. Cost scales with token count. At some point, we need architectures that don't require the model to hold the entire trajectory in context.
There's work on code-generation agents that write tool-calling code rather than predicting JSON — the model generates a Python script that makes the calls, and the script executes. That separates the reasoning from the execution. The model thinks once, generates a plan as code, and the code handles the execution details. It's not a silver bullet, but it addresses some of the context-window problems.
There's retrieval-augmented tool calling — instead of putting all tool schemas in the prompt, you retrieve the relevant ones at runtime based on the task. That reduces prompt bloat and makes it easier to handle large tool libraries. But it introduces its own failure mode: what if the retrieval system doesn't surface the right tool? Now the model can't call it even if it wanted to.
The fundamental tension is between capability and reliability. Every new capability — more tools, longer trajectories, more complex reasoning — creates new failure modes. The benchmarks we have today are measuring capability. What we need are benchmarks that measure reliability under stress. Noisy tool responses. That's where the real engineering challenge is.
The field is starting to wake up to this. The fact that BFCL V four added hallucination measurement and multi-turn evaluation is a step in the right direction. Tau-bench's pass-k metric is exactly the kind of reliability measurement we need more of. But we're still early. The gap between what benchmarks measure and what production systems need is enormous, and it's not closing fast enough.
If I had to bet on where the biggest impact will come from in the next year or two, it's not better models. It's better evaluation. Better ways to measure reliability, better ways to detect silent failures, better ways to stress-test agents before deployment. The models will keep improving — that's happening regardless. But knowing whether they're actually good enough for a specific production task, and knowing what will break first — that's the harder problem.
It's a problem that requires infrastructure, not just research. Standardized tool schemas. Versioned compatibility testing. Adversarial evaluation suites. Production monitoring for agent-specific failure modes. These are engineering problems, and they're not glamorous, but they're what stands between the current state of tool calling and actually reliable autonomous agents.
To bring it back to Daniel's question — the state of tool-calling evaluation is fragmented, each benchmark catches different things, and none of them catch the failures that actually wake you up at three in the morning. BFCL tells you about structural correctness. Tau-bench tells you about outcome reliability. Nexus tells you about generalization to rare APIs. What none of them tell you is whether your agent will still be working correctly after two hundred tool calls, or whether it will silently confirm a wrong booking and smile while doing it.
That's the evaluation gap that matters. Thanks to our producer Hilbert Flumingtop for making this episode happen, and thanks to Modal for sponsoring the show — serverless infrastructure that actually scales.
This has been My Weird Prompts. Find us at myweirdprompts dot com for every episode, transcripts, and the full archive. We'll be back with more.
Until then, may your function calls be valid and your database states correct.
