In 30 seconds

Choose tools for an agent the way you grant permissions: give the fewest it needs, prefer read-only, and make each write tool narrow and limited. Every tool you add widens what the agent can do, and what it can get wrong.

Why this comes up

It is tempting to give an agent broad, powerful tools "so it can handle anything." That is exactly how an agent ends up able to take actions nobody intended. Each tool is a capability and a risk, so choosing them is a safety decision, not a convenience one.

Start from the job, not the possibilities

Work from the agent's defined job, not from what the connected systems can do. For each thing the job genuinely requires, add the specific tool that does it. Anything the job does not need, the agent should not have, even if a system technically offers it.

Prefer read-only, and keep write tools narrow

Apply the read versus write distinction to every tool:

  • Favour read-only tools. They are far safer, because a wrong call does not change anything.
  • Make each write tool as specific as possible. "Create a ticket in the support queue" is safer than "modify any record." A narrow tool cannot be misused into a broad action.
  • Attach limits to each write tool, matching your allowed and prohibited actions.

Fewer, well-understood tools beat many

An agent with a handful of clear tools is easier to reason about, test and trust than one with many overlapping ones. More tools mean more combinations of behavior, more to test, and more ways to surprise you. Resist adding a tool "just in case."

A small example

A support agent's job needed three things, so it got three tools: search the knowledge base (read), read a ticket (read), and draft a reply for approval (no direct send). It was deliberately not given tools to close tickets, email customers or edit accounts, even though those systems offered them. Its tools were exactly its permissions.

What this does not solve

Choosing tools carefully sets what the agent can do; it does not ensure it uses them correctly. A tool can be called with wrong inputs or at the wrong moment. Validate tool inputs, gate consequential tools behind approval, and test how the agent uses them. See the checklist before giving an agent write access.

Good enough to move on when

  • Each tool traces to a genuine need in the agent's job.
  • Read-only tools are preferred and write tools are narrow.
  • Each write tool has explicit limits.
  • No tool is included "just in case."