AI Agent: how it works, architecture, and key components

Understanding what an AI agent is is good. Understanding how it works is what will allow you to deploy it intelligently, calibrate expectations, and avoid unwelcome surprises.

This article is for those who want to go a step further: CIOs, IT managers, IT architects, tech leads. No need to be a developer to follow along, you just have to be willing to open up the hood.

To do this, we will review the 5 fundamental components of an AI agent, understand the patterns, and compare simple agents to multi-agent systems. Let's go!

The 5 fundamental components of an AI agent

An AI agent is not monolithic software, but rather an assembly of bricks, each with a specific role. Understanding each brick means understanding why the agent does what it does, and why it fails when it fails.

The LLM: the reasoning engine

The LLM (Large Language Model) is the brain of the agent. It reads the objective, assesses the situation, chooses the next action to perform, and generates instructions for the other components.

This point deserves to be highlighted: the LLM doesn't just produce text, as it also reasons. An agent asks itself, "what do I need to do next to move toward the goal?" at each iteration of the loop.

Two limits are important to keep in mind from the start:

• Hallucinations: the LLM can produce incorrect information with apparent confidence. In a text generation context, this is annoying. In an action context (triggering a follow-up, modifying a record, sending an email), it is potentially problematic. The governance of your CRM and your AI begins here.

• The context window: the LLM can only process a limited amount of information at a time. On long or complex tasks, the first instructions can "fall out" of the active context.

Memory

This is the most underestimated brick. And yet, it is what determines whether the agent is truly useful over time or if it starts from scratch in every session.

There are two levels of memory:

• Short-term memory matches the context of the current session. Everything that the agent "knows" in the moment: the objective received, the actions already taken, the results obtained. It disappears at the end of the session.

• Long-term memory persists between sessions. It is stored in an external database: interaction history, reference documents, preferences, business data. The agent accesses it by querying the database when needed.

The technology that makes long-term memory possible at scale is RAG (Retrieval-Augmented Generation). Instead of loading everything into the context (impossible beyond a certain volume), the agent retrieves only the relevant information when it is needed.

Tools

This is the brick that turns the agent into an actor. Without tools, the LLM produces text. With tools, it can act. A tool, in concrete terms, is a function that the agent can call to interact with the real world:

• Read or write in a CRM

• Send an email

• Browse the web

• Execute code

• Query a database

• Call an external API

The mechanism is called tool calling or function calling: the LLM decides it needs a tool, calls it with the correct parameters, gets the result, and continues its reasoning. This is fundamentally what distinguishes an agent from an LLM alone.

The planner

For a simple goal ("send a confirmation email to this contact"), the agent does not need to plan. It directly calls the email tool and it is done.

For a complex goal ("identify the ten hottest leads of this quarter, prepare a personalized follow-up sequence for each, and schedule the mailings over two weeks"), it is different. You have to decompose, sequence, and sometimes parallelize.

This is the role of the planner. It translates a high-level goal into an ordered and executable list of subtasks. Two approaches coexist depending on the architectures:

• Plan-and-execute: the agent establishes a complete plan before starting to act, then executes it step-by-step. Predictable, but rigid if the situation changes along the way.

• ReAct (Reasoning + Acting): the agent continuously alternates between reasoning and action, without a pre-established plan. More flexible, but less predictable. This is the reference pattern today.

The evaluation module

Once an action is taken, someone must check if it achieved its goal. This is the evaluation module. It answers three questions:

1. Does the result obtained match what was expected?

2. Should we continue, correct, or stop?

3. Does this situation require human validation?

This is where human-in-the-loop comes into play: precisely defining at which points the agent must ask for a confirmation before going further. Not too often (otherwise autonomy disappears), not too rarely (otherwise the risk of error increases).

The ReAct loop: the reference pattern

Definition and origin

ReAct stands for Reasoning + Acting. This pattern was formalized by Google researchers in 2022. Today, it is the de facto standard for most AI agents deployed in production. The principle is simple, the agent continuously alternates between two modes:

• Reasoning: it thinks out loud (in its internal context) about what it knows, what it must do, and why.

• Acting: it calls a tool, observes the result, and starts again.

This alternation continues until the goal is achieved or a stop condition is triggered.

To go further in understanding how AI agents work with ReAct, I invite you to watch this short video.

Step-by-step example of a ReAct loop

Let's take a concrete case: an agent whose goal is to analyze the performance of retail stores during the last year-end promotion, then rank them in value and volume.

Step 1 - Reasoning: "My goal is to qualify the best-performing retail stores during the holiday promotion. I must first retrieve the sales data for the relevant period from the CRM."

