The taxonomy that actually decides your architecture.
Search this topic and you will find the same list repeated: simple reflex agents, model-based reflex agents, goal-based, utility-based, learning agents. It comes from a 1995 artificial intelligence textbook, it is a perfectly good academic taxonomy, and it will not help you decide what to build. The distinction that matters in production is not how an agent reasons. It is how much authority it has, and what happens when it is wrong. That single axis determines your architecture, your budget, your review process, and whether the thing ever leaves a staging environment.
Type 1 — The retriever.
Answers questions over your content. Retrieves, synthesises, cites. Takes no action and changes no state. Strictly speaking this is not an agent at all, and it is where most organisations should start. It is useful, cheap relative to the alternatives, and it surfaces your real problem early — which is almost never the model, and almost always that your content is contradictory, out of date, or scattered across four systems. The failure mode is a confident wrong answer, mitigated by citation, by refusing to answer outside the corpus, and by evaluating against a fixed question set. Build this when the task is find-and-explain and a human acts on the output.
Type 2 — The drafter.
Produces work for a human to approve: a reply, a summary, a structured record, a first-pass classification. It calls tools to read, never to write. The economics are better than most teams expect, because you are not trying to remove the human — you are removing the blank page. Acceptance rate is the metric, not accuracy, and a drafter accepted seventy percent of the time is transformative even though it is wrong the rest. The failure mode is plausible output that a rushed reviewer waves through; mitigate it by making the uncertain parts visibly uncertain rather than smoothing them into confident prose. Build this when the task has an existing human checkpoint you intend to keep.
Type 3 — The bounded actor.
Takes real actions, but only within an enumerated set: update this field, create this ticket, send this templated message, schedule this job. It cannot invent new kinds of action. This is the first genuinely agentic type and the one with the best risk-to-value ratio in most businesses. The bound is the safety mechanism — you are not relying on the model to stay in scope, you are making out-of-scope actions unrepresentable. The failure mode is the right action on the wrong object: the agent correctly decides to close a ticket and closes someone else's. Mitigate with idempotency, confirmation on anything destructive, and a complete audit trail. Build this when the actions are well understood, repetitive, and individually reversible.
Type 4 — The planner.
Decomposes a goal into steps and executes them, choosing its own sequence and adapting when a step fails. The action set may still be bounded, but the order and combination are up to the agent. The cost jump from Type 3 is substantial and it is not the model: partial failure becomes the dominant engineering problem. A five-step plan that fails at step four leaves the world in a state nobody designed, so you need compensating actions, or checkpoints, or both — and you need to be able to replay exactly what happened. The failure mode is silent partial completion, the hardest class of bug in agent systems and the reason observability is not optional at this tier. Build this when the goal is stable but the path genuinely varies per case, and you have already run a Type 3 agent successfully.
Type 5 — The supervised autonomous system.
Runs continuously against real volume, with defined authority limits and human approval gates on high-impact actions only. Not autonomous in the sense of unsupervised — autonomous in the sense that a competent employee is autonomous: trusted within a scope, escalating outside it. Everything in Type 4 applies, plus rate limiting, cost controls, behavioural regression testing against model upgrades, and someone who owns the system's decisions when it is wrong. Build this when a Type 3 or 4 agent has earned it with a track record you can point at.
The multi-agent question.
Multiple agents coordinating is a deployment topology, not a sixth type. Each agent in the system is still one of the five above, and each one still needs its own authority boundary. Split into multiple agents when the tasks need genuinely different tools, permissions or context — not because the diagram looks more impressive. A single well-scoped agent beats four poorly-scoped ones passing confusion between themselves.
Choosing, in one paragraph.
Start at the lowest type that solves the problem. Move up only when the lower type is working and its limitation is the actual bottleneck. The organisations that end up with production agents are, almost without exception, the ones that shipped a Type 1 or Type 2 first and earned their way up. The ones that start at Type 5 produce an impressive demo and a stalled project.