Tools Are What Make an Agent Useful, Not the Model Alone

The model inside an agent is only half the story. What separates a genuinely useful agent from an impressive demo is the set of tools it has access to and how well those tools are built.

What a tool is, concretely

A tool is a specific, narrow capability the agent can call on: search a database of public filings, pull the text of a specific document, check a name against a client list, send a draft to a named person for approval. Each tool does one thing reliably, and the agent decides when to use which one.

Why narrow tools beat a general one

A tool built specifically to fetch a company's filings from an official source is more reliable than asking a general model to 'remember' what it might know about that company from training data. The narrow tool goes and gets the actual current document. That is a meaningful reliability difference, not a cosmetic one.

The design work firms underestimate

Building a good agent is mostly the work of building and testing its tools, deciding what data sources it can reach, what actions it can take without asking, and what actions require a person's sign-off first. That design work, done carefully, is what determines whether the agent is trustworthy enough to run unsupervised on the easy 80 percent of a task, or whether it needs a person watching every step.

A short vetting checklist for any new tool

Before adopting an agentic tool, ask what specific tools it has access to, whether each one pulls from a live, authoritative source or from the model's general training, and what happens, specifically, when a tool call fails or returns an ambiguous result. A vendor that cannot answer these questions clearly is likely offering a general chatbot dressed up in agent language rather than a genuinely tool-equipped system.

This vetting step takes less time than a single failed pilot, and it reliably separates products that will hold up under real use from ones that will not.

A short pilot structure that limits downside

Rather than adopting a new agentic tool firm-wide immediately, run it for two weeks on a small, low-stakes batch of internal research tasks before allowing it near any client-facing work. This limits the cost of discovering, during the pilot, that a vendor's tools are less reliable than advertised, and it gives the firm real evidence, its own, not the vendor's, before making a larger commitment.

Where this leaves a firm

None of this is complicated in principle, which is exactly why it gets skipped under deadline pressure. The question worth returning to before treating letting a tool act across several steps responsibly as settled is what a careful reader would actually notice if the firm got it right. On the point raised above under “what a tool is, concretely,” the answer is usually specific rather than clever: an agent's usefulness depends heavily on the specific tools it has, not the model alone. Firms that build this expectation into how they train new associates find it easier to sustain once experienced staff move on, because the standard lives in a documented habit rather than in one person's memory. The gap between a firm that talks about letting a tool act across several steps responsibly and a firm that actually practices it shows up over several quarters, not in any single engagement, and it tends to show up most clearly in the small, unglamorous checks that a client never sees directly but benefits from anyway.

It also helps to name, plainly, who is responsible for keeping this working once the novelty of a new tool wears off. Someone should own the point raised under “why narrow tools beat a general one,” check it periodically rather than assume it stays true on its own, and be the person a colleague asks when a new situation does not fit the pattern described here. Put simply: tool design determines how much of a task can run unsupervised versus requiring sign-off. That kind of ownership, named and specific, is a small addition to a firm's process, and it is usually the difference between a good idea that is followed for a month and a standard that actually holds up over a year of real client work.

None of this needs to be elaborate to be effective. A short, dated note in a shared file, reviewed at the next quarterly check-in, is usually enough to keep the responsibility from quietly disappearing when the person who first cared about it moves on to something else.

Key takeaways

  • An agent's usefulness depends heavily on the specific tools it has, not the model alone.
  • Narrow, purpose-built tools (like pulling a live filing) beat relying on a model's memory.
  • Good agent design is mostly the work of choosing and testing tools and their permissions.
  • Tool design determines how much of a task can run unsupervised versus requiring sign-off.