What Is an AI Agent? A Developer's Definition
"AI agent" is used to describe everything from a customer-support chatbot to a system that opens pull requests without supervision. That range makes the term nearly useless in a technical conversation — two engineers can agree they are building an agent and mean entirely different architectures.
There is a narrower definition that survives contact with actual code, and it comes from a distinction that predates large language models: an agent is software that perceives an environment and takes actions in it to pursue a goal. Russell and Norvig's Artificial Intelligence: A Modern Approach has used that framing for decades, long before anything called an LLM existed.
Applied to systems built on language models, that yields a working definition:
An AI agent is a system where a language model decides which action to take next, executes that action against a real environment, observes the result, and repeats — until a goal is met or a stopping condition fires.
The load-bearing word is decides. If the sequence of steps is fixed in advance by a developer, there is no agent in the loop, however sophisticated the model calls are.
This article covers what that definition includes, the five classic agent types and how LLM-based systems map onto them, the components every implementation ends up with, and the failure modes that appear once one is running against real systems.
The Three Properties That Define an Agent
Three properties separate an agent from adjacent things. A system needs all three; systems with two are common and are usually better off staying that way.
It Chooses Its Own Next Action
The model selects what happens next from a set of available options, rather than following a branch a developer wrote. This is the property that distinguishes agents from workflows, and it is the one most often claimed without being true.
A useful test: if you can draw the complete set of possible execution paths as a flowchart before running the system, it is a workflow. If the path depends on what the model decides at runtime, it is an agent.
It Acts on an Environment
The chosen action does something outside the model's own context — queries a database, calls an HTTP endpoint, writes a file, sends a message. A model that only produces text about what someone should do is not acting; it is advising.
The environment is what makes agents both useful and consequential. A model that reasons brilliantly and touches nothing cannot cause damage or deliver value.
It Observes and Adapts
The result of the action returns to the model as new input, and the next decision accounts for it. This closes the loop. Without observation, a system that picks several actions up front and fires them is doing planning, not agency — it cannot recover when step two fails.
Agents, Assistants, and Bots
These three terms are often used interchangeably, and the distinctions are worth stating because they change what you need to build.
A bot executes predetermined responses. A rules-based support bot matching keywords to canned replies has no decision-making component at all.
An assistant responds to user requests, typically conversationally, and typically one exchange at a time. The user drives; the assistant answers. Most products labelled "AI assistant" are a model call wrapped in a chat interface.
An agent pursues a goal across multiple steps, deciding for itself what to do next. The user states an outcome rather than a request.
The boundaries blur in practice — many assistants now call tools, which makes them agentic in a limited sense — but the useful question is who decides the next step. If the user decides each time, it is an assistant. If the system decides, it is an agent.
The Five Types of AI Agents
Long before LLMs, Russell and Norvig classified agents by how sophisticated their decision-making is. The taxonomy is still the standard reference, and it is worth knowing because it clarifies what LLM-based agents actually are.
1. Simple reflex agents act only on the current input, using condition-action rules. A thermostat is the canonical example: if temperature is below the threshold, turn on heat. No memory, no model of the world. They fail whenever the correct action depends on something not visible right now.
2. Model-based reflex agents maintain an internal model of how the world works and what state it is currently in. This lets them handle partial observability — acting sensibly even when the current input does not reveal everything relevant.
3. Goal-based agents consider future consequences. Rather than reacting, they search over possible action sequences to find one that reaches a stated goal. This is where planning enters, and it is a substantially harder problem than reflex behavior.
4. Utility-based agents go further: instead of a binary goal, they maximize a utility function that scores outcomes. This lets them make trade-offs — faster versus cheaper, thorough versus timely — when no option is best on every dimension.
5. Learning agents improve their behavior from experience, adjusting based on feedback rather than staying fixed at whatever their designer specified.
Where LLM Agents Fit
Most systems currently described as AI agents are goal-based agents — given an objective, they reason about what steps might achieve it. Some approach utility-based behavior when prompted to weigh trade-offs, though the "utility function" is prose in a system prompt rather than a formal specification.
Very few are genuinely learning agents. A typical LLM agent does not update from its own runs; its weights are fixed, and any apparent learning comes from context carried within a single session, or from a human later editing the prompt. Systems that store outcomes to a memory retrieved on future runs get closer, but this is retrieval rather than learning in the classical sense.
The taxonomy also explains a common confusion. When people ask whether something is "really" an agent, they often mean whether it is autonomous and adaptive — closer to types 4 and 5. A goal-based agent is a legitimate agent by the classical definition even though it does not learn.
The Core Loop
Strip away framework vocabulary and nearly every LLM agent implementation reduces to the same loop:
observe → decide → act → observe → ...
Concretely, on each iteration:
- The model receives the goal, the history so far, and the list of tools it may call.
- The model emits either a tool call (structured arguments naming a tool) or a final answer.
- If it emitted a tool call, the runtime executes it and appends the result to the history.
- Repeat from step 1.
This pattern was described in the ReAct paper (Yao et al., 2022), which interleaved reasoning traces with actions and showed the combination outperformed either alone on tasks requiring external information. Most agent frameworks in use today are recognizable descendants of that structure.
Tool Calling Is the Mechanism
The loop only works because models can emit structured, machine-parseable requests to call a named function with typed arguments. OpenAI shipped function calling in 2023 and other providers followed with equivalent mechanisms; it is now a standard capability rather than a differentiator.
This matters more than it sounds. Before reliable structured output, extracting an intended action from prose required regex and hope, and it failed often enough to make production agents impractical. Structured tool calls turned a research pattern into something deployable.
Anthropic's Model Context Protocol (MCP), open-sourced in late 2024, addresses the layer above: rather than each application defining its own tool integrations, MCP specifies a common protocol so tools and data sources can be exposed once and consumed by any compatible client.
Termination Is a Design Decision
The loop needs to stop. In practice, implementations combine several conditions:
- The model signals completion by returning a final answer instead of a tool call.
- A maximum iteration count is reached.
- A cost or token budget is exhausted.
- An unrecoverable error occurs.
- A human review gate rejects the current state.
The iteration cap deserves particular attention. Without one, a model that misreads a tool result can loop indefinitely, and every iteration bills for the full accumulated context. Treating the cap as a required parameter rather than an optional safeguard is the more defensible default.
Levels of Agency
Rather than asking whether a system is an agent, it is usually more productive to ask how much agency it has:
| Level | The model decides | Typical example |
|---|---|---|
| 0 | Nothing | A single prompt, fixed output |
| 1 | Content only | Summarization inside a fixed pipeline |
| 2 | Which branch | Routing a ticket to a category |
| 3 | Which tools, in what order | A research assistant querying sources |
| 4 | The plan and the tools | A coding agent given a bug report |
| 5 | The goal itself | Rare, and rarely advisable |
Most production systems that deliver value sit at level 2 or 3. Levels 4 and 5 attract attention because they demonstrate better, but they are also where cost, latency, and failure rates rise sharply. Choosing the lowest level that solves the problem is generally the more durable engineering decision.
What Every Agent Implementation Needs
Implementations converge on the same components regardless of framework.
A model with tool-calling support. The decision-maker. Weaker models can drive simple loops, but reliability of tool selection tends to be the binding constraint rather than raw reasoning ability.
A tool registry. Definitions of what the agent may call — name, description, parameter schema. The descriptions are prompt engineering, not documentation: they are what the model reads to decide. Vague descriptions produce wrong tool choices.
State. At minimum, the running history of decisions and observations. This grows on every iteration, which has direct cost consequences covered below.
An execution runtime. The code that parses tool calls, invokes the actual functions, handles errors, and feeds results back. Frameworks such as LangGraph, CrewAI, and AutoGen differ mainly in how opinionated this layer is.
Guardrails. Constraints on what the agent may do — permission scoping, human approval for irreversible actions, sandboxing. These are not optional for an agent with write access to anything that matters.
Observability. Traces of what was decided and why. Agents fail in ways that are difficult to reconstruct after the fact; without traces, debugging becomes guesswork.
Where Agents Actually Break
The failure modes are structural rather than incidental, and they follow from the loop itself.
Context Grows Every Iteration
Each observation appends to the history. A ten-step run means the tenth model call carries all nine previous results. Cost per iteration rises through the run, and long runs can approach the model's context limit, at which point behavior degrades or the call fails outright.
Mitigations — summarizing older history, storing large results externally and passing references, resetting context at checkpoints — all trade fidelity for headroom. There is no clean solution, only a choice about what to lose.
Errors Compound
Multi-step reliability is multiplicative. A step that succeeds most of the time still yields a materially lower success rate across many steps, and the arithmetic worsens as step count rises. This is why shorter loops with more constrained tools tend to outperform longer, open-ended ones — and why "add more steps" is rarely the fix for an unreliable agent.
Tool Descriptions Are Load-Bearing
When an agent picks the wrong tool, the cause is usually an ambiguous description rather than a reasoning failure. Two tools with overlapping descriptions will be confused. This makes tool design a genuine engineering surface, and it is worth reviewing descriptions before concluding a model is inadequate.
Autonomy Amplifies Blast Radius
An agent that can write is an agent that can write the wrong thing, repeatedly and quickly. Deletion, external messages, financial transactions, and configuration changes all warrant human approval gates rather than trust in model judgment. The relevant question when granting a tool is not whether the model usually gets it right, but what happens on the occasion it does not.
When Not to Build an Agent
The pattern is frequently the wrong choice.
If the steps are known in advance, write them as a workflow. It will be cheaper, faster, deterministic, and debuggable — and a workflow with a model call inside it is a perfectly respectable architecture, not a lesser one.
If the task is a single transformation — classify, summarize, extract, rewrite — a direct model call is sufficient. Wrapping it in a loop adds cost and latency for nothing.
If failures are expensive and hard to reverse, the autonomy is a liability rather than a feature. Constrain the system until the irreversible actions require approval.
If latency matters to a user waiting on a response, multi-step loops are difficult to reconcile with that. Each iteration is a full model round-trip.
Agents earn their complexity when the path genuinely cannot be known in advance — open-ended research, debugging, tasks where the next step depends on what the last one revealed. Outside that, simpler architectures usually win.
Conclusion
An AI agent is a system where a language model decides its next action, executes it against a real environment, observes the result, and repeats until finished. The definition turns on the model making the routing decision at runtime — not on the sophistication of the prompt, the number of model calls, or the presence of the word "agent" in a product description.
The classical taxonomy places most current systems as goal-based agents: capable of planning toward an objective, but not genuinely learning from their own runs. That is a useful corrective to marketing language suggesting otherwise.
For teams evaluating whether to build one, the productive question is not "should this be an agent" but "what is the least agency that solves this." Level 2 routing with three well-described tools solves a surprising number of real problems, and it fails in ways that are cheap to diagnose.
Frequently Asked Questions
Is ChatGPT an AI agent?
It depends which capability is in use. Used as a chat interface where a person asks a question and receives an answer, it functions as an assistant — the user decides each next step. When it invokes tools such as web browsing or code execution and chains several steps toward a goal on its own, it is behaving agentically. The product spans both modes, which is exactly why the label is contested.
What does an AI agent do?
It pursues a goal by repeatedly deciding on an action, executing it, and reacting to the result. Concretely that might mean researching a question across multiple sources, triaging and routing incoming tickets, investigating a failing test and proposing a fix, or gathering data from several systems to assemble a report. The common thread is a multi-step task where the correct sequence is not known in advance.
What are the 5 types of AI agents?
The classical taxonomy is simple reflex, model-based reflex, goal-based, utility-based, and learning agents, ordered by increasing sophistication of decision-making. Most LLM-based agents are goal-based: they plan toward an objective but do not update themselves from experience. Note that some sources list seven or more categories by adding groupings such as multi-agent or hierarchical systems, which describe how agents are composed rather than how an individual agent decides.
What is the difference between an agent and a workflow?
In a workflow, the sequence of steps is determined by developer-written logic; the model may be called within steps but does not choose the path. In an agent, the model chooses the path at runtime. The practical test is whether you can enumerate every possible execution path before running the system. Workflows are cheaper, faster, and easier to debug, and should be preferred whenever the steps are actually knowable in advance.
What is the salary of an AI agent?
This question is usually asking about roles that build agentic systems — titles such as AI engineer, machine learning engineer, or applied AI developer — rather than about software. Published figures vary widely by country, seniority, industry, and whether the role is research or product-focused, so any single number quoted without that context is unreliable. Current listings on a major job board for your specific location and seniority will give a more accurate picture than a global average.
Do AI agents need to use large language models?
No. The agent concept long predates LLMs and includes rule-based systems, reinforcement learning agents, and robotic controllers — the five-type taxonomy above was written with those in mind. What language models added was general-purpose reasoning over unstructured input, which made agents practical for tasks that resist explicit rule-writing. In current usage "AI agent" usually implies an LLM, but the underlying pattern does not require one.
Are AI agents safe to run autonomously?
It depends entirely on what the agent can do. An agent restricted to read-only queries has a limited blast radius. An agent that can delete records, send external messages, or move money can cause real harm when it errs, and models do err. Standard practice is to scope permissions tightly, require human approval for irreversible actions, sandbox execution, and log every decision for review. Autonomy should be granted to the extent that failures are recoverable.
Comments (0)
No comments yet.