Agents

A support team asks for "an agent" to handle refund requests. The process has four steps: read the request, find the order, refund it if the amount is under 50 euros, otherwise pass the case to a support representative. The steps never change order. This team does not need an agent. It needs a fixed workflow, with an LLM (large language model) to read the request.

Fixed workflow or agent

In a fixed workflow, code sets the order of the steps in advance. An LLM can handle one of them, such as reading a request or drafting a reply, but it does not choose what comes next. In an agent, the model decides: which step comes next, which tool to call, when to stop. A guide published by Anthropic in December 2024 draws this distinction. It advises looking for the simplest solution and adding complexity only when it is needed.

Compare the two approaches on three points, not on intelligence:

• predictability: a fixed workflow always follows the same path, while an agent can take a different one on every request;
• cost: an agent sends several requests to the model for a single task, and their number varies. According to the same Anthropic guide, an agent often trades higher cost and a longer response time for better results;
• debugging: when a fixed workflow goes wrong, you know at which step. When an agent goes wrong, you have to read through its whole path to see where it went off course.

An agent is justified when the steps cannot be known in advance. Finding out why a customer's invoice is wrong may mean checking the contract, then the order history, then an old ticket, in an order that depends on what you find. Nobody can write that order down in advance.

The loop: plan, act, observe

An agent runs in a loop. It plans: based on the goal and what it already knows, the model picks the next action. It acts: it asks to call a tool. It observes: it reads the result, then goes back to the start of the loop. Anthropic's guide stresses this last point: at each step, the agent must check where it stands against real results, not against what it assumes.

A tool is a function the application makes available to the model: look up an order, read a document, create a ticket, send an email. Each tool is described by a schema, like a structured output. In October 2026, Anthropic's documentation states that the model never runs anything itself. It produces a request to call a tool. The application runs the tool, or the vendor does for some built-in tools, then sends the result back to the model. So the model does not decide what it is allowed to do. The application does.

To connect an agent to a company's tools, there is a common protocol: MCP (Model Context Protocol). In October 2026, its website describes it as an open-source standard for connecting AI applications to external systems. The protocol makes the connection easier. It does not define what the agent is allowed to do once connected.

Knowing when to stop

An agent decides by itself when it is done. Nothing guarantees that it will: it is up to you to set limits. Anthropic's guide mentions common stopping conditions, such as a maximum number of passes through the loop. In October 2026, OpenAI's agent development kit applies the same idea: past the maximum number of passes the developer sets, it stops the run and raises an error.

An agent that stops on a plain message, with no tool call, is not necessarily done. As of October 2026, Anthropic's guide for Claude Opus 5.5 says to treat that message as a report, not as proof that the task is complete. State up front what counts as done. Keep the task's state outside the conversation, in a checklist or a progress file the agent updates. If items remain open, prompt the agent again by naming them, but two or three times at most: an agent that is truly stuck should stop so that someone can look at what is blocking it. For a large job, split it across several subagents, agents that the first one launches, each on part of the task. Then check each one's evidence (a test result, a file, a source), not just its account. According to Anthropic, a verifier subagent that starts from a fresh context checks better than an agent rereading its own work.

Set a budget too. Each pass through the loop is a new request that sends the model the whole history of the task: the instructions, the tool definitions and every result obtained so far. So each pass costs more than the one before. Prompt caching narrows the gap without removing it. The Tokens and cost page explains what a request costs. A budget per task, in requests or in euros, turns an endless loop into a visible incident.

Finally, build in human checkpoints. Before an irreversible action, such as issuing a refund, writing to a customer or deleting data, the agent stops and waits for approval. Anthropic's guide mentions these pauses, and OpenAI's kit pauses the run until any tool that requires approval gets it.

How an agent fails

Three failures come up often.

• Going in circles: the agent repeats the same action without making progress, for example the same search with barely different words. Without a limit, it burns through the budget until someone notices.
• Drift: a small mistake early on steers every later step. Anthropic's guide talks about compounding errors. The agent ends up solving a different problem from the one it was given.
• Overreach: the agent does more than it was asked. Asked to draft a reply, it sends it. Asked to fix one record, it fixes ten.

