Inside AI Agents (2/3): Architecture Pattern Catalog — from ReAct to Multi-Agent

If you read Part 1, you know that an agent is essentially a loop: the LLM receives an observation, reasons, decides on an action, executes it, observes the result, and repeats. What differentiates architectural patterns is not the loop itself — it is how the reasoning is structured inside it and how many agents participate.

Think like a software developer. You have written a while with a stop condition. An agent is exactly that, but the stop condition is decided by the LLM ('is the task complete?'), and the loop body can call external tools. The engineering problem is: how do you structure the reasoning inside the loop so that it is reliable, auditable, and does not enter an infinite loop?

ReAct (Reasoning + Acting, Yao et al., 2022) was the first pattern to formalize this: the model explicitly alternates between a Thought step (natural language reasoning), an Action step (tool call), and an Observation step (tool result). This explicit alternation is powerful because it makes reasoning auditable — you can read the log and understand why the agent made each decision. It is the equivalent of writing code with inline comments instead of a monolithic block.

Reflexion (Shinn et al., 2023) adds a second inner loop of self-critique: after each attempt, the agent generates a reflection on what went wrong and stores that reflection in session memory before trying again. It is like a developer who writes a test, sees it fail, notes the diagnosis, and then fixes it — instead of simply trying again in the dark. The cost is clear: more tokens per attempt. Use it when the task has a verifiable correctness criterion (e.g. code that must compile, SQL that must return a non-empty result).

Plan-and-Execute separates reasoning into two distinct phases: a Planner LLM generates a step-by-step plan (think of a Makefile), and an Executor LLM executes each step independently. The advantage is that the plan can be inspected and approved by a human before execution — excellent for high-risk flows. The disadvantage is rigidity: if the environment changes during execution, the plan may become stale.

Agentic RAG is the upgrade from static RAG that every architect should know. In traditional RAG, you always fetch documents before generating. In Agentic RAG, the agent decides when to fetch, formulates the search query as part of its reasoning, and can perform multiple iterative searches ('I did not find it, I will reformulate the query'). This reduces noise in the context — you do not inject irrelevant documents — but requires the agent to know when it does not know something, which is a model calibration problem.

Memory in agents is analogous to storage in microservices: you have RAM (fast, expensive, volatile), local disk (cheaper, session-persistent), and distributed database (slow, cheap, shared). Each layer has a different trade-off.

The context window is the agent's RAM: everything in the active prompt. It is the fastest memory, but has linear token cost — every extra token you inject into the context increases inference cost and latency. The classic mistake is to dump everything into the context window ('I will include the full conversation history') and discover that the API bill tripled.

Session memory (short-term) is the equivalent of a Redis cache per session: you persist the current conversation history outside the prompt and inject only a summary or the last N turns. This solves the cost problem, but requires a summarization strategy — and LLM-based summarization has a cost too.

Long-term memory — vector, episodic, semantic — is the distributed database. You store facts, user preferences, past episodes in a vector store (e.g. OpenSearch, pgvector) and retrieve by semantic similarity when relevant. The risk here is twofold: memory without TTL grows indefinitely (storage cost and search latency), and stale memory generates hallucinations — the agent 'remembers' a fact that has changed.

The most important question about multi-agent is not 'which topology to use' — it is 'do I really need multi-agent?' The honest answer is: in most cases, no. A well-designed single agent with the right tools solves 80% of the problems people try to solve with complex multi-agent architectures.

Multi-agent makes sense in three real scenarios: (1) genuine parallelism — independent sub-tasks that can run simultaneously (e.g. analyzing 10 documents in parallel); (2) domain specialization — a sub-agent with a system prompt and tools optimized for a specific domain (e.g. a compliance agent vs. a financial analysis agent); (3) context isolation — you do not want the context of one sub-task to contaminate the reasoning of another.

The four main topologies are: Supervisor/Orchestrator (a central agent delegates to sub-agents and consolidates results — like a tech lead distributing tasks); Hierarchical (supervisor of supervisors — for very large problems); Swarm/Peers (agents without hierarchy that communicate via messages — more resilient, harder to debug); and Specialist Routing (a router LLM classifies the task and sends it to the correct specialist agent — analogous to an API Gateway with semantic routing).

The decision criterion I use in production: if you cannot explain in one sentence why each agent exists separately, you probably do not need multi-agent.

The most common mistake I see in teams coming to AI agents is treating security as a layer added afterwards. That does not work. Guardrails need to be designed as part of the flow from the start, because they affect latency, cost, and tool design.

Prompt injection is the SQL injection of agents: external data (an email, a document, an API response) can contain instructions that hijack the agent's behavior. The defense is layered: (1) clearly separate data from instructions in the prompt (use explicit delimiters); (2) validate in the input guardrail whether data content contains instruction patterns; (3) apply the principle of least privilege to tools — an agent that only needs to read documents should not have a database write tool.

Tool sprawl is the anti-pattern of giving the agent 30 tools 'because it might need them'. The LLM must choose the right tool from all available ones — the more tools, the higher the probability of wrong selection and the larger the system prompt. Practical rule: if an agent has more than 15 tools, consider splitting into specialized sub-agents.

Human-in-the-loop is not a sign of architectural weakness — it is a business requirement in any system that executes irreversible actions (financial transfers, mass email sending, data deletion). The correct pattern is to model explicit checkpoints in the Plan-and-Execute flow: the plan is generated, a human approves, execution begins. This is also what Amazon Bedrock Agents supports natively with 'human approval steps'.