How many tools should an agent have?

Beginners should start with 2-3. Every additional tool multiplies the chance of the model choosing wrong. Add tools only when the agent demonstrably fails at its job without them — not because it might be nice someday.

Should my agent be able to send emails?

Only after weeks of trustworthy behavior on read-only tasks, and even then with rate limits and a review queue for anything going to humans outside your team. Email is the classic first-tool mistake: high blast radius, and errors are permanent and public.

What's a read-only tool?

A tool that cannot change state anywhere: search, fetch URL, read database, list files. Read-only tools can waste money and time but can't break anything. Agents should earn write access by behaving on read-only tools first.

Do I need custom tools or are built-in integrations enough?

Built-in integrations (search, HTTP, database connectors in n8n/Make) cover most needs. Build a custom tool when you need an action your platform lacks or want tighter validation than the generic connector allows — but wrap existing APIs rather than building from scratch.

What Tools Should Your AI Agent Actually Have?

If you’ve built the research agent from our getting-started guide, you’ve felt it: the moment the agent works, the temptation is to give it more power. More tools, more reach, more autonomy. And that instinct — more power = more useful — is exactly backwards for agents. Tool selection is where agents succeed or fail, and the failure mode isn’t “too few tools,” it’s “the wrong tools badly described.”

This is the decision framework we use for every agent we deploy, including the tools that shouldn’t be anywhere near a beginner’s agent.

The one rule that generates all the others

Every tool is a chance for the model to be wrong, multiplied by the damage when it’s wrong.

A search tool that gets called inappropriately wastes a few cents. An email tool called inappropriately burns a client relationship. Both are “the model chose wrong” — but the blast radius differs by orders of magnitude. So the rules all reduce to: minimize chances, match blast radius to demonstrated reliability.

Rule 1: Start read-only, earn write access

Tools sort into three tiers by what happens when they misfire:

Tier	Examples	Failure cost
Read-only	web search, fetch URL, read sheet/DB, list files	cents + time
Reversible write	create draft, add row, tag a record, queue a message	minutes to undo
Irreversible/hard-to-reverse	send email to a human, pay an invoice, delete data, publish publicly	permanent damage

A new agent gets read-only tools, full stop. After two weeks of behaving — and you watching it behave, which is different — it can graduate to reversible writes (with a human-review queue on the output). Irreversible actions are last, and for most agents running real businesses, they stay behind a human approval step forever. That’s not timidity; it’s the same reason companies don’t give the intern the company card on day one.

The exception that proves the rule: an agent acting inside your systems (tagging, filing, drafting) can have broad write access because errors are contained and visible. An agent acting outward (emailing, posting, paying) needs the approval gate even when it’s otherwise reliable — because outward errors damage relationships, not just data.

Rule 2: Fewer tools, better described

The model chooses tools by reading their names and descriptions. This makes tool descriptions a genuine engineering artifact, not documentation afterthought:

Bad:   "Search CRM"
Good:  "Search the CRM for a contact or company by name, email,
        or domain. Returns the record with owner and last-contact
        date. Use when you need a client's details or account status.
        Do not use for updating records — that's update_contact."

The good version tells the model when to use the tool, what comes back, and — critically — when not to use it. That last clause is what prevents the classic beginner bug: the model calling search_crm when it meant update_crm because both descriptions were one vague word long.

And keep the count low. Every tool you add:

makes the model’s choice harder (more options, more chances to confuse)
dilutes the description quality you can maintain
adds one more integration to keep working when APIs change

Our production agents run 3-6 tools. The demos with 40 tools are demos — nobody successfully runs those in production, including the people doing the demos.

Rule 3: The three tools that cover most business agents

Before you build anything custom, check whether your agent is just these three plus domain flavor:

Search/find records — read data from wherever your business keeps it (CRM, sheet, database, Notion). Read-only.
Create/update records — write back to the same systems. Reversible.
Communicate internally — post to Slack, draft an email, create a task for a human. This is the “agent asks for help” channel, and it’s the most underrated tool in the kit: an agent that can escalate to a human when it’s unsure is safer than a smarter agent that can’t.

That third one deserves emphasis. The single most valuable “tool” in most of our agents is ask_a_human: post a Slack message describing what it’s trying to do and what it’s unsure about, then stop and wait. Agents with an escape hatch fail gracefully; agents without one fail creatively.

The `ask_a_human` tool, built for real

Because it’s the tool we recommend most and the one nobody builds, here’s the complete implementation — n8n flavor, but the pattern is identical in Make. It’s a “Send message to Slack” node exposed to the agent via a sub-workflow tool, with this description:

