Agents

The definition that survives contact

Start from tool use, because an agent is what you get when you put tool use in a loop. A model can't do anything but produce text. Give it a list of tools it may request, and its text can include a request: search this, read that file, run this query. Something outside the model carries the request out and hands back the result.

A single pass through that cycle is tool use. An agent is the same cycle, repeated, with the model deciding each time what to do next based on what came back:

1. You give it a goal.
2. It looks at what it knows and picks a next action.
3. Something runs that action and returns the result.
4. The result gets added to what it knows, and it decides again.
5. It keeps going until it judges the goal met, or something stops it.

That's the whole architecture. Not a new kind of model, not a mind with intentions. A loop, a list of available actions, and a stopping condition. When someone describes an agent in language that can't be reduced to those three things, they are usually selling rather than explaining.

Two very different things share the name

This distinction is the single most useful thing to hold onto, and Anthropic draws it cleanly in its own engineering guidance. Workflows are systems where, in their words, "LLMs and tools are orchestrated through predefined code paths." Agents are systems where "LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks."

The difference is who chooses the path. In a workflow, a developer wrote the steps and the model fills in the parts that need language: summarise this, classify that, draft the reply. The route is fixed and inspectable. In an agent, the route is decided at runtime by the model, and two runs of the same task may take different paths.

Most products sold as agents are workflows, and that is not a criticism. Fixed paths are cheaper, faster, far easier to test, and much easier to reason about when something goes wrong. Anthropic's own advice is to "find the simplest solution possible, and only increase complexity when needed," including the possibility of "not building agentic systems at all." The honest reason to reach for a real agent is a task where you genuinely cannot predict the steps in advance.

The loop is where the difficulty lives

Errors compound. This is the fundamental one. A single model call has some chance of going wrong. Chain many calls and each one inherits everything the previous ones got wrong, because the mistake is now sitting in the record as though it were a fact. The arithmetic is brutal and entirely general: multiply a per-step success rate by itself enough times and even a very reliable step produces an unreliable run. Longer chains are not linearly harder, they are exponentially harder, which is why demos of twenty-step agents look magical and production versions of them get quietly shortened.

The context fills up. Every action and every result gets added to what the model is holding, so a long run steadily consumes the window. Once it is full, something has to be dropped or summarised, and what gets dropped is usually the early material, which is exactly where the original instructions live. Agents that go strange late in a long task are often just agents that can no longer see what they were asked to do. → Context windows

Cost multiplies, quietly. Each turn re-sends the accumulated history, so cost grows faster than step count. This is the number that surprises people who priced a prototype on single calls, and it is the main reason a technically working agent gets cancelled. It is also the single biggest thing you can do something about, since the unchanging part of that preamble can be cached. → Tokens · Prompt caching

Stopping is a real problem. The loop needs to end. A model judging its own completion is the same model that will confidently claim a task is done, and the failure mode nobody warns you about is not an infinite loop, it's a confident early exit that reports success on a half-finished job. → Hallucination

The security problem gets sharper, not just bigger

Tool use introduces prompt injection: the model reads content from the outside world, and that content can contain instructions. A page, an email or a document can say "ignore your previous instructions and do this instead," and a system that cannot distinguish data from instructions may simply comply.

Agents make this worse along the two axes that matter. They read far more untrusted material, because reading is how they gather information. And they act more, often several steps after the moment they read the poisoned input, so the connection between cause and consequence is not visible to anyone watching. The practical rule is unglamorous and holds up well: anything irreversible, anything that spends money, and anything that sends a message on your behalf should require a human to approve it, no matter how reliable the agent has been. → Tool use

How to tell a real agent from a marketing one

Four questions, all answerable without technical knowledge, and all of them awkward for a vague product:

• Who decides the steps? If the vendor can hand you a diagram of the steps it takes, it's a workflow. That may be exactly what you want, but it isn't what the word implies.
• What happens when a step fails? A real agent notices and tries something else. A demo re-runs from the top and hopes. Ask what failure looks like, not what success looks like.
• What can it actually do? The list of tools is the list of everything it can ever do. If nobody will show you the list, there is nothing to evaluate.
• What does it do without asking? The honest products name their irreversible actions and gate them. Vagueness here is the loudest signal on the page.

Where they genuinely work today

The pattern that predicts success has little to do with model quality and almost everything to do with the shape of the task. Agents do well where three things hold at once:

• The result can be checked automatically. Code that must pass tests, a query whose output can be validated, a task with a verifiable end state. When the loop can tell whether it succeeded, it can correct itself, which is what breaks the compounding-error problem.
• Failure is cheap and reversible. Work in a scratch copy, a branch, a sandbox. Blast radius matters more than accuracy.
• The path genuinely can't be scripted. Investigation, search, debugging: work where the next step depends on what the last one turned up.

Where all three fail — an unverifiable result, irreversible consequences, a task you could have written down as steps — an agent is the expensive way to get an unreliable version of something a workflow would have done cleanly.

Sources

The workflow/agent distinction and the quoted definitions come from Anthropic's Building effective agents, fetched 11 August 2026, which also contains the recommendation to find the simplest solution and only add complexity when needed. The rest of this page is mechanical argument from how the loop works rather than vendor claim, and is presented as reasoning you can check rather than fact you should take on trust.

Read first → Tool use · Related → RAG and retrieval · Context windows · All → Concepts