What AI agents actually do — and what they don't

The word "agent" has become one of those terms that gets applied to so many different things that it starts losing any useful meaning. A customer support chatbot gets called an agent. A fully autonomous system that books flights, sends contracts, and reconciles expenses gets called an agent. A prompt with a loop around it gets called an agent.

This isn't purely a marketing problem. The vagueness creates real issues when someone is trying to decide whether to build one, buy one, or automate the thing they're already doing with a simpler approach.

A practical definition

Here's the distinction I find most useful: an agent is a system that perceives some state of the world, makes a decision about what to do, takes an action (often via a tool or API call), and then observes the result of that action before deciding what to do next.

That loop — observe, decide, act, observe — is what separates an agent from a pipeline. A pipeline runs in sequence, step by step, without reacting to intermediate results. An agent responds to what it finds.

The "intelligence" part is the model's ability to make decisions that generalise across cases it hasn't seen before. A rule-based system can do the same observe-decide-act loop, but its decision logic is fixed. An agent using a language model can reason about novel situations using context rather than matching against a predetermined list.

Where the range actually matters

There's a spectrum of autonomy, and different positions on it make sense for different problems.

At one end: an agent that drafts a reply to an email enquiry, then pauses and waits for a human to review before sending. The model does the reasoning. A person makes the final call. This is useful when the stakes are moderate and the volume is high enough that drafting everything manually is slow.

At the other: an agent that receives a booking request, checks availability, sends a confirmation, updates the calendar, and marks the task complete — all without any human involvement. Faster, cheaper, but only safe when the decisions involved are genuinely low-stakes and the edge cases are well-understood.

Most real implementations sit closer to the middle. The agent handles the common case autonomously and surfaces exceptions for human review. Getting the boundary right is usually the hard part of the design work.

The question isn't "can we automate this?" It's "which part of this can we automate without creating risk we haven't accounted for?"

What they're good at

Agents work well when:

• The task involves reading unstructured input (emails, messages, documents) and extracting structured information from it
• The decision logic is clear enough to describe, but complex enough that hardcoding every rule would be impractical
• The volume is high enough that manual processing creates a real bottleneck
• The consequences of an error are recoverable — the agent books the wrong slot, the human notices and fixes it
• There's a clear definition of what "done" looks like

What they're not good at

Agents are less useful — or genuinely risky — when:

• The decision requires judgement that's hard to describe (relationship dynamics, cultural context, organisational politics)
• Errors are difficult or impossible to reverse — financial transfers, legal commitments, public communications
• The inputs are highly variable in ways that weren't anticipated during design
• There's no good feedback mechanism — the agent can't tell whether it made the right call

The last one matters more than people expect. A lot of agent failures don't announce themselves. The system keeps running, keeps making decisions, and the error accumulates quietly until someone notices that something has been wrong for three weeks.

The part people underestimate

Most of the complexity in building a useful agent isn't in the model or the prompt. It's in the edge case handling, the logging, and the failure modes.

What happens when the input is ambiguous? What happens when the API the agent is calling returns an error? What happens when the agent reaches a decision it's not confident in? These questions have to be answered before the system goes into production, and answering them requires someone who understands both the process being automated and the failure modes of the model being used.

The agents that work well in production are usually simpler than they look. They handle one category of task, log every decision clearly, and have obvious escalation paths when something falls outside the expected range. The ones that fail are often the ones that tried to handle too much autonomously without enough visibility into what they were doing.