The five foundational types of AI agents are simple reflex, model-based reflex, goal-based, utility-based, and learning agents. Hierarchical agents and multi-agent systems add two ways to organize work. Modern LLM-based agents introduce another distinction: the technology used to interpret tasks and guide actions.
These labels answer different questions. Some describe how an agent chooses its next action; others describe how multiple agents divide responsibility. Understanding that distinction makes the categories more useful when designing or evaluating a system.
What is an AI agent?
IBM describes AI agents as systems that autonomously perform tasks by designing workflows with available tools. That definition is particularly useful for understanding modern agents that do more than generate a response.
The foundational categories also cover simpler behavior, such as applying a fixed rule to a current observation. Classification helps identify what a task actually requires: a reaction, remembered context, a plan, a comparison of outcomes, or improvement through feedback.
The foundational framework: classic AI agent types
Olostep’s overview of agent architectures identifies five classical types and extends the discussion to hierarchical and multi-agent arrangements. The following table brings their operational differences together.
| Agent type | Decision process | Memory or state | Typical task fit |
|---|---|---|---|
| Simple reflex | Applies fixed condition-action rules | No memory | Basic automation |
| Model-based reflex | Applies rules using an internal model | Retains context about the environment | Context-aware tasks |
| Goal-based | Plans steps toward a target | Session or world state | Task execution |
| Utility-based | Scores trade-offs between outcomes | Session or world state | Optimization |
| Learning | Uses feedback to improve performance | Retains information over time | Adaptive tasks |
| Hierarchical | Delegates work across levels | Shared context | Complex workflows |
| Multi-agent | Coordinates collaboration or competition | Distributed state | Work involving specialized roles |
Use the first five rows to examine decision behavior. Use the last two to examine how work is organized. A need for planning and a need for delegation are separate design questions.
The examples below illustrate these mechanisms. They are not claims about particular commercial products or documented deployments.
Type 1: Simple reflex agents
A simple reflex agent uses a fixed condition-action rule: when a condition is met, take a specified action. It operates without memory, so its decision depends on the current observation.
The research package’s thermostat example makes this concrete. A thermostat that adjusts temperature from the current reading illustrates a direct response to an observed condition. Previous readings do not enter the decision in this simplified example.
For basic automation, the implementation question is whether the current input contains enough information to select an action. If the task depends on what happened earlier, a memoryless rule will not capture that requirement.
Type 2: Model-based reflex agents
Model-based reflex agents retain an internal state, a representation of relevant information about their environment. This allows them to act when the current observation provides only part of the picture, a situation described as a partially observable environment.
Their distinguishing feature is the combination of rules and retained context. The agent still reacts, but it has more information available than a simple reflex agent.
To see the difference, extend the thermostat illustration conceptually: if the decision also used retained information from earlier observations, it would illustrate the role of internal state. The useful design question is which information must persist between observations to make the next decision sensible.
Type 3: Goal-based agents
A goal-based agent plans steps toward a specified target and maintains session or world state. Its organizing question is: what actions will get the system to the desired result?
A navigation system planning a route to a user-defined destination is the supplied illustration. The destination establishes the goal; the route provides the sequence of steps toward it.
Implementation begins with a clear description of the target and the state needed to track progress. “Reach the destination” gives the agent a success condition. Choosing among several routes on the basis of competing preferences introduces the next category.
Type 4: Utility-based agents
Utility-based agents score trade-offs to optimize outcomes. A utility score represents how desirable an outcome is under the system’s criteria. Like goal-based agents, they maintain session or world state, but they compare the quality of alternatives rather than relying only on whether a target is reached.
The package offers dynamic pricing as an illustration. An algorithm adjusting prices in response to market conditions fits this category when it scores competing outcomes against its optimization criteria. Price adjustment by itself does not explain the decision mechanism; the scoring of alternatives does.
For a developer or product manager, the central requirement is to specify the trade-offs the system should evaluate. A goal states the desired result. A utility function expresses preferences among possible results.
Type 5: Learning agents
Learning agents improve their performance over time through feedback loops and retain information beyond an immediate interaction. Feedback must affect later behavior for the learning mechanism to matter.
The supplied coding-assistant example is conditional: an assistant that improves its suggestions from user feedback would illustrate a learning agent. Receiving a correction or saving a conversation alone does not establish that future performance improves.
When considering this architecture, identify both the feedback available and the behavior it is meant to improve. Retaining context supports informed decisions; using feedback to improve performance adds a different capability.
Type 6: Hierarchical agents
Hierarchical agents delegate tasks to manage complex workflows. The defining feature is an arrangement of responsibilities across levels, supported by shared context.
Applied to the package’s collaborative research example, a hierarchical arrangement would have a coordinating agent delegate parts of the analysis to other agents. This is an illustration of delegation, not an additional deployment claim.
The design work centers on deciding who assigns tasks, what information accompanies an assignment, and how delegated work contributes to the larger workflow. Hierarchy describes that relationship between responsibilities.
Type 7: Multi-agent systems
A multi-agent system involves multiple agents with specialized roles that collaborate or compete. The supplied example is a group of research agents working together to analyze datasets.
In a single-agent arrangement, one agent carries responsibility for the task. In a multi-agent arrangement, work is distributed across agents, making their interactions part of the system’s operation. A hierarchy can provide one way to organize those interactions; collaboration does not itself require that particular structure.
Choose this arrangement when distinct roles are useful to the task. Define what each agent contributes and what context must move between them. The number of agents alone says little about how they make decisions.
Modern LLM-based and autonomous agents
According to IBM’s discussion of agent evolution, modern agents, particularly those based on large language models, can autonomously respond to and act upon their environment in real time.
The operational difference from a fixed rule-based agent is the role of the language model in responding to the task and environment. The simple reflex mechanism is a predefined condition-action rule. A modern LLM-based agent can participate in a workflow that uses available tools and acts on environmental information.
LLM-based, autonomous, and utility-based describe different properties. The first identifies a technology; the second concerns the system’s ability to act independently; the third specifies how it evaluates outcomes. A chatbot’s use of an LLM does not, by itself, establish autonomous goal pursuit or utility-based decision-making. Look for actual actions, goals, environmental feedback, and outcome scoring before applying those labels.
Choosing the right AI agent type
Start with the task’s requirements and turn them into architecture questions:
- Is the current observation sufficient? Fixed rules may cover the task. If earlier observations matter, examine the need for internal state.
- Does the task require a sequence of actions? Define the target and consider goal-based planning.
- Must the system compare acceptable outcomes? Specify the preferences and trade-offs a utility-based decision should score.
- Should performance improve from feedback? Identify how feedback will influence later behavior.
- Does the workflow need separate responsibilities? Consider specialized agents, and use hierarchy when delegation across levels fits the work.
Then assess whether an LLM belongs in that architecture and how much independent action the task requires. A useful system description should explain its decision process, retained state, and division of work. Those details make an agent’s behavior easier to assess than a broad claim of autonomy.
Explore more AI Agents coverage.
