Agent systems: what they are and when you need one

Target audience: everyone | Prerequisites: 3.7 Security: keys, data, malicious instructions

What you'll learn

After this document you will be able to:

• explain what makes an agent an agent — a goal, tools, and decision-making freedom — and how the agent loop (agent loop: plan → act → observe → decide) works;
• decide between a workflow and an agent, and justify the choice;
• name the agent's four main risks and the safeguard (a restriction built into the system's design) that mitigates each;
• build a hybrid (a workflow with an agent step) and explain why it is often the best choice.

In plain terms

A workflow is a package tour: the program is written out in advance and the destination is known. An AI agent is a local guide: you give it a destination (“the customer must get a clear answer”), a phone, and permission to decide for itself whom to call and when. The guide finds a way even where the package tour doesn't reach — but nobody knows in advance how many calls it will make or how much they will cost. That's why the guide is only put to work when the package tour can no longer cover it.

From document 1.5 we know the three shapes and the basic rule: the agent is the last choice, not the first — this document unpacks that rule. 3.3 showed how the model requests tools; now we assemble the parts into an agent system.

What makes an agent an agent: three parts

An AI agent (a system that has a goal, tools, and decision-making freedom) differs from a single model call in three properties:

1. A goal — what end state counts as good. In a workflow the target is hidden in the sequence of steps — the path itself shows where you're going. An agent has no path, so the goal must be stated and checkable: not “help the customer” but “the question has been answered and the answer contains only data that came from the system”. The latter also keeps hallucination (the model's confidently stated but wrong answer) at bay.

2. Tools — what it can use. The 3.3 principle applies: function calling means the model asks, the system acts — an agent cannot do anything itself; it can only demand that your program do it. Types: data lookup, exact computation, action outside the system — the last one always through the human-in-the-loop.

3. Decision-making freedom — it chooses the order and the steps itself. The real difference is not in the tools or the model, but in the path: in a workflow the path is written out in advance (2.3), while for an agent the model itself decides the next step — based on what it has learned so far.

The three parts working together form the agent loop:

   GOAL: “the answer is based only on data that came from the system”
        │
        ▼
  ┌─► PLAN — what is the next useful step?
  │        │
  │        ▼
  │   ACT — a tool call
  │   (the model asks, the system acts — 3.3)
  │        │
  │        ▼
  │   OBSERVE — what did the result say:
  │   data in hand / the call failed / the answer half-done?
  │        │
  │        ▼
  │   DECIDE — is the goal met?
  │        │
  │        ├── yes ──► RESULT to the output + an entry in the history
  │        │
  └── no ◄─┘  (back to the start, a new plan)

The loop's length is not known in advance: a workflow has its number of steps written down; the number of an agent's rounds is decided by the agent itself. That's why you set the limit — “ten rounds, then stop and hand over to a human” — because an unbounded loop is an open-ended cost and risk.

In plain terms: a workflow is a machine with a button — press it and it runs through a fixed path; an agent is an experienced assistant to whom you state the goal and hand the tools, but who finds the way itself. What turns an assistant into an agent is knowing “which end state is good”, tools (the model asks, the system acts), and permission to decide the order itself.

Agent vs workflow: a comparison

An agent is justified when three things hold at once:

• The path is not known in advance — which steps a task will take is only learned as the work proceeds.
• Steps depend on content — the next step is decided based on what the previous one found.
• Tasks are diverse — a separate flow for every new question type means endless building.

And three signs that an agent is not justified:

• The path is known → workflow (2.3): a pre-written path is faster, cheaper, and more controllable.
• Errors are expensive → checkpoints and human-in-the-loop (a workflow where a human approves the result before it is used) work reliably only at a fixed place (3.5) — on an agent's path you don't know that place in advance.
• Simplicity is enough → always try the simpler shape first — that's the basic rule from 1.5.

In all four rows the table favors the workflow — and that's the point: an agent is justified only where the path cannot be written out in advance.

Agent risks

