In Part 1 we established what AI agents are and how they differ from chatbots and traditional automation. This instalment goes inside the agent itself: the components every agent has, how they work together, and the four major architectural patterns used to build agent systems in practice.
Understanding the architecture matters whether you are building agents, evaluating vendor claims, or deciding whether agents are the right tool for a specific problem. The architecture determines what an agent can do, how it fails, and what safeguards are practical.
The Four Components Every Agent Has
Every AI agent — regardless of the framework, the LLM, or the specific use case — has the same four fundamental components. Understanding each one, what it does, and how it fails is the foundation of working with agents effectively.
The LLM brain: reasoning and planning
The large language model is the cognitive core of the agent. At each step of the agent loop, it reads the full current context — the original goal, everything that has happened so far, the outputs of any tools already called, and descriptions of the tools available — and decides what to do next: reason through a step, call a tool, or declare the task complete.
This is why model quality is the primary determinant of agent quality. In a single chatbot exchange, a weaker model produces a worse answer — but the failure is isolated. In an agent, a weaker model produces planning errors that compound across many steps, misinterprets tool outputs and acts on false assumptions, fails to recognise errors when they occur, and loses track of the original goal as context accumulates. Agent capability scales with model capability in a way that simple question-and-answer evaluation does not reveal.
The model also needs to reliably produce structured output — well-formed JSON specifying which tool to call and with what arguments. All frontier models (GPT-4, Claude 3, Gemini 1.5) support this natively through function calling or tool use APIs, making tool selection and invocation stable rather than dependent on fragile text parsing.
Tools: the agent's hands
Tools are the interfaces through which the agent takes actions in the world. Without tools, the agent can only generate text. With tools, it can browse the web, write and execute code, call external APIs, read and write files, send messages, query databases, and control software interfaces. The agent's capability ceiling is set by the combination of its LLM's reasoning ability and its available tool set.
How tools work mechanically: the LLM outputs a structured tool call — a function name and argument object in JSON. The agent framework intercepts this, validates the arguments against the tool's schema, executes the actual function (making an HTTP request, running code in a sandbox, reading a file), captures the result, and returns it to the LLM as an observation in the next loop iteration. The LLM never directly executes code or makes network calls; the framework does, and feeds results back.
Analogy: the LLM is the brain deciding to make a phone call; the tools are the hand that dials, the mouth that speaks, and the ear that listens. The brain and body communicate through a structured protocol — the tool call format — that both sides understand.
Tool design quality is one of the most underappreciated factors in agent reliability. Good tools have names and descriptions that make their purpose unambiguous — because the LLM selects tools based entirely on their descriptions. They return structured, parseable outputs. They fail with informative error messages that allow the agent to recover. Poorly described tools cause the agent to select the wrong one, call it with wrong arguments, or misinterpret its output — even when the reasoning model is capable.
Memory: what the agent knows and can recall
Agents need different types of memory for different purposes. Understanding all four — and their limitations — explains why agents lose context on long tasks and why memory management is a harder engineering problem than it first appears.
In-context memory: everything currently in the context window — the goal, the action history, tool outputs, observations. The agent's working RAM. Fast and immediately accessible; limited in size and cleared between sessions. The dominant memory type in most current deployments.
External memory: databases, vector stores, and file systems that the agent can query but that live outside the context window. Enables access to large knowledge bases without context window limits. Access is mediated by retrieval — the agent must know to query, and the retrieval must surface the right information. RAG (Retrieval-Augmented Generation) is the standard pattern.
Episodic memory: stored records of previous task executions — what worked, what failed, what was tried — that can inform future tasks. Most current frameworks have primitive episodic memory; it is an active frontier.
Semantic memory: structured knowledge bases encoding facts about the domain or organisation that the agent can query on demand.
The memory management challenge: deciding what to keep in context, what to summarise, what to write to external storage, and what to retrieve is itself a reasoning task — and agents frequently fail mid-task by losing track of information that was critical earlier in the sequence.
The planning mechanism: how agents decide what to do
The planning mechanism translates a goal into a sequence of concrete actions. The dominant patterns:
Chain-of-thought (CoT): the agent explicitly reasons through the problem before acting. "First I need to find X, then check whether Y is true, then calculate Z." The reasoning trace improves action quality and makes behaviour more interpretable.
ReAct (Reason + Act): alternates between a Thought step (the LLM reasons about the current situation) and an Action step (tool call). The tool result becomes the next Observation. Loop: Thought → Action → Observation → Thought → Action → Observation. The dominant pattern for single-agent tasks.
Plan-and-execute: a Planner generates a structured multi-step task list from the goal. An Executor works through each step in sequence. More efficient for well-structured tasks; less adaptive when early steps change what later steps require.
Self-critique and reflection: after generating an output, the agent evaluates it against the goal and decides whether to continue, revise, or escalate. The Reflexion paper (2023) showed that adding a self-critique loop dramatically improves task success rates at the cost of additional LLM calls.
The Four Architectural Design Patterns
Agent systems are built using a small number of recurring architectural patterns. These are not arbitrary choices — each suits a different class of task, and using the wrong pattern for the wrong task is one of the most common causes of poor agent performance.
Single-agent ReAct loop
The simplest architecture: one LLM, a set of tools, and a loop. The model reasons, calls a tool, receives the output as an observation, reasons again, calls another tool, and continues until the task is complete or a failure condition is reached.
When to use: well-scoped tasks with clear success criteria, a moderate number of steps, and a manageable tool set. Research tasks, data extraction from documents, iterative code generation and debugging, question-answering over a knowledge base.
Key strengths: simple to build, simple to debug, transparent execution trace, no coordination overhead.
Key failure modes: context window overflow as history accumulates on long tasks; the model losing track of the original goal in a long context; infinite loops when the model cannot determine task completion; error cascades when a tool fails and the model proceeds on incorrect assumptions.
Plan-and-execute
Two-phase architecture. Phase one: a Planner LLM receives the goal and generates an explicit, structured multi-step task list — a plan that a human can read and verify before execution begins. Phase two: an Executor works through each step, potentially re-invoking the Planner if execution reveals that the original plan needs revision.
When to use: complex tasks with many sub-tasks that can be largely anticipated from the goal statement. Report generation from multiple sources, software project scaffolding, multi-source research synthesis. The explicit plan also enables human review before execution — valuable for high-stakes workflows.
Key strengths: more efficient than ReAct (planning once instead of reasoning at every step), easier to audit (the plan is human-readable), predictable execution, easier to scope before starting.
Key failure modes: the plan becomes invalid when reality diverges from what the planner assumed. A plan to 'query three data sources' fails silently if one source is unavailable. Rigid plan-executor separation misses adaptation opportunities. Re-planning adds latency and cost.
Join our newsletter for regular updates on AI, digital marketing and growth!
Multi-agent systems
Multiple specialised agents working together, each with a focused role, coordinated by an orchestrating agent. The classic pattern: an Orchestrator receives the top-level goal, decomposes it into sub-tasks, delegates each to a specialist (Researcher, Analyst, Writer, Reviewer), collects outputs, and synthesises the final deliverable.
Why specialisation improves quality: a Researcher agent with retrieval-focused tools, a retrieval-optimised system prompt, and a narrow task scope performs better on research than a generalist agent trying to handle everything simultaneously. Specialisation reduces tool-selection errors and allows each agent to be tuned for its specific role.
When to use: tasks too large for one context window, tasks with clearly separable sub-tasks that can run in parallel, tasks where critique-and-revision loops improve output quality, or tasks where specialist expertise in each sub-domain matters.
Key failure modes: error propagation (one agent's incorrect output becomes the unquestioned input to the next); communication overhead (passing context between agents is expensive and lossy); coordination failures (agents duplicate effort or work at cross-purposes); debugging difficulty (tracing which agent introduced an error requires full execution logs across all agents).
Multi-agent pattern | How coordination works | Best for |
Hub-and-spoke | One orchestrator delegates to workers and synthesises results | Tasks with clear sub-task decomposition; simple to reason about |
Pipeline | Output of Agent A is input to Agent B, in sequence | Linear workflows with clear stage boundaries |
Peer-to-peer | Agents communicate directly, no central coordinator | Fluid collaboration where division of labour is dynamic |
Hierarchical | Orchestrators coordinate sub-orchestrators | Very complex, long-horizon tasks requiring multiple layers |
Human-in-the-loop (HITL)
Not all agent decisions should be autonomous. HITL architectures define explicit checkpoints where the agent pauses, presents its current state and proposed next action, and waits for human approval or correction before proceeding. The agent is autonomous within approved boundaries; consequential or uncertain actions require explicit human sanction.
What requires human approval: irreversible actions (sending emails, executing financial transactions, deleting production data); novel situations outside the agent's established competence; any action with legal or compliance implications; actions whose cost if wrong exceeds the cost of a human review.
What can proceed autonomously: read-only operations, internal reasoning steps, staging-environment operations, actions within previously approved patterns.
Designing checkpoints well: human review points should be infrequent enough that automation remains valuable, and presented clearly enough that the human can make an informed decision quickly. A wall of technical detail at every step produces confirmation fatigue — the human approves without reading, which defeats the purpose. The checkpoint should surface exactly what is needed for that specific decision, nothing more.
Choosing the right architecture Single-agent ReAct for bounded, well-specified tasks. Plan-and-execute when the task has many predictable sub-steps and upfront scoping matters. Multi-agent when the task is too large for one context window, benefits from specialisation, or needs parallel execution. Always add human-in-the-loop checkpoints for irreversible or high-stakes actions — regardless of which primary architecture you choose. |
Tools in Practice — What Agents Can Actually Do
An agent's reach is bounded by its tools. This section gives a practical overview of the major tool categories — what each enables, and where each reliably fails.
Web search and browsing
The agent submits queries to a search engine, retrieves ranked results, fetches the full content of selected pages, and — with browser automation tools like Playwright — interacts with dynamic web applications: filling forms, clicking buttons, navigating authenticated flows. Essential for tasks requiring current information beyond the model's training cutoff.
Limitations: paywalled content requires authentication; anti-bot systems block naive scrapers; retrieved information may be outdated or incorrect; the agent has limited ability to assess source credibility automatically.
Code execution
The agent writes code (Python, SQL, JavaScript, bash), executes it in a sandboxed environment, reads stdout and stderr, and iterates — exactly as a human developer would. The most powerful single tool available to LLM agents.
Code execution unlocks: arbitrary computation (data analysis, statistical modelling), file manipulation, web scraping from code, mathematical verification, data visualisation, and the ability to call external APIs programmatically rather than through pre-built tool definitions.
Security imperative: code execution must be sandboxed without exception. An agent with unsandboxed execution can delete files, exfiltrate data, install packages, and consume resources without limit. Sandboxing means: filesystem isolation, network restrictions, resource limits (CPU, memory, disk), and process restrictions. This is non-negotiable in any production deployment.
External API and service integrations
Agents can call any service that exposes an API — calendars, email, CRM systems, project management tools, databases, cloud infrastructure, communication platforms. All frontier models support structured tool call output natively, making API integration reliable without fragile text parsing.
The Model Context Protocol (MCP, Anthropic 2024) is an open standard for connecting LLMs to external tools in an interoperable way — analogous to USB for AI tool integrations. Adoption across the developer ecosystem grew rapidly through 2024–2025, reducing the integration burden from "build a custom connector for every tool" to "connect to the ecosystem."
Computer and UI control
Computer-use agents interact with software through the graphical user interface — taking screenshots, identifying buttons and input fields, sending keyboard and mouse inputs. This enables agents to use any application, including legacy systems with no APIs.
Anthropic's Computer Use capability (Claude 3.5 Sonnet, October 2024) was the first widely available frontier implementation. Early results: strong on structured, repetitive GUI tasks; unreliable on novel layouts; slower than API-based tools due to screenshot round-trip latency. Improving with each model generation.
File and data operations
Agents can read and write files, create and modify documents and spreadsheets, and process data at scale. A complete data workflow — ingest raw files, write analysis code, execute it, generate visualisations, write a narrative report — can be handled end-to-end without human intervention at each step. This is one of the most mature and reliable agent use cases currently in production.
Summary and What's Next
Every agent has the same four components: an LLM brain, tools, memory, and a planning mechanism. The architecture pattern — ReAct, plan-and-execute, multi-agent, or HITL — determines how these components are organised and coordinated. Tool quality is as important as model quality in determining overall agent reliability.
Part 3 of this series covers what agents are actually being used for in production today: software development, knowledge work, customer service, business operations, and personal productivity — with honest assessment of where deployment is mature and where it remains experimental.