What Is Tool Calling? How an AI Agent Acts on Your Mailbox

What is tool calling in AI? It is the mechanism that lets a large language model request an external action — search the web, read a database, send a message — without executing that action itself. The model outputs a structured function call. The host application receives it, decides whether to run it, executes the named tool, and feeds the result back into the model's context. The model never leaves text prediction. Every real-world consequence belongs to the application.

This single distinction — model proposes, application executes — is the foundation of how every serious AI agent works, including agents that act on your inbox. Understanding it tells you where an agent's power comes from, where its limits are, and where every approval gate and audit record should sit.

This guide defines tool calling precisely, walks through the mechanics step by step, compares it to the adjacent concepts it gets mixed up with, and names the misconceptions that cause confusion in evaluation calls and security reviews. We then show how tool calling appears in practice when an AI agent is working your mailbox.

What is tool calling in AI?#

Tool calling — also called function calling — is the protocol by which an AI model signals that it needs the application to execute a specific function on its behalf. The model does not run the function. It outputs a structured message that names the function and supplies the arguments, like a request written in a formal language the application knows how to parse.

The host application holds a registry of the tools the model is allowed to call. When it receives a tool call request, it validates that the requested function is on the list, executes it in the application layer, and returns the output as a new message in the conversation. The model reads the returned result and continues its reasoning — deciding whether it has enough information or needs to call another tool.

This back-and-forth — model reasoning, tool call request, application execution, returned result — is what people mean when they say an AI has internet access or can read your inbox. The model is not browsing the web or opening your mail client. It is asking the application to do those things and reading back the output. The capability lives in the application; the intelligence lives in the model.

The distinction matters because it defines the security boundary. If the model executed tools directly, an instruction hidden in an email could immediately trigger any action the model knew how to take. Because execution is separated out to the application, every tool call can pass through a validation step, an allowlist check, and optionally a human approval gate before any real-world action runs.

How does tool calling work, step by step?#

The mechanics follow the same five steps every time, regardless of whether the agent is searching the web, reading a thread, or deciding what to do with an email.

1. 1

   The application describes available tools to the model

   Before conversation starts, the application builds a tool registry — a list of named functions with typed parameters and descriptions. These are sent to the model as a structured schema. The model only knows about the tools it has been given. It cannot invent new ones or call functions outside the registry.

2. 2

   The model reasons and emits a tool call request

   During its reasoning step, the model decides it needs external information or needs to take an action. It outputs a structured object — not plain prose — that names the function and supplies the required arguments. This output is the tool call request.

3. 3

   The application intercepts, validates, and decides

   The application receives the tool call before anything executes. It checks whether the requested function is on the allowlist, whether the arguments are valid, and whether the call requires human approval. A well-built application rejects any call for a tool not on the list, even if the model requested it confidently.

4. 4

   The tool runs in the application layer

   If the call passes validation, the application executes the named function. For an email agent this might mean reading a thread, labeling a message, generating a draft, or queuing a send. Every execution happens in code controlled by the application, not by the model.

5. 5

   The result is returned to the model as a new message

   The application formats the tool output and appends it to the conversation as a tool-result message. The model reads it and continues reasoning. If the task is complete, it produces a final answer. If it needs more information or another action, it emits another tool call and the loop runs again.

Why this architecture exists, and what breaks without it#

It would be simpler to let the model run functions directly. The reason no serious agent does this is that direct execution collapses the security boundary that makes autonomous action safe.

When execution is separated from reasoning, the application layer can enforce three things. First, an allowlist: the model can only call tools explicitly registered with it, so the worst a compromised or manipulated model can do is request tools it is allowed to request — not arbitrary system calls. Second, validation: arguments are type-checked and scope-checked before anything runs, so a malformed call fails cleanly. Third, approval gates: for high-stakes actions like sending email, the application can hold the tool call and present it to a human before executing — making the consequence reviewable before it is real.

The OWASP Top 10 for Large Language Model Applications names two risks directly relevant here: excessive agency, where a model is given more tool access than the task requires, and prompt injection, where malicious content in the model's context hijacks its tool call decisions. Both attacks are substantially easier when execution is not mediated through an explicit validation layer.

Without the separation, a malicious instruction embedded in an email body could reach the model's reasoning step and immediately trigger a tool call — forwarding that email, deleting threads, or impersonating the user — with no intervening check. With it, the worst-case scenario is a tool call request that the application can reject, log, and surface to a human.

Tool calling, function calling, plugins, agents: what is the difference?#

These terms are used interchangeably in product marketing and inconsistently across model providers. The concepts beneath them are distinct, and the distinctions affect what questions to ask when evaluating an AI product.

The flow in practice#

The diagram below captures the key point: the model never touches the execution environment directly. It sees descriptions of available tools and the results the application returns. Everything between the tool call request and the tool result is application territory — where validation, allowlist enforcement, and optional human approval live.

Three common misconceptions about tool calling#

Three misunderstandings come up repeatedly when people evaluate AI agents, and each leads to poor purchasing or configuration decisions.

The first is that the model sends the email. It does not. The model emits a tool call request naming a send function and supplying the recipient and body as arguments. The email application receives that request, checks whether sending is permitted and whether approval is required, and only then invokes the mail transport. If the application requires human approval before sending, no email is dispatched until a person confirms. The model's request is a proposal, not a command.

The second is that giving the model more tools makes it more capable in a straightforwardly good way. A larger tool registry does extend what an agent can do, but it also expands the attack surface for prompt injection. A malicious instruction in an email body has more damage potential when the agent has access to a delete-all-messages or export-contacts tool than when it is limited to read-thread and draft-reply. Security guidance from OWASP recommends the principle of least privilege: give the agent only the tools the task requires, and add more deliberately as the use case justifies.

The third is that all tool calls are equally consequential. Calling a read-thread tool is reversible and low-risk. Calling a send-email tool is harder to undo and high-stakes. Calling a delete-thread tool may be irreversible. This asymmetry is why the right governance model for tool use is not a single on/off permission but a per-tool approval model: reads run freely, drafts queue for review, sends require explicit confirmation, and destructive actions require special authorization. Any agent that treats all tool calls the same is not taking safety seriously.

How tool calling appears in AI Emaily#

We build AI Emaily — an AI-native email client — and tool calling is how its agent takes action on your mailbox. The agent's tool registry is deliberately bounded: it can read threads, label messages, archive, draft replies, queue sends, schedule follow-ups, and search. Tools for destructive or high-stakes actions are either absent from the registry or gated behind the approval layer.

In Copilot mode, every send tool call is held before execution. The agent drafts and queues, the application surfaces the draft for your review, and the send only runs when you confirm. This is the model-proposes-application-decides architecture in practical form: the agent does the reasoning work, but the tool call that would actually dispatch email passes through a human gate before any real consequence occurs. You see what the agent decided, you approve or edit it, and the application executes what you authorized.

In Autopilot mode, you can expand the tool registry for specific low-stakes categories — routine confirmations, scheduling acknowledgments — so those send calls run without per-message approval. The allowlist still constrains what the agent can request, the audit log records every call that executed, and undo is available on every action the agent took. The agent earns expanded tool access one category at a time as you verify its judgment on your real mail. A 7-day free trial at aiemaily.com lets you see this in action on your own inbox before committing.