1. Why agentic AI changes everything

Blogs 1 and 2 covered how to make an LLM better informed — through prompting, retrieval, and grounding. This blog covers something fundamentally different: how to make an LLM take action.

A RAG system answers a question. An agent completes a task.

That distinction sounds simple. The architectural implications are enormous. When you move from answering to acting, you introduce planning, memory, tool use, error recovery, multi-step sequencing, and the question of how much autonomy to grant a system that can write to databases, send emails, call APIs, and trigger workflows.

Enterprise AI has been in the "better answers" phase for the past two years. The next phase is agentic — systems that do not just inform decisions but execute them. This is where the real productivity unlock lives, and it is where most enterprise architects are currently underprepared.

The shift from RAG to agents is the shift from a very knowledgeable consultant who gives you great answers to an autonomous colleague who takes your brief and gets the work done. Both are valuable. They require completely different architecture.

2. What is an AI agent — really

The word "agent" is used so loosely in the industry that it has almost lost meaning. Every chatbot with a web search tool is now called an agent. Let us be precise.

A true AI agent has four components:

LLM (the reasoning engine) — the model that thinks, plans, and decides what to do next. The LLM is the brain, but it is not the agent. The agent is the system built around it.

Memory — what the agent knows and remembers across steps. This includes the current context window, retrieved knowledge, logs of past actions, and potentially learned procedures. We cover memory types in section 4.

Tools — the interfaces through which the agent acts on the world. A tool might be a web search function, a database query, a code executor, an API call, or a file writer. Without tools, an agent can only generate text. With tools, it can change state in external systems.

Planning loop — the mechanism by which the agent decides what to do, does it, observes the result, and decides what to do next. This is the core of what makes an agent different from a single LLM call.

The agent spectrum

Not everything called an agent is equally autonomous. Think of a spectrum:

• Tool-augmented LLM — a single LLM call that can invoke one or more tools. Simple, predictable, low risk.
• ReAct agent — an LLM in a loop: reason about what to do, take an action, observe the result, reason again. Can handle multi-step tasks.
• Plan-and-execute agent — an LLM that generates a full plan first, then executes it step by step with a separate execution model.
• Multi-agent system — multiple specialised agents coordinating to complete tasks no single agent could handle alone.

When to use an agent vs. a simpler architecture

Agents introduce latency, cost, and failure complexity that simpler architectures do not. Before reaching for an agent, ask:

• Can this be solved with a single LLM call and a well-structured prompt? If yes — do that.
• Can this be solved with RAG + a single LLM call? If yes — do that.
• Does this require multiple sequential steps where each step's output determines the next? Does it require tool use across external systems? Does it require adapting to unexpected results mid-task? If yes to any — you need an agent.

3. Tool calling — how agents interact with the world

Tool calling (also called function calling) is the mechanism by which an LLM signals that it wants to invoke an external function rather than generate text. The model outputs a structured specification of which tool to call and with what parameters. The agent runtime intercepts this, executes the actual function, and returns the result to the model.

How it works under the hood

You define a set of tools as JSON schemas — each with a name, description, and parameter specification. These schemas are included in the system prompt or API call. When the model decides a tool is needed, it outputs a structured tool call object instead of (or alongside) text. Your code intercepts this, runs the function, and feeds the result back into the conversation.

The model never directly executes code or calls APIs. It requests; your runtime executes. This is an important security boundary.

Types of tools

Retrieval tools — web search, vector database query, document lookup. These give the agent access to knowledge beyond its training data.

Computation tools — code execution (Python interpreter, SQL runner, calculator). These let the agent perform precise calculations that LLMs handle poorly natively.

Read tools — database queries, file reads, API GET requests. These let the agent observe the current state of external systems.

Write tools — database writes, file creation, API POST/PUT/DELETE requests, email sending, calendar scheduling. These let the agent change the state of external systems. Handle with care.

Agent tools — calling another agent as if it were a tool. This is the foundation of multi-agent architectures.

Tool design principles

The reliability of your agent depends more on tool design than on model choice. A well-designed tool:

• Has a name and description precise enough that the model can correctly decide when to use it
• Has parameters with clear names, types, and descriptions — the model infers parameter values from context
• Returns structured, parseable responses — not raw HTML or unformatted text
• Fails gracefully with informative error messages the model can reason about
• Is idempotent where possible — calling it twice produces the same result as calling it once

