Choosing Your First Three Tools

The instinct when building a first agent is to give it everything it might plausibly need. Eight tools, maybe twelve, so it isn't blocked.

Three is better, and not as a training-wheels compromise. Three well-chosen tools produce a genuinely useful agent, and each one teaches you something you'll need for every agent after it.

Why three

You can hold the whole surface in your head. When something goes wrong, "which tool should it have called?" has three candidates. At twelve it's a search.

Selection accuracy is nearly free. Models pick correctly from a short, distinct list. Most tool-selection problems people hit are list-length problems in disguise.

Every tool is a thing to debug. Its description, its arguments, its result shape, its error text. Three tools is three small design problems; twelve is a project.

The three roles

Not three arbitrary functions — three roles that between them cover a complete task.

1. A find tool. Locates what the task is about. search_notes(query), list_tickets(status), find_files(pattern).

2. A read tool. Retrieves one thing in full. read_note(id), get_ticket(id).

3. A finish tool. Ends the run explicitly, with the answer and what it used.

Find, read, conclude. That's enough for a real agent — answering questions over your own notes, summarizing what's in a queue, tracing something across records.

Why the finish tool belongs in the first three

This is the one people leave out, and it's the one that changes the most.

Without it, a run ends when the model stops requesting tools. "Done" is the absence of a decision — indistinguishable from stuck, confused, or having answered half the question.

With it, ending is an explicit act you can see and check:

finish(answer: string,
       notes_used: string[],
       couldnt_find: string[])

Now the loop can verify something before accepting the ending — that notes_used isn't empty when the question required evidence, that couldnt_find gets surfaced rather than silently dropped. ✅ And a run that ends without calling it becomes a detectable anomaly instead of a normal outcome.

What to leave out on purpose

Write tools. Not yet. Read-only means the worst outcome of any bug is a wrong answer, which is exactly the safety margin you want while learning what your agent does. Everything you learn transfers when you add writes later.

Anything with an unbounded surface. A generic fetch_url or run_code isn't one capability — it's every capability reachable through that door. Powerful, and the wrong thing to be debugging in week one.

A tool "just in case." ⚠️ If you can't name a task in your eval set that needs it, it's adding selection difficulty and context cost for nothing.

A worked example

A notes agent, three tools:

search_notes(query, limit=20)
  → {results: [{id, title, snippet, updated}],
     total_matched: 47, returned: 20, truncated: true}

read_note(id)
  → {id, title, body, updated}
  → or {error: "no note with id n_88", retryable: false}

finish(answer, notes_used, couldnt_find)

That handles "what did I decide about the vendor contract?" — search, read the two or three that matter, answer with citations. It's useful on day one, and every part of it is inspectable.

🔍 What each tool teaches you

The reason to build these three specifically:

The find tool teaches you about empty and truncated results. What does your agent do when nothing matches? What does it do when 47 matched and it saw 20? These are the two most common silent-wrong-answer bugs in all of agent work, and you meet both in your first hour.

The read tool teaches you result formatting. Return the whole record and watch your context balloon. Return too little and watch the agent guess. Somewhere in between is a judgment you'll make for every tool you ever write.

The finish tool teaches you that completion is a claim. Once ending is a tool call with arguments, you can check it — and you'll immediately find runs that finish confidently having answered part of the question.

Adding the fourth

When read-only starts to feel genuinely limiting rather than theoretically limiting, add one write tool. Two rules:

• Make it staged. draft_note rather than save_note. create_ticket_draft rather than create_ticket. A human confirms until you trust it.
• Make it idempotent. Agents repeat calls for ordinary reasons — a retry, a resumed run, a summarization step dropping the earlier result. A write that runs twice should produce one effect.

Then stop again, and add the fifth only when something concrete demands it.

The takeaway

Find, read, finish. Three tools cover a real task, keep the whole surface in your head, and teach you empty-versus-truncated results, result formatting, and completion-as-a-claim — the three things that cause most agent failures later. Keep it read-only until read-only genuinely blocks you, and when you add a write tool, make it staged and idempotent from the first line.