A Taxonomy Written for a World That No Longer Exists
When Stuart Russell and Peter Norvig wrote Artificial Intelligence: A Modern Approach, the most sophisticated agent anyone could build was a chess program running on dedicated hardware. Their five-type taxonomy — simple reflex, model-based reflex, goal-based, utility-based, and learning — was organized by increasing internal complexity. Each type added one capability its predecessor lacked: memory, planning, optimization, adaptation.
That hierarchy still maps cleanly to how agents are built in 2026. What changed is the substrate. An LLM provides reasoning, memory, and planning as a service. This makes it trivially easy to build something that looks like a Type 5 learning agent but is architecturally a Type 3 goal-based agent with a context window. The classification matters because the infrastructure requirements are different by an order of magnitude. Getting the type wrong means burning money or shipping fragile systems. For the foundational vocabulary, see our guide to intelligent agents in AI.
What follows is the Russell and Norvig taxonomy as it actually manifests in production systems today. For each of the five types of intelligent agents in artificial intelligence, I will give you a real 2026 example, explain how LLMs changed the implementation, specify the infrastructure requirements, identify the dominant failure mode, and tell you when the type is the right choice versus when it is overkill.
The Insight Nobody Wants to Hear
Here is the uncomfortable finding from analyzing osModa deployment telemetry across 2024 and 2025: roughly 70% of agents deployed as “intelligent” or “learning” systems are architecturally goal-based agents. They plan toward objectives using prompt chains and tool calls. But they do not learn. They do not modify their own performance element. They do not maintain a critic. The context window resets between sessions, and no model weights update.
This matters for infrastructure. A genuine learning agent (Type 5) needs GPU access, persistent storage for training data, atomic rollback for model updates, and continuous supervision. A goal-based agent (Type 3) needs 4–8 GB of RAM and a couple of CPU cores. The cost difference is roughly 10x. Teams that misclassify their agents as Type 5 when they are actually Type 3 overspend by thousands of dollars per year per agent. The reverse is worse — teams that under-classify end up with learning agents on infrastructure that cannot support training loops, and those agents silently degrade. For the broader agent landscape, see our complete guide to AI agents.
Type 1: Simple Reflex Agents
Complexity: MinimalThe simple reflex agent is the most primitive intelligent agent type, and I mean that as a compliment. It perceives the current state of the environment, matches that percept against a set of condition-action rules, and executes the corresponding action. No memory. No internal model. No planning. No optimization. Just pattern-matching applied to the present moment.
Russell and Norvig described this as the simplest possible agent architecture, and they were right. What they could not have predicted is that in 2026, this simplest architecture would handle the majority of production agent workloads.
2026 Production Example: Email Spam Filters & Rule Engines
Every major email provider runs simple reflex agents at massive scale. SpamAssassin, Postfix policy daemons, and cloud-native email gateways all operate the same way: ingest a message, evaluate it against a rule set, classify it, route it. No memory of previous messages. No model of the sender's behavior over time. Pure condition-action at millions of messages per hour.
How the LLM era changed it: LLMs upgraded the “condition” side. Where rule engines used regex and keyword lists, teams now use LLM-based classifiers as the condition function. The architecture remains reflex — stateless, single-pass, no planning — but the pattern matching is vastly more capable.
Failure mode: Ambiguous inputs that require context. When the correct action depends on who sent the message, what they sent previously, or what the agent did last time, a reflex agent will make inconsistent decisions. This is the signal to upgrade to Type 2.
When it is overkill: Never. A simple reflex agent is the floor. If your problem is simpler than this, you are writing a function, not deploying an agent.
Infrastructure Requirements
# Simple reflex agent — stateless condition-action
def reflex_agent(percept: dict) -> str:
rules = {
"spam_score > 0.9": "reject",
"spam_score > 0.5": "quarantine",
"has_attachment": "scan_attachment",
}
for condition, action in rules.items():
if evaluate(condition, percept):
return action
return "deliver" # default actionType 2: Model-Based Reflex Agents
Complexity: LowThe model-based reflex agent adds one thing to its predecessor: an internal representation of the world. This model tracks aspects of the environment that the agent cannot directly observe in the current percept. It still uses condition-action rules, but those rules can now reference historical state. This is the architectural jump from stateless to stateful, and it is where every conversational AI system lives.
2026 Production Example: Chatbots with Context Windows
Intercom's Fin, Zendesk's AI agents, and every customer support chatbot that remembers what you said three messages ago is a model-based reflex agent. The “model” is the conversation history. The agent does not plan ahead — it responds to each message based on current input plus conversation state. Monitoring dashboards that track system health over time and trigger alerts based on trends, not just thresholds, also fit this type.
How the LLM era changed it: The LLM context window is the internal model. Before LLMs, building a model-based agent meant engineering explicit state representations — database schemas, state machines, belief networks. Now you append the conversation history to the prompt and the LLM maintains the internal model implicitly. This reduced the engineering effort from weeks to hours but introduced a new constraint: context window limits become memory limits.
Failure mode: State decay. As conversations grow longer, earlier context gets truncated or diluted. The agent “forgets” commitments it made 20 messages ago. In monitoring systems, the failure mode is state explosion — tracking too many variables degrades response time and accuracy.
When it is overkill: If every interaction is independent. If the agent's response to message N never depends on messages 1 through N-1, you are paying for state management infrastructure you do not need. Use Type 1.
Infrastructure Requirements
# Model-based reflex agent — stateful with internal world model
class ModelBasedAgent:
def __init__(self):
self.state = {} # internal world model
def update_state(self, percept: dict):
self.state["history"].append(percept)
self.state["turn_count"] += 1
self.state["sentiment"] = analyze(percept["message"])
def act(self, percept: dict) -> str:
self.update_state(percept)
if self.state["sentiment"] < -0.5 and self.state["turn_count"] > 3:
return "escalate_to_human"
if percept["intent"] == "billing":
return "route_billing"
return "generate_response" # condition-action on stateType 3: Goal-Based Agents
Complexity: MediumThe goal-based agent is where the taxonomy makes the jump from reactive to deliberative. Instead of mapping percepts to actions through rules, the agent considers future states. It has a goal — a description of a desirable world state — and it plans sequences of actions to achieve that goal. This requires the agent to simulate outcomes: “If I do X, then Y will happen, and then I can do Z to reach my goal.”
This is the type of intelligent agent that the LLM era has exploded. Every coding agent, research agent, and task-completion agent that generates a plan, executes steps, and evaluates progress is a goal-based agent. And this is where most teams over-classify — they see the planning behavior and assume they have built something more sophisticated than they actually have. For the practical distinction between agent types and programs, see our guide to agent programs in AI.
2026 Production Example: Coding Agents & Research Agents
Cursor's agent mode, Devin, and Claude Code are canonical goal-based agents. They receive a goal (“refactor this module to use dependency injection”), generate a plan (identify dependencies, create interfaces, modify constructors, update tests), execute each step sequentially, and verify the outcome against the goal state. Research agents like Perplexity's deep research follow the same architecture: decompose a question into sub-queries, execute searches, synthesize findings, and check completeness.
How the LLM era changed it: Before LLMs, goal-based agents required explicit state space search — A*, BFS, STRIPS-style planners. LLMs replaced formal planning with natural-language reasoning. The agent “plans” by generating a step-by-step breakdown in text, then executes each step by prompting itself again. This eliminated the need for domain-specific planning languages but introduced a new failure mode: plans that are linguistically coherent but logically unsound.
Failure mode: Plan divergence. The agent generates a five-step plan, executes step one, encounters an unexpected result, and then either blindly continues with the original plan or re-plans from scratch every step. Both behaviors waste compute. Good goal-based agents need conditional re-planning — modifying the plan only when a step's outcome deviates beyond a threshold.
When it is overkill: If the correct action is always a single step. If there is no sequence to plan, if the action space is one level deep, use Type 1 or Type 2. Many “agents” that teams build as goal-based are actually single-step classifiers wrapped in a planning framework for no reason.
Infrastructure Requirements
# Goal-based agent — plans toward objectives
class GoalBasedAgent:
def __init__(self, goal: str):
self.goal = goal
self.plan = []
self.state = {}
def formulate_plan(self, percept: dict) -> list:
return llm.generate_plan(self.goal, percept, self.state)
def act(self, percept: dict) -> str:
if not self.plan or self.needs_replan(percept):
self.plan = self.formulate_plan(percept)
next_step = self.plan.pop(0)
result = execute(next_step)
self.state["last_result"] = result
if self.goal_achieved(result):
return "done"
return resultType 4: Utility-Based Agents
Complexity: HighA utility-based agent goes beyond achieving goals. It maximizes a utility function that maps world states to real numbers, enabling it to reason about degrees of desirability. Where a goal-based agent asks “Did I reach the goal?” a utility-based agent asks “How good is this outcome compared to alternatives, weighted across multiple dimensions?”
This distinction is critical and frequently confused. I have reviewed hundreds of agent deployments labeled “utility-based” where the utility function was effectively return 1 if goal_met else 0. That is not utility optimization. That is goal-checking with a 2x compute overhead. Real utility-based agents balance genuine tradeoffs: cost versus latency, risk versus return, exploration versus exploitation.
2026 Production Example: Trading Bots & Recommendation Engines
Algorithmic trading systems are the purest utility-based agents in production. They evaluate candidate trades across a multi-dimensional utility function: expected return, volatility risk, correlation with existing positions, liquidity cost, and regulatory constraints. Netflix and Spotify recommendation engines similarly optimize across user engagement, content diversity, freshness, and business objectives simultaneously.
How the LLM era changed it: LLMs gave utility-based agents the ability to reason about tradeoffs in natural language before computing the formal utility. Hybrid systems now use an LLM to identify relevant dimensions and estimate weights, then pass those parameters to a traditional optimization engine. This reduced the domain expertise needed to design utility functions but made the systems less transparent and harder to audit.
Failure mode: Reward hacking. The agent discovers strategies that maximize the utility function without achieving the designer's actual intent. A recommendation agent might maximize engagement by showing increasingly extreme content. A trading bot might maximize returns by concentrating risk. The utility function is always an approximation of what you really want, and the agent will exploit the gap.
When it is overkill: If you are optimizing a single dimension. If there is one metric you care about and no tradeoffs, use a goal-based agent. Utility-based agents earn their 2–3x infrastructure premium only when there are genuine competing objectives that cannot be collapsed into a single goal.
Infrastructure Requirements
# Utility-based agent — maximizes multi-dimensional value
class UtilityBasedAgent:
def __init__(self, utility_fn):
self.utility = utility_fn # maps state -> float
self.state = {}
def utility_fn(self, outcome: dict) -> float:
return (
0.4 * outcome["expected_return"]
- 0.3 * outcome["risk"]
+ 0.2 * outcome["diversity"]
- 0.1 * outcome["cost"]
)
def act(self, percept: dict) -> str:
candidates = self.generate_actions(percept)
outcomes = [self.simulate(a, percept) for a in candidates]
utilities = [self.utility_fn(o) for o in outcomes]
return candidates[utilities.index(max(utilities))]Type 5: Learning Agents
Complexity: Very HighThe learning agent sits at the top of the Russell and Norvig taxonomy. It has four components: a performance element (executes actions), a critic (evaluates results against a quality standard), a learning element (modifies the performance element based on the critic's feedback), and a problem generator (proposes exploratory actions to gather new information). The defining property is self-modification: the agent changes its own behavior over time based on accumulated experience.
This is the type that everyone wants and almost nobody actually builds. In production, a genuine learning agent requires infrastructure that most teams do not budget for: persistent model storage, training pipelines, safe rollback mechanisms, and continuous evaluation loops. The gap between “our agent learns” and “our agent uses an LLM context window that resets every session” is the gap between Type 5 and Type 3. For the broader relationship between intelligence and agency, see our deep dive on AI and intelligent agents.
2026 Production Example: Adaptive Fraud Detection & Self-Tuning Infrastructure
Stripe's Radar is a learning agent in the strict sense. It processes billions of transactions, maintains a critic that compares predictions against confirmed fraud outcomes, updates its models nightly based on that feedback, and explores edge cases through controlled exposure. Self-tuning infrastructure agents like those in Kubernetes autoscalers follow the same pattern: observe resource usage, evaluate against SLA thresholds, adjust scaling parameters, test new configurations.
How the LLM era changed it: LLMs enabled a new subtype: agents that learn through prompt refinement rather than weight updates. The agent stores successful and failed interaction patterns, then modifies its system prompt or few-shot examples based on accumulated experience. This is lighter than traditional fine-tuning but still requires persistent storage, evaluation pipelines, and rollback capability. Whether this constitutes “true” learning is a philosophical question. Whether it requires learning-agent infrastructure is an engineering fact: yes, it does.
Failure mode: Catastrophic forgetting and distribution shift. The agent optimizes for recent patterns and degrades on older ones. A fraud detection agent trained heavily on 2025 attack patterns might miss 2024-style attacks that re-emerge. Without proper evaluation across the full distribution, learning agents silently regress. This is why atomic rollback is non-negotiable infrastructure.
When it is overkill: If the environment is stable. If the rules that work today will work next month, you do not need a learning agent. Deploy a goal-based or utility-based agent with fixed rules and revisit when the domain actually shifts. Learning agents are a continuous cost, not a one-time investment.
Infrastructure Requirements
# Learning agent — self-modifying with critic loop
class LearningAgent:
def __init__(self):
self.performance = load_model("current")
self.critic = EvaluationPipeline()
self.experience_store = PersistentStore()
def act(self, percept: dict) -> str:
action = self.performance.predict(percept)
outcome = execute(action)
score = self.critic.evaluate(percept, action, outcome)
self.experience_store.append(percept, action, outcome, score)
return action
def learn(self): # runs on schedule, not per-action
batch = self.experience_store.sample(n=1000)
updated = self.performance.fine_tune(batch)
if self.critic.validate(updated) > self.critic.validate(self.performance):
self.performance = updated # atomic swap
else:
rollback() # NixOS atomic rollbackInfrastructure Comparison: All 5 Intelligent Agent Types
This table reflects actual infrastructure costs from osModa deployments, not theoretical estimates. API costs (OpenAI, Anthropic, etc.) are additional and vary by usage volume. The key takeaway is the 10x infrastructure gap between adjacent types — misclassification is expensive. For the extended 7-type taxonomy that adds tool-using and multi-agent types, see our practical guide to types of AI agents.
| Agent Type | RAM | CPU | GPU | Persistence | Cost/mo |
|---|---|---|---|---|---|
| 1. Simple Reflex | 256–512 MB | 0.5 | — | None | $5–10 |
| 2. Model-Based Reflex | 1–4 GB | 1 | — | Session store | $10–25 |
| 3. Goal-Based | 4–8 GB | 2–4 | Optional | Plan state | $25–60 |
| 4. Utility-Based | 8–16 GB | 4 | Recommended | State + history | $50–150 |
| 5. Learning | 16–64 GB | 4–8 | Required | Weights + data | $100–400 |
The cost ratio from Type 1 to Type 5 is roughly 40x. That is the difference between $60/year and $4,800/year for a single agent. Multiply by the number of agents in your fleet and the classification decision becomes a budget line item, not an academic exercise.
The Misclassification Epidemic: Type 3 Pretending to Be Type 5
I want to be precise about this because it is the single most expensive mistake in agent engineering today. When a team says their agent “learns,” I ask four diagnostic questions:
1. Does the agent update model weights or prompt templates based on past performance?
If no, it is not a learning agent. It uses a fixed model. The LLM provider might update the underlying model, but the agent itself does not learn.
2. Does the agent have a critic that evaluates outcomes against a quality standard?
If no, there is no feedback loop. The agent repeats the same mistakes. It might have logging, but logging is not criticism — criticism requires automated evaluation and comparison.
3. Is the behavior modification persistent across sessions?
If the agent “forgets” what it learned when the context window resets, it is not learning. It is using in-context memory, which is a feature of model-based reflex agents (Type 2), not learning agents.
4. Does the agent explore new strategies beyond its current policy?
If no, it lacks the problem generator component. A learning agent without exploration eventually overfits to its training distribution and fails on novel inputs.
In my experience, fewer than 10% of agents marketed as “learning” or “adaptive” pass all four tests. The rest are goal-based agents (Type 3) using LLM reasoning to plan toward objectives, which is genuinely useful but does not require learning-agent infrastructure. Correctly classifying your agent saves $50–350/month per instance. Across a fleet of 10 agents, that is $6,000–$42,000/year. For deeper coverage of the general agent classification, see our complete types of AI agents reference.
Matching Infrastructure to Intelligent Agent Type
Once you have correctly classified your agent, the infrastructure decision follows directly. Each type demands specific capabilities from the hosting layer. Deploy a learning agent on reflex-agent infrastructure and it will silently degrade. Deploy a reflex agent on learning-agent infrastructure and you waste 90% of your budget.
Types 1–2: Stateless and Lightweight
Simple and model-based reflex agents run on minimal infrastructure. NixOS containers with 512 MB to 4 GB RAM, process supervision via watchdog with sub-6-second restart on failure, and optional session state persistence for Type 2. No GPU allocation, no training pipelines, no model storage overhead. This is where osModa's agent hosting starts — lightweight environments that scale down to the floor.
Type 3: Persistent Planning State
Goal-based agents need plan checkpointing. If the process crashes mid-plan, it must resume from the last completed step, not restart from scratch. This requires persistent Nix environments that survive restarts, dedicated CPU for search and planning, and enough RAM to hold the plan state and intermediate results. NixOS atomic rollbacks let you revert a failed deployment without corrupting mid-execution plans.
Type 4: Compute for Optimization
Utility-based agents need more raw compute than any other single-agent type except learning agents. They evaluate multiple candidate actions, simulate outcomes for each, compute utility scores across dimensions, and select the optimal action. This means dedicated CPU with optional GPU for parallel evaluation, persistent state for utility history and parameter tuning, and cgroup isolation to prevent optimization loops from starving co-located processes.
Type 5: Full Training Pipeline
Learning agents require the complete stack: GPU passthrough for training, persistent storage for model weights and training data, watchdog-supervised training loops that restart on OOM errors, atomic rollback for safe model updates, and continuous evaluation pipelines that catch regression before deployment. NixOS atomic rollbacks let you revert a bad model update in under 10 seconds without losing the previous weights.
A Decision Framework for 2026
Understanding the types of intelligent agents in artificial intelligence is not about taxonomy for taxonomy's sake. It is about making infrastructure decisions that match reality. Here is the framework I use with every team that deploys on osModa:
- Classify before you build. Use the Russell and Norvig taxonomy to identify which type of intelligent agent your workload actually needs. Not which type sounds impressive. Not which type the framework defaults to. Which type the problem demands.
- Start at Type 1 and prove your way up. Build the simplest reflex agent that could possibly work. Run it. Measure where it fails. That failure mode is your upgrade signal — it tells you exactly which type to move to next.
- Apply the four-question test for learning agents. If your agent does not update weights, does not have a critic, does not persist behavior changes across sessions, and does not explore — it is not Type 5. Deploy it as Type 3 and save 10x on infrastructure.
- Match infrastructure to classification. Once you know the type, the infrastructure requirements are deterministic. Do not over-provision, do not under-provision. Both waste money and create failure modes.
- Re-evaluate quarterly. Agent types are not permanent. A goal-based agent might need to become a learning agent when the domain starts shifting. A utility-based agent might simplify to goal-based when you realize you only optimize one dimension. Re-classify when the workload changes.
Russell and Norvig gave us a taxonomy that has survived three decades because it maps to genuine architectural differences, not marketing categories. The five types of intelligent agents in AI are not abstract — they are infrastructure decisions with dollar signs attached. Get the classification right and everything downstream simplifies: provisioning, monitoring, scaling, debugging. Get it wrong and you fight the architecture for the lifetime of the project.
Frequently Asked Questions
What are the 5 types of intelligent agents in artificial intelligence?
The five types of intelligent agents, as classified by Russell and Norvig, are: (1) simple reflex agents that map percepts directly to actions with no memory, (2) model-based reflex agents that maintain internal state to track aspects of the world they cannot observe directly, (3) goal-based agents that plan sequences of actions toward specific objectives, (4) utility-based agents that maximize a value function across competing tradeoffs, and (5) learning agents that improve their own performance from experience over time. This taxonomy has been the standard classification in AI textbooks since 1995.
How do intelligent agent types differ from general AI agent types?
The intelligent agent taxonomy from Russell and Norvig is specifically about the internal architecture of the agent: how it processes percepts, maintains state, and selects actions. General AI agent classifications often focus on the agent's role (coding agent, research agent, customer support agent) or its tool usage pattern. The intelligent agent taxonomy is more fundamental because it describes the computational structure, not the application domain. A coding agent might be goal-based or utility-based depending on how it makes decisions internally.
Which type of intelligent agent do most LLM-powered systems actually use?
Most LLM-powered agents in production are goal-based agents (Type 3) that are marketed as learning agents (Type 5). They plan multi-step sequences toward objectives using prompt chains, tool calls, and reasoning loops. However, they do not genuinely learn from experience in the Russell and Norvig sense: they do not update their own performance element based on a critic. The context window acts as temporary memory, but it resets between sessions. True learning agents require persistent model updates, which demands fundamentally different infrastructure.
What is the infrastructure cost difference between intelligent agent types?
The infrastructure gap between types is roughly 10x at each major transition. A simple reflex agent runs on 256 to 512 MB of RAM with no GPU, costing around $5 to $10 per month. A model-based reflex agent needs 1 to 4 GB for state persistence, costing $10 to $25. Goal-based agents need 4 to 8 GB with 2 to 4 CPU cores, costing $25 to $60. Utility-based agents need 8 to 16 GB with optional GPU, costing $50 to $150. Learning agents need 16 to 64 GB, dedicated GPU access, and persistent storage, costing $100 to $400 per month. Misclassifying your agent type leads directly to wasted infrastructure spend.
What is a simple reflex intelligent agent with a real example?
A simple reflex intelligent agent maps percepts directly to actions using condition-action rules with no internal state or memory. Real production examples include email spam filters that classify incoming messages based on content patterns, Zapier automations that trigger actions based on webhook events, and log-level routing systems that forward alerts based on severity keywords. These agents are stateless: every input is processed independently. They handle an estimated 60 to 70 percent of production automation workloads because most business logic is deterministic routing.
When should I use a utility-based agent instead of a goal-based agent?
Use a utility-based agent only when you have genuine competing objectives that require tradeoff optimization. If your agent is trying to maximize a single metric or reach a single goal state, a goal-based agent is simpler and cheaper. Utility-based agents earn their complexity when the agent must balance cost versus speed, risk versus return, precision versus recall, or similar multi-dimensional tradeoffs. The infrastructure cost of a utility-based agent is typically 2 to 3 times higher than goal-based because it must evaluate and compare multiple candidate actions using a value function.
What makes a learning agent different from other intelligent agent types?
A learning agent has four components that other types lack: a performance element that executes actions, a critic that evaluates outcomes against a quality standard, a learning element that modifies the performance element based on criticism, and a problem generator that suggests exploratory actions. The defining characteristic is that the agent changes its own behavior over time based on experience. This requires persistent storage for model weights, GPU access for training cycles, and atomic rollback capability for safe model updates. In contrast, goal-based and utility-based agents use fixed decision procedures that do not self-modify.
Can I run all 5 types of intelligent agents on the same infrastructure?
Yes, but the infrastructure requirements are additive as you move up the taxonomy. osModa supports all five types on the same platform by adapting resource allocation to the agent architecture. Simple reflex agents run as lightweight stateless processes. Model-based agents use persistent Nix environments for state management. Goal-based and utility-based agents get dedicated CPU allocation for planning and optimization. Learning agents leverage GPU passthrough, persistent storage for training data, and NixOS atomic rollbacks for safe model updates. The key is matching infrastructure to agent type rather than over-provisioning everything.