The most common agent failure is not the LLM making a wrong decision — it is the LLM misusing a poorly designed tool because the description was ambiguous.

Error handling and retries

Agents encounter tool failures constantly in production: APIs time out, queries return no results, permissions are denied, rate limits are hit. Your agent architecture needs explicit retry logic, fallback strategies, and a mechanism for the agent to reason about failures and decide whether to retry, try a different tool, or escalate to a human.

4. Agent memory — how agents remember

Memory determines what an agent knows at any point in its operation. Most production agent failures can be traced to a memory design problem — either the agent does not have access to something it needs, or its context is polluted with irrelevant information that degrades its decisions.

In-context memory

Everything currently in the context window. Fast, immediately accessible, but finite and ephemeral — it disappears when the session ends. For most single-session agentic tasks, in-context memory is sufficient. The design challenge is managing what goes in the context and in what order, especially in long multi-step tasks where the context can fill up before the task is complete.

External memory (semantic)

A vector database or knowledge store the agent can query at any time. This is RAG applied to agent memory — the agent retrieves relevant past experiences, domain knowledge, or reference data as needed rather than loading everything into context upfront. Essential for agents that operate across many sessions or need access to large knowledge bases.

Episodic memory

Logs of past actions, decisions, and their outcomes. An agent with episodic memory can look back at what it tried before, what worked, and what failed — and use that to make better decisions in the current task. This is the foundation of learning agents that improve with use. Practically implemented as structured logs stored in a database and retrieved via semantic search.

Procedural memory

Learned skills and workflows the agent can execute without reasoning through them from scratch every time. In practice this means storing successful action sequences and tool call patterns that can be retrieved and replayed. Early-stage in most commercial frameworks but emerging rapidly.

5. Agent planning and reasoning patterns

How an agent plans its approach to a task is one of the most consequential architectural decisions. Different patterns offer different trade-offs between reliability, flexibility, and cost.

ReAct — Reason + Act

The foundational agentic pattern. The agent alternates between reasoning (thinking about what to do next) and acting (invoking a tool). After each action, it observes the result and reasons again. This continues until the task is complete or the agent determines it cannot complete the task.

ReAct is simple, interpretable, and works well for most single-agent tasks. Its weakness is that it can get stuck in loops or pursue unproductive paths without a way to step back and reconsider the overall approach.

Plan-and-execute

The agent generates a complete plan for the task before taking any actions. A separate execution model (often a lighter, cheaper model) then carries out the plan step by step. When a step fails or produces unexpected results, the planner is re-invoked to update the plan.

This pattern is more reliable for complex tasks with many steps because it separates high-level planning from low-level execution. It is also more expensive and less flexible — if the world changes mid-task, the plan may need to be regenerated entirely.

Reflection and self-critique

After completing a task or a set of steps, the agent reviews its own output against the original objective and critiques what could be improved. It then revises its approach. This dramatically improves output quality on tasks that require high accuracy — writing, analysis, code generation — at the cost of additional LLM calls.

Tree of Thoughts

Instead of following a single reasoning path, the agent generates multiple candidate next steps, evaluates each, and follows the most promising branch — backtracking when a branch fails. Powerful for tasks with large solution spaces but computationally expensive.

6. Model Context Protocol (MCP)

Until 2024, every agent integration was a custom one-off build. Connecting an agent to Slack meant writing a Slack integration. Connecting to a database meant writing a database connector. Connecting to a file system meant writing file system tools. Each integration was bespoke, fragile, and needed to be rebuilt for every new agent or model.

Anthropic introduced the Model Context Protocol (MCP) in late 2024 to solve this problem. MCP is an open standard that defines how AI applications connect to external tools, data sources, and services — a universal integration layer for the agentic ecosystem.

The problem MCP solves

Think of MCP like USB-C for AI integrations. Before USB-C, every device had its own connector. After USB-C, one cable works everywhere. Before MCP, every AI tool integration was custom-built. After MCP, a single MCP server exposes a tool or data source to any MCP-compatible agent or application.

MCP architecture