1. Costs grow. Each round is at least one model call — a ten-step path means ten or more calls, where a fixed flow would have been limited to two. Since the agent decides the number of rounds, the cost before execution is only an estimate (3.6).

2. Errors propagate. The rounds rest on each other: if the agent early on grabs the wrong order number or picks the wrong tool, the subsequent steps are already based on wrong data — and it may not suspect it itself. In a fixed flow a checkpoint catches the error; on an agent's path you have to foresee that point and install it.

3. Predictability is lost. The same question may take a different path today and tomorrow — a single test case no longer proves anything. Quality must be assessed with samples and continuously, not once before launch (4.5).

4. Safety must be real. An agent is one step away from the outside world, so the 3.5 safeguards apply with extra strictness: tools the agent doesn't have cannot be used — no matter what the goal says; money and shipping always go through a human's signature; and a prohibition written in the instructions alone doesn't protect, because malicious instructions know how to get around a ban (3.7).

In plain terms: an agent does more than a fixed flow — and has more ways to go wrong; each mistake gets more expensive the later it is caught. The risks are not an argument against the agent — they only set the condition: the path must truly be unwritable in advance.

The hybrid: a workflow with an agent step

Most tasks have a path that is largely known after all — and there a workflow keeps things predictable. A hybrid (a workflow with an agent step) combines both: a fixed main path and ONE agent step where the path cannot be written in advance. This is often the best solution: each part does what it does best.

Where to place the agent step? At the point where the workflow would break down — if one point needed a new branch for every new type of case, the number of branches would grow faster than you can maintain them. The fixed part does the fixed steps, the agent solves the rest — and the agent's output no longer goes straight to the customer: it is a draft that passes through the same approval as every other path. This way the first gives predictability, the second flexibility, and the approval chain catches the error before it reaches the customer.

A step-by-step example: the online store picks a path

Starting point. The home goods store's return flow (2.5) works: about 40 emails a day, a classifier assigns the type, a fixed path drafts a proposal, Piret approves. Now the emails diversify: size exchanges, order changes, complaints, and a whole bunch of questions that don't fit any known type. Three paths:

Path a — five new workflows. A separate flow for every new type: steps, conditions, tests. It works, but every new question type is a new build, and a customer who writes about two things at once still ends up on the “unknown” path.

Path b — one agent with tools. The agent gets a goal (“the customer's question has been answered and the answer is based on real data”) and three tools: order lookup, product info, starting the exchange flow — and decides itself what to ask for and when. Flexible, but all four risks apply; financial decisions, however, always go through a human's signature (3.5).

Path c — a hybrid. The fixed base stays untouched: the return flow keeps working, complaints still go to a human as before. The change is one: the “unclear” branch no longer takes an email straight to Piret's list, but to an agent step — an agent whose tools (order lookup, product info — read-only) draft a proposal (“this is a size exchange; here is the data and a suitable option”), which goes to Piret for approval.

Recommendation. Start with the hybrid. Watch for a few weeks (4.5, 4.6) which emails land at the agent step and how many proposals Piret changes. If 90 percent of the “unclear” ones turn out to be three recurring questions, build fixed flows for them — the agent's load decreases. If the proposals are usable and costs are under control, the agent's share can grow. Let the deciding factor be data, not impressions — an agent is not a goal in itself.

Summary

• An AI agent is a system that has a goal, tools, and decision-making freedom, and it works in an agent loop: plan → act → observe → decide. The agent decides the number of rounds — you set the limit.
• Choosing the shape: path known in advance → workflow; path depends on content, cannot be written in advance, errors are not expensive, and the simpler shape was not enough → agent.
• Four risks: costs grow (3.6), errors propagate, predictability is lost (4.5), and safety needs real safeguards, not just a prohibition in the instructions (3.5).
• A hybrid — a fixed main path + an agent step at one point, always with approval — is often the best solution and a sensible starting point.
• A simpler solution that works beats an impressive agent that sometimes errs. Agents are a powerful tool, not a status symbol.

What's next?

• previous → 3.7 Security (level 3 is complete)
• next → 4.2 RAG: using your own data as a source of answers
• back → handbook index