AI agent architecture patterns
AI agent architecture is the model, tools, memory and control flow, plus a pattern. Compare single-agent, planning, loop and multi-agent patterns.
An AI agent architecture has two layers: the parts of a single agent (a model, tools, memory and planning) and the pattern that controls how one or more agents run. Google Cloud’s design guide lists twelve patterns, from a single agent to swarms and human-in-the-loop checkpoints, and recommends starting with a single agent (Google Cloud, last updated May 2026).
For the definition of an agent, see what are AI agents. For coordinating several agents in depth, see agent orchestration.
The parts of one agent
Anthropic describes the basic building block as “an LLM enhanced with augmentations such as retrieval, tools, and memory,” and says an agent is typically “just LLMs using tools based on environmental feedback in a loop” (Anthropic, December 2024).
Lilian Weng’s survey (June 2023) names the same pieces and adds planning (Weng):
| Component | What it does | Limit the survey names |
|---|---|---|
| Model | Reasons and decides the next step | Output in natural language can be unreliable, so much agent code parses it |
| Planning | Splits large tasks into subgoals and reflects on past actions | LLMs struggle to adjust plans after unexpected errors |
| Memory | Short-term is in-context learning; long-term is an external store, usually a vector store | Finite context length limits how much history fits |
| Tools | Call external APIs for information “missing from the model weights” | Not stated |
Two design rules from Anthropic apply to every pattern below. At each step the agent should gain “ground truth” from the environment, such as a tool result, and a loop should have stopping conditions such as a maximum number of iterations. Anthropic also says to invest in tool documentation and testing as you would in a human interface. See context windows for the memory limit.
Control-flow patterns
Google Cloud’s guide groups the patterns by who decides the next step. Its sequential, parallel, loop and iterative refinement patterns run on predefined logic and need no model orchestration; the others let the model or a coordinator choose.
| Pattern | How it works | Main cost |
|---|---|---|
| Single agent | One model, a set of tools, one system prompt | Degrades as tool count and task complexity grow |
| Sequential | Specialized agents in a predefined, linear order | Rigid; cannot easily skip steps |
| Parallel | Subagents work on sub-tasks at the same time | More tokens; needs logic to merge conflicting outputs |
| Loop | Repeats subagents until a termination condition is met | Infinite loop if the exit condition is wrong |
| Review and critique | A generator makes output and a critic checks it against set criteria | At least one extra model call per check |
| Iterative refinement | Loops to improve an output over cycles | Latency and cost per cycle; needs a quality threshold or iteration cap |
| Coordinator | A central agent splits the request and routes sub-tasks to specialists | More model calls than one agent |
| Hierarchical | A multi-level hierarchy for complex, ambiguous problems | Complex, with high latency and cost |
| Swarm | Agents communicate all-to-all and build on each other’s work | Most complex and costly; may not converge without an exit condition |
| ReAct | Cycles thought, action and observation | A bad tool result can carry into the final answer |
| Human in the loop | The agent pauses at a set checkpoint and waits for a person to review or approve | You build and maintain the external system for that review |
| Custom logic | Your code orchestrates agents with conditions and branches | You build and debug all of it |
The guide also says that if a task is predictable or one model call can handle it, a non-agentic approach may be more cost-effective.
Planning architectures
Inside a single agent, the main design choice is how it plans. LangChain’s post (February 2024) compares three designs against the one-step-at-a-time ReAct loop:
| Design | How it works | Stated tradeoff |
|---|---|---|
| Plan-and-execute | A planner writes a multi-step plan, executors run each step, then a re-plan prompt decides to answer or plan again | Avoids calling the large planner for each tool call; tool calls stay serial |
| ReWOO | The plan uses variables (such as #E2) that a worker fills in; a solver combines the results | Fewer LLM calls; still sequential, so runtime can be longer |
| LLMCompiler | The planner streams a graph of tasks with dependencies, and independent tasks run in parallel | “Can grant a significant speed boost (the paper claims 3.6x)” |
A ReAct loop adapts after every observation. A fixed plan is cheaper and easier to inspect, but it must re-plan when a step fails. See ReAct agents for the loop itself.
Choosing
Google Cloud suggests defining task complexity, latency tolerance, cost budget and how much human involvement is needed, then picking from the pattern groups:
- Fixed, predictable steps: sequential, parallel or iterative refinement.
- The agent must decide how to proceed: a single agent for a prototype, a coordinator for adaptive routing, hierarchical for complex ambiguous problems.
- Output must be refined or checked: ReAct, loop, review and critique, iterative refinement.
- Unusual branching or high-stakes approvals: custom logic or human in the loop.
Anthropic adds a practical note on frameworks: start with the LLM APIs directly, because “many patterns can be implemented in a few lines of code,” and frameworks can obscure the prompts and responses you need for debugging. The guide says the choice is not one-time and should be revisited as requirements change. For workflows without model-chosen steps, see agentic workflows; for the multi-agent end, see multi-agent systems.
Tracing whichever pattern you pick
The more control the model has, the less the code shows you about what happened, so each pattern needs traces of its steps. HoneyHive records a run as a session of nested events typed model, tool or chain (“A logical grouping of child events”), which maps to a planner call, tool calls and a grouped step (HoneyHive tracing concepts). See agent observability for what to capture.
FAQ
What are the main components of an AI agent architecture?
A model plus tools, memory and some form of planning. Anthropic calls "an LLM enhanced with augmentations such as retrieval, tools, and memory" the basic building block of agentic systems, and Lilian Weng's survey adds planning as a fourth part (Weng).
What is the simplest AI agent architecture?
A single agent with a set of tools and a system prompt. Google Cloud's guide recommends starting there, refining the agent (for example with ReAct) when more tools and complexity make it degrade, and moving to multi-agent patterns when one agent must handle several distinct responsibilities.
What is the difference between ReAct and plan-and-execute?
ReAct decides one step at a time from the latest observation. Plan-and-execute writes a multi-step plan first, so the large planner model is not called for each tool call (LangChain). See ReAct agents.
When do I need a multi-agent architecture?
When one agent must handle several distinct responsibilities that refining its reasoning (for example with ReAct) does not fix, or when sub-tasks can run independently. Google Cloud notes that the coordinator pattern, for example, increases token throughput, operational costs and latency compared with a single agent. See multi-agent systems.