MCP Hosts — the AI applications that want to use tools. Claude Desktop, your custom agent application, an IDE with AI assistance. The host initiates connections to MCP servers.

MCP Clients — protocol clients built into the host that manage one-to-one connections with MCP servers. Each client maintains a session with one server.

MCP Servers — lightweight programs that expose specific capabilities: tools the agent can call, resources (data and content) the agent can read, and prompts (reusable interaction templates). A server might expose a company's internal database, a SaaS platform's API, a file system, or a web search capability.

Transports — how hosts and servers communicate. Local servers use stdio transport (standard input/output). Remote servers use HTTP with Server-Sent Events (SSE). This means MCP servers can run locally alongside your agent or remotely as cloud services.

MCP in the enterprise

The MCP ecosystem is growing rapidly. Zapier's MCP server exposes thousands of app integrations to any MCP-compatible agent. Cloudflare's MCP server exposes edge computing capabilities. Enterprise teams are building internal MCP servers to expose their CRM, ERP, HR systems, and internal databases to AI agents — without rebuilding integrations for every new model or agent framework.

For architects, MCP is a significant simplification. Instead of building and maintaining custom tool integrations for each agent you deploy, you build MCP servers once and any MCP-compatible agent can use them. This is the path to an enterprise AI integration layer that is maintainable at scale.

7. Agent-to-Agent communication (A2A)

MCP solves the problem of how an agent connects to tools and data. But it does not address a different problem: how does one agent communicate with, delegate to, or coordinate with another agent?

This is the problem Google's Agent-to-Agent (A2A) protocol addresses. Introduced in 2025, A2A defines a standard for how AI agents discover each other's capabilities and collaborate on tasks — regardless of which framework, model, or vendor built them.

How A2A works

Agent Cards — each agent publishes a machine-readable JSON document describing its capabilities, the tasks it can handle, the input/output formats it accepts, and the authentication it requires. Think of an Agent Card as the agent's API documentation, but structured for consumption by other agents rather than human developers.

Task lifecycle — when one agent (the client agent) wants to delegate to another (the remote agent), it sends a task request. The remote agent processes the task, which may transition through states: submitted → working → input-required → completed (or failed). The client agent can poll for status, receive streaming updates, or be notified on completion.

Capability negotiation — agents use Agent Cards to negotiate whether a task can be handled, what format the response will be in, and whether the interaction will be single-turn or multi-turn. This prevents mismatched expectations between agents that were built independently.

MCP vs. A2A — complementary, not competing

This is one of the most common points of confusion in the agentic AI space.

MCP connects an agent to tools and data sources — a database, a web search API, a file system. The agent is the consumer; the MCP server is a passive capability provider.

A2A connects an agent to another agent — where both sides are autonomous reasoners that can negotiate, ask clarifying questions, and adapt to each other. The remote agent is not a passive tool; it is an active participant.

In a well-designed multi-agent architecture, both protocols are in use simultaneously. An orchestrator agent uses A2A to delegate tasks to specialised sub-agents. Each sub-agent uses MCP to connect to the tools and data sources it needs to complete its assigned task.

8. Multi-agent systems — orchestrating agents at scale

Single agents are powerful. Multi-agent systems are transformative — and significantly more complex to design, operate, and debug.

Why single agents hit limits

A single agent operating in a single context window cannot:

• Work on multiple parts of a problem simultaneously
• Specialise deeply in different domains at once
• Scale to tasks that exceed the context window
• Maintain separation of concerns across complex workflows

Multi-agent systems address all of these by distributing work across specialised agents that coordinate to produce a unified result.

Orchestrator and worker pattern

The most common multi-agent pattern. An orchestrator agent receives the high-level task, breaks it into sub-tasks, delegates each sub-task to a specialised worker agent, collects the results, and synthesises a final output.

The orchestrator does not need to be the most capable model — it needs to be good at planning and delegation. Worker agents are optimised for their specific task: one might be a retrieval specialist, another a code generator, another a data analyst.

Parallel agents

Some tasks can be decomposed into independent sub-tasks that can run simultaneously. Instead of executing step-by-step, a parallel multi-agent system fans out to multiple worker agents at once and collects all results before synthesising. This dramatically reduces end-to-end latency for complex tasks.

Hierarchical agent networks

