Agente de IA: funcionamiento, arquitectura y componentes clave

Comprender qué es un agente de IA está bien. Comprender cómo funciona es lo que le permitirá desplegarlo de forma inteligente, calibrar las expectativas y evitar sorpresas desagradables.

Este artículo está dirigido a quienes desean ir un paso más allá: directores de TI (CIO), responsables de TI, arquitectos de SI, tech leads. No hace falta ser desarrollador para seguirlo, solo hay que estar dispuesto a abrir el capó.

Para ello, repasaremos los 5 componentes fundamentales de un agente de IA, comprenderemos los patrones y compararemos agentes simples con sistemas multiagente. ¡Comencemos!

Los 5 componentes fundamentales de un agente de IA

Un agente de IA no es un software monolítico, sino más bien un conjunto de piezas modulares, cada una con una función precisa. Comprender cada pieza es entender por qué el agente hace lo que hace y por qué falla cuando falla.

El LLM: el motor de razonamiento

El LLM (Large Language Model, o modelo de lenguaje grande) es el cerebro del agente. Es él quien lee el objetivo, evalúa la situación, elige la siguiente acción que se debe llevar a cabo y genera las instrucciones para los demás componentes.

Conviene destacar este punto: el LLM no produce únicamente texto, ya que también razona. Un agente se pregunta “¿qué debo hacer a continuación para avanzar hacia el objetivo?” en cada iteración del bucle.

Es importante tener presentes dos limitaciones desde el principio:

• Las alucinaciones: el LLM puede generar información incorrecta con aparente seguridad. En un contexto de generación de texto, es molesto. En un contexto de acción (lanzar un recordatorio, modificar una ficha, enviar un correo electrónico), es potencialmente problemático. La gobernanza de su CRM y de su IA comienza aquí.

• La ventana de contexto: el LLM solo puede procesar una cantidad limitada de información a la vez. En tareas largas o complejas, las primeras instrucciones pueden “quedar fuera” del contexto activo.

La memoria

Es el componente más subestimado. Y sin embargo, es el que determina si el agente resulta verdaderamente útil a largo plazo o si vuelve a empezar de cero en cada sesión.

Existen dos niveles de memoria:

• La memoria a corto plazo corresponde al contexto de la sesión en curso. Todo lo que el agente “sabe” en el momento presente: el objetivo recibido, las acciones ya realizadas, los resultados obtenidos. Desaparece al finalizar la sesión.

• La memoria a largo plazo persiste entre sesiones. Se almacena en una base de datos externa: historial de interacciones, documentos de referencia, preferencias, datos del negocio. El agente accede a ella consultando la base de datos en el momento en que lo necesita.

La tecnología que hace posible la memoria a largo plazo a gran escala es la RAG (Retrieval-Augmented Generation). En lugar de cargar todo en el contexto (imposible a partir de cierto volumen), el agente recupera únicamente la información relevante en el momento preciso en que la necesita.

Las herramientas

Es la pieza que transforma al agente en un ejecutor. Sin herramientas, el LLM produce texto. Con herramientas, puede actuar. Una herramienta, en la práctica, es una función que el agente puede invocar para interactuar con el mundo real:

• Leer o escribir en un CRM

• Enviar un correo electrónico

• Navegar por la web

• Ejecutar código

• Consultar una base de datos

• Llamar a una API externa

El mecanismo se denomina tool calling o function calling: el LLM determina que necesita una herramienta, la invoca con los parámetros adecuados, obtiene el resultado y continúa su razonamiento. Esto es lo que distingue fundamentalmente a un agente de un simple LLM.

El planificador

Para un objetivo sencillo (“envía un correo de confirmación a este contacto”), el agente no necesita planificar. Invoca directamente la herramienta de correo y listo.

Para un objetivo complejo (“identifica los diez prospectos más prometedores de este trimestre, prepara una secuencia de seguimiento personalizada para cada uno y programa los envíos a lo largo de dos semanas”), es distinto. Hay que descomponer, secuenciar y, a veces, paralelizar.

Esta es la función del planificador. Traduce un objetivo de alto nivel en una lista de subtareas ordenadas y ejecutables. Coexisten dos enfoques según la arquitectura:

• Plan-and-execute: el agente define un plan completo antes de empezar a actuar y luego lo ejecuta paso a paso. Predecible, pero rígido si la situación cambia por el camino.

