Tool Use Is the Hard Part of Agentic AI

Ask teams what model they plan to use and you usually get a confident answer. Ask which CRM fields the agent may update, what happens when Jira returns a 500, or who owns the calendar connector when OAuth expires, and the room slows down. That second conversation is the real project.

Agentic AI lives or dies on tool use. The model proposes. The tools do. If the tools are brittle, over-privileged, or poorly described, a clever model just fails with more confidence.

Why tools beat model shopping as the bottleneck

Models are relatively easy to swap in many stacks. Your ticketing taxonomy, CRM custom fields, and internal APIs are not. They carry years of exception handling, half-documented side effects, and permission models that were never designed for a non-human caller.

When an agent "uses tools," it typically:

• Chooses a function or API from a list
• Fills arguments (IDs, dates, filters, text)
• Receives a response (or an error)
• Decides what to do next

Each of those steps can go wrong. Wrong ticket ID. Date in the wrong timezone. Filter that returns 10,000 rows. Silent partial success. The model did not invent your integration debt. It just runs into it at machine speed.

Calendars, tickets, CRM: familiar systems, sharp edges

Take a simple goal: "Schedule a follow-up and open a ticket if the client risk flag is high." On a whiteboard that is three steps. In production it touches identity, calendar free/busy rules, ticket required fields, CRM picklists, and maybe a notification channel.

Sharp edges I keep seeing:

• Ambiguous identifiers: which "Acme" account is the right one?
• Write amplification: one wrong bulk update becomes hundreds of bad records
• Side effects: creating a ticket that auto-emails a customer
• Stale schemas: tool description says field X is optional; production says required
• Auth drift: tokens expire, scopes change, service accounts get locked

None of that is solved by a newer model release. It is solved by integration design, testing, and operations.

Design tools that fail safely

Treat each tool as a product surface for an unreliable-but-fast junior operator. That mindset changes the API you expose to the agent.

Patterns that help:

• Narrow tools over god tools. "Create draft ticket in project A with these fields" beats "call Jira with arbitrary JSON."
• Dry-run and draft modes. Prefer create-draft / propose-change over immediate write when the impact is high.
• Idempotency keys. Retries should not create five duplicate tickets.
• Hard limits. Max rows, max messages, max dollar amount, max records touched per run.
• Clear errors. Return structured failures the agent (and logs) can use, not a vague HTML error page.
• Least privilege. Separate read tools from write tools. Separate sandbox credentials from production.

Human approval still belongs in front of high-impact writes. Tool safety and human-in-the-loop design work together. One without the other is incomplete.

Descriptions are part of the interface

Agents choose tools based on names and descriptions as much as on code. Vague descriptions produce creative misuse. Overlong descriptions get ignored. Good tool docs for agents look a lot like good API docs for humans: when to use, when not to use, required fields, examples, and side effects.

If two tools overlap ("search accounts" vs "search contacts"), spell out the difference. If a tool is expensive or slow, say so. If a tool should never be used for external communication, say that in the description and enforce it in code.

Standards and reusable connectors

Building one-off function calling for every model and every app gets old fast. That is why protocol and connector strategies matter. I cover this more in why the protocol can matter more than the model: a shared way to expose tools and data reduces the rewrite tax when hosts or models change.

MCP is not a free lunch. You still need auth, governance, evaluation, and careful tool design. It can, however, shift the work from "new glue for every chat product" toward "stable connectors many agents can use." For company knowledge, pair tools with RAG so the agent is not inventing policy while it happily calls your CRM.

How to scope a tool-first pilot

Skip the all-systems vision. Pick one workflow and list:

1. Systems touched
2. Read vs write for each
3. Required human gates
4. Failure modes and owner
5. What "done" looks like in the source systems, not only in the chat transcript

Then build the smallest tool set that can finish a real artifact. Measure broken tool calls, human overrides, and time-to-done. If the model is fine but the connectors are chaos, you have your roadmap.

The practical takeaway: model choice is rarely the long pole. Tool contracts, permissions, failure behaviour, and observability are. Design those as carefully as you would design an API for a third-party partner, because that is what the agent is. A partner that works very fast, never gets tired, and will use any tool you left unlocked.