Lesson 21.421.4 Tools: which the worker can see, and where each call runs

In everyday life. A new accounts clerk gets a laptop set up for developers, full of apps. The manager has it wiped back to two things: the payments system and the policy manual. In this concept, the developer apps are an SDK's built-in tools, and the two things are the tools you choose.

What you will learn. Which tools a worker can see, who runs each call, and why turning tools off is only one of the checks that keep a worker in bounds.

Why it matters. A tool the job does not need can still be called, by the model or by text hidden in a tool's output.

One request, start to finish. Ana asks: "What is today's exchange rate for the euro?" The worker has no reason to know. On the first SDK with its built-in tools on, the worker saw dozens of tools, among them a shell, and the model asked for it. The permission rule (21.5) denied it. With the built-in tools off, the worker saw its five tools, and said at once it could only work with Brightline's records. The second SDK has no built-in tools on by default.

What kinds of tool can a worker see?

A worker sees one list of tools. Each tool is one of four kinds, and for each you must know who runs the call:

Does an AP worker need the built-in tools?

Give a worker only the tools its job needs. An AP worker needs none of the built-in tools. Each one is a way for an injected instruction in tool output (Chapter 17) to reach your computer. Turn them all off, then read the tool list the run reports, to check.

Is the tool list the only boundary?

The tool list is one boundary, not the only one. Four separate checks keep a worker in bounds, and each stops a different bad call. The tool list decides what the model can ask for. The permission check decides whether this call may run (21.5). The connector's own check decides whether the token allows it (Chapter 19). A sandbox, a place a program runs with limited reach, decides what a running call can touch (21.9). Turning the built-in tools off shrinks only the first.

Figure 21.4. Four boundaries, not one. Each stops a different bad call.

Where should each tool call run?

Keep tool calls in your own process unless you have a reason. Then Step 4 of your loop stays where you can see it, trace it and test it. A hosted tool is faster, but the call and its result happen on the provider's side, the connector must be reachable from the internet, and the provider holds the token. The lab keeps every call in your process, with the test token in a header, as in Chapter 20.

Figure 21.5. One list of tools, and who runs each call. In this lab, your process does.

What are agents as tools, and handoffs?

One agent can be offered to another as a tool, and only its answer comes back. A handoff passes the whole conversation to another agent: the model sees it as one more tool, and the SDK switches agents when it is called. This worker uses neither. Chapter 26 designs systems of agents.

At work. Lab 21, Task 5: the same question with the built-in tools on, then off.

The operating rule: give a worker only the tools its job needs, and read the tool list each run reports. Say in writing who runs each tool call and who holds its token, and keep the calls in your own process unless you have a reason to move them.