Ask ten people to list the types of AI agents and you will get ten different lists. Some name five classical types from a textbook; others name the labels vendors use today — conversational agents, coding agents, research agents, multi-agent systems. Both lists are real, and neither replaces the other. This guide maps the two onto each other: the five classical types of AI agents, how each one decides what to do, and how the modern functional types sit on top of them — so you can name the kind of agent you need instead of guessing from marketing.
There is no universally agreed definition of an AI agent. The US Government Accountability Office says so plainly, and the honest way to read the field is as a spectrum of capabilities rather than a yes-or-no label.
What a type of AI agent actually means
The standard definition comes from Stuart Russell and Peter Norvig in Artificial Intelligence: A Modern Approach: an intelligent agent is anything that can be viewed as perceiving its environment through sensors and acting upon that environment through actuators. The National Institute of Standards and Technology describes agentic systems in similar terms: systems that can independently make decisions, learn from interactions, and adapt to changing environments.
Underneath the definitions, most agents run the same loop: perceive, reason, act, then observe the result and repeat. Anthropic’s engineering guidance draws one architectural line that matters before any taxonomy: a workflow is a system where a language model and its tools are orchestrated through predefined code paths, while an agent is a system where the model dynamically directs its own processes and tool usage. The line is who directs the process: code paths written in advance, or the model deciding at run time.
Modern LLM-based agents are built from a base unit Anthropic calls the augmented LLM: a model enhanced with retrieval, tools, and memory. The model can generate its own search queries, select appropriate tools, and determine what information to retain. That description belongs to today’s LLM systems. The classical types mapped out below predate language models — a thermostat, a fixed rule set — and do not require one: the taxonomy describes decision logic, not the technology that implements it. The types differ in how the agent decides what to do next.
There are two axes to keep apart. The first is how the agent decides: react to the present moment, keep a model of the world, plan toward a goal, weigh outcomes, or learn from experience. That axis gives the five classical types. The second is what the agent is built for: holding a conversation, writing code, doing research, or working as part of a team. That axis gives the modern functional types. A coding agent is a role on the second axis; the classical type underneath it is a question for the first.
Simple reflex agents
A simple reflex agent selects actions based entirely on the current percept. It follows condition-action rules — if this, then that — and holds no memory of the past. It does not consider the history of its interactions with the environment and has no concept of the future; its decision-making is entirely present-focused.
The textbook example is a thermostat that switches on at a set temperature. A fixed rule set maps an input directly to an action, and the pattern is reliable for narrow jobs — useless the moment the right action depends on history. Outside the conditions its rules cover, what happens depends on the rules and fallback handling the implementation provides: a condition-action agent has no memory and no reasoning of its own to fall back on, so an input its rules do not cover is one it cannot handle on its own terms.
A condition-action rule set looks like this:
{
"rules": [
{"if": "temperature < 20", "then": "heater_on"},
{"if": "temperature >= 20", "then": "heater_off"}
]
}That is the whole decision logic. There is nothing to learn, nothing to plan, and nothing to remember — which is a feature when the job is genuinely that simple, and a liability the moment it is not.
Model-based reflex agents
A model-based reflex agent improves on the simple reflex agent by maintaining an internal state that depends on the history of its percepts. That internal model reflects at least some of the unobserved aspects of the current state, so the agent can act sensibly even when it cannot see everything at once.
Take an illustrative example: a cleaning robot that maps a room as it moves. It cannot see the whole room at once, so it keeps an internal model of where it has been and how the space is laid out, and it chooses its next move from the current percept plus that model. The model fills in what the sensors miss: the agent knows how the world changes in response to its own actions and how the environment evolves between observations.
A model-based reflex agent in an LLM system would pair retained state with an internal model of how the environment changes — the model, not the memory alone, is what makes it model-based. Memory by itself does not establish the classification: logs of past turns that are stored but never used to choose the next action do not change the agent’s type, and a system that decides by fixed rules on the current percept alone is simple reflex whatever it happens to have stored. The distinction is whether the agent tracks how the world evolves in an internal state and uses that model alongside reactive rules.
Goal-based agents
A goal-based agent knows where it wants to end up. Instead of just reacting to the current state, it evaluates potential actions by asking whether each one moves it closer to an explicit goal. That often involves search and planning, because the agent needs to predict the outcomes of its actions before choosing one.
The textbook example is a navigation app choosing between routes: it is not reacting, it is comparing paths against the objective of reaching a destination. In agent systems, the same shape appears in research assistants that gather sources to answer a question, multi-step automation, and lead qualification — any job where the right next step depends on a plan rather than a rule.
Planning costs more than reacting. A goal-based agent may need to search ahead and run several rounds of model and tool calls before it acts, and each of those rounds is work a reflex agent never does. That is why the planning type earns its place only where the task genuinely needs a plan — a research question with an unknown answer, a schedule with competing constraints — and not where a fixed rule would have done.
Utility-based agents
A utility-based agent extends the goal-based design by assigning numeric values to outcomes. Where a goal-based agent treats success as binary — the goal is reached or it is not — a utility-based agent measures success on a continuum using a utility function. That lets it compare different states according to a preference, and strive not only to achieve its goals but to reach the best version of them.
This is the type for trade-offs. Pricing agents, resource allocation, and agents that balance speed against accuracy are the typical uses: each candidate outcome gets a score, and the agent picks the highest. The same mechanism is what makes the type dangerous. If the scoring function is wrong, the agent maximises the wrong thing: a support agent scored on tickets closed will close tickets, and whether it resolved them is a different question — one the utility function has to encode explicitly. Where utility is hard to define, the type breaks down, because there is nothing to maximise except a number someone wrote down.
Learning agents
A learning agent improves its performance over time based on experience. Russell and Norvig describe four components: a learning element that makes improvements, a performance element that selects actions, a critic that evaluates how well the agent is doing, and a problem generator that suggests exploratory actions to learn new things.
In practice, the shape shows up as recommendation agents that refine their suggestions from what users actually pick, agents tuned on production logs, and coding agents working with a codebase’s conventions over time. Russell and Norvig’s four components — learning element, performance element, critic, problem generator — are a conceptual framework for how such an agent is organised, not a claim that every learning system implements them in the same way. The examples above are possible uses of learning: systems whose behaviour changes with experience, in whatever form that learning takes in each implementation.
The failure mode is the mirror of the strength. A feedback loop that picks up a bad signal amplifies it: if users keep rewarding short answers, the agent learns to be brief even when the question needed depth. Learning agents are the most advanced type in the taxonomy, and the one whose quality depends most on the quality of its feedback.
Modern functional types of AI agents: conversational, coding, research and multi-agent systems
Conversational agents, coding agents, and research agents are roles built on top of the classical types, not replacements for them. The role names the job; the classical type names how the agent decides while doing it. Anthropic’s own Research feature is the clearest example of the team shape: a research agent whose job is to answer a question from sources, built as a lead agent delegating to subagents rather than a single loop.
Take one hypothetical task and run it through three designs: preparing a weekly support summary. A simple reflex design applies fixed rules — pull every ticket tagged with a set of keywords, count them, and paste the counts into a template. It is fast, and anything outside the keywords is simply absent from the summary. A goal-based design starts from the goal — a summary a manager can act on — and plans: gather the tickets, group them by theme, check which themes recurred, and draft the summary around the recurring ones. It handles the open-ended part the rules cannot, at the price of several rounds of model and tool calls. A multi-agent design has a lead agent split the tickets by theme across subagents working in parallel, then synthesise their findings. Splitting the work this way can cover more ground in a single pass, at the cost of extra model calls for the additional agents. The same task, three system designs — two decision mechanisms and one team architecture: the multi-agent design is an architecture, and its members still decide by mechanisms from the classical taxonomy. And the role labels sit on top of all three: a conversational agent is the role that asks the manager which themes matter, a coding agent is the role that writes the script pulling the tickets, and either role can be built on either decision mechanism or as part of a multi-agent team.
A multi-agent system is a different kind of thing again: not a sixth type, but an architecture. Anthropic defines it plainly as multiple agents — language models autonomously using tools in a loop — working together. Its research system uses an orchestrator-worker pattern: a lead agent coordinates the process while delegating to specialised subagents that operate in parallel, each with its own context window, exploring different aspects of the question before condensing the most important findings for the lead agent.
The measured payoff is large and so is the cost. On Anthropic’s internal research evaluation, a multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed a single-agent Claude Opus 4 by 90.2% — while using about 15 times the tokens of a standard chat interaction. That is the shape of the trade: parallelism and fresh context windows buy quality, and they charge for it in tokens.
One example of the tooling is the OpenAI Agents SDK, released in March 2025: a small Python framework built on a few primitives — agents, tools, handoffs, guardrails, and tracing — with a Runner that calls the model, executes the tools the model requests, and loops until a final output.
Choosing the right type, and the mistakes to avoid
The selection advice follows from the taxonomy, framed as questions rather than guarantees. Ask how much the right action varies from case to case, what a wrong step costs, and whether present observations and fixed rules suffice for the job. Where they do, a simple reflex agent — or no agent at all, just a workflow — is a reasonable starting point, and the supported advice is to start there and add complexity only when the simpler system falls short. If the job needs the agent to track how the world changes between observations, a model-based design is the fit; memory alone does not make an agent model-based. If the job needs a plan, it needs goals. If the job needs trade-offs between good outcomes, it needs a utility function. If the job needs to get better over time, it needs to learn.
Two mistakes are worth watching for. The first is overbuilding: using a learning or goal-based agent where a reflex agent would do. Each step up the taxonomy can add cost — the multi-agent research system, for instance, used about 15 times the tokens of a standard chat interaction — so the extra capability has to earn its place. The second mistake is the reverse: calling a workflow with a model in it an agent, and then being surprised when nothing adapts. A system whose steps follow code paths written in advance is a workflow on Anthropic’s definition, even when a model runs some of those steps; whether it can adapt depends on what those paths include, not on the label.
The five classical types are a ladder of decision-making, from reacting to the present moment to learning from the past. The modern functional types are the jobs built on top of that ladder. Know which rung your task sits on before you build.
