Practice · What You Can Do Now

From “can talk” to “can do”: wire up the first tool

After M1, you’ve got an AI that’s great at talking. And you’ve seen Alice’s story with 132 tools. The line between an Agent and a chatbot is the first tool that actually gets executed. You don’t need 132. You need 1.

Hands-on track, third square: talking is stable — now give it hands and feet.
M0
Know what you want it to do for you
M1
Talks like a human, reliably
M2
Actually gets work done
M3
Better or worse, measurably
M4
Runs long without losing memory
M5
The process is reproducible
See it first · One complete tool-calling loop

“Wiring up a tool” sounds like engineering. The chain is only four steps, and the model never executes anything — it just asks. The framework does the work. See these four steps and you’ll know which one to check when something breaks.

From the model asking to the result feeding back

01
The model asks

It outputs JSON: which tool, with what params

02
The framework validates params

Is the format right? Is the value legal? If not, bounce it back

03
Real execution

Query a database, send a request, write a file — this is the step that touches the real world

04
Result feeds back

The result goes back into the conversation. The model digests it, then talks like a human

All four steps done. Behind the one reply the user sees is a full loop
All four steps done is a closed loop. The step people forget most is the fourth: the tool result has to go back to the model so it can turn it into human language. Otherwise the user sees a blob of raw JSON.

How to pick the first tool

Three criteria, none optional: high frequency (you’ll almost always need it in your scenario), low risk (read-only first — checking weather or searching docs is safer than sending email), clear inputs and outputs (two or three params, a fixed return shape). This chapter covered the craft of tool descriptions: for the same function, a good description vs a bad one can triple the call success rate. So after you pick, write the description clearly before you talk about wiring it up.

Hands-on checklist · Pick one, start it, tick it off

This Chapter's Hands-on Checklist

0 / 3 done

Pick the first tool

15 min Everyone

Using the three criteria above (high frequency, low risk, clear I/O), pick the first tool from your scenario and write down: tool name, one-line function, and what the two or three params are. If you can’t pick one, use “search my [whatever] docs” — it fits almost every scenario.

What counts as done
All three criteria pass on a self-check, and you can say: if this tool executed wrong, what’s the worst case (for a low-risk tool the answer should be “no big deal”).

Write the tool description in three lines

1 hour If you want it called accurately

Line 1: when to use this tool (also write when not to); Line 2: each param’s meaning, format, and an example value; Line 3: what it returns and what to do with the result. Then self-check from the “5 messages behind one conversation” lesson: the model decides how to call from these three lines alone. It cannot see your code.

What counts as done
Send the description to someone who hasn’t seen your code. They can correctly say “when this tool would be used, and with what params.” If they can’t, the model won’t call it right either.

Run one complete loop

Half a day Ready to actually build one

On a platform you already use (Coze, Dify, Cursor, or just write code), actually wire this tool up. Ask a question that must use it, and watch all four steps finish. Then break it on purpose: ask something with vague params, see which step it sticks on and what feedback the user gets. This chapter covered five Agent deadlock patterns — you should see at least one with your own eyes.

What counts as done
A normal question completes all four steps, and the answer is human language, not JSON. For the broken question you can point to “which step it stuck on, and why.” Do both and M2 is standing.

Log the first loop in the Build Log

For M2, record: the tool’s name, how you wrote the description, and what the first successful run and the first stuck run looked like. The stuck one is especially valuable — the next chapter’s eval starts from it.

Fill in M2