The Video Assistant · Lesson 8 — The Other Tools ← Course

The other tools — tool calling.

A model is brilliant with language and hopeless at measuring a trajectory. So you give it instruments to call on.

A model can reason about words, but it cannot reliably do arithmetic, look up today's score, or measure where a ball was heading. For those it needs help — so you hand it a set of tools it is allowed to use, and let it call on them. This is tool calling (also “function calling”).

Here is the part that trips people up, and it is the same shape as the last lesson: the model does not run the tool. It requests one — it names the tool and the inputs — and then a real program on your side runs the actual tool and hands the result back. The model reads that result and carries on.

The football VAR works exactly this way. It cannot judge to the centimetre whether a ball crossed the line, so it calls for goal-line technology; it cannot eyeball a tight offside, so it calls for semi-automated offside; it cannot be certain about a handball, so it calls for multi-angle replay. The VAR asks for the instrument, the instrument does the measuring, and the VAR rules on what comes back.

So the model's real skill here is judgement: turning a vague appeal into the right tool with the right inputs — and then reading the answer correctly.

Send up an incident the VAR can't settle from words alone. Watch it call the right instrument, and rule on what the instrument reports back.

Pick an incident. The VAR asks for an instrument — it never runs the instrument itself.
the incident
↓
① the model asks for a tool model · requests, doesn't run
↓
② the instrument runs and reports back the tool · not the model
↓
③ the model reads it and rules model

Ask, run, read.

You hand the model the tools; it hands you back a request; your code runs the tool and gives it the result. The model only ever reads text. 


      

    


    

      
The model decides; the tool does.

      

        Tools give a model powers it does not have on its own — exact measurement, live data, real
        actions. But it never runs them itself: it picks the right tool and inputs, your code runs
        the tool, and the model reads the result and continues. Its job is judgement, not
        execution.
      

      

        Retrieval, last lesson, was really just one tool — a search. Tool calling is the general
        version: give the model a whole kit of instruments, and let it call whichever the moment
        needs.
      

      

        
Quick check

        
The model needs to know whether the whole ball crossed the line. It should…

        

          
          
          
        

        

      

      

        Next: the standard socket →
        
      

    


  


  

    

      ▸ Go deeper — how tool calling really works optional
      

        
The request is structured, not a wish

        

          A tool call is not the model muttering “check goal-line tech”. It is a precise, machine-readable
          request — the tool's name and its inputs, filled in from a schema you provided. That is
          what lets your code actually run it. Half the craft is describing each tool clearly enough
          that the model fills the inputs correctly.
        

        
The model can't execute — you do

        

          The model produces text, full stop. It has no hands: it cannot hit an API, run a query, or
          move a robot. Everything real happens in your code, which chooses to honour the request,
          runs the tool, and passes the result back. That gap is also your safety boundary — you
          decide which requests to allow.
        

        
It can ask for the wrong thing

        

          The model can pick the wrong tool, or fill an input badly — call goal-line tech when it
          needed the offside check. Tools do not make it infallible; they just extend its reach. Validate the
          request before running it, and check the result makes sense.
        

        
Tools are how a model acts on the world

        

          Reading data is one thing; tools can also do things — send an email, place an order,
          book a slot. The same request-run-read loop applies, but now the “run” step has real
          consequences, which is why an action tool deserves far more caution than a read-only one.