Evaluating AI Agents on Tool Calling and Planning

An agent that picks the right function 90% of the time can still fail the task nine times out of ten. Tool calls compound: get the fourth one wrong in a twelve-step sequence and everything after it is built on a bad result.

Tool calling and planning are the same failure surface in practice. The plan decides which tools get called and in what order, and a tool result that comes back wrong invalidates the plan. Here is what the current benchmarks measure, what they get wrong, and what to do instead.

This is one of three pieces on evaluating AI agents. Each stands alone, and together they cover the capabilities, the reasoning and the risks:

• Evaluating AI Agents on Tool Calling and Planning (you are here)
• Can AI Agents Catch Their Own Mistakes?
• Evaluating AI Agents for Manipulation, Deception and Adversarial Risk

Identifying meaningful agent benchmarks

Tool calling is an agent's ability to select an external function, supply correct arguments, and use what comes back. Four benchmark families cover it and the planning that precedes it.

Function calling benchmarks: Why multi-state handling outweighs syntax

The Berkeley Function-Calling Leaderboard is the reference for raw function-calling ability. Its current version, V4, is the one worth reading: it added multi-hop web search, memory retrieval across key-value, vector and recursive-summarization backends, and format sensitivity.

The most decision-relevant number on it is the gap between two of its own columns. Claude Opus 4.5 leads overall at 77.47% while scoring roughly 89% on non-live syntax checking. Single-turn accuracy is saturated. Multi-turn state handling and memory are where models separate, at 68.38% and 73.76% for the same model.

The format sensitivity results are the quiet find. Running the same 200 tasks under 26 prompt variations showed JSON and Python return formats consistently outperform XML, and JSON function documentation beats both. If you are choosing a serialization format for your tool schemas, that is a free accuracy decision.

Check cost before you commit. A full BFCL run cost $86.55 on Claude Opus 4.5, $298.47 on Gemini 3 Pro Preview and $4.64 on GLM-4.6 — a 64-fold spread across models within eight points of each other.

Evaluating policy compliance with pass^k metrics

τ²-bench evaluates agents in multi-turn conversations against realistic databases, APIs and domain policy documents, with a simulated user who can also act on the world rather than only talk about it. It grades the final state of the database rather than the individual calls, which allows multiple valid paths to a goal. Adding an active user cost about 20 points of single-attempt accuracy.

It is now close to saturated, with leading models above 85%. τ³-bench, released in March 2026, is where the headroom moved. Its banking variant pairs tasks with a knowledge base of roughly 700 documents and averages 9.5 tool calls per task, and leading models sit in the 45-55% range. A voice variant tests full-duplex interaction with interruptions, accents and background noise.

The metric to take from this family is pass^k: whether an agent succeeds at the same task on k consecutive independent attempts, not at least once. Single-attempt accuracy routinely overstates pass^8 by thirty points or more. Since users encounter your agent repeatedly, pass^k is the number that predicts what they will experience.

One caution on comparability: Sierra audited and corrected more than 50 airline and retail tasks in February 2026, so results either side of that revision are not directly comparable.

Planning: Frontier models surpass classical solvers

PlanBench remains the standard planning benchmark, testing plan generation, verification and adaptability in controlled domains where genuine planning can be separated from retrieval of something seen in training. Its most useful variant obfuscates the predicate names, leaving the identical planning problem with the vocabulary stripped out — historically the point where language models collapsed.

That boundary has moved. Researchers testing frontier models against International Planning Competition tasks in late 2025 found Gemini 3.1 Pro solving 245 of 360 problems against 234 for the strongest classical planner baseline. On some task distributions, models have caught up.

Two limits still hold, and both matter for design. Performance degrades when the semantics are obscured, which suggests the gains are not purely about search. And models remain poor at recognizing that a problem has no solution, producing confident, complete, impossible plans rather than reporting failure. If your agent plans against constraints that can be infeasible, test the infeasible cases explicitly — it will not tell you.

For anything that can be formally specified, a classical planner is still faster, cheaper and complete. The interesting question is not whether a model can plan, but whether it can plan in the underspecified settings where you cannot write down a domain definition.

Measuring long-horizon performance and real-world reliability

