What Is an AI Agent? Definition, Types, and Real Business Use Cases

The Definition, Unpacked

Strip away the marketing and an AI agent has exactly three parts. A model that reasons about what to do next. A set of tools it is allowed to call — an API, a database query, a file, a browser. And a loop that keeps running until the goal is met or a stopping condition fires.

The loop is the part that matters. A normal program follows a path a developer wrote in advance. An agent is handed an objective and works out the path at runtime, one step at a time, using the result of each step to choose the next one. That is why the same agent can handle an invoice with two line items and an invoice with two hundred without anyone editing the code.

It is also why agents are harder to build than they look. The moment software chooses its own steps, you inherit a new class of problem: the wrong step, the repeated step, the step that costs money. Almost everything difficult about building agents that survive production is a consequence of that single design choice.

What Separates an Agent From Everything Else

Four kinds of system get called AI in the same sentence, and they behave nothing alike. The useful question is never how advanced something is — it is who decides the next step.

The Four Patterns Worth Knowing

Almost every agent in production is one of four shapes. Knowing which one you need saves more time than any model comparison.

• —Tool-using single agent. One model, a small and well-described set of tools, a clear goal. This covers the majority of real business cases and is always the right place to start.
• —Retrieval agent. The agent searches your own documents or database first, then answers from what it found. This is what people usually mean when they say they want to ask questions of their own data.
• —Multi-agent orchestration. A coordinator delegates sub-tasks to specialised agents and assembles the result. Genuinely powerful for long jobs, and roughly double the debugging work — worth it only once a single agent has provably hit its ceiling.
• —Human-in-the-loop agent. The agent prepares the work and a person approves the consequential step. This is the correct pattern for anything that moves money, sends external email, or writes to a system of record.

Where Agents Earn Their Keep

The use cases that work are unglamorous. They share a shape: a clear finishing condition, a bounded set of tools, and a person who cares whether the output is right.

• —Support triage. Read the incoming ticket, pull the customer history, classify it, draft a reply, and route the ones it should not answer. The routing is the value, not the drafting.
• —Document intake. Take a PDF, invoice, or form, extract structured fields, validate them against your records, and flag mismatches instead of guessing at them.
• —Research and enrichment. Given a company or a lead, gather information from a defined set of sources and return a filled-in brief in a fixed format.
• —Internal operations. Reconcile two systems that disagree, chase incomplete records, assemble the recurring report that currently eats someone's Monday morning.
• —Engineering support. Reproduce a bug report, run the suite, summarise what failed. Mechanical work that quietly consumes senior time.

Why Agent Projects Fail

In our experience the failures are rarely about model capability. They are about scope, evaluation, and permissions.

• —The goal is vague. Improve customer experience is not a goal an agent can finish. Reply to password-reset tickets within five minutes and escalate anything mentioning billing is.
• —There is no evaluation. If you cannot separate a good run from a bad one automatically, you cannot improve the agent — you can only have opinions about it.
• —Loops are unbounded. Without step limits and a cost ceiling, a confused agent will retry cheerfully and indefinitely. That is a budget problem before it is a quality problem.
• —Tool permissions are half-granted. An agent that can read but not write, or query but not filter, will invent a workaround. The workaround is usually wrong.
• —Failure is silent. An agent that returns something plausible when it should have stopped is more dangerous than one that crashes loudly.

When an AI Agent Is the Wrong Choice

Some of the most useful advice we give in a scoping call is not to build one.

If the steps never change, write the automation — it will be faster, cheaper, and testable. If the task is a single transformation of text, one model call is enough and the agent loop adds cost and latency for nothing. If a wrong answer is unacceptable and cannot be caught in review, keep the decision with a person and use the model only to prepare the evidence. And if the data the agent would need does not yet exist in a queryable form, that groundwork is the project — the agent comes after it.

Deciding between an agent, a chatbot, and plain automation comes down to one measurement: how much the steps vary with the input. Very little variation is an automation. A lot of variation is an agent. No variation at all is a script you already know how to write.

A Five-Question Test

Before commissioning anything, answer these honestly. They predict the outcome of an agent project better than the choice of model does.

• —Can you describe the finished state in one sentence a new hire would understand?
• —Do the steps genuinely change depending on what the system finds?
• —Do the tools it would need already exist as APIs or queries you control?
• —Can you tell automatically whether a given run succeeded?
• —Is there a person who will notice, and care, if the output is wrong?