Tools are the actions an agent can take.

The agent era already covered the history: chat got APIs, browsers, code, apps. A tool is a capability your runtime can actually run, with a name, a purpose, and a limit on how much harm it can cause (its “blast radius”). The model may ask for it. Part 5 is how it asks. Here we stay on what exists to be asked for.

If you want the control narrative (badges, approval, audit), keep AI Right Now Part 6 open. The question for this page: which tools did you give the agent access to?

What belongs in the catalogue

Typical tools:

  • Read — query a table you own, fetch a URL you allow, open a ticket by ID
  • Search — web or internal docs (internal search is often RAG underneath)
  • Write — create a draft, patch a record, enqueue a job
  • Code — run in a sandbox, not on the host
  • Side effects — email, charge, deploy, delete

Each entry needs a description honest enough that a model can choose it, and a boundary honest enough that you can sleep. “query_orders — look up orders for an account you already identified” is a tool. “run_sql — any string” is not a good tool, it is too abstract and too dangerous (imagine it drops your table).

The runtime holds the credentials, not the model. The model never holds the password if you designed it like a pro. It holds a name. OpenAI’s tools guide (external link) is an example of that split: the model selects, your code performs.

That split is the architecture:

Model sees:   get_order(order_id)
Runtime holds: DB URL, API key, network path
Observation:  { "status": "paid" }   ← only this goes back

If the model ever sees the key, you did not wrap the tool properly.

Width is the architecture

Too few tools: the agent essays instead of acting.
Too many tools: it doesn’t carefully pick the right one. It picks the tools with name sounds more related.
Too wide a tool: one function that can read or refund. You will not eval that cleanly.

Prefer small verbs. Prefer dry runs (draft_ticket) next to wet ones (submit_ticket). Prefer no payment tool at all until evaluation has a case that proves it stays untouched.

Example

Catalogue: search_kb, get_order, draft_ticket.
Not in the catalogue: refund, email_customer.

Goal: “Handle this complaint.” The agent can ground in the knowledge base, attach the order, and leave a draft. A human sends. That is still an agent. It is an agent with a small set of tools you can list.

Conclusion

A tool is not a smarter model. It is a named capability your code runs, with limits on harm that you chose. Install a short allowlist of small verbs, keep credentials in the runtime, and separate drafts from irreversible writes. Too few tools and the agent essays; too many or one mega-tool and it chooses badly. Part 5 is how the model asks to use a tool: the format of the request, not the list of tools.

Takeaway: Tools are runtime-executed capabilities with a name and a limit on harm, not extra intelligence inside the model.

Sources