• ReAct (Reasoning + Acting): el agente alterna de forma continua entre razonamiento y acción, sin un plan preestablecido. Más flexible, pero menos predecible. Es el patrón de referencia en la actualidad.

El módulo de evaluación

Una vez realizada una acción, alguien debe verificar si cumplió su objetivo. Este es el módulo de evaluación, que responde a tres preguntas:

1. ¿El resultado obtenido coincide con lo esperado?

2. ¿Se debe continuar, corregir o detenerse?

3. ¿Requiere esta situación una validación humana?

Aquí es donde entra en juego el concepto de human-in-the-loop: definir con precisión en qué momentos el agente debe solicitar confirmación antes de continuar. Ni demasiado a menudo (de lo contrario desaparece la autonomía), ni demasiado raras veces (o aumentará el riesgo de error).

El bucle ReAct: el patrón de referencia

Definición y origen

ReAct es el acrónimo de Reasoning + Acting (Razonamiento + Acción). Este patrón fue formalizado por investigadores de Google en 2022. Hoy en día es el estándar de facto para la mayoría de los agentes de IA desplegados en producción. El principio es simple, el agente alterna continuamente entre dos modos:

• Reasoning: reflexiona en voz alta (en su contexto interno) sobre lo que sabe, lo que debe hacer y por qué.

• Acting: llama a una herramienta, observa el resultado y vuelve a empezar.

Esta alternancia continúa hasta que se alcanza el objetivo o se activa una condición de parada.

Para profundizar en el funcionamiento de los agentes de IA con ReAct, le invito a ver este breve vídeo.

Ejemplo de bucle ReAct paso a paso

Tomemos un caso práctico: un agente cuyo objetivo es analizar el rendimiento de los puntos de venta en la última promoción de fin de año y luego clasificarlos por valor y por volumen.

Paso 1 - Reasoning: “Mi objetivo es clasificar los puntos de venta más eficientes en la promoción de fiestas. Primero debo extraer los datos de ventas del periodo correspondiente en el CRM”.

Paso 1 - Acting: llamada a la herramienta del CRM, extracción de los datos de ventas por punto de venta durante el periodo promocional definido.

Paso 2 - Reasoning: “Tengo los datos sin procesar. Algunos puntos de venta tienen datos incompletos o faltantes. Debo limpiar el conjunto de datos antes de poder calcular indicadores fiables”.

Paso 2 - Acting: detección y tratamiento de datos faltantes, normalización de formatos, exclusión de puntos de venta sin actividad en el periodo.

Paso 3 - Reasoning: “Los datos están limpios. Ahora puedo calcular dos clasificaciones distintas: una por volumen de negocio generado y otra por volumen de unidades vendidas. Estas dos lecturas pueden aportar resultados diferentes y complementarios”.

Paso 3 - Acting: cálculo de los indicadores de rendimiento por punto de venta, generación de las dos clasificaciones (valor y volumen), identificación de los puntos de venta situados en el 20% superior en ambos ejes.

Paso 4 - Reasoning: “Las clasificaciones están listas. Ahora debo generar un resumen procesable para el responsable: los puntos de venta que rinden bien en ambos ejes, los que rinden solo en uno y los aprendizajes que se deben extraer para la próxima campaña”.

Paso 4 - Acting: generación del informe estructurado, creación de una tarea asignada al responsable de trade marketing con el archivo adjunto.

Paso 5 - Reasoning: “El informe ha sido generado y enviado. El objetivo se ha cumplido”.

Fin del bucle.

Las limitaciones del patrón ReAct

ReAct es potente pero no es perfecto. Estas son 3 limitaciones notables:

1. El riesgo de bucle infinito. Si el objetivo está mal definido o si el agente no encuentra una condición de parada clara, puede seguir iterando indefinidamente. Siempre es necesario fijar un número máximo de iteraciones.

2. El coste en tokens. Cada iteración del bucle consume tokens y, por tanto, tiempo y dinero. En tareas muy complejas con muchas iteraciones, el coste puede ser significativo.

3. La imprevisibilidad. A diferencia de un script, ReAct no siempre recorre el mismo camino para un mismo objetivo. Es una ventaja (flexibilidad) y a la vez una desventaja (reproducibilidad limitada).

