Types of AI Agent, Explained With Working Examples

There are five types of AI agent in the taxonomy every ranking page copies, and each type adds exactly one capability to the one before it. A simple reflex agent applies a rule to what it sees right now. A model-based reflex agent adds remembered state, so it can act when the current percept is missing or partial. A goal-based agent adds a goal and searches for a sequence of actions that reaches it. A utility-based agent adds a score, so it can trade off between outcomes that all reach the goal. A learning agent adds feedback that rewrites its own rule. The lists that say seven or eight types append multi-agent systems and hierarchies, which are arrangements of agents rather than ways an agent decides.

Below, all five are written as short Python against one shared environment, run together, and they produce five different decisions from the same input. That's the part the explainer pages skip. Then the question I actually wanted answered when I first read this list, which is what type the LLM tool-calling loop is, and whether it counts as a learning agent. It's a goal-based agent with model-based state, and at runtime it isn't learning anything.

Where The Five Types Come From

The taxonomy is Russell and Norvig's, from chapter 2 of Artificial Intelligence: A Modern Approach, the textbook the site says over 1,500 schools use. Section 2.4, "The Structure of Agents", walks through simple reflex, model-based reflex, goal-based, utility-based, and learning agents in that order, and the book's pseudocode is short enough to quote. A simple reflex agent interprets the percept into a state, matches a rule, and returns the rule's action. The model-based version keeps a persistent state and updates it from the last action and the new percept before matching a rule.

None of the pages on the first page of results cite the book, which is odd, because their examples are the book's examples. The thermostat, the vacuum that sucks if the square is dirty and moves otherwise, the taxi weighing speed against safety. I'd rather use one environment a developer recognizes and let the code make the distinctions.

One Environment, Five Agents

The environment is a disk that's nearly full and a temp folder with three files. A percept is the free space in percent plus each file's size in megabytes and age in days. An action is delete <name> or wait. Nothing here touches a real disk, so run it freely.

from itertools import combinations

TOTAL_MB = 1000
FILES = {"old.tar": (20, 40), "build.log": (150, 9), "cache.bin": (300, 2)}
FREE = 6


def gain(size_mb):
    return round(100 * size_mb / TOTAL_MB)

Six percent free. Deleting old.tar gains 2 points, build.log 15, cache.bin 30. The files are chosen so that the oldest is nearly useless, the biggest is two days old, and the middle one is the sensible pick. Each agent below sees the same (FREE, FILES) percept.

Simple Reflex

def simple_reflex(percept):
    free, files = percept
    if free < 10 and files:
        oldest = max(files, key=lambda n: files[n][1])
        return f"delete {oldest}"
    return "wait"

One rule, applied to the current percept, with no memory of anything. It deletes old.tar because that's the rule, and gains two percent, and next tick it will still be under ten and delete the next oldest. This is most cron cleanup scripts, and there's nothing wrong with it as long as the rule is cheap to be wrong about.

Model-Based Reflex

class ModelBased:
    def __init__(self):
        self.free = None

    def __call__(self, percept):
        free, files = percept
        if free is not None:
            self.free = free
        return simple_reflex((self.free, files))

The same rule, but the agent keeps a model of the world, here just the last known free space. When the sensor returns None, which real disks do when a metrics call times out, the reflex agent above would crash on the comparison. This one acts on what it remembers. That is the whole difference between the first two types. State that outlives a percept.

Goal-Based

def goal_based(percept, goal=30):
    free, files = percept
    for size in range(1, len(files) + 1):
        for combo in combinations(files, size):
            if free + sum(gain(files[n][0]) for n in combo) >= goal:
                return [f"delete {n}" for n in combo]
    return []

Now there's a goal, thirty percent free, and the agent searches for the shortest plan that reaches it rather than firing a rule. It returns a plan, ['delete cache.bin'], one action instead of three, because 6 plus 30 clears the bar. It's also the worst answer in the set, because cache.bin is two days old and somebody is using it. A goal-based agent knows how to reach a state. It has no way to say that two states which both reach the goal are not equally good.

Utility-Based

def utility(size_mb, age_days):
    return size_mb if age_days >= 7 else -2 * size_mb


def utility_based(percept):
    free, files = percept
    if free >= 10 or not files:
        return "wait"
    best = max(files, key=lambda n: utility(*files[n]))
    return f"delete {best}" if utility(*files[best]) > 0 else "wait"

Utility is a number attached to each outcome. Here the score is the megabytes freed, and a file younger than a week counts double against. cache.bin scores minus 600, old.tar scores 20, build.log scores 150 and wins. The trade-off the goal couldn't express, space against regret, is one line of arithmetic. My experience with these scoring functions is that they're where the arguments happen, because the number is a policy decision wearing a math costume. That's fine. At least it's written down.

Learning

class Learning:
    def __init__(self):
        self.recent_days = 7

    def utility(self, size_mb, age_days):
        return size_mb if age_days >= self.recent_days else -2 * size_mb

    def act(self, percept):
        free, files = percept
        if free >= 10 or not files:
            return "wait"
        best = max(files, key=lambda n: self.utility(*files[n]))
        return f"delete {best}" if self.utility(*files[best]) > 0 else "wait"

    def feedback(self, deleted_age, needed_again):
        if needed_again and deleted_age >= self.recent_days:
            self.recent_days = deleted_age + 1

Same utility agent, plus a feedback method. Tell it that a nine-day-old file it deleted was needed again, and it moves its own definition of "recent" from seven days to ten. Before feedback it deletes build.log. After, build.log counts as recent, scores minus 300, and the agent deletes old.tar instead. The rule changed because of an outcome, and no human edited the code. That is the only thing "learning" means in this taxonomy, and it is a higher bar than most software that calls itself learning actually clears.