For very complex enterprise workflows, a hierarchy of orchestrators can manage other orchestrators, which in turn manage workers. A top-level business process agent might coordinate a procurement orchestrator, a compliance orchestrator, and a supplier communication orchestrator — each managing their own set of specialised workers.

Failure modes in multi-agent systems

Multi-agent systems fail in ways that single agents do not:

Failure propagation — a failure in one worker agent can cascade through the system if the orchestrator does not handle it gracefully. Every worker's output needs to be validated before it is passed downstream.

Coordination overhead — the communication between agents takes time and costs tokens. Poorly designed multi-agent systems can be slower and more expensive than a well-designed single agent.

Trust and prompt injection — when one agent passes information to another, that information could contain malicious content designed to hijack the receiving agent's behaviour. Multi-agent systems need explicit trust boundaries and input validation at every agent boundary.

Debugging complexity — when something goes wrong in a multi-agent system, tracing the failure across multiple agents, tool calls, and LLM invocations requires comprehensive logging and observability from day one.

9. Agent frameworks — the builder's toolkit

Four frameworks dominate the current enterprise agentic landscape. Each reflects a different philosophy about how agents should be built and orchestrated.

LangGraph

LangGraph models agent workflows as directed graphs where nodes are processing steps (LLM calls, tool invocations, human checkpoints) and edges are the transitions between them. State flows through the graph and is updated at each node.

Strengths: Explicit control flow, stateful workflows, built-in support for cycles and loops, strong observability via LangSmith, production-ready. Best for complex multi-step workflows where you need precise control over the agent's execution path.

Best for: Enterprise workflows with complex branching logic, human-in-the-loop requirements, and production observability needs.

OpenAI Agents SDK

A lightweight framework for building agents that call tools and hand off tasks between agents. Deliberately simple — it does not impose a graph or a role structure. You define agents, give them tools and handoff targets, and the SDK manages the execution loop.

Strengths: Minimal boilerplate, fast to get started, clean handoff semantics, good for straightforward tool-calling agents. Built to work seamlessly with OpenAI models and the Responses API.

Best for: Straightforward agentic applications where simplicity and speed of development are priorities.

CrewAI

Models multi-agent systems as crews of agents with distinct roles, goals, and backstories. Agents collaborate like a team — a researcher agent, an analyst agent, a writer agent — each contributing their specialisation to a shared objective.

Strengths: Intuitive mental model for teams already thinking in terms of roles and responsibilities, sequential and parallel task execution, built-in collaboration patterns.

Best for: Workflows that map naturally to human team structures — content production, research synthesis, business analysis pipelines.

AutoGen

Microsoft's framework for conversational multi-agent systems. Agents communicate with each other through structured conversations, with each agent responding to messages from other agents. Supports human-in-the-loop via a special human proxy agent.

Strengths: Natural conversation-based coordination between agents, strong for iterative refinement tasks, good research and experimentation base.

Best for: Tasks that benefit from agents debating, critiquing, and refining each other's outputs — code review, document drafting, analysis verification.

10. Human-in-the-loop — where and why it matters

Fully autonomous agents are not appropriate for most enterprise use cases today. Not because the models are not capable enough — but because the risk profile, regulatory environment, and organisational trust levels do not support it.

Human-in-the-loop (HITL) is not a failure mode. It is a design pattern that determines where human judgment is inserted into an otherwise automated workflow.

Approval gates

Before the agent takes an irreversible action — sending an email, updating a database record, placing an order, deleting a file — it pauses and requests human approval. The human reviews what the agent is about to do, approves or rejects it, and the agent proceeds accordingly.

Approval gates are most important for actions that are: irreversible, high-value, customer-facing, or compliance-sensitive. They add latency but provide the accountability that enterprise stakeholders require.

Escalation patterns

When an agent encounters a situation it is not confident about — an ambiguous instruction, an unexpected tool result, a decision that exceeds its defined authority — it escalates to a human rather than guessing. Well-designed agents know what they do not know and ask for help rather than proceeding with low confidence.

Audit trails and explainability

Every action an agent takes, every tool it calls, every decision it makes should be logged with enough detail that a human can reconstruct exactly what happened and why. This is not optional in regulated industries — it is a compliance requirement.

