Types of AI Agents: Complete Taxonomy and When to Use Each (2026)
A practical taxonomy of AI agent types β by autonomy, loop architecture, domain, tool access, and human involvement β with a decision matrix for choosing the right agent design in 2026.
Every vendor in 2026 calls their product an "AI agent." That label now covers a chat sidebar with web search, a terminal coding assistant that runs for an hour unsupervised, a customer-support bot that opens tickets, and a fleet of twelve specialized subagents coordinating a research report. Those are not the same architecture β and picking the wrong type is the fastest way to waste tokens, miss deadlines, or ship something unsafe.
This guide gives you a practical taxonomy: the major types of AI agents, how they differ, real examples of each, and a decision matrix for choosing the right design.
Axis 1: Autonomy level β reactive vs deliberative vs autonomous
Classic AI textbooks (Russell & Norvig) define agent types by how they choose actions. LLM agents map cleanly onto this framework β with one important twist: the "model" is doing the reasoning, not hand-coded rules.
Reactive agents
A reactive agent maps the current input directly to an action. No internal world model, no multi-step plan. Think: autocomplete, inline code suggestions, or a classifier that routes a ticket to the right queue.
Strengths: Fast, cheap, predictable on narrow tasks.
Weaknesses: Cannot recover from errors across steps; no memory of prior actions unless you inject it.
Modern example: GitHub Copilot inline completions β one observation (cursor context), one action (suggest next lines), no loop.
Deliberative (goal-based) agents
A deliberative agent maintains a goal, reasons about what to do next, acts, observes the result, and repeats. This is the dominant LLM agent pattern in 2026.
Strengths: Handles multi-step tasks; can adapt when a tool call fails.
Weaknesses: Token cost scales with steps; can drift on very long horizons.
Modern examples: Claude Code, Cursor Agent, Devin, OpenAI Codex CLI β all run a goal-directed loop until the task completes or hits a stop condition.
Fully autonomous (background) agents
These agents run on schedules or triggers without a human initiating each session. Anthropic's managed agents, Claude Code's /goal mode, and various "AI employee" products fall here.
Strengths: True automation β work happens while you sleep.
Weaknesses: Highest risk profile; requires strong guardrails, logging, and rollback.
The critical design choice is not "how autonomous" but which actions stay gated. See Human-in-the-Loop AI for the decision framework.
Axis 2: Loop architecture β how the agent thinks step by step
Autonomy tells you whether the agent loops. Loop architecture tells you how each iteration works.
ReAct (Reason + Act)
The default pattern: the model outputs reasoning (optional) and a tool call, the harness executes it, the result goes back into context, repeat.
A planner produces a numbered step list first. An executor runs each step sequentially. Replanning happens only when a step fails or the plan becomes invalid.
When to use: Tasks with 15+ steps where pure ReAct drifts (migrations, multi-file refactors, research reports with fixed sections).
Trade-off: Slower to adapt mid-flight; upfront plan can be wrong.
LangGraph's PlanAndExecute chain and CrewAI's task decomposition are common implementations.
Reflexion (self-critique)
After each attempt, a critic model evaluates output quality and injects feedback before the next iteration. Useful when success criteria are fuzzy (writing quality, test coverage, security review).
When to use: Code review agents, content generation with quality bars, eval-driven improvement loops.
Trade-off: 2β3x token cost per iteration.
Agents optimized for web search, document retrieval, synthesis, and citation. Perplexity Deep Research, Google's research mode, and custom RAG pipelines are the main forms.
Key difference from coding agents: Read-heavy, write-light; evaluation is factual accuracy and source coverage, not test pass rate.
Customer support agents
Ticket routing, knowledge-base lookup, draft responses, escalation to humans. Usually reactive or short-loop deliberative β not open-ended autonomy.
Design constraint: Must handle PII, stay within policy, and escalate gracefully. Human gates on every customer-facing send.
Browser / computer-use agents
Agents that control a browser or desktop via screenshots and UI actions. Anthropic's Computer Use, OpenAI's Operator, and various open-source Playwright wrappers.
Strengths: Can interact with any web UI without an API.
Weaknesses: Slow (screenshot β action cycles), fragile on dynamic UIs, high token cost.
Workflow / automation agents
Zapier-style agents, n8n AI nodes, Make.com scenarios β fixed DAGs with LLM steps at decision points. Less "autonomous loop," more "LLM inside a workflow."
When to use: Repeatable business processes with known steps (invoice processing, lead enrichment, report generation).
Voice agents
Speech-in, speech-out agents with tool access β customer phone lines, meeting assistants, real-time translation with action capability.
Extra constraints: Latency budget (under 800ms for natural conversation), interruption handling, and ASR/TTS error propagation.
Rule of thumb: Start with one agent. Add a second only when you can name the specific subtask that needs a different system prompt, tool set, or parallel execution β not because "multi-agent sounds more advanced."
Claude Code subagents are orchestrator/worker at the harness level: the main session spawns specialists via the Task tool. See Claude Code Subagents.
Axis 5: Tool and memory access
RAG-only agents
Retrieve documents, inject into context, generate answer. No external actions.
Good for: Q&A over internal docs, policy lookup, knowledge bases.
Not an agent in the strict sense if there is no action loop β but vendors often label these "agents" anyway.
API / MCP agents
Connect to structured tools via REST APIs or Model Context Protocol (MCP) servers. The standard pattern for production integrations in 2026.
The agent type does not determine safety β the harness does. A fully autonomous coding agent with no gates on git push is a different risk class than the same agent with hooks that block production deploys.
Decision matrix β which agent type should you build?
Answer these five questions in order:
Is the task reversible?
No β Supervised or checkpointed, regardless of domain.
Yes β Continue.
How many steps?
1β3 β Reactive or single-shot (maybe not an agent at all).
4β20 β Single ReAct agent.
20+ β Plan-and-execute or multi-agent decomposition.
Does it need external systems?
No β RAG or pure generation (chatbot may suffice).
Every agent type above sits on the same underlying stack:
Prompt engineering β how each turn is worded
Context engineering β what the model sees (history, RAG, tool schemas)
Loop engineering β how observeβact cycles run (ReAct, plan-execute, etc.)
Harness engineering β the code that enforces gates, retries, and tool execution
Changing the "type" usually means changing layers 3 and 4, not just the prompt. A multi-agent system is primarily a loop + harness change. A browser agent is primarily a tool-access + harness change.
Human involvement: copilot β supervised β checkpointed β autonomous
Most production systems in 2026 are deliberative, ReAct-style, domain-specific agents with MCP tool access and supervised gates on irreversible actions. Multi-agent and plan-and-execute patterns appear when task complexity or parallelism demands them β not by default.
Product names, API capabilities, and agent features referenced in this guide reflect the landscape as of June 29, 2026. Agent taxonomies evolve quickly β check official documentation for the latest capabilities.