Run all five and you get five decisions from one percept:

simple reflex   delete old.tar
model-based     delete old.tar   (sensor returned None, used remembered free)
goal-based      ['delete cache.bin']
utility-based   delete build.log
learning before delete build.log   recent_days = 7
learning after  delete old.tar     recent_days = 10

If the types were only definitions, that table would be five rows of the same thing. The fact that they diverge on a three-file folder is why the taxonomy is worth knowing.

Which Type Is An LLM Agent?

Take the tool-calling loop from the how to build an AI agent post. The model gets a task, calls list_issues, reads each one, calls set_label, and stops when it says the job is done. Anthropic's tool use docs describe the mechanics, and a tool_result comes back as a new percept every turn while the whole conversation is resent.

That's a goal-based agent. The goal is in the prompt, the search for a sequence of actions happens inside the model, and the percepts are tool results. It's also model-based, because the message list is the persistent state, the agent's current conception of the world, updated every turn from the last action and the new percept, which is close to word for word how the textbook describes the model-based loop. Whether it's utility-based depends on the code around it, and usually the honest answer is no. The loop I wrote has no score. It has a turn cap and a token cap, which are constraints, and the permission ledger from the autonomous agent post is a set of constraints too. Constraints say what's forbidden. Utility says what's better. Most LLM agents in production have the first and a prompt that gestures at the second.

Is it a learning agent? At runtime, no. Nothing about a run changes the decision rule for the next run. The weights don't move, and a memory file, which Anthropic's docs describe as information stored "in files you control", is state, the same kind of thing as the message list, just longer lived. It becomes a learning agent when something reads the outcomes and rewrites the prompt, the tool descriptions, or the scoring, whether that something is you on a Friday afternoon or an eval loop. My read is that "self-improving agent" in most product copy means "we save notes to a file", which is a model-based agent with a good memory.

Classify Any Agent In Four Questions

Ask the questions in order and stop at the first "no". Applied to the five programs above it yields the five labels. Applied to a cron job that deletes files over 30 days old it stops at the first question, which is correct, and applied to Claude Code or Codex on an unattended task it gets to the third question and stops there unless you've bolted on a scorer. The one place people argue is the fourth row, and the test is strict on purpose. A human reading a log and editing a prompt is a learning system, and the human is the part that learns.

Types Of AI Agent In Real Life

The explainer pages pick physical examples because they're vivid. I've kept one of those per row and added the software example a developer actually meets.

The middle column matters more than the right one for most of us. In my own monorepo the cleanup scripts, the retry wrappers, and the deploy checks are all in the first two rows, and the one honest goal-based agent is the tool loop. That's not a failing. The types go up in capability and they go up in cost of being wrong at the same rate, and a rule you can read is often the correct level.

What Are The 7 Types Of AI Agents?

The seven-type lists take the five above and add multi-agent systems and hierarchical agents. Red Hat's version reaches eight by putting "functional agents", deterministic API integrations with no decision at all, below simple reflex, and ordering everything by complexity from very low to very high.

The additions aren't wrong so much as a different axis. Multi-agent and hierarchical describe how agents are arranged, one manager calling workers, or peers handing off, and every agent inside the arrangement is still one of the five decision types. Google's page makes the same move explicitly, categorizing by interaction (a surface agent you talk to versus a background agent driven by events) and by number (single versus multi). Those are useful labels for a system. They tell you nothing about how any single agent picks its next action, which is what the original five are for. The multi agent AI post covers the arrangement question on its own terms, including when a second agent earns its transcript.

What Are The Top 5 AI Agents?

That question is about products, and this taxonomy won't rank them for you. Every hosted coding agent on the market is a goal-based loop with tools and constraints, so by type they tie. The differences that matter are the permission ledger, what they're allowed to touch, and how they score on a task you can rerun. The AI coding assistant scorecard is built for exactly that, and I'd trust one run of it over any top-five list, including one I wrote.

Is ChatGPT An AI Agent?

By the textbook's definition, an agent is anything that perceives its environment and acts on it, which is broad enough to include a chat window that reads your message and replies. That breadth is why the vendor definitions narrow it. OpenAI's own guide says agents are systems that "independently accomplish tasks on your behalf" and that a simple chatbot which doesn't use the model to control workflow execution is not one. Under that definition the chat app is a model-based reflex agent at most, since it acts on the transcript and reaches no goal state on its own, and the agent OpenAI ships inside it is Codex, which runs a tool loop in a sandbox. So the honest answer depends on which definition you're holding, and I'd hold the vendor one, because it's the one that predicts what the thing will do to your repository.

What Are The 7 Types Of AI?

Different list, different subject. The "types of AI" lists classify whole systems by capability or by cognitive analogy, narrow versus general, reactive machines, limited memory, theory of mind, and so on. The five agent types classify how one program decides on its next action. An LLM is on the first list. The loop you wrap around it is on the second.

Pick The Type Before The Framework

When someone shows me an agent framework, the first thing I want to know is which of the four questions above it answers yes to, because that tells me what the framework is doing and what it's asking me to do. Most of them give you a goal-based loop and a memory file and leave the scorer and the feedback to you, which is fine as long as nobody calls the result a learning agent.

Start from the type the job needs. If a rule on the current state is enough, write the rule and skip the model. If you need a goal and a plan, the tool loop is a good goal-based agent and the sibling post builds one. If two good outcomes need to be told apart, write the utility function down where it can be argued with. And if you want the agent to learn, decide what feedback reaches it and what it's allowed to change, then look at the ten-line Learning class again, because that's all it is.