For enterprise architects, this means building structured logging into your agent from day one. Not as an afterthought. Every tool call, its parameters, its result, and the LLM's reasoning that led to it should be captured.

How much autonomy is appropriate

The right level of autonomy depends on three factors: the reversibility of the actions the agent can take, the cost of errors (financial, reputational, regulatory), and the maturity of your observability and recovery infrastructure.

Start with high human oversight and loosen it gradually as you build confidence in the agent's behaviour in production. Never grant an agent more autonomy than your incident response capability can handle.

11. Real-world application — Retail & QSR use cases

Retail Operations Agent

A large retail chain wants an agent that can monitor inventory levels across all stores, identify stockout risks, draft replenishment orders, communicate with suppliers, and update the inventory management system — with human approval before any order is placed.

Agent architecture decisions:

• Framework: LangGraph — the workflow has complex branching (different suppliers, different approval thresholds, different urgency levels) that maps naturally to a graph structure
• Tools: Inventory DB query (read), demand forecasting API (read), supplier portal API (write), order management system (write), email (write)
• Memory: External semantic memory (vector store) containing supplier contracts, pricing agreements, and past order history; episodic memory logging all orders placed and their outcomes
• Planning pattern: Plan-and-execute — the agent generates a full replenishment plan before taking any action, making it easier for humans to review and approve
• MCP: Internal MCP servers for the inventory DB, order management system, and supplier portal — reusable across other agents in the enterprise
• Human-in-the-loop: Mandatory approval gate before any order is placed; automatic escalation if order value exceeds threshold
• Multi-agent: A monitoring agent continuously watches inventory levels and triggers the replenishment agent when thresholds are crossed

QSR Incident Resolution Agent

A quick-service restaurant group wants an agent that monitors equipment sensor data across all locations, detects anomalies, diagnoses the likely fault, checks the warranty and service contract status, dispatches a service technician if needed, and logs the incident — all with minimal human intervention for routine faults.

Agent architecture decisions:

• Framework: OpenAI Agents SDK — the workflow is relatively linear (detect → diagnose → dispatch → log) and does not require the complexity of a graph structure
• Tools: Sensor data API (read), equipment knowledge base (RAG retrieval), warranty DB query (read), service dispatch API (write), incident log (write), notification system (write)
• Memory: RAG over equipment manuals and past incident logs — the agent retrieves similar past incidents to inform its diagnosis
• Planning pattern: ReAct — the agent reasons about the sensor data, retrieves relevant knowledge, decides on a diagnosis, and acts
• MCP: MCP server for the equipment knowledge base (shared with the QSR Operations Chatbot from Blog 2) — one MCP server serving multiple agents
• Human-in-the-loop: Automatic resolution for known faults under defined cost threshold; escalation to regional manager for novel faults or high-cost repairs
• A2A: The incident resolution agent delegates to a specialist parts-availability agent (built by a different team) to check whether required parts are in stock before dispatching a technician

The same agentic principles — tools, memory, planning, MCP, HITL — produce completely different architectures depending on the workflow complexity, data sensitivity, and acceptable autonomy level.

Key takeaways

1. An agent is not a chatbot. It is an LLM with memory, tools, and a planning loop. The architecture around the model matters as much as the model itself.
2. Tool design determines agent reliability more than model choice. Precise descriptions, structured outputs, and graceful error handling are non-negotiable.
3. MCP standardises tool integration. Build MCP servers once; any compatible agent can use them. This is the path to a maintainable enterprise AI integration layer.
4. A2A enables agent collaboration. Agent Cards + task lifecycle management allow independently built agents to discover and delegate to each other reliably.
5. MCP and A2A are complementary. MCP connects agents to tools; A2A connects agents to agents. Production multi-agent systems use both.
6. Multi-agent systems introduce new failure modes. Failure propagation, coordination overhead, trust boundaries, and debugging complexity all require explicit architectural attention.
7. Human-in-the-loop is a design pattern, not a limitation. Start with high oversight and loosen it as confidence in your agent's production behaviour grows.
8. Framework choice follows workflow structure. LangGraph for complex stateful workflows. OpenAI Agents SDK for simplicity. CrewAI for role-based teams. AutoGen for conversational refinement.