Building an agent: tools, loop, guardrails

A chatbot responds. An agent acts: it consults systems, executes actions, chains steps towards a goal. Technically, the basic building block is simple; what separates a useful agent from a dangerous one is the guardrails.

The basic building block: function calling

You declare a list of tools to the model ("search_order(number)", "send_email(recipient, text)"). Faced with a request, the model no longer just responds with text: it produces a structured call, "search_order(4812)". Your code actually executes the function, returns the result to the model, which decides what to do next. Crucial point: the model proposes, your code disposes. It's your program that executes, validates, and filters.

The agentic loop

An agent is that building block in a loop: observe the situation, decide on an action, execute it, observe the result, repeat until the goal is reached (or failure). Standards like MCP let you plug in tools (databases, messaging systems, browsers) without rewriting an integration for each vendor.

Design rules that prevent disasters

• Least privilege. The agent only has access to the tools strictly necessary for its mission. Read-only by default.
• Human confirmation for anything irreversible or binding: sending, paying, deleting, publishing. The agent prepares, the human approves.
• Budgets and limits. Maximum number of steps, spending cap, timeout: a loop that goes off the rails must stop on its own.
• Full logging. Every action is traced: who, what, when, why. Without logs, auditing an incident is impossible.

And above all: do you really need an agent?

If the steps in your task are known in advance (extract, classify, notify), a classic workflow that calls the model at fixed steps is more reliable, cheaper, and easier to debug. Reserve the agent for cases where the path is unpredictable and depends on what you discover along the way.