An agent answers a customer's question correctly. The eval passes, green. In getting there, it called an internal admin API it should never have touched, guessed half the arguments, and landed on the right number by luck. The eval saw "correct answer" and moved on. You just shipped a system that will eventually call that same API with worse luck.
A right answer from the wrong tool call is still a bug. And most agent evals can't see it, because they grade the output and ignore the path that produced it.
The answer is not the action
For a chatbot, the output is the product — scoring the answer is enough. For a tool-using agent, the output is the visible tip of something that also read data, called APIs, and changed state. Two agents can produce the identical correct answer: one by calling the right tool with the right arguments and stopping before the irreversible step, the other by calling the wrong tool, guessing parameters, and getting lucky. Same answer. Same eval score. Wildly different production risk.
That's why the eval has to include side effects, not just the transcript: did the agent call the right tool, avoid the ones it wasn't allowed to, pass the right arguments, stop before the irreversible action, and leave the audit event a human would need later? An eval that only reads the final answer is blind to the part of the system that can actually do damage.
The research already separates these signals
Here's the tell: even at training time, the field has stopped treating tool use as a single reward. ToolRL decomposes the tool reward into matching tool names, parameter names, and parameter values — three separate signals, because "called a tool" and "called the right tool correctly" are different things. THOR uses hierarchical RL that scores trajectory-level problem-solving and step-level code-execution success as distinct objectives. ReTool interleaves code execution with reasoning and rewards when and how tools get invoked, not just the answer that falls out the end.
The throughline is hard to miss: if the researchers training these models score the tool call separately from the answer, your production eval — the thing that decides whether a change ships — can't afford to collapse them into one pass/fail.
What this means for how you evaluate
- Score the trajectory, not just the answer. The blocking eval checks the tool calls: right tool, right arguments, allowed for this user and this object state, stopped before anything irreversible, audit event emitted.
- A correct answer reached through a bad tool call is a failed eval, not a pass. Getting it right by luck is precisely the failure mode you're trying to keep out of production — it passes today and bills you tomorrow.
- You can only grade the tool call if you can see it. That's a trace, not a log — and the runtime version of this discipline is a verifier that checks the action before the side effect fires.
In a chatbot, the answer is the whole story. In an agent, the answer is the part the customer sees — and the tool call is the part that moves the money, touches the data, or books the wrong flight. Grade both, or you're shipping a system that's right until it's expensively wrong.