Types of AI Agents

The types of AI agents are categories that describe how an agent chooses its actions, from fixed condition-action rules to planning, scoring and learning. The classic classification contains five categories: simple reflex, model-based reflex, goal-based, utility-based and learning agents, and modern LLM-based agents combine several of these properties.

• Basis: Agent types differ in what they remember, whether they reason about a goal and whether they learn from results.
• Increasing capability: Each category adds a capability to the one before it, at the cost of more computation.
• Origin: The list comes from classic AI textbooks and is older than large language models.
• Practical relevance: Production systems frequently combine several types, such as a reflex rule for safety and a goal-based planner for diagnosis.
• Shared foundation: Every type follows the perceive, decide and act cycle of an AI agent.

For example, a DevOps agent responding to a failing CI job can simply retry it, diagnose the specific error, compare several remedies or learn which remedy usually succeeds.

Overview of the Types of AI Agents

Simple Reflex Agents

• Mechanism: The agent maps the current percept, meaning its current input, directly to an action through fixed rules.
• Strength: It is fast, predictable and easy to audit.
• Weakness: It ignores history, so it repeats an ineffective action indefinitely.
• Example: A rule that retries every failed CI job once.

Model-Based Reflex Agents

• Mechanism: The agent keeps an internal model, a record of state that it cannot see in the current input.
• Strength: It can recognise patterns across events, such as a test that fails on every third execution.
• Example: A monitor that marks a test as flaky after three intermittent failures within one day.

Goal-Based Agents

• Mechanism: The agent predicts the effect of candidate actions and selects one that achieves its goal.
• Strength: It can handle cases that no single rule foresaw, as long as its model of actions is correct.
• Weakness: It treats every successful plan as equivalent and does not compare their costs.
• Example: An agent with the goal "the pipeline passes" that installs a missing dependency instead of retrying.

Utility-Based Agents

• Mechanism: A utility function, a formula that assigns a numeric score to each outcome, ranks every acceptable option.
• Strength: It balances competing criteria, such as speed, cost and risk.
• Example: An agent that prefers reverting one commit over rebuilding the entire cache because the revert is faster and less risky.

Learning Agents

• Mechanism: A learning element updates the decision policy using feedback from a critic, which evaluates previous outcomes.
• Strength: Performance improves as more incidents are recorded.
• Weakness: It needs reliable feedback data and close checks for wrong learned behaviour.
• Example: A system that learns which remediation resolves each category of CI failure most frequently.

LLM-Based Agents

• Mechanism: A large language model interprets unstructured information, such as logs and error messages, and selects tools through tool calling.
• Combination: It typically behaves as a goal-based agent with memory, and developers add utility rules for safety.
• Limitation: Its decisions are probabilistic, so validation, iteration limits and human approval remain necessary.
• Example: A coding agent that reads a stack trace, edits the code and opens a pull request.

Example: Reflex Agent vs Goal-Based Agent on a Failing CI Job

The following program compares a simple reflex agent and a goal-based agent on three identical CI failures.

# A simple reflex agent and a goal-based agent on the same failing CI jobs.
# Each CI error is fixed by exactly one action (the environment's hidden truth).
FIXES = {"TimeoutError": "retry", "ModuleNotFoundError": "add_dependency",
         "CacheCorrupted": "clear_cache", "OutOfMemory": "raise_memory_limit"}

def run_ci(error, action):
    return "passed" if FIXES[error] == action else "failed"

def reflex_agent(error, max_tries=3):
    # Condition-action rule on the current percept only: failed -> retry.
    for attempt in range(1, max_tries + 1):
        status = run_ci(error, "retry")
        print(f"  reflex try {attempt}: retry -> {status}")
        if status == "passed":
            return
    print("  reflex agent gives up")

# The goal-based agent's model: what it expects each action to achieve.
PREDICTS = {"retry": {"TimeoutError"}, "add_dependency": {"ModuleNotFoundError"},
            "clear_cache": {"CacheCorrupted"}, "open_ticket": set()}

def goal_based_agent(error):
    # Goal: the job passes. Choose the action predicted to reach it.
    for action, fixes in PREDICTS.items():
        if error in fixes:
            print(f"  goal-based plan: {action} -> {run_ci(error, action)}")
            return
    print("  goal-based plan: no action reaches the goal, open_ticket")

for error in ("TimeoutError", "ModuleNotFoundError", "OutOfMemory"):
    print(f"CI job failed with {error}")
    reflex_agent(error)
    goal_based_agent(error)

CI job failed with TimeoutError
  reflex try 1: retry -> passed
  goal-based plan: retry -> passed
CI job failed with ModuleNotFoundError
  reflex try 1: retry -> failed
  reflex try 2: retry -> failed
  reflex try 3: retry -> failed
  reflex agent gives up
  goal-based plan: add_dependency -> passed
CI job failed with OutOfMemory
  reflex try 1: retry -> failed
  reflex try 2: retry -> failed
  reflex try 3: retry -> failed
  reflex agent gives up
  goal-based plan: no action reaches the goal, open_ticket

• Transient failures: Both agents succeed on the timeout, because a retry is the appropriate remedy.
• Cause-specific failures: The reflex agent repeats an ineffective retry, while the goal-based agent selects the dependency correction.
• Model limits: The goal-based agent escalates the memory failure to a ticket, because its internal model contains no action for it.

How to Choose the Right Agent Type

• Predictable, low-risk events: A simple reflex agent is enough and is the easiest to audit.
• Intermittent or history-dependent problems: A model-based agent tracks the state that a single observation cannot reveal.
• Multi-step diagnosis: A goal-based agent, often combined with planning in AI agents, fits problems without a fixed rule.
• Trade-offs between valid remedies: A utility-based agent is appropriate when cost, speed and risk must be balanced.
• Large volumes of labelled outcomes: A learning agent can improve when reliable feedback is available.
• Unstructured input: An LLM-based agent, usually following the ReAct agent pattern, handles logs, code and natural-language tickets.

The components that these types share are described in AI agent architecture, and coordination between several agents is covered in multi-agent systems.