The final answer alone does not reveal these failures. A good answer can hide a path of forty tool calls, one of which changed data it should not have touched. So evals (short for "evaluations") of an agent also check its path: which tools it called, how many calls it made and which actions were blocked.

Making deterministic and probabilistic steps work together

A fixed workflow is deterministic: the same input always follows the same path and gives the same result. An LLM is probabilistic: it builds its answer through a series of random draws, as the page on the large language model explains. So the same request can get two different answers. A serious product often combines the two. The question is not which one to pick, but where to draw the line between them.

Three shapes

• A fixed workflow with an LLM on one step. A company sorts the emails it receives. The code receives the email, the LLM gives it a category from a closed list of values (invoice, complaint, other), then the code routes it to the right team. The model reads, but does not decide what comes next.
• An agent. This is the wrong-invoice investigation from earlier: the agent chooses where to look next, based on what it has just found.
• An agent inside one step of a fixed workflow. Back to refunds. For simple cases, the fixed workflow is enough. For doubtful cases, one step hands the investigation to an agent: it checks the order, the carrier's tracking and past messages, then proposes a decision. The workflow then takes back control. It checks the proposal, asks for human approval when needed and triggers the refund.

In the third shape, the agent proposes and the fixed workflow decides. Nothing forces you to pick a single shape: Anthropic's guide presents its common patterns as building blocks that developers can shape and combine.

The boundary between the two

Five elements govern the moment the agent hands control back to the fixed workflow.

• A structured output. The agent does not return free text, but a response in a format set in advance: a decision chosen from a closed list (refund, decline, escalate), an amount and a reason.
• Validation in code. The schema guarantees the shape, not the accuracy. The code checks the business rules: the order exists, the amount does not exceed the order total, the 50-euro threshold is respected.
• A fallback behavior. When validation fails, the fixed workflow knows what to do: retry the call once, then pass the case to a support representative. A failure must never block the queue or go unnoticed.
• A human checkpoint. Before an irreversible action, a person approves the agent's proposal. You can reserve this approval for amounts above a threshold.
• Tools cut to what is needed. The investigating agent gets read tools, nothing else. The action that changes something stays in the fixed workflow. This is the principle of least privilege, covered on the Tools and MCP: connecting a model to your systems page.

Best practices

• Choose the shape step by step, not for the whole product. One product can have ten fixed steps and a single step handed to an agent. For each step, ask yourself whether you can describe in advance what it has to do.
• Make every step that acts idempotent. An idempotent step has the same effect whether it runs once or twice. In October 2026, the online payment service Stripe describes this mechanism in its documentation: an idempotency key attached to a request lets you retry it without the risk of creating a second object, such as a second refund.
• Log every step. Record what each step received, what it returned and the path taken. Without this log, you will not know whether an error comes from the code or from the model.
• Put limits on the agent part. The maximum number of passes, the budget and the stopping conditions apply to the step handed to the agent. The cost of the fixed workflow is predictable; the agent's cost is not.
• Test each part separately. The fixed workflow is tested like ordinary code: the same input gives the same result. The agent part is tested with evals on many real cases, and judged on a success rate, not a simple yes or no.

Watch-outs

• Hidden non-determinism. As soon as an LLM picks a branch, the fixed workflow is no longer fully deterministic: the same email can go to one team one day and to another the next. In October 2026, Anthropic's glossary points out that identical inputs can produce different outputs. Add an "unknown" value, routed to a person, and test each case several times.
• Retries that repeat an action. A step runs past its time limit and the workflow retries it. But the refund had already gone out: the customer is refunded twice, or receives two emails. Idempotency protects against this double effect.
• An agent output used without validation. An invented order number, in the right format, passes the schema and travels all the way to accounting. Every output from the agent is a proposal to check, not reliable data.
• The word "agent" for a fixed workflow. A product presented as an agent is sometimes a fixed workflow with an LLM step. That is not a flaw: it is often the right choice. Ask which steps the model chooses on its own: the answer tells you what you need to test.

What it means for you

The classic mistake

Around this topic