The types of AI agents, explained

What the types of AI agents are

The types of AI agents come from one taxonomy: simple reflex, model-based reflex, goal-based, utility-based, and learning agents. Each name describes one thing, how much the agent remembers and how far ahead it plans before it acts. Two more terms, multi-agent and hierarchical, describe how several agents are wired together rather than how any single one of them decides.

That list is older than every model you have used. It comes from the standard AI textbook, and it survived the arrival of large language models because it asks the question that still decides your design: what does this thing need to know before it acts? If you are still working out where an agent ends and a chat assistant begins, read the difference between an AI agent and the LLM it runs on first. This page starts after that line.

Simple reflex agents: one condition, one action

A simple reflex agent maps the current input to an action and keeps no memory of anything earlier. If the temperature is above 25, turn on the fan. That is the entire mechanism.

You have almost certainly run one. A webhook that fires an n8n workflow, which reads a form submission and writes a row to a database, is a simple reflex agent. It stays one even when a language model sits in the middle choosing a category for that row. Ask it what it did an hour ago and it cannot tell you, because nothing kept the answer.

This type is right more often than people expect. It is cheap to run, and its failure is legible: the condition matched, or it did not. When the job really is "when X arrives, do Y", memory adds ways to be wrong and buys nothing. A webhook-triggered n8n agent is this row of the taxonomy with a user interface on top.

It breaks the moment the correct action depends on history. A reply bot with no thread state will contradict itself on the third message, because the first two messages were never part of its input.

Model-based reflex agents: keeping state between events

A model-based reflex agent holds an internal picture of its environment and updates that picture as new input arrives. The word "model" here means a model of the world, not a neural network. The term predates the current meaning by about forty years, and it confuses nearly everyone on first reading.

A home automation rule that switches lights off after twenty minutes with no motion is model-based. It has to be. "No motion right now" and "no motion since 21:40" are the same input to a simple reflex agent, so only stored state tells them apart.

The LLM version is any agent with a memory store behind it: a rolling conversation summary, or a plain markdown file the agent reads at the start of every run. A local memory service for an agent is that idea packaged. The mechanism does not change. The agent's picture of the world outlives the event that created it.

State has a price. A stale fact is worse than no fact, because the agent acts on it with full confidence and no warning. Anything you store needs a way to expire or a way to be re-checked, or the agent will keep reasoning about a server you decommissioned in March.

Goal-based agents: planning toward a state you can check

A goal-based agent receives a target state and searches for a sequence of actions that reaches it. It works backward from where it needs to end up, so the path is not written down in advance.

A coding agent is the clearest example you can run yourself. "Make the failing test pass" names no files and no steps. The agent reads the test, forms a plan, edits something, runs the test, reads the error, and tries again. The loop ends on a check it can actually execute, which is why that instruction works and "improve this code" does not. A goal the agent can evaluate is a goal the agent can reach. A goal it cannot evaluate becomes an endless loop with a bill attached. Running a coding agent on your own VPS puts that loop somewhere it can churn without occupying your laptop.

Cost lives in this row. Every planning step is another model call carrying the history so far, so a ten-step task is not ten times the price of one step, it is more. The engineering that matters is the shape of the loop and the condition that stops it, which is the subject of loop engineering.

Utility-based agents: choosing between several good answers

A goal is binary. Utility is a score. A utility-based agent faces several acceptable outcomes and picks the one that scores highest under a function you wrote.

A backup job that has to finish before the working day starts without saturating the uplink is a utility problem. There is no single correct answer, only a trade-off. A router that decides which model handles which request, weighing price against answer quality, has the same shape.

The algorithm is not the hard part. Writing an honest utility function is. Score only on cost and you get the cheapest model on every request, including the one request that needed the expensive one. The system optimises exactly what you measured, which is a problem when what you measured was chosen because it was easy to measure.

Learning agents: the type most people assume they already have

A learning agent changes its own behaviour from feedback about past results. It needs something that judges the outcome and something that changes the policy in response.

Very few self-hosted systems qualify. An agent that reads notes it wrote last week is a model-based agent with a memory file. Its weights are identical. Its policy is identical. Retrieval is not learning, and the distinction is practical: a memory-based system repeats a mistake forever unless something edits the memory, while a learning system is supposed to stop making it.

If you want the learning half, build the evaluation first. A scored test set, a run of your change against it, and a decision to keep or discard the change is a closed loop in which you are the learning component. That is slower than it sounds, and it is the only version that works today on self-hosted parts. Self-hosting an eval harness is where that starts.

Multi-agent and hierarchical systems: arrangements, not types

These are not a sixth and seventh type. They describe how agents are arranged.

A multi-agent system runs several agents at once inside a shared environment, such as a queue or a git repository. Because the environment is shared, they collide in it. Two agents editing one file is the standard failure, and the fix is a lock or a work queue. No prompt solves it.

A hierarchical system puts a supervisor above workers. The supervisor splits a task, hands out the parts, and merges what comes back. It is popular because it matches how people divide work, and it is expensive because the supervisor's context grows with every report it reads. A multi-agent harness shows that wiring in practice.

