Protocols and Function Calling

Two intelligent participants — until now

Look back at every conversation so far and notice something: both participants were intelligent. The messages were rich, loose, full of nuance — "the batter is really thick, almost like dough," "warm at the edges, cold in the middle." A human reads those effortlessly. So does an LLM.

A computer does not. Without an LLM to interpret them, computers can only process messages in very constrained formats. If the computer is going to become the other participant in the conversation, the LLM has to produce its actions in a format the computer can automatically detect and parse: which tool is being requested, with what parameters.

A protocol

What we have to build is a protocol: the syntax, the semantics, and the timing governing the messages exchanged in the conversation.

We teach the LLM the protocol in the prompt that starts the conversation — and it restricts itself to outputs in that format:

Here is why that matters so much. A message like Use: whisk, bowl, pale and foamy can be broken apart by a completely ordinary program — split on the colon, split on the commas, look up the tool name, hand over the parameters. No intelligence required. Which means the human reading these messages and doing the work can be replaced by a computer that detects the pattern, executes the action with traditional computing tools, and writes back a description of what changed. Everything computers have been able to do for decades — files, databases, networks, devices — can now be connected to the LLM through this narrow, parseable channel.

However: the LLM is probabilistic

But there is a catch. An LLM is not guaranteed to follow the format. It is a next-word predictor, and sometimes the most natural continuation includes a little commentary:

Function calling: a high guarantee

Because this problem is so central, frontier models provide a special way of prompting for it, called function calling (or function prompting). The conversation is presented to the LLM together with a list of tools and their parameters — and the model is constrained so that its next output is, with high guarantee, the selection of exactly one of the provided tools, with parameters that follow what the tool specifies, in a fixed format that is easy to detect:

The exact output format is built in and mandated by the maker of the model — you don't design it, and you don't parse anything exotic. What you supply is exactly what we have already built: tools, with names, descriptions, and parameters. The model typically selects one tool per turn (more than one is possible), and its parameters respect the constraints you declared. The guarantee is high, not absolute — but it is a different world from "please follow the format."

The intelligence mismatch

Step back, because there is a clean way to see everything in this lesson. The LLM is much more intelligent and flexible than the computer — and that creates a mismatch at the interface. Between a human and an LLM there is very little friction: both sides repair ambiguity effortlessly. The moment a computer becomes the other side of the conversation, one participant can no longer repair anything.

Function calling is how we manage the mismatch: it puts the LLM into a special, rigidly structured conversational mode — essentially forcing it to switch into the language of the computer: simplified, strict syntax, no improvisation. The intelligence stays; the flexibility of expression is deliberately constrained, so the least intelligent participant in the conversation can still do its job.