Tools and function calling, simply

Intermediate · 5 min · Explain how an assistant uses tools, and where the approval gate belongs.

  • tools
  • mental models

Function calling is how an assistant does something beyond writing text: it asks the surrounding software to run a named tool — check a calendar, look up an order, send a message — and then continues with the real result. The model proposes the call; your system decides whether it runs. Permissions and confirmation live on that second side, which is exactly where you want them.

The loop, in full

  1. You ask something the chat cannot answer from its own text: “Is the studio free at 15:00?”
  2. The model proposes a tool call — which tool, with which arguments (studio, date, time).
  3. The surrounding system checks whether that tool and those arguments are allowed at all.
  4. The tool runs and returns a result: free, busy until 14:30, or an error.
  5. The model answers using the returned result — not from memory of what calendars usually do.

Reads and writes are not the same animal. A read fails quietly; a write changes the world. Sending an email, deleting a file, moving a booking: each needs a gate before execution, because a wrong argument that reaches a real system is no longer a draft.

Where the risk sits

  • Wrong parameters. The model may propose the wrong date, the wrong recipient, the wrong file — fluently.
  • Untrusted text turning into instructions. If a tool reads a document or a web page, anything inside it is potential instruction. That is the prompt injection problem, and it gets sharper the moment tools can act.
  • Silent success. “Done!” is the model’s summary, not proof. The check is the tool’s own result — or a dry run that lists what would happen before anything happens.

A bad example

Ask: “Clean up the duplicates in our CRM and email the team a summary.”

One sentence, two writes and no review step. Wrong matches become deletions; an inaccurate summary becomes the team’s record. The fluent version of this instruction is exactly the one that does the most damage.

A better example

Ask: “List candidate duplicate companies with the reason each pair was flagged. Do not delete anything. After I confirm the list, draft the team summary.”

Now the first pass is a read that produces evidence for a human decision — and the write only happens after a specific yes.

Why it works

Splitting propose from execute turns “trust the assistant” into “review a proposal”. The model is genuinely good at forming the call: tool name, arguments, sensible defaults. It is not the right place for judgment about consequences, because it does not know your policy, your margins or what a mistaken deletion costs. Keep the model on proposal duty and yourself on approval duty, and the whole interface becomes a queue of reviewable actions instead of a set of irreversible bets.

From question to action

  1. You ask for something the model cannot answer from the conversation alone.
  2. The model proposes a tool call — tool name, arguments, and why.
  3. The system checks permission: is this tool allowed, for this user, with these arguments?
  4. The tool executes and returns a real result — or an error the model must handle honestly.
  5. The model answers from the result; anything that writes to the world passes a human confirmation first.
You are asked to set up an assistant that can move bookings in a shared calendar. Which design keeps the useful part and the risk contained?

Practice

Order the tool call

You are writing the spec for a small internal assistant that checks whether a meeting room is free and, after confirmation, moves a booking. The team building it needs the loop described in the right order — permissions and confirmation included.

Order the steps of a single tool-using request, from the user's question to the final answer.

  1. The tool executes and returns a real result — free, busy until 14:30, or an error.
  2. The model answers using the returned result, quoting what the calendar actually said.
  3. Any write — moving the booking — is proposed with details, confirmed by a human, then executed and reported.
  4. The user asks something the chat cannot answer from the conversation alone: “is Studio B free at 15:00 on Thursday?”
  5. The model proposes a tool call — tool name, room, date and time — with the purpose stated.
  6. The surrounding system checks permissions and policy: may this assistant read the calendar, with these arguments?
Hint

Permission checks sit between the proposal and the execution, never after the fact.

Writes come last and pass a human gate: reads inform, writes commit.

Transfer

  • Calendar and email: propose then confirm; never auto-send on the first run.
  • Orders and CRM: reads first, writes gated; keep a log of what the tool actually returned.
  • Files: prefer a dry run that lists affected files before a rename or delete.
  • Untrusted sources plus tools: treat document or web content as data, never as instructions.

Key takeaways

  • The model proposes tool calls; your system decides whether they run.
  • Reads can be open; writes need a confirmation gate and a visible result.
  • “Done!” is a summary, not proof — the tool’s returned result is the evidence.

Next

Finished this lesson?