Tools are the hands.

The agent era already told the historical beat: chat got APIs, browsers, code, apps. A tool is a capability your runtime can actually run — with a name, a purpose, and a 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. Architecture question for this page: which doors did you install?

What belongs in the catalog

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 owns 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 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

Catalog: search_kb, get_order, draft_ticket.
Not in the catalog: 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 hands you can count.

Conclusion

A tool is not a smarter model. It is a named capability your code runs, with a blast radius 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 for a hand — the request shape, not the catalog.

Takeaway: Tools are runtime-executed capabilities with a name and a blast radius — not extra neurons in the model.

Sources

Part 3: Planning
Part 5: Function calling