METR measures what teams actually care about: how long a task can be before the agent stops finishing it. Its headline metric is the human task duration at which an agent succeeds half the time, and the doubling time for models since 2023 is roughly 129 days — considerably faster than the seven-month figure still widely repeated.

Two caveats keep it honest. METR states measurements above sixteen hours are unreliable with the current task suite. And the 80% horizon is far shorter than the 50% one: roughly seventy minutes against twelve hours for the same model. That order-of-magnitude gap between "can sometimes" and "can reliably" is the same story pass^k tells, and it is where most production disappointment comes from.

Taxonomy of failure: Diagnosing tool selection and execution errors

ToolFailBench, published in July 2026, gives the most usable failure taxonomy: tool-skip, where the agent answers from parametric knowledge instead of calling the tool it needs; result-ignore, where it calls the tool then disregards the output; output-fabrication, where it invents a result; and unnecessary-tool-use, where it calls a tool for a question that did not need one.

Its central finding is the one to design around. Models with nearly identical aggregate scores fail in completely different ways — two similarly sized open models differed by 89 percentage points on control tasks built to require no tool at all. Tool discipline is a property of how a model was trained, not of how large it is, so a leaderboard position will not tell you which failure mode you are buying.

For multi-agent systems, MAST catalogs 14 failure modes from 150 annotated traces: specification and design issues account for roughly 42%, inter-agent misalignment 37%, and task verification 21%. Almost four in five failures are not the model being wrong about a fact — they are architecture.

The reliability gap: Measurement errors in public benchmarks

A 2026 validity audit examined BFCL V4, τ²-bench and two MCP benchmarks across 496 expert-assessed tasks and found the automated evaluator disagreed with human judgment on 18.5% of them. Deterministic benchmarks failed through brittle state matching, trajectory lock-in that penalizes valid alternative paths, and wrong ground truths. Model-judged benchmarks failed through rubric drift and hallucinated completion.

The same audit re-ran one benchmark 23 times in an identical configuration and got scores from 57.9% to 76.8% — an 18.9-point spread, wide enough to reorder a leaderboard by itself. Treat positions separated by a few points as indistinguishable.

Then there is the simpler problem. A benchmark measures a model on someone else's tasks, with someone else's tools, under someone else's policies. No public benchmark will tell you that your refund tool silently truncates order IDs above a certain length.

That specificity is why error localization matters more than error detection. Work on agent error taxonomies traced how a single root-cause error cascades through every subsequent decision in a trajectory. Knowing a run failed is nearly useless; knowing which step went wrong first is what you act on, and it is substantially harder to determine.

How to operationalize agent observability

With the move away from static benchmarks to production monitoring, you are operationalizing observability in agentic systems. These three practices follow from everything we’ve covered above.

1. Instrument at the granularity of the failure. A tool selection error happens at a single model call; a wasteful path happens across a session. Evaluation that only inspects final output makes both invisible and leaves you reading transcripts.
2. Write assertions specific to your domain. "Did it pick a reasonable tool" is worth far less than "did it check inventory before promising a delivery date." The rules your agent must follow are the rules worth testing, and no external benchmark contains them.
3. Measure consistency, not just success. Run the same task repeatedly and track pass^k. An agent that works most of the time is a different product from one that works reliably.

Agent observability with Splunk

This is what Splunk Agent Observability is built to do: structure agent runs as spans, traces and sessions and attaches evaluators where each failure type occurs — Tool Selection Quality and Tool Errors at the individual call, Agent Efficiency and Action Completion across a session. Agent Flow validates a trajectory against tests written in plain language, which is the honest answer to domain specificity: it ships as a template you fill in with your own assertions and does nothing until you write them. Signals sweeps production traces for failure patterns you did not think to look for, and any pattern it surfaces can become a tracked evaluator.

The evaluator documentation covers what attaches where, or you can explore the platform.

Conclusion

The benchmarks converge on a consistent message. Single-turn function calling is solved. Multi-turn state management, long-horizon consistency, and planning under obscured or infeasible conditions are not. The reliability gap between succeeding once and succeeding repeatedly is the most decision-relevant number available, and it is the one most often left off a leaderboard.

Use benchmarks to shortlist a model. Then evaluate your own agent on your own tasks, because the failures that will cost you are the ones no public benchmark contains.

FAQs on agent tool calling and planning