AI Agents: Types and Architectures

What Is an AI Agent?

In artificial intelligence, an agent is anything that perceives its environment through sensors and acts upon that environment through actuators or effectors. This definition, popularized by Stuart Russell and Peter Norvig in Artificial Intelligence: A Modern Approach, is deliberately broad: a thermostat, a chess program, a robot, and a large language model orchestrating tools can all be described as agents. What separates a useful agent from a trivial one is the mapping it applies from perceived inputs (its percept history) to chosen actions, often called the agent function.

A rational agent is one that selects actions expected to maximize a performance measure, given the evidence provided by its percepts and any built-in knowledge. Russell and Norvig frame agent design with the PEAS specification: Performance measure, Environment, Actuators, and Sensors. Defining these four elements is the standard first step in characterizing any agent task, because the environment (observable or partial, deterministic or stochastic, single-agent or multi-agent) heavily constrains which architecture is appropriate.

In contemporary usage, the phrase AI agent most often refers to an LLM-based agent: a system in which a language model decides what to do next, calls external tools, and incorporates the results into ongoing reasoning. The classic theory still applies, but the implementation has shifted from hand-coded rules to model-driven decision making.

• An agent perceives via sensors and acts via actuators, mapping percepts to actions.
• A rational agent picks actions expected to maximize a defined performance measure.
• PEAS (Performance, Environment, Actuators, Sensors) specifies any agent task.
• Today the term usually means an LLM-based agent that plans and calls tools.

Core Components: Perception, Planning, Memory, and Action

Most agent architectures, classic or LLM-based, can be decomposed into four recurring functions. Perception ingests observations from the environment, whether sensor readings, an API response, or a user message. Planning or decision making selects the next action, ranging from a single condition-action rule to multi-step reasoning over candidate plans. Memory stores state across steps so the agent can track context it cannot currently observe. Action executes the chosen step through actuators or tool calls, changing the environment and producing new percepts.

These components form a loop: perceive, decide, act, observe the result, and repeat. In LLM agents this is often called the agent loop or the reasoning-acting cycle, and the quality of an agent depends largely on how well each stage is engineered and how the loop is bounded to avoid runaway iteration.

• Perception: convert raw environment signals or inputs into a usable internal representation.
• Planning: choose an action or sequence of actions, from reflex rules to deliberative search.
• Memory: maintain internal state across steps to handle partially observable environments.
• Action: invoke actuators or tools, then feed results back into the next perception step.

Classic Agent Types

Russell and Norvig organize agent programs into five increasingly capable types, a taxonomy that remains the standard reference for understanding agent architectures. Each type adds a capability the previous one lacks, trading simplicity for flexibility.

These categories are not mutually exclusive. A modern system can be a learning, utility-based, model-based agent at once. The taxonomy is best read as a ladder of capabilities rather than a fixed set of boxes.

• Simple reflex agents act only on the current percept using condition-action (if-then) rules, with no internal state. They fail when the environment is partially observable.
• Model-based reflex agents maintain an internal model of how the world evolves, letting them track unobserved aspects of the current state.
• Goal-based agents choose actions by considering future consequences and whether they advance an explicit goal, enabling planning and search rather than fixed reactions.
• Utility-based agents use a utility function to compare states on a continuous scale, allowing trade-offs when multiple goals conflict or when goals are uncertain.
• Learning agents improve over time: a learning element updates a performance element based on feedback, while a critic and a problem generator drive exploration.

LLM-Based Agents: Tool Use, Function Calling, and ReAct

LLM-based agents implement the agent loop with a language model as the decision maker. The model is given a task, a set of available tools, and the conversation or reasoning so far, and it decides whether to respond directly or to call a tool. Tool use (also called function calling) lets the model interface with external systems: search engines, databases, code interpreters, or arbitrary APIs. In a typical flow the application sends the model a request along with tool schemas, the model returns a structured tool call, the application executes it, and the result is returned to the model for the next step.

A foundational pattern is ReAct, introduced in the 2022 paper ReAct: Synergizing Reasoning and Acting in Language Models by Yao and colleagues (arXiv:2210.03629, ICLR 2023). ReAct interleaves reasoning traces (thoughts about what to do) with actions (tool calls), so the reasoning helps plan and adjust while the actions gather external information. The authors reported that on the ALFWorld and WebShop interactive benchmarks, ReAct outperformed imitation and reinforcement learning baselines by absolute success-rate margins of 34 percent and 10 percent respectively, while also reducing hallucination on question-answering tasks by grounding answers in a Wikipedia API.

To standardize how agents connect to tools and data, Anthropic introduced the Model Context Protocol (MCP) in November 2024 as an open standard. MCP defines hosts, clients, and servers communicating over JSON-RPC, replacing bespoke per-tool connectors with a shared interface. It has since seen broad industry adoption, with OpenAI and Google among the providers that adopted it.