Agente simple vs. sistema multiagente

Agente simple: cuándo es suficiente

Un agente simple es un único agente, con un objetivo claramente delimitado y un conjunto limitado de herramientas. Opera de forma secuencial, sin delegación. Es la opción adecuada para:

• Tareas lineales con un alcance bien definido

• Situaciones donde el riesgo de error debe mantenerse bajo y bajo control

• Primeras implementaciones, antes de avanzar hacia una mayor complejidad

Sistemas multiagente: cuándo la complejidad lo justifica

En un sistema multiagente, varios agentes especializados cooperan entre sí, coordinados por un agente orquestador. Cada agente tiene una función precisa: uno recopila datos, otro los analiza, un tercero redacta el informe y un cuarto lo envía.

Las ventajas de los sistemas multiagente son:

• La paralelización: varias tareas se ejecutan al mismo tiempo.

• La especialización: cada agente está optimizado para su cometido específico.

• La resiliencia: si un agente falla, el orquestador puede redirigir la tarea.

Estos son algunos frameworks de código abierto que permiten construir estas arquitecturas: AutoGen (Microsoft), CrewAI, LangGraph.

Entonces, ¿cómo elegir entre ambos? Si la tarea se puede descomponer en subtareas paralelas con diferentes áreas de especialización, el enfoque multiagente está justificado. En caso contrario, un agente simple bien diseñado es casi siempre preferible.

Agente de IA vs. pipeline clásico vs. RPA

Esta es una pregunta que se hacen todos los CIO a la hora de evaluar la IA agéntica: ¿es verdaderamente diferente de lo que ya tenemos?

Sí, y he aquí por qué.

Cuándo elegir cada uno:

• RPA: tareas muy repetitivas, interfaces estables, variabilidad cero, presupuesto limitado. Ejemplo: extracción automática de datos de una factura en PDF hacia un ERP.

• Pipeline clásico: tratamiento de datos estructurados, flujos predecibles, necesidad de reproducibilidad. Ejemplo: transformación y carga de datos entre dos bases de datos.

• Agente de IA: tareas complejas con variabilidad, necesidad de razonamiento, excepciones frecuentes. Ejemplo: cualificación de leads entrantes con enriquecimiento y enrutamiento inteligente.

Lo que debe estar preparado antes de desplegar un agente de IA

Comprender la arquitectura no basta. El despliegue real exige prerrequisitos concretos. Descuidar este paso es la principal causa de fracaso.

Prerrequisitos técnicos

1. Datos estructurados y accesibles. Es el requisito indispensable no negociable. Un agente bien diseñado alimentado con datos deficientes producirá acciones deficientes. Antes de desplegar, audite la calidad de los datos que el agente va a consumir.

2. APIs expuestas y documentadas. El agente necesita llamar a herramientas. Si sus sistemas no disponen de APIs accesibles, el agente no podrá actuar. Este es un punto de bloqueo habitual en entornos legacy.

3. Un sistema de registro (logging). Todas las acciones del agente deben quedar registradas: entrada, razonamiento, acción, resultado. Sin logs, es imposible supervisar, auditar o corregir.

4. Una infraestructura capaz de gestionar la latencia. Un bucle ReAct con varias iteraciones requiere tiempo. En tareas críticas, la latencia puede convertirse en un problema. Por tanto, esto debe anticiparse durante el diseño.

Prerrequisitos organizativos

1. Un objetivo preciso. Un objetivo ambiguo genera un agente errático. “Mejora la atención al cliente” no es un objetivo para un agente. “Contacta automáticamente a los leads sin actividad desde hace 14 días con un mensaje personalizado según su sector” sí lo es.

2. Guardrails definidos. ¿Qué acciones puede realizar el agente sin intervención humana? ¿Cuáles requieren confirmación? Estas directrices deben definirse antes del despliegue, no después del primer incidente.

3. Equipos formados para supervisar. Un agente de IA no es una herramienta que se active y se olvide. Requiere ser supervisado, ajustado y corregido. Los equipos que lo utilicen deben comprender lo que hace y cómo intervenir cuando algo no funcione debidamente.

Comprender la lógica de los agentes de IA transforma la forma en que se aborda su implementación. Ahí radica la diferencia entre un despliegue exitoso y un fracaso.