Pebellslearn by building
0%
RoadmapsMatrixCoursesSandboxSign in
The Agent Loop  ›  Lesson

Acting — How Tools Get Invoked

Acting / Tool Invocation 12 minWhen an agent acts, the model writes a structured tool call and the application validates it, runs the real function and returns the result to the model as a new message.

Acting — How Tools Get Invoked

Tripmate has decided its next step: search trains from Pune to Jaipur for Thursday night. But a language model can only produce text. It cannot open a connection to a railway website. So how does a decision become an action?

The rule

The model writes a request; your code does the deed.

A tool is a function your program offers to the model, described by a name, a purpose and the inputs it takes. When the model wants to act, it does not run anything. It writes a structured tool call — which tool, with which arguments:

{
  "tool": "search_trains",
  "arguments": { "from": "Pune", "to": "Jaipur", "date": "2026-10-15", "class": "sleeper" }
}

Your program then does four things:

  1. Reads the call and checks the tool name exists.
  2. Validates the arguments — right types, allowed values, permission to act.
  3. Runs the real function, such as an API request to a timetable service.
  4. Returns the result to the model as a new message, so the next turn can use it.

Many model providers support this directly: you pass tool descriptions with the request, and the model's reply can contain tool calls in a fixed format instead of plain text. The exact field names differ between providers, but the shape is the same everywhere.

The shortcut

Picture a waiter and a kitchen. The model is the waiter: it takes the order and writes a ticket. Your code is the kitchen: it checks the ticket, cooks, and sends the plate back. Whenever you wonder "can the model do X?", ask "is there a ticket for X, and will the kitchen accept it?"

One tool call, start to finishStep 1 of 4
  1. Model writes the ticket

    Tripmate emits a call to search_trains with Pune, Jaipur, 15 October, sleeper.

The trap is trusting the ticket blindly. Models sometimes invent a tool that does not exist, pass a malformed date, or request an action they should not take. Validation in your code is the safety net, and anything risky — like book_ticket, which spends money — deserves a confirmation step.

Drills

Answer fast — trust the rule.

quick drill

What does a model produce when it "calls" a tool?

quick drill

Tripmate asks for search_trians (a typo). What should the program do?

quick drill

How does the model learn what search_trains returned?

quick drill

Which Tripmate tool most needs a confirmation from Asha before it runs?

Remember

  • The model writes a tool call; your code validates it, runs it and returns the result.
  • Shortcut: waiter and kitchen — is there a ticket, and will the kitchen accept it?
  • Trap: running tool calls without validation, especially ones that spend money or change data.

Practice — level up

0/1 solved

Write your answer, then compare it with a rubric and a model answer.

ExplainWho does what in a tool call?

Explain, step by step, what happens when Tripmate decides to call book_ticket, making clear which parts the model does and which parts the application code does. Include at least one check the code should make.