Thought: I need the user's current open tasks before I can prioritize them.
Action: search_tasks(status="open")
Observation: ["Draft Q3 report", "Reply to vendor", "Book travel"]
Thought: Three open tasks. The vendor reply is time-sensitive, so it goes first.
Action: finish()
Final Answer: Start with "Reply to vendor", then the Q3 report, then booking travel.

• Function calling: the model returns a structured tool call that the application executes.
• ReAct (2022) interleaves reasoning traces with actions to plan, act, and self-correct.
• Built-in tools commonly include web search, code interpreters, and file or vector-store retrieval.
• MCP (2024) is an open standard for connecting agents to tools over JSON-RPC.

Single-Agent vs Multi-Agent Systems

A single-agent system uses one model-driven controller that owns the full task: it plans, calls tools, and produces the result. This is the simplest and most predictable design and is sufficient for the majority of tasks. A multi-agent system instead distributes work across several specialized agents, often coordinated by an orchestrator agent that decomposes a goal and delegates subtasks to workers, then synthesizes their outputs.

Multi-agent designs can improve performance on tasks that parallelize cleanly or that benefit from specialized roles, but they add coordination overhead and cost. Anthropic's engineering guidance notes that agentic systems consume substantially more tokens than single-shot chat interactions, and multi-agent systems more still, so the added complexity should be justified by the task.

• Single-agent: one controller, easier to debug, lower cost, suitable for most workloads.
• Multi-agent (orchestrator-worker): a lead agent delegates subtasks to specialized agents.
• Trade-off: parallelism and specialization versus coordination overhead and higher token cost.

Agent Memory: Short-Term Context and Long-Term Stores

By default, an LLM agent's only memory is its context window: the tokens currently passed to the model, including recent messages, reasoning, retrieved documents, and tool outputs. This is effectively short-term or working memory, and it is bounded by the model's maximum context length. Once information scrolls out of the window, the agent forgets it unless it has been persisted elsewhere.

Long-term memory lives outside the model, typically in an external store the agent can query. A common pattern keeps embeddings of past interactions or documents in a vector database and retrieves the most relevant items at each step, the same retrieval mechanism used in retrieval-augmented generation. Systems such as MemGPT layer a context-window main memory over a searchable recall store and a vector-indexed archive, with explicit rules for moving information between tiers. Deciding what to write to long-term memory, what to retrieve, and what to keep in the live context is an active area sometimes called context engineering. AI memory applications, including second-brain tools that store documents, photos, and voice notes and retrieve them by plain-English query, apply the same retrieval ideas at the level of a personal knowledge base.

• Short-term memory: the live context window holding recent turns, tool results, and retrieved text.
• Long-term memory: external stores (often vector databases) queried by relevance at each step.
• Tiered designs move information between working memory and persistent stores as needed.

AI Agents vs Agentic AI vs Workflows

The terms agent, agentic, and workflow are often used loosely. Anthropic's guidance offers a useful architectural distinction: it groups all LLM-driven task systems under the umbrella of agentic systems, then separates workflows from agents. In a workflow, LLMs and tools are orchestrated through predefined code paths, a fixed sequence with explicit control flow. In an agent, the LLM dynamically directs its own process and tool usage, retaining control over how the task is accomplished.

Neither is strictly better. Workflows offer predictability and consistency for well-defined tasks, while agents provide flexibility when the steps cannot be known in advance. The recommended practice is to start with the simplest approach that works, often a single LLM call or a fixed workflow, and to add agentic autonomy only when dynamic decision making clearly earns its added cost and unpredictability.

• Workflow: LLMs and tools follow predefined, code-controlled paths; predictable and cheaper.
• Agent: the LLM dynamically directs its own steps and tool use; flexible but less predictable.
• Agentic AI: the umbrella term covering both, where an LLM drives task completion.

Real-World Applications and Limitations

Agentic systems power coding assistants that read, edit, and run code; research and customer-support assistants that search and synthesize information; and automation that drives browsers, files, and enterprise APIs through standards like MCP. Their strength is handling open-ended tasks where the exact steps are not known in advance.

The limitations are real and well documented. Agents can hallucinate facts or tool arguments, compound errors across a long loop, and incur high token cost, especially in multi-agent configurations. Autonomy also raises safety and reliability concerns: an agent that can act on external systems needs guardrails, permission boundaries, and human oversight. The practical takeaway from current engineering guidance is to prefer the simplest design that meets the requirement and to escalate to fuller agency only when the task genuinely demands it.

• Common uses: coding assistants, research and support agents, browser and API automation.
• Key risks: hallucinated actions, error compounding over long loops, and high token cost.
• Mitigations: bounded loops, permission scoping, evaluation, and human-in-the-loop review.