Article
The term got popular before it got precise, so it now covers everything from a single API call with a system prompt to a fleet of coordinating processes. Here is the definition we use, because it is the one that predicts what a system can and cannot do: an AI agent is a model that can call tools, observe the results, and decide what to do next, in a loop, until the task is done or it gives up. Remove the loop or remove the tools, and it is something else, usually simpler and usually a better fit.
The three things that make it an agent
Tool use. The model can take an action in the world, not just produce text — call an API, run a query, write to a record. Without this, it is a chatbot with good answers.
Observation. The result of the action goes back to the model before it decides the next step. Without this, it is a script that calls tools in a fixed order, which is often what people actually need and is far cheaper to build.
Autonomy over the next step. The model, not a developer, decides what happens next based on what it saw. This is the part that creates both the value and the risk, and it is why the harness around the model matters more than the model itself.
What it is not
Not a bigger prompt. A well-written prompt against a single model call is still one call; it does not become an agent by being longer or by claiming to be one in its instructions.
Not automatically better than a workflow. A fixed sequence of steps with a model doing the judgement-heavy parts is often the right answer, and it is more predictable, cheaper to run, and easier to test than letting the model choose the sequence itself. We reach for a true agent when the number of possible paths through a task is too large to enumerate in advance; otherwise we build the workflow, which is most of the time.
Not one thing. "Agent" spans a single-tool assistant answering questions about a customer record, and a multi-agent system with dozens of tools and its own approval pipeline. Cost, risk, and architecture differ by an order of magnitude between them, which is why "how much does an agent cost" has no single answer — see our breakdown of what actually drives the number.
Why the framework matters less than the definition
Ask ten teams building agents which framework they use and you get ten different answers, because LangGraph, CrewAI, and AutoGen all implement the same three-part definition with different opinions about how explicit the loop should be. The framework is a convenience layer over tool calls and observation; it does not change what an agent fundamentally is, and choosing one before the tools and permissions are designed usually means choosing it for the wrong reasons.
Where agents earn their complexity
The clearest signal that a task needs a real agent rather than a workflow: the right next step depends on information you cannot know until the previous step runs, and the number of branches is too large to hand-write. Investigating a support ticket that could resolve in one lookup or twelve, depending on what the first lookup finds, is a genuine agent task. Sending a welcome email after signup is not, no matter how the vendor pitching it phrases it.
Before building one
Write down the tools it would call and what happens if it calls one with the wrong argument. If that list is short and the failure modes are containable, you likely want an agent. If the list requires touching billing, deleting records, or anything hard to reverse, read what we do differently when an agent can modify customer data before writing a line of the harness. Our AI Agents work always starts with this list, because it is the same list a security review will ask for later.