Why AI Agents Fail to Act — Even When They Know What to Do
If you've deployed an AI agent that calls tools — books meetings, updates a CRM, files a ticket — you've probably seen it stall out on something that should be trivial. The model reasons correctly. It knows exactly what needs to happen next. And then it fails to actually do it: the wrong parameter, a malformed call, a tool that never gets invoked at all.
A new research paper puts a name and a number on that failure mode, and the findings matter for anyone running agents in production — especially small and mid-sized teams without a dedicated ML ops function.
The paper
"When Agents Fail to Act: A Diagnostic Framework for Tool Invocation Reliability in Multi-Agent LLM Systems" (Huang, Malwe, and Wang — Singapore Management University and Mastercard R&D) tackles a gap that's easy to overlook: most agent benchmarks grade whether the final answer is correct, not whether the agent reliably invokes the right tool, with the right parameters, at the right moment. Those are different problems, and the second one is where a lot of real-world agent deployments quietly break.
The team built a diagnostic framework — a 12-category error taxonomy covering failures across four stages of the tool-use pipeline:
- Tool initialization — the agent fails to recognize a tool is needed, or picks the wrong one
- Parameter handling — arguments are missing, malformed, or hallucinated
- Execution — the call is issued but fails or times out
- Result interpretation — the tool returns valid output, but the agent misreads or ignores it
They ran 1,980 deterministic test instances across a spread of models — open-weight (Qwen2.5 series, Functionary) and proprietary (GPT-4, Claude 3.5/3.7) — on varied edge-hardware configurations, framed specifically around SME-centric, privacy-sensitive deployment scenarios (i.e., not everyone can or wants to route every tool call through a frontier-model API).
What they found
Two results stand out.
Tool initialization is the bottleneck, not execution. For smaller models, the primary source of failure wasn't botched parameters or flaky tool execution — it was simply failing to recognize that a tool call was needed in the first place, or reaching for the wrong tool. That's a reasoning/routing failure, not an infrastructure one, and it's much harder to catch with standard "did the API call succeed" monitoring.
Scale buys reliability, but not linearly. Qwen2.5:32B reached flawless performance on this benchmark — matching GPT-4.1. Smaller variants in the same family did not. That's a useful data point if you're weighing self-hosted or edge-deployed models against proprietary APIs purely on cost: below a certain scale threshold, procedural reliability degrades in ways that a "the model seems smart in conversation" spot-check won't reveal.
Why this matters beyond the benchmark
Most teams evaluate agents the way they'd evaluate a chatbot: does the response sound right? Tool-invocation reliability is a different axis entirely, and it's the one that actually determines whether an agent can be trusted to act — send the email, update the record, trigger the workflow — without a human re-checking every step.
A few practical takeaways if you're building or buying agent systems:
- Test the pipeline stage, not just the outcome. If your evaluation only checks final task success, you can be blind to a model that gets the right answer despite fumbling a tool call, and you won't see the failure mode until it happens somewhere with real consequences.
- Initialization failures are a routing problem — treat them like one. If an agent is skipping tool calls it should be making, more parameter validation won't fix it. That's a signal to tighten tool descriptions, reduce ambiguity between similar tools, or add explicit routing logic.
- "Good enough at reasoning" isn't "good enough at acting." A model that reasons well in eval transcripts can still be unreliable at the mechanical step of invoking a tool correctly and consistently. Procedural reliability needs its own evaluation, especially before you hand an agent write access to anything that matters.
- Model size thresholds are a real cost lever. If you're choosing between a smaller self-hosted model and a larger proprietary one, factor in where reliability falls off — not just raw benchmark scores or per-token cost.
The bigger picture
This kind of diagnostic thinking is exactly why AI employees need real operational guardrails, not just a capable underlying model. Reliable tool invocation — knowing when to act, acting with the right parameters, and correctly interpreting what happened — is the difference between an agent that assists and one you can actually delegate to.
It's also a reminder that the industry's evaluation habits are still catching up to how agents are actually used. "Did it answer correctly" was the right question for chatbots. "Did it act correctly, every time, without supervision" is the right question for agents — and it's a much higher bar.
Curious how AI employees handle tool reliability in practice? See how Odella's AI employees work.