Name: ask_a_human
Description: Ask a human for help when you are unsure how to
proceed. Input: a clear question plus the context needed to
answer it (what you were asked to do, what you found, what
you're unsure about). Use this whenever a task is ambiguous,
a required input is missing, or taking the action might be
wrong or irreversible. Asking early is better than guessing.

Three details make it work in practice rather than in theory:

The message template enforces structure. The Slack message the node sends isn’t a raw dump of the model’s question — it’s formatted as three labeled fields: GOAL (what the agent is trying to accomplish), FOUND (what it knows so far), QUESTION (the specific thing it needs answered). The formatting lives in the node’s message field, not the prompt, so the model can’t produce an incoherent escalation. Half the value of the tool is that the template forces the model to articulate its own confusion.
“Stop and wait” is a real design choice. The tool returns a confirmation (“Your question has been sent to the team. Stop here.”) and the system prompt reinforces it: “After calling ask_a_human, end your turn. Do not attempt the task further.” Without that line, some models will escalate and then keep going — asking for help and then guessing anyway, which is the worst of both worlds.
The reply path can stay manual forever. At small scale, the human answers by typing the answer into the next day’s input, or just fixing the situation themselves. Only build the automated return path (a Slack reply triggers a new agent run with the answer injected) when you’re drowning in escalations — which is a signal to fix the underlying prompts, not to build more plumbing.

We instrumented ours after the first month: 11 escalations, of which 9 were genuinely ambiguous situations the agent was right to flag, 1 was a lazy escalation the prompt tightening fixed, and 1 was the agent asking permission for something it was already allowed to do (also a prompt fix — “you don’t need to ask for X”). That ratio is what a healthy ask_a_human looks like: mostly legitimate, occasionally fixable, never silent.

What good descriptions look like, side by side

The fastest way to level up tool descriptions is to see bad and good next to each other. These are real (lightly anonymized) before/after pairs from agents we’ve debugged:

Tool	Bad description	Fixed description
CRM search	“Searches the CRM.”	“Search contacts by name, email, or company. Returns owner, status, and last activity. Use before creating a contact to avoid duplicates.”
Update record	“Updates a record.”	“Update fields on an existing CRM contact. You must provide contact_id from search results. Do not invent IDs — search first if you don’t have one.”
Send email	“Sends an email.”	“Send a plain-text email. For client-facing messages, draft only (draft_mode: true) — a human sends. Internal addresses can be sent directly.”
Calculator	“Does math.”	“Evaluate arithmetic precisely. Use for any calculation with numbers over 100. Models (including you) estimate; this tool doesn’t.”

The patterns worth copying: every fixed version says when to use it (the trigger condition), what it returns or requires, and — when applicable — what not to do (the boundary against a sibling tool). “Do not invent IDs” is doing as much work as the rest of the sentence; invented IDs are the number-one cause of write-tool misfires we see.

The test for your descriptions: hand them, without the tool names, to a new team member and ask which tool they’d use for five sample tasks. Wherever they hesitate or pick wrong, that’s a description to fix. The model reads them the same way your colleague does.

The tools that don’t belong in a beginner’s kit

Money movement — payment execution, invoice payment, subscription changes. The upside is efficiency; the downside is an agent that misunderstands one invoice and pays the wrong amount, at machine speed, to someone who won’t return it.
Free-form email to external humans — outbound email is the most common “it seemed harmless” tool. One misread situation and your agent has sent a confused, wrong-tone message to a client who now knows you automate carelessly.
Data deletion — anything destructive. If the agent’s job creates garbage, have it tag the garbage for a human to purge, not purge it.
Social media posting — public, permanent, brand-damaging. Our cross-posting guide uses a review queue for exactly this reason, and that’s a deterministic pipeline, not an autonomous agent.
Credential-holding browsers — agents with your logged-in browser session can do anything you can do, which is the definition of unlimited blast radius. This will be practical someday for some uses; for now it’s the tool equivalent of leaving your password on a sticky note.

The intermediate kit: when you’re ready

After a month of trustworthy read-only behavior, the typical progression adds: a schedule tool (cron triggers), a memory tool (the notes file from our memory guide), maybe a second data source. Each addition follows the same ritual: describe it precisely, watch the first 20 calls, check the agent still chooses correctly with the new option in the mix.

And one addition people forget to make: rate limits. Every tool that costs money or touches external systems gets a cap — max calls per run, per day. The tool-call equivalent of a circuit breaker, so a confused loop fails cheap instead of expensive.

The test for “should this agent get this tool?”

Ask, honestly:

If the model calls this tool at the worst possible moment with plausible-but-wrong inputs, what happens?
Have I watched the agent behave correctly for at least two weeks on less dangerous tools?
Is there a human approval step between this tool’s output and anything irreversible?

If the answers are “something bad,” “no,” and “no” — the agent doesn’t get the tool yet. Not never; yet. Agent autonomy is earned in stages, and the agents that earn it are the ones still running (and still trusted) a year later.