Ask two people to describe an AI agent and you’ll get two completely different products. One will describe a chatbot that answers refund questions from a script. The other will describe a system that spots a late invoice, drafts the chase email, logs into the payment portal to check whether it cleared, and only taps a human when the account is big enough to matter.
Both get filed under “AI agent,” which is exactly why the conversation about types of AI agents gets muddy so fast. The label covers everything from a three-line if-statement to a multi-model system that plans, browses, and delegates. Here’s a practical way to sort them.
The two dials that decide which type you’re looking at
Forget vendor decks for a second. Most agents differ along two axes: how much they decide on their own, and what they’re allowed to touch.
A rule that auto-refunds anything under $20 has almost no autonomy and touches exactly one internal database. A computer-use agent that navigates a supplier’s website, fills a purchase order, and confirms delivery has a lot of both. Same category label, wildly different engineering problems.
The classic taxonomy from AI textbooks (Russell and Norvig, if you want the source) still holds up well: reactive, model-based, goal-based, utility-based, and learning. Add two modern categories, tool-using agents and multi-agent systems, and you’ve got the map.
Reactive agents: pure reflex, no memory
A reactive agent maps a situation straight to an action. No history, no planning, no internal state. The thermostat is the textbook version: temperature drops, heating clicks on.
In software they’re everywhere, just less glamorous than the demos. Spam filters, fraud triggers on a card transaction, a Slack bot that auto-assigns tickets tagged “billing.” They’re cheap, fast, and easy to audit, which is why banks still run enormous fleets of them.
The trade-off is brittleness. A reactive refund bot will approve a $19 charge from a customer who has filed forty disputes, because it never looks at the pattern around the request.
Model-based agents: they keep a picture of the world
These add memory. The agent maintains an internal model of what’s happening, updates it as new information arrives, and acts on that model rather than on the raw last input.
An inventory agent is a clean example. It tracks current stock, inbound shipments, and sales velocity over the last fortnight, then reorders before a specific SKU runs dry. It doesn’t just react to “stock low.” It reasons about how fast low is approaching.
Most customer support agents that feel genuinely competent are model-based underneath. They hold the conversation history, the account tier, the open ticket, and the last three orders in memory, which is why they stop asking you to repeat your order number.
Goal-based agents: given an outcome, find the path
Now we’re into planning. A goal-based agent gets a target and works out a sequence of steps to reach it, searching through options when the first route fails.
Tell one to “get this part delivered by Friday for under $4,000” and it will enumerate suppliers, compare shipping tiers, check whether a split order beats a single expedited one, and revise when a quote comes back late. That’s search plus replanning, and it’s where LLM-based agents started getting genuinely useful in 2024.
The failure mode is loops. Without a step budget or a clear stopping condition, a goal-based agent will happily spend forty minutes trying to book a meeting room that doesn’t exist.
Utility-based agents: optimising instead of satisfying
Sometimes many actions are technically correct and you need to rank them. Utility-based agents attach a score to outcomes and pick the highest one, which means you can encode real business trade-offs instead of hard rules.
Content moderation is a good illustration. A moderation agent doesn’t ask “is this toxic, yes or no.” It assigns a probability, weighs it against the cost of a false positive versus a false negative, and routes accordingly. That shift from binary rule to scored decision is a big part of how AI decision models are reshaping content moderation, and it applies just as well to pricing, collections, and ad spend.
The catch: whoever defines the utility function defines the agent’s values. Get the weights wrong and you’ve automated the wrong instinct at scale.
Learning agents: the type that changes after you ship it
Learning agents improve from feedback, whether that’s reinforcement signals, click data, or a human rating the output. Ad bidding agents that adjust bids every few minutes are the classic production case. Recommenders are another.
This category carries a specific operational burden: the agent you tested in March is not the agent running in September. Performance drifts, and a policy that learned from last quarter’s traffic can quietly misjudge a new customer segment. Budget for monitoring, not just launch.
Tool-using and computer-use agents
This is where most of the practical value sits right now. A tool-using agent doesn’t just generate text; it calls functions. Search APIs, CRMs, calendars, payment systems, internal endpoints. The model decides which tool to call and with what arguments.
API agents versus pixel agents
An API agent talks to endpoints. Fast, reliable, cheap, and completely dependent on someone having built the integration. A computer-use agent looks at a screen, moves a cursor, and clicks, which means it can operate software that has no API at all.
That generality costs you. Pixel agents are slower, more expensive per action, and break when a button moves. Research like Holo4 and the push toward generalist computer-use agents is aimed squarely at making them less fragile across unfamiliar interfaces.
Platforms are adapting on their side too. Figma’s new features for defining how agents work on its platform are a decent signal of where this goes: design tools building agent-aware hooks rather than waiting for someone to script the UI.
Multi-agent systems: one manager, several specialists
The last type isn’t a single agent at all. It’s a team. An orchestrator breaks a job into subtasks and hands them to specialised workers: one retrieves, one fact-checks, one writes, one reviews. Coding tools that split planning from execution from testing use the same shape.
Done well, it beats a single generalist because each worker gets a tighter prompt and a narrower toolset. Done badly, it’s an expensive way to lose track of who did what. Token costs multiply, errors compound across handoffs, and debugging means reading an entire conversation transcript between machines.
Most real products stack three or four of these
Almost nothing ships as one pure type. A single support deployment might run a reactive router, a model-based state tracker, a goal-based planner for refunds, and a utility scorer deciding which cases escalate to a human.
That’s why benchmark comparisons flatter agents that fall apart in production. If you want to see what the stacks look like assembled, there’s a useful collection of ten real AI agent systems doing actual work, from coding to claims processing, with the messy parts left in.
The wall every agent type hits eventually
Sooner or later, an agent has to leave the sandbox. That’s where the technical taxonomy stops mattering and permissions start.
- Bot defences. Logins, CAPTCHAs, and rate limits treat an agent exactly like a scraper. As covered in the growing problem of getting websites to let agents in, this is now a policy fight as much as an engineering one.
- Identity. Whose credentials is the agent using, and can you revoke them at 2am without breaking the workflow?
- Spend limits. A goal-based agent with a corporate card needs a hard ceiling, not a sternly worded system prompt.
- Audit trails. Regulators and internal risk teams want the reason for a decision, not just the decision.
- Approval gates. The difference between a useful agent and a lawsuit is often a single human click before money moves.
The teams getting value from agents in 2025 are the ones who picked the least autonomous type that still solves the problem, then widened it once the guardrails held. Reflex bot first, planner second, computer-use agent only when nothing else reaches the data. Boring sequencing, but it’s the version that survives contact with a real support queue.