Why AI Agents Fail at Tool Use (and How to Design Tools That Don't)

When an AI agent misbehaves — calling the wrong tool, looping, or passing malformed arguments — the instinctive fix is to swap in a bigger model or rewrite the system prompt. That usually isn't where the problem lives. Anthropic's own engineering guidance on building effective agents is blunt about this: agentic systems fail mainly through compounding errors and rising cost as the number of steps grows, and the fix is extensive testing in sandboxed environments, clear stopping conditions, and human checkpoints — not a model swap. A companion piece, writing tools for agents, goes further: tool quality is usually the first lever to pull, and small wording changes in a tool's description can have large effects on whether an agent calls it correctly.

Workflow or agent? Start with the simplest thing that works

Not every AI feature needs to be an autonomous agent looping on its own tool calls. Anthropic's building-effective-agents guidance lays out a small set of patterns, roughly in order of increasing complexity, and recommends adding complexity only when it clearly improves results:

• Augmented LLM — a single call enhanced with retrieval, tools, and memory. Often enough on its own.
• Prompt chaining — sequential steps with a programmatic check between them. Trades speed for accuracy.
• Routing — classify the input first, then send it to a specialized prompt, tool, or cheaper model for the easy cases.
• Parallelization — split independent subtasks across calls, or run the same task multiple times and vote on the result.
• Orchestrator-workers — a central LLM breaks a task down, delegates the pieces, and synthesizes the results.
• Evaluator-optimizer — one call generates, another critiques, in a loop. Works best with clear evaluation criteria.
• Autonomous agents — an LLM uses tools in a loop guided by feedback from its environment, for problems where the number of steps can't be predicted up front.

Reach for the last pattern only when the task is genuinely open-ended. Workflows are more predictable, cheaper to run, and far easier to debug than a full agentic loop — and most "agent" use cases people describe are actually a workflow in disguise.

Four ways tool design quietly breaks agents

1. Descriptions that leave questions open

Anthropic's tool-definition guidance contrasts two descriptions for the same tool. The weak version — "Gets the stock price for a ticker" — leaves the model guessing at what the tool actually returns and when to call it. The strong version states the exchange it covers, the currency it returns, when to use it, and explicitly what it won't tell you. The guidance recommends at least 3-4 sentences per tool description, more if the tool is complex, and reserving input_examples for schemas with nested objects or format-sensitive parameters.

2. Too many tools that overlap

Anthropic's writing-tools-for-agents guidance warns that overlapping tools distract agents from efficient strategies — the model has to spend reasoning effort deciding between two tools that do almost the same thing. The fix is consolidation: a single schedule_event tool that finds availability and books the event beats separate list_availability and create_event tools the agent has to chain itself. Namespacing tool names by service (github_list_prs, slack_send_message) keeps a growing tool library unambiguous.

3. Responses that bury the signal

A tool that dumps a full record — internal IDs, timestamps, every field in the row — forces the model to spend context figuring out what matters. The same guidance recommends returning high-signal fields (names, stable slugs) instead of opaque identifiers, and preferring a targeted tool like search_logs, which returns only the relevant lines with context, over a read_logs tool that returns everything.

4. Errors that don't tell the model what to fix

An agent can self-correct from a tool_result that says what went wrong and how to fix it. It can't self-correct from a bare error code or a raw stack trace — it will usually just retry the same malformed call.

Designing tools that hold up in production

Put together, Anthropic's tool-use documentation and engineering guidance point to a short, concrete checklist:

• Write descriptions like onboarding a new hire — what the tool does, when to use it, when not to, and what each parameter means.
• Consolidate related actions into one tool with a parameter instead of one tool per API endpoint.
• Use unambiguous parameter names (user_id, not user) and strict types.
• Turn on strict tool use for anything that feeds a downstream system. Setting strict: true constrains the model's token sampling to schema-valid output, so a passenger-count field can't come back as "two" or "2" when your code expects the integer 2 — it guarantees type-safe arguments instead of making you validate and retry after the fact.
• Return only what the next step needs. Paginate, filter, and truncate large responses, and steer the model toward a narrower query instead of dumping everything.

Guardrails that catch what good tool design can't

Even well-designed tools don't make an agent infallible, so the building-effective-agents guidance pairs tool quality with explicit guardrails before anything reaches production:

• Sandboxed evaluation against realistic, multi-step tasks — not a toy scenario, and not graded only on the final answer. Anthropic's own process tracks accuracy alongside tool call counts, token use, and error rate, and reads full transcripts, since what an agent leaves out of its reasoning can matter as much as what it says.
• A maximum iteration count, so a confused agent fails loudly instead of looping indefinitely and running up cost.
• Human checkpoints at the steps where a wrong call is expensive to undo.
• Clear, verifiable success criteria for each step — automated tests for code, a schema check for structured data — rather than trusting the agent's own account of whether it succeeded.

None of this is specific to one model or vendor. If you're building an agent that calls tools against your own systems — a CRM, an internal API, a billing platform — the discipline is the same regardless of which model sits behind it: design the tools first, evaluate them against real workflows, then decide how much autonomy the agent actually needs. That evaluation step is also where you catch the model-choice and prompt problems people usually blame first — see our guide to LLM evaluation for how to structure it. If you're weighing a managed protocol against hand-rolled tool integrations for that same agent, we cover the trade-off in MCP vs. custom API integration.

This is also exactly where our AI integration work starts: proving tool reliability against real workflows in a sandboxed evaluation before an agent is allowed to touch production data, rather than discovering the failure modes after launch.