A taxonomy of agents

Why it matters

Ask ten engineers what kinds of agent exist and you get ten lists. A list is a catalogue, not a model. It cannot tell you why a coding agent is safe to run for an hour unattended while a browser agent needs a confirmation gate every few steps. Interviewers ask "what kind of agent would you build here" to see whether you reason from the properties of the problem or recite product names. A taxonomy with named axes lets you place any product in a sentence and predict its failure modes before it is built.

The idea

A product sits in three places at once, which is what a single list hides.

Axis one: autonomy, who decides the path

A workflow follows a path the developer fixed: classify the request, retrieve, draft, check, respond. The model fills in steps; it does not choose them. An agent runs a loop in which the model picks the next action from what it just observed, and the path differs on every run. A multi-agent system splits the work across several loops, each with its own context, with one of them deciding who does what. The agent loop module covers the mechanics; here the question is who decides the path, which sets how predictable cost, latency and behaviour are. Workflows test like code; agents test statistically, over many runs.

Axis two: architecture, where the reasoning lives

Monolithic: one model, one prompt, one transcript holds everything. Easiest to debug, since the whole run is one trace. Modular: separate planner, executor and critic prompts, often on different models for cost; a run is three traces stitched together. Multi-agent: several agents with private contexts and a protocol between them; the failures hide in what one agent did not tell another. Tool-augmented: a model plus tools, where most of the real work happens inside tool results; debug the tools first. Embodied: the model drives a robot or a vehicle, where latency is a safety property. Most products in 2026 are tool-augmented monoliths; the positions overlap, and the axis asks where you look when a run goes wrong.

Axis three: environment, what the agent can touch

The environment fixes three things at once: which tools exist, what an observation looks like, and what a wrong action costs. In a chat the tools are a few lookups and the observation is text; a wrong action is a wrong sentence. In a codebase the tools are read, edit and run; the observation is a test result, which is ground truth; a wrong action is reverted by version control. In a browser or desktop the observation is a screenshot or an accessibility tree, expensive and ambiguous, and a wrong click can submit a payment. In a data warehouse the observation is a result set that can be valid and wrong at the same time. On a voice channel the observation arrives as noisy audio under a sub-second clock. In the physical world there is no undo.

Placing the seven types

The pills show typical placements, not fixed ones. A task assistant that confirms every write is a workflow; give it a loop and a wider tool set and it moves right on the autonomy row. A browser agent and a research agent share the web and differ entirely in observation: one sees pixels and clicks, the other fetches text and reads. That is why the environment axis matters most for risk. It decides whether an action can be verified (tests, row counts), whether it can be undone (a branch, a draft), and how much each observation costs in tokens.

	Autonomy	Architecture	Environment
Question it answers	Who decides the next step: the developer, the model, or several models	Where the reasoning lives and which trace you read when it breaks	Which tools exist, what an observation looks like, what a wrong action costs
Positions	Workflow, agent, multi-agent	Monolithic, modular, multi-agent, tool-augmented, embodied	Chat, codebase, browser or desktop, warehouse, voice, physical
What it decides	Predictability of cost, latency and behaviour; how you test	Debuggability, cost per step, specialisation	Safety controls: sandbox, confirmation gate, run-as-user; the evaluation
First failure to look for	Loops that never stop or stop too early	Information lost between components	An unverifiable or irreversible action

Trade-offs

Any taxonomy flattens: a product can be a workflow at the top (route the request) with an agent inside one branch (debug the failing test). The autonomy axis trades predictability for coverage: fixed paths handle fixed problems cheaply and fail on the unanticipated case; loops handle it and cost more on every run. The architecture axis trades debuggability for cost and specialisation. The environment axis is not a choice once the product is fixed, which is why it is named first and why the mitigations (sandboxes, confirmation gates, run-as-user) are environment-specific rather than general.

In an interview

Name the axes, then place the product: "Autonomy: this is an agent, the model picks the next action. Architecture: a tool-augmented monolith, so the trace is one transcript. Environment: a browser, so observations are expensive and some actions are irreversible, which is where the design effort goes." At junior depth, distinguish workflow from agent and say why the environment sets risk. At mid depth, place the seven types and explain how monolithic and multi-agent runs are debugged. At senior depth, show how one product spans several positions and derive the evaluation and safety plan from the environment. Expect "Why not build one general agent?" The answer is the environment axis: tools, observation and risk differ so much that a general agent is a general liability.