What is an AI agent?

“Agent” has become one of the most stretched words in software. Strip away the marketing and a useful definition remains: an AI agent is a system in which a language model decides, step by step, what to do next, carries out those decisions through tools, looks at what happened, and keeps going until the job is done. The interesting questions are not whether something deserves the label, but how much control you hand to the model and whether that control is worth the price.

The agent loop

At the heart of every agent is a simple loop:

1. Decide. The model reads the goal plus everything gathered so far and chooses an action: call a tool, or declare that it is finished.
2. Act. Your application runs the chosen tool: a search, a file read, a shell command, an API request.
3. Observe. The tool’s result is appended to the model’s context.
4. Repeat. With the new information in view, the model decides again.

In pseudocode, the whole idea fits in a few lines:

messages = [goal]
for step in range(MAX_STEPS):
    reply = model(messages, tools)
    if reply.is_final_answer:
        break
    result = run_tool(reply.tool_call)   # your code executes it
    messages += [reply, result]          # the observation feeds the next decision

This pattern goes back to research such as ReAct (Yao et al., 2022), which showed that letting a model interleave reasoning with actions, then read the observations, beats reasoning alone on tasks that need outside information. Modern agents are more polished, but the loop is recognisably the same.

The observation step is what makes the loop powerful. A model on its own can only predict; a model that runs the tests, reads the error and tries again is working from ground truth. That is why coding is such a natural home for agents: the environment gives clear, frequent feedback.

Workflows versus agents

Anthropic’s widely cited guide, Building effective agents (December 2024), draws a helpful line inside the broad family of “agentic systems”:

• Workflows orchestrate LLM calls and tools through predefined code paths. A developer decides the structure; the model fills in the steps.
• Agents let the LLM dynamically direct its own process and tool usage. The model decides the structure as it goes.

Common workflow patterns include:

• Prompt chaining: a fixed sequence, such as outline, then draft, then edit.
• Routing: classify the input, then send it to a specialised prompt or model.
• Parallelisation: run independent subtasks, or several attempts, side by side.
• Orchestrator-workers: one call breaks a task up and others handle the pieces.
• Evaluator-optimizer: one call produces, another critiques, repeat.

None of these is inferior. A workflow is often exactly what you want, because you can test each path, predict costs and explain behaviour.

The key question is not “is this an agent?” but “who controls the control flow: my code or the model?”

The autonomy spectrum

It helps to picture a dial rather than a switch:

1. A single call: one prompt in, one answer out, perhaps with retrieved documents.
2. Fixed workflows: several calls in a sequence you designed.
3. Model-chosen branches: the model picks which predefined path to take.
4. Tool-using loops: the model chooses which tools to call, and in what order, within one task.
5. Long-running agents: the model plans, acts over many steps, and may work for a long time with light supervision.

Every notch up buys flexibility, since the system can cope with situations you did not anticipate, and costs predictability. Many successful products sit in the middle: an agent loop with a small, carefully designed toolset, hard limits and human checkpoints.

When an agent is the right tool

Agents tend to earn their keep when:

• the task is open-ended, so you cannot write down the steps in advance;
• the model genuinely needs to choose its approach as it learns more;
• the environment provides feedback it can check against, such as tests, search results or validation errors;
• the task is valuable enough to justify extra time and tokens;
• mistakes are recoverable, or a human reviews before anything irreversible happens.

When it is not

Agents carry real costs, and they multiply:

• Money. A loop can make dozens of model calls, each re-reading a growing context.
• Latency. Many round trips mean seconds or minutes, not milliseconds.
• Compounding errors. If each step is 95% reliable and nothing checks the work, a 20-step run succeeds only about a third of the time. An early wrong turn can mislead every step after it.
• Testing and debugging. Non-deterministic paths are harder to evaluate and explain.
• Blast radius. An agent with real tools can do real damage: delete files, send messages, spend money.

So the practical advice is to start simple. Try a single well-prompted call first. If that falls short, add a workflow. Reach for an agent only when the task truly demands flexibility, and when you can measure that the agent does better.

Building sensibly

If you do build an agent, a few habits go a long way:

• Cap the loop: maximum steps, tokens, time or spend.
• Keep tools few and well designed: the model can only act as well as its tools let it.
• Make the process visible: log each decision and observation so you can see why it did what it did.
• Put humans at the risky points: require approval before irreversible or costly actions.
• Test in a sandbox before letting it near production systems or real data.

An agent is not magic; it is a loop around a model, with tools. Understanding that loop, and being honest about when you need it, is most of the battle.