One agent that works beats four that mostly work.

Every handoff is a place for information to be dropped. Start with one loop. Split it only when you can name the step that is the bottleneck.

Why almost every real system is a hybrid

Consider a deployment agent you might run yourself. A webhook starts it, which is reflex. It reads the current release state, which is model-based. It plans the steps from the running version to the target version, which is goal-based. It picks a rollout window from current load, which is utility-based. It never edits its own policy, so it is not learning.

One system, four rows of the taxonomy at the same time. The taxonomy earns its keep as a design checklist, not as a label for the finished product. When the system misbehaves, the useful question is which layer is wrong. A trigger that fired on the wrong event, a state that went stale, a goal check that can never pass, and a score that rewards the wrong outcome are four different bugs with four different fixes.

Which type suits which job

• Fixed trigger, fixed response, no history required: simple reflex.
• The right response depends on what happened earlier: model-based reflex.
• The end state is checkable but the path is unknown in advance: goal-based.
• Several acceptable outcomes with a real trade-off between them: utility-based.
• You need results to improve over time: build an eval loop, and accept that you are the learning component.

Can you host these agents yourself, and what does it cost?

Yes, and the cost splits in two. Orchestration is cheap. An n8n instance or an agent loop in Python spends most of its life waiting on network calls, so 2 vCPU and 4 GB of RAM carries it. The model is where the money goes.

If the agent calls a hosted API, the server needs almost nothing and the bill scales with tokens. For a goal-based agent that means it scales with how many planning steps you allow, so cap the loop.

If you run the model on your own hardware, RAM decides what you can run at all. The figures below are typical published file sizes for 4-bit quantised weights as of August 2026, next to a planning figure for total RAM, because the context window and the runtime both need room beyond the weights.

[
  {
    "label": "3B model",
    "weights_gb": 2,
    "ram_needed_gb": 6
  },
  {
    "label": "8B model",
    "weights_gb": 4.9,
    "ram_needed_gb": 10
  },
  {
    "label": "14B model",
    "weights_gb": 9,
    "ram_needed_gb": 16
  },
  {
    "label": "32B model",
    "weights_gb": 20,
    "ram_needed_gb": 32
  },
  {
    "label": "70B model",
    "weights_gb": 43,
    "ram_needed_gb": 64
  }
]

An 8B model at 4-bit is about 4.9 GB of weights, and a box with 10 GB of RAM runs it without swapping. A 70B model at the same quantisation is 43 GB of weights and wants around 64 GB. Notice what those numbers leave out: speed. On a VPS with no GPU, an 8B model at 4-bit produces single-digit tokens per second. That is fine for an agent working through a queue overnight and painful for anything a person is waiting on. Keep local inference for batch work, and use a GPU or an API for the interactive parts. The shortlist of self-hostable AI agents covers which projects are worth the disk, and a study path for agents in 2026 covers what to learn in what order.

Where the taxonomy stops helping

It says nothing about tools or permissions. The textbook agents perceive and act. Nobody writing that chapter was worried about an agent holding a production API token. A goal-based agent with shell access and a goal-based agent with one read-only database connection sit in the same row of the table and carry completely different risk. Decide what an agent may touch before you decide how clever it should be, and read how to keep secrets out of an AI agent before you hand it a credential.

It also says nothing about what happens when a step fails. Real agents spend most of their runtime handling errors: a rate limit, or a tool that returned something the model did not expect. That code decides whether your system is usable, and no row of the taxonomy describes it.

FAQ

What are the five types of AI agents?

Simple reflex, model-based reflex, goal-based, utility-based, and learning agents. They are ordered by how much the agent knows before it acts. A simple reflex agent sees only the current input. A model-based agent keeps state about its environment. A goal-based agent plans toward a target state. A utility-based agent scores several acceptable outcomes and picks the highest. A learning agent changes its own policy from feedback, which almost no self-hosted setup actually does.

Which type of AI agent should I use for a simple automation?

A simple reflex agent, which in practice means a webhook or a schedule that triggers a fixed sequence. If the correct response depends only on the input that just arrived, memory adds failure modes and no capability. Move up to a model-based design at the point where you can name one decision that has to know what happened before.

Can I run my own AI agents on a VPS?

Yes. The orchestration layer is light, so 2 vCPU and 4 GB of RAM runs a workflow engine or an agent loop comfortably. The real decision is where the model runs. A hosted API keeps the server small and moves the cost to tokens. A local model needs RAM in proportion to its parameter count, and without a GPU it generates single-digit tokens per second, which suits queued batch work rather than a chat window.

Is a large language model an AI agent by itself?

No. A model maps input text to output text and then stops. It becomes an agent when something wraps it in a loop that can act on the world and feed the result back in, which needs tools it can call and a condition that tells the loop when to stop. The wrapper is the agent. The model is one component inside it.

Do I need a multi-agent system?

Usually not. A single loop with several tools handles most work and is far easier to debug. Multiple agents help when parts of a task are genuinely independent and can run at the same time, or when one part needs a different model. The cost is coordination: shared state, and a supervisor whose context grows with every worker report it reads. Add the second agent when you can point at the step that is slow.