Function Calling: How AI Went from Talking to Doing

"Look up the order status for Mr. Chen, then draft him a follow-up email." Send that to an AI two years ago and you got a nicely worded draft plus an apology: it could not check orders, and it could not send anything. Send it today to an assistant wired into the right systems, and half a minute later the order status is retrieved and the email sits in the outbox awaiting a click.

The mechanism between "can talk" and "can do" is called function calling. The name sounds like engineering; the idea fits on one sheet of paper.

The model never touches your systems

It is tempting to think "AI can operate software now" means the model grew hands. The opposite is true. The core design of function calling is that the model operates nothing directly. It does exactly one thing: it fills in a structured request form — which tool to call, with what parameters. For instance: "order lookup, customer ID C1024."

Who receives the form? Ordinary software outside the model. The things actually touching the database, calling the API or sending the email are regular systems; when they finish, they hand the result back, and the model decides what comes next — query again, start writing, or ask a human. The whole arrangement works like a new hire: he cannot walk into the warehouse and take stock, he submits a requisition slip, the warehouse keeper checks and executes it, and the goods are handed over.

One example, end to end

Back to the opening instruction. Taken apart, it is two separate tool calls with a stretch of the model's home turf in between:

1. The model reads the intent, realises it lacks the order data, and fills in form number one: call "order lookup" with the customer ID.
2. The external system runs the query and returns the result: last order shipped three days ago, delivery expected tomorrow.
3. The model drafts the follow-up email from that result — no tool needed; this is what it does best.
4. Draft done, it fills in form number two: call "send email" with recipient, subject and body. Whether that actually goes out automatically depends on the permission you gave the tool — many companies deliberately require one human click before anything leaves the building.

Once you see this round trip, you hold the key to evaluating every "AI that does work" product: capability is the model plus the tools it is allowed to use. The same model can only check orders if an order system is connected. More tools mean more it can do — and a larger surface for things to go wrong.

Why this is the foundation of agents

Chain the loop — fill a form, execute, read the result, decide the next step — and let the model sequence calls and correct itself, and you have the basic shape of an AI agent. Business workflow automation is the same story: "inquiries routed automatically" or "reports compiled overnight" are, underneath, an orchestrated series of tool calls. Without function calling, none of it exists.

One aside: once the number of tools grows, how they all plug in consistently becomes its own problem — which is exactly what the MCP protocol sets out to solve. We will leave that for its own article.

Boundary design: which forms get auto-approved

The request-form mechanism hands companies a natural control point: permissions live on the tools, not on the model. Across the business scenarios we encounter, a three-tier split has proven sensible.

Read-only operations — checking orders, stock, documents — can run freely; a wrong answer is just wrong information, nothing changes. Write operations and anything outbound — updating records, sending emails, replying to customers — go through approval: a person confirms, then it executes. Anything touching money — refunds, payments, price changes — stays with humans; the AI's job ends at filling in the form and attaching the evidence.

Whether a tier can be auto-approved comes down to two questions: is the error reversible, and will it be noticed in time? Two noes, and a human goes back into the loop.

A yardstick for managers

The next time you watch a demo of an AI product that claims to "get work done", skip the technical details and ask two questions: which tools is it connected to, and how are each tool's permissions managed? The first determines what work it can do; the second caps how much trouble it can cause. A vendor with clear answers to both is worth the next meeting. Without them, however smooth the demo, you are still looking at "can talk".