Tools and Binding

> >

Unit 3 · Agents·Module 7 of 20·13 min

By the end of this module

Describe what a tool is from the model's side, and what the runtime does with it
Tell an edge-bound tool from a discretionary one, and say what each guarantees
Explain why a skill is not a tool, and what its trigger is for

Definition

The previous module had an agent calling tools without saying what a tool is. From the model's side, a tool is a name, a description and a shape for its arguments. That is all it ever sees. It never sees the code, the service behind it, or whether it worked last time.

The model does not run anything. It emits a request that names a tool and fills in arguments. The runtime matches that name against what it registered, runs the real thing, and appends the result to the conversation. Every property people attribute to the model picking a good tool is really a property of how the tool was described.

The Description Is the Interface

Because the description is all the model has, it is doing the job documentation does for a person and the job a type signature does for a compiler, at once, in prose. Two consequences follow, and both surprise engineers.

Consequence	What it means
Wording is behaviour	Rewording a description changes which tool gets picked and how often. It is a behaviour change with no type error to catch it, so tool descriptions belong under review like the code they front.
Unused tools still cost	Every registered tool spends context on every call, whether or not it is used. A long registry makes each individual tool harder to pick correctly, so removing tools often improves accuracy.
Arguments are guesses	The model fills arguments from the conversation and from the general case, exactly as in module one. An argument nobody supplied will still arrive, well formed and plausible.
Errors are just text	A failed tool returns a message into the conversation. Nothing makes the model handle it, so retry behaviour and giving up are things the surrounding system decides, not the model.

Binding

Here is the property that matters most and gets written down least. Two tools can look identical in a transcript and differ completely in what they guarantee.

An edge-bound tool sits on the path. Reaching that point in the flow runs the call, and the model has no say in it. A discretionary tool has no position: it is offered, and the model decides each time. Switch between them below and watch the last run.

Binding on policy_check

The tool sits on the path. Reaching that point in the flow runs the call, and the model has no say in it.

6 runs of the same task

run 1Refund inside the window, obvious casecheck checked

run 2Refund outside the window, customer upsetcheck checked

run 3Refund request with no order referencecheck checked

run 4Refund inside the window, repeat customercheck checked

run 5Refund on a discounted itemcheck checked

run 6Refund the model judged clear-cutcheck checked

verifiedEvery run passed through the check. That is a property of the flow, so it holds for runs you have not seen.

The sixth run is the whole point. A discretionary tool that was called on every run you happened to look at produces transcripts indistinguishable from an edge-bound one, right up to the run where the model judged it unnecessary. Nothing failed, nothing errored, and the check simply did not happen.

So the question to ask of any check that matters is not whether the agent has the tool. It is whether reaching that point runs it. If a compliance check, an authorisation lookup or an audit write is discretionary, you do not have a control. You have a strong suggestion.

Tools and Skills

A third thing gets called a tool and is not one. A skill is a set of instructions loaded when something triggers it, and it runs inside the calling agent's context rather than behind a service.

	Tool	Skill
What it is	An external capability behind a name and a schema.	Instructions loaded into the context on a trigger.
Where it runs	Outside the model, in a service or in local code.	Inside the calling agent, as part of its context.
What it returns	A result appended to the conversation.	Nothing. It changes how the agent behaves from then on.
Availability	Always callable once registered.	Conditionally present. The trigger is the defining property.
What goes wrong	Called when it should not be, or not called when it should.	Never triggers and costs budget anyway, or always triggers and is really just instructions.

The trigger is the defining property rather than a detail. A skill is conditionally present, and that is the entire reason it exists instead of being more system prompt. A skill with no trigger either always loads, in which case it is just instructions, or never loads while still spending the budget its description costs. Either way it is worth finding.

quizCheck

A team says their agent always checks customer entitlement before issuing a credit, because the entitlement lookup is one of its tools. What should you ask?

Discussion

List the checks your team believes happen on every run of something. For each, say whether reaching that point runs it, or whether a model decides. The uncomfortable ones are usually the checks that exist precisely because something went wrong once.