While an LLM feature is "ask the model, get an answer," everything is predictable. But some tasks can't be solved that way: to answer, you need to go to the database, then based on the result to another service, then decide what to do next. This is where an agent appears — a model that works in a loop, deciding for itself which tools to call to see the task through. It's the most powerful and the most treacherous form of LLM application.

How an agent differs from a single call

An ordinary LLM feature is a straight line: input → model → output. An agent is a loop with branching, where the model at each step chooses the next action itself.

The classic loop is "reason → act → observe" (often called ReAct):

  1. reason — from the task and what's already known, the model decides what to do next;
  2. act — it calls a tool (a database query, a search, an API call);
  3. observe — it gets the tool's result and adds it to what it knows;
  4. repeat — until the task is solved or a stop condition fires.

The difference is fundamental: in an ordinary feature you define the flow; in an agent the model decides on the fly how many steps to take and in what order. This gives flexibility (an agent handles tasks you can't script in advance) but takes away predictability.

Tools — the agent's hands

An agent is useless without tools: without them it can only reason in text. Tools are the functions you give it: "find an order," "send an email," "run a query." The mechanics of how the model calls functions from a description are covered in tool calling; an agent is the layer on top that runs such calls in a loop and decides which one to make and when. Whether the agent succeeds depends directly on which tools you gave it and how clearly you described them.

Why an agent needs supervision

An autonomous loop is a source of new problems a single call doesn't have:

  • looping. An agent can get stuck repeating the same action. You need a hard step limit — a ceiling after which the loop stops forcibly.
  • cost. Each step is a model call, and there can be dozens. Costs grow quietly and fast; cap them with a budget.
  • unpredictability and risk. Since the model chooses actions itself, it may choose the wrong one — and if a tool changes something (deletes, pays, writes to a customer), the mistake is costly. Guard dangerous actions with human confirmation or give the agent only safe tools.
  • error accumulation. Over a long chain of steps, a small mistake early on drags the following steps off course. The longer the autonomous loop, the higher the risk of going astray.

Hence the practice: give the agent guardrails — step and budget limits, an allowlist of safe tools, confirmation for irreversible actions, verification of the result on output. Autonomy without guardrails isn't flexibility, it's a landmine.

When an agent is justified

The temptation to make "an agent for everything" is strong, but more often it's overkill. A guide:

  • no agent needed if the flow is known in advance — then an explicit chain of fixed steps is more reliable and cheaper;
  • an agent is needed if the task requires a variable number of steps and decisions on the fly that can't be scripted: figuring out an unfamiliar situation, assembling an answer from several sources depending on circumstances.

Rule: start with the simplest thing that solves the task — a single call, then a fixed chain, and only if that's not enough — an agent. An agent isn't a badge of sophistication but a tool for a specific class of tasks, paid for with predictability.

Where it applies

Agent applications fit where the path to the answer isn't known in advance: an assistant that decides for itself which data to consult; handling a complex ticket across several systems; automation where steps depend on intermediate results. The same "model in a loop with tools" principle underlies the AI development agents you write code with — only there the tools are about files and the terminal.

In short

  • An agent is a model in a "reason → act → observe" loop that chooses which tools to call; unlike a single call, the model defines the flow, not you.
  • Without tools an agent is useless; their set and the quality of their descriptions determine whether it succeeds.
  • Autonomy demands guardrails: step and budget limits, safe tools, confirmation of irreversible actions, result verification — otherwise looping, cost, and risk.
  • Don't make an agent by default: single call → fixed chain → and only with a variable number of steps — an agent.

This is the last article in the cluster on building LLM applications. Together with LLM feature basics, LangChain, RAG and vector databases, you have a map of how to embed AI into your own product — not just use it for development.