Step 1 - Acting: call to the CRM tool, extraction of sales data by store over the defined promotional period.

Step 2 - Reasoning: "I have the raw data. Some stores have incomplete or missing data. I need to clean the dataset before I can calculate reliable indicators."

Step 2 - Acting: detection and handling of missing data, normalization of formats, exclusion of stores with no activity during the period.

Step 3 - Reasoning: "The data is clean. I can now calculate two distinct rankings: one by revenue generated, one by volume of units sold. These two readings can give different and complementary insights."

Step 3 - Acting: calculation of performance indicators by store, generation of the two rankings (value and volume), identification of stores in the top 20% on both axes.

Step 4 - Reasoning: "The rankings are ready. Now I must produce an actionable summary for the manager: the stores that perform on both axes, those that perform on only one, and the lessons to keep in mind for the next promotional campaign."

Step 4 - Acting: generation of the structured report, creation of a task assigned to the trade marketing manager with the file attached.

Step 5 - Reasoning: "The report is produced and sent. The goal is achieved."

End of loop.

The limitations of the ReAct pattern

ReAct is powerful, but it is not perfect. Here are 3 notable limitations:

1. The risk of an infinite loop. If the goal is poorly defined or if the agent doesn't find a clear stop condition, it may keep iterating indefinitely. You must always define a maximum number of iterations.

2. The token cost. Every iteration of the loop consumes tokens, which means time and money. On very complex tasks with many iterations, the cost can become significant.

3. Unpredictability. Unlike a script, ReAct does not always produce the same path for the same objective. This is a strength (flexibility) and a weakness (limited reproducibility)

Simple Agent vs. Multi-Agent System

Simple agent: when it is enough

A simple agent is a single agent, which has a well-defined goal, with a tight set of tools. It works sequentially, without delegation. It is the right choice for:

• Linear tasks with a well-defined scope

• Situations where the risk of error must remain low and controllable

• Initial deployments, before moving towards more complexity

Multi-agent systems: when complexity justifies it

In a multi-agent system, several specialized agents cooperate, coordinated by an orchestrator agent. Each agent has a precise role: one collects data, another analyzes it, a third writes the report, a fourth sends it.

The benefits of multi-agent systems are:

• Parallelization: several tasks run at the same time.

• Specialization: each agent is optimized for its role.

• Resilience: if an agent fails, the orchestrator can reroute.

Here are some open-source frameworks that allow building these architectures: AutoGen (Microsoft), CrewAI, LangGraph.

So, how to choose between the two? If the task can be split into parallel subtasks with different expertise, multi-agent is justified. Otherwise, a well-designed simple agent is almost always preferable.

AI Agent vs. Classic Pipeline vs. RPA

This is a question all CIOs ask when evaluating agentic AI: is it really different from what we already have?

Yes, and here is why.

When to choose what:

• RPA: highly repetitive tasks, stable interfaces, zero variability, limited budget. Example: automatically extracting data from a PDF invoice to an ERP.

• Classic Pipeline: structured data processing, predictable flows, need for reproducibility. Example: data transformation and loading between two databases.

• AI Agent: complex tasks with variability, reasoning needed, frequent exceptions. Example: qualifying inbound leads with enrichment and intelligent routing.

What you need to have in place before deploying an AI agent

Understanding the architecture is not enough. Implementation in the real world requires precise prerequisites. Neglecting this step is the primary source of failure.

Technical prerequisites

1. Structured and accessible data. This is the non-negotiable prerequisite. A well-designed agent with bad data produces bad actions. Before deploying, audit the quality of the data that the agent will consume.

2. Exposed and documented APIs. The agent needs to call tools. If your systems do not have accessible APIs, the agent cannot act. This is a common bottleneck in legacy environments.

3. A logging system. All actions of the agent must be traced: input, reasoning, action, result. Without logs, it is impossible to supervise, audit, or correct.

4. An infrastructure capable of handling latency. A ReAct loop with multiple iterations takes time. On critical tasks, latency can be a problem. This must therefore be anticipated in the design.

Organizational prerequisites

1. A precise goal. A vague objective produces an erratic agent. "Improve customer relations" is not a goal for an agent. "Automatically follow up with leads with no activity for 14 days with a personalized message based on their industry" is.

2. Defined guardrails. What actions can the agent take without human validation? Which ones require confirmation? These rules must be defined before deployment, not after the first incident.

3. Teams trained to supervise. An AI agent is not a set-it-and-forget-it tool. It must be supervised, tuned, and corrected. The teams using it must understand what it does and how to intervene when something goes wrong.

Understanding the logic of AI agents changes how we approach deployment. This is where the difference between a successful deployment and a failure is made.