AI agents and tool use: function calling explained

Tools let a model act, not just talk. Learn the loop behind agents and the design rules that keep them reliable and safe.

A model choosing tools in a loop with a human approval gate

A plain LLM can only produce text. With tools it can also do things: search the web, query a database, read a file, call an API, run code. A system that lets a model decide which tools to use, step by step, to reach a goal is often called an agent.

How function calling works

  1. You describe the available tools to the model: a name, a description and a parameter schema.
  2. The user asks something. The model either answers directly or replies with a request to call a tool, with arguments.
  3. Your code runs the tool (the model never runs it itself) and returns the result.
  4. The model reads the result and continues: answers, or calls another tool.
tools = [{
  name: "get_order_status",
  description: "Look up the status of a customer's order by order ID.",
  parameters: { type: "object", properties: { order_id: { type: "string" } }, required: ["order_id"] }
}]

The exact request format varies by provider, but the idea is the same. The key point: the model only proposes calls. Your application decides whether to execute them.

The agent loop

repeat until done or limit reached:
    ask the model what to do next
    if it requests a tool: validate, run it, add the result to the conversation
    else: return the final answer

Agents add planning, memory and self-checking on top of this loop. More autonomy means more power and more ways to go wrong.

Designing good tools

  • Clear names and descriptions. The model chooses tools from the text you write, so say exactly what each does and when to use it.
  • Small, focused tools with simple parameters beat one giant tool.
  • Useful results: return concise, structured output, not a flood of text that wastes context.
  • Helpful errors: return a clear message ("order not found, check the ID") so the model can recover.
  • Idempotent where possible, so a retry does not repeat a side effect.
  • Make the dangerous parts explicit, such as separate "draft email" and "send email" tools.

Safety rules for tools

The tool layer is where an agent can cause real harm, especially if it reads untrusted content (see the LLM security article in this series).

  • Least privilege. Each tool and credential has the smallest access that works.
  • Validate arguments in code. Check types, ranges, allowed values, and that the current user may act on that resource. Never trust the model's arguments just because they look right.
  • Human approval for irreversible or costly actions: payments, deletes, sending messages, deploying.
  • Read-only first. Start with tools that cannot change anything.
  • Sandbox code execution with no secrets and limited network.
  • Limits: a maximum number of steps, tool calls, time and spend per task, to stop loops and runaway costs.
  • Log every tool call with its arguments and result, for audit and debugging.

Reliability tips

  • Keep the prompt focused on one job and give the agent a clear definition of done.
  • Return errors to the model and let it retry, but cap retries.
  • Check the final result with code where you can (for example run the tests the agent claims pass).
  • Evaluate end to end on a test set of tasks, including failure and abuse cases (see the evaluation article).
  • Start with a human watching, then relax supervision only as evidence builds.

Workflow or agent?

Many problems are better solved by a fixed workflow where code decides the steps and the LLM only handles individual steps (classify, extract, draft).

  • Use a workflow when the steps are known. It is cheaper, faster, more predictable and easier to test.
  • Use an agent when the path cannot be known in advance and the task needs flexible decisions, such as open-ended research or coding across a codebase.

A good rule: use the simplest design that works, and add autonomy only where it clearly pays.

Standards you may meet

Protocols such as the Model Context Protocol (MCP) define a common way for models and apps to connect to tools and data sources, so you do not write a custom integration for every pair. Treat every tool server as code that runs with your permissions: only connect ones you trust and review what they can do.

Takeaway: the model proposes tool calls and your code executes them. Design small, clear, least-privilege tools, validate everything, require approval for risky actions, set limits, log everything, and choose a simple workflow over an autonomous agent when you can.


AI & LLM series, Part 2 (quality, agents and cost): 3 of 5. Previous: How to evaluate an LLM app: test sets, metrics and LLM judges.

Keep reading