Cómo funcionan los agentes de IA: del LLM al bucle de retroalimentación

Escribir una pregunta en ChatGPT y recibir una respuesta es una cosa. Pedir a un sistema "investiga los competidores de mi empresa, crea una hoja de cálculo comparativa y envíamela por correo electrónico" y ver que esto sucede solo, en varios pasos, es algo completamente diferente. Lo segundo es lo que hoy se llama agente de IA, y entender cómo funciona internamente requiere separar seis piezas que, juntas, transforman un modelo que solo predice texto en algo que decide, actúa y corrige su propio rumbo.

Qué es un agente de IA

Un agente de IA es un sistema construido alrededor de un LLM (modelo de lenguaje) que puede ejecutar tareas de múltiples pasos de forma autónoma, decidiendo por sí mismo qué acción tomar en cada paso, basándose en el estado actual de la tarea. La diferencia central con un chatbot común no es el modelo subyacente (generalmente es el mismo), sino la arquitectura que lo rodea: memoria entre pasos, un ciclo de planificación, acceso a herramientas y un mecanismo de repetición hasta que la tarea esté lista.

Esto cambia completamente el tipo de trabajo que el sistema puede realizar. Un chatbot responde una pregunta y se detiene. Un agente puede buscar, leer el resultado, darse cuenta de que falta información, buscar de nuevo con un término diferente, organizarlo todo y solo entonces entregar la respuesta final, sin que el usuario tenga que mediar en cada paso.

El término se ha convertido en un paraguas utilizado para productos muy diferentes entre sí: agentes de código que editan repositorios enteros, agentes de navegador que rellenan formularios y hacen clic en botones, agentes de atención al cliente que consultan sistemas internos antes de responder a un cliente. Lo que todos tienen en común, a pesar de su apariencia tan distinta, es precisamente esta estructura de seis piezas que detalla este artículo. Entender cada pieza por separado es lo que permite comparar productos diferentes de manera justa, en lugar de juzgarlo todo por el resultado final que aparece en la pantalla.

También vale la pena delimitar lo que un agente no es. No es un sistema con "libre albedrío" ni toma decisiones fuera del alcance que el desarrollador ha definido: el conjunto de herramientas disponibles, los límites de iteración y los criterios de éxito se configuran de antemano. La autonomía de un agente es real dentro de esos límites, pero los límites en sí mismos siguen siendo definidos por humanos.

LLM: el motor de razonamiento

El LLM es el componente que decide qué hacer a continuación, pero vale la pena aclarar un malentendido común: el modelo no "recuerda" nada entre una llamada y otra. Cada vez que el agente necesita una decisión, construye un nuevo prompt completo (con historial, resultados de herramientas, instrucciones) y lo envía al modelo, que responde de manera stateless, sin memoria propia incorporada.

Lo que hace que el LLM parezca que está "razonando" a lo largo de varios pasos es una técnica llamada chain-of-thought: en lugar de saltar directamente a una respuesta, se induce al modelo a exponer pasos intermedios de razonamiento antes de decidir la acción final. Esto mejora bastante la calidad de las decisiones complejas, porque el propio proceso de "escribir pensando" ayuda al modelo a no saltarse pasos lógicos importantes.

En la práctica, el LLM dentro de un agente cumple un papel muy específico: observar el estado actual (lo que ya se ha hecho, lo que la herramienta ha devuelto, cuál es el objetivo original) y decidir la próxima acción, ya sea llamar a una herramienta, pedir más información al usuario o concluir que la tarea ha terminado.

Un punto que suele sorprender a quienes están empezando: el mismo modelo, con el mismo prompt, puede generar decisiones ligeramente diferentes en ejecuciones distintas. Esto sucede porque la generación de texto en un LLM es probabilística, no determinista, controlada por un parámetro llamado temperatura. En agentes que toman decisiones sensibles (como mover dinero o eliminar datos), es común configurar una temperatura baja para reducir esta variación y hacer que el comportamiento sea más predecible, aunque nunca perfectamente determinista.

También vale la pena señalar que "el LLM" de un agente rara vez es una única llamada al modelo. Los sistemas más sofisticados utilizan modelos diferentes para etapas diferentes: un modelo más barato y rápido para decisiones simples de enrutamiento, y un modelo más grande y caro solo para los pasos que realmente requieren razonamiento profundo. Esta división del trabajo ayuda a controlar el costo sin sacrificar la calidad donde realmente importa.

Memoria

Como el modelo no guarda nada por sí solo, toda la "memoria" de un agente es, en realidad, ingeniería de contexto: decidir qué poner de nuevo en el prompt en cada llamada. En la práctica, existen dos tipos:

• Memoria a corto plazo: el historial de la conversación o de la ejecución actual, que cabe dentro de la ventana de contexto del modelo. Crece con cada paso del agente, y en tareas largas puede necesitar ser resumida para no exceder el límite de tokens.
• Memoria a largo plazo: información que debe sobrevivir más allá de una sola ejecución, almacenada fuera del modelo, en una base de datos, un archivo o un índice vectorial, y recuperada bajo demanda cuando es relevante. La técnica más común para esto es el RAG (generación aumentada por recuperación): antes de responder, el sistema busca los fragmentos más relevantes de esa memoria externa y los inyecta en el prompt.

Un ejemplo práctico ayuda a fijar la diferencia: un agente de programación que lee el código de un proyecto guarda el archivo abierto en ese momento como memoria a corto plazo, pero las convenciones del equipo (como "usa siempre TypeScript estricto" o "nunca uses la biblioteca X") suelen guardarse como memoria a largo plazo, en un archivo de configuración que se recarga en cada nueva sesión.

La ventana de contexto de un modelo, por grande que sea, tiene un límite físico de tokens, y cada token cuesta dinero y tiempo de procesamiento. Esto obliga a quien construye el agente a tomar decisiones constantes sobre lo que vale la pena mantener en la memoria a corto plazo y lo que se puede resumir o descartar. Una técnica común es la compactación progresiva: cada cierto número de pasos, el propio agente genera un resumen de lo que ha sucedido hasta ese momento, sustituye el historial bruto por ese resumen y continúa la ejecución con un contexto mucho más ligero.

Para la memoria a largo plazo basada en RAG, el mecanismo subyacente suele implicar una base de datos vectorial: cada fragmento de información se convierte en un vector numérico (embedding) que representa su significado, y la búsqueda no busca palabras exactas, sino los vectores más similares semánticamente a la pregunta actual. Por eso un agente con RAG bien configurado puede encontrar un documento relevante incluso si utiliza palabras completamente diferentes a las que el usuario ha escrito.

Planificación

Ante una tarea compleja, un agente rara vez lo resuelve todo en una sola llamada al modelo. El patrón más utilizado hoy en día es el ReAct (Razonamiento y Actuación), publicado en 2022: el modelo alterna entre "pensar" (razonar sobre qué hacer) y "actuar" (llamar a una herramienta), observando el resultado de cada acción antes de decidir la siguiente, en lugar de intentar predecir el plan completo de una sola vez.

También existe el patrón "planificar y ejecutar", en el que el modelo primero escribe un plan completo con varios pasos, y solo después comienza a ejecutarlos uno por uno. Tiende a ser más predecible, pero menos flexible: si un paso en medio del camino falla o revela información nueva, el agente necesita replanificar, lo que no siempre se maneja de forma automática en este diseño.

En la práctica, la mayoría de los agentes de producción combinan ambos: un plan inicial aproximado, revisado cada pocos pasos en función de lo que realmente ha sucedido, en lugar de seguirlo ciegamente de principio a fin.

Un ejemplo concreto del patrón ReAct en acción: pregúntale a un agente "¿cuál es el horario de apertura de la tienda más cercana a mí que tiene el producto X en stock?". Un plan rígido, hecho de una vez, probablemente fallaría, porque el agente aún no sabe qué tiendas existen ni cuáles tienen el producto. Con ReAct, el modelo primero razona ("necesito encontrar tiendas cercanas"), actúa (llama a una herramienta de búsqueda por ubicación), observa el resultado, razona de nuevo ("ahora necesito comprobar el stock de cada una"), actúa de nuevo, y solo entonces, con información suficiente, formula la respuesta final. Cada decisión depende del resultado de la anterior, lo que sería imposible de predecir en un plan único y fijo.

También existe la cuestión de la profundidad de la planificación: las tareas simples pueden saltarse la etapa de planificación explícita e ir directamente a la selección de herramientas, mientras que las tareas complejas, con muchas dependencias entre subtareas, se benefician de un plan escrito de forma explícita, a veces incluso mostrado al usuario antes de comenzar la ejecución, para que pueda aprobar o ajustar el rumbo antes de que se realice cualquier acción real.

Herramientas

Las herramientas son lo que le dan al agente la capacidad de actuar en el mundo real, más allá de solo generar texto: buscar en la web, ejecutar código, consultar una base de datos, enviar un correo electrónico. El mecanismo técnico detrás de esto es el function calling (o tool calling): el desarrollador describe cada herramienta disponible, con nombre, descripción y un esquema de los parámetros que acepta, y el modelo devuelve una respuesta estructurada indicando qué herramienta llamar y con qué argumentos.

El modelo en sí nunca ejecuta la herramienta. Solo decide y formatea la llamada; quien realmente ejecuta el código, realiza la solicitud HTTP o consulta la base de datos es el software que rodea al modelo. Esta separación es importante: significa que el mismo "cerebro" puede conectarse a herramientas completamente diferentes sin necesidad de ser reentrenado, solo reconfigurando qué funciones están disponibles en el prompt.

El Model Context Protocol (detallado en el artículo anterior sobre MCP) resuelve precisamente la parte de estandarizar cómo se describen y descubren estas herramientas, para que un agente no necesite una integración específica para cada servicio externo que utiliza.

En la práctica, las herramientas de un agente suelen agruparse en algunas categorías recurrentes: búsqueda y lectura de información (web, documentos, bases de datos), acción sobre sistemas externos (enviar correo electrónico, crear un ticket, actualizar una hoja de cálculo), ejecución de código (ejecutar un script, una consulta SQL, un comando de terminal) y comunicación con el propio usuario (pedir confirmación, hacer una pregunta aclaratoria). Un agente bien diseñado normalmente no recibe acceso a todas las herramientas disponibles en el sistema de una vez, solo al subconjunto necesario para la tarea en cuestión, siguiendo el mismo principio de menor privilegio utilizado en la seguridad de sistemas tradicionales.

La calidad de la descripción de cada herramienta importa más de lo que parece. Un nombre vago como process_data con una descripción de una línea tiende a generar llamadas incorrectas o mal formateadas, porque el modelo no tiene suficiente contexto para decidir cuándo usarla. Las descripciones específicas, con ejemplos de uso y límites claros (lo que la herramienta no hace), reducen considerablemente la tasa de error en esta etapa.

Ejecución

La ejecución es la capa de software, generalmente llamada runtime u orquestador del agente, que recibe la decisión del LLM y la pone en práctica: llama a la API correcta, ejecuta el comando, espera la respuesta, maneja el error si la llamada falla. Aquí también entran las capas de seguridad: sandboxing para el código generado por el modelo, límites de tiempo (timeout) para cada llamada y validación de los parámetros antes de ejecutar cualquier cosa irreversible.

Un detalle que genera confusión: no toda ejecución es secuencial. Los agentes más sofisticados pueden lanzar varias herramientas en paralelo cuando son independientes entre sí, como buscar en tres fuentes diferentes al mismo tiempo, lo que reduce bastante el tiempo total de la tarea en comparación con llamar a una herramienta cada vez y esperar cada respuesta antes de continuar.

El manejo de errores en esta capa es lo que separa un agente frágil de uno confiable. Una llamada a una herramienta puede fallar por docenas de razones: la API externa está fuera de servicio, los parámetros están mal formateados, el permiso fue denegado, el tiempo límite se agotó. Un orquestador bien construido captura cada tipo de fallo por separado y decide qué hacer con él: intentarlo de nuevo automáticamente (con un límite de intentos, para no repetir un fallo permanente indefinidamente), devolver el error al LLM como parte de la observación para que intente un enfoque diferente, o escalar el problema a intervención humana cuando ninguna de las opciones automáticas lo resuelve.

El sandboxing merece una mención especial cuando la herramienta implica la ejecución de código generado por el propio modelo. Ejecutar ese código directamente en el mismo entorno donde vive el agente es un riesgo real, por lo que las implementaciones serias aíslan esa ejecución en un contenedor o máquina virtual desechable, sin acceso a la red o a archivos sensibles por defecto, liberando solo lo que la tarea específica realmente necesita.

Bucle de retroalimentación

Después de que una herramienta se ejecuta, su resultado no desaparece: vuelve al contexto, como si fuera una nueva información que el LLM debe tener en cuenta en la siguiente decisión. Este ciclo (percibir el estado, planificar, actuar, observar el resultado, actualizar el contexto) se repite tantas veces como sea necesario hasta que ocurra una de dos cosas: el modelo decide que la tarea está completa, o el agente alcanza un límite de seguridad, como un número máximo de iteraciones o un tiempo total de ejecución.

Este límite de iteraciones no es un detalle menor. Sin él, un agente mal configurado puede entrar en un bucle donde repite la misma acción sin considerar nunca la tarea completada, gastando tokens (y dinero) indefinidamente. Por eso, prácticamente todo framework de agente serio incorpora algún tipo de bloqueo: un contador máximo de pasos, una comprobación explícita del criterio de éxito, o la exigencia de confirmación humana después de cierto número de intentos sin progreso.

Vale la pena distinguir dos tipos de parada. La parada "feliz" ocurre cuando el LLM evalúa el estado actual contra el objetivo original y concluye, de forma explícita, que se han cumplido todos los criterios. La parada por límite ocurre cuando el agente agota el número de iteraciones o el presupuesto de tiempo/costo permitido sin llegar a ese punto, y en ese caso el comportamiento esperado no es simplemente bloquearse, sino informar al usuario de lo que se ha hecho hasta ese momento y por qué la tarea no se ha podido completar por sí sola.

Un patrón cada vez más común en sistemas de producción es el human-in-the-loop: para acciones de alto riesgo (mover dinero, eliminar datos, enviar una comunicación pública), el bucle de retroalimentación incluye una pausa obligatoria esperando la aprobación humana antes de continuar con la siguiente iteración, aunque el agente ya haya decidido por sí solo que esa es la acción correcta.

El ciclo completo, en diagrama

Juntando las seis piezas, el ciclo de un agente de IA queda así:

El punto central de este diseño es que la flecha de retorno no es un detalle estético: es lo que separa a un agente de un simple flujo automatizado de pasos fijos. El agente decide, en cada vuelta del ciclo, si necesita continuar o si ya ha cumplido el objetivo.

Chatbot vs agente

Vale la pena ponerlos uno al lado del otro, porque la línea entre ambos no siempre es obvia para quien usa el producto final:

Aspecto	Chatbot tradicional	Agente de IA
Estructura de la respuesta	Una pregunta, una respuesta	Varios pasos encadenados hasta completar un objetivo
Acceso a herramientas	Raro o inexistente	Central, mediante function calling o MCP
Memoria entre pasos	Solo el historial de la conversación actual	Corto y largo plazo, a menudo con búsqueda externa (RAG)
Autonomía de decisión	Baja, el usuario guía cada intercambio	Alta, el propio sistema decide los siguientes pasos
Criterio de parada	Fin del mensaje generado	Criterio de éxito de la tarea o límite de iteraciones

En la práctica, la frontera es un espectro, no una línea nítida: muchos productos hoy en día son chatbots con algunas herramientas simples conectadas, sin llegar a tener un ciclo de planificación completo. El término "agente" tiende a reservarse para sistemas que realmente deciden sus propios siguientes pasos, no solo ejecutan una función cuando el usuario lo pide explícitamente.

Una prueba práctica para diferenciarlos al evaluar un producto: pide una tarea que requiera al menos tres pasos dependientes entre sí, sin detallar el paso a paso, solo el resultado deseado. Un chatbot tiende a pedir más instrucciones o intentar resolverlo todo en una respuesta única y superficial. Un agente real descompone la solicitud en subtareas, utiliza herramientas para resolver cada una, y solo entrega el resultado final después de completar todo el ciclo por sí mismo.

Ejemplo completo

Para hacer todo esto concreto, vale la pena seguir a un agente hipotético de investigación de mercado que recibe la solicitud: "investiga los 3 principales competidores de mi empresa en Brasil y envíame un resumen por correo electrónico".

Paso 1, planificación: el LLM descompone la solicitud en subtareas: buscar competidores, recopilar datos de cada uno, sintetizar en un resumen, enviar por correo electrónico. Este plan inicial se guarda en la memoria a corto plazo de la ejecución.

Paso 2, primera herramienta: el agente llama a una herramienta de búsqueda en la web con la consulta "principales competidores [empresa] Brasil". El resultado (una lista de nombres y enlaces) vuelve como observación.

Paso 3, retroalimentación y replanificación: el LLM observa que la búsqueda ha devuelto 5 nombres, pero solo necesita 3. Filtra los más relevantes y decide, para cada uno, llamar a una nueva herramienta que extrae datos públicos básicos (tamaño, principales productos, presencia en el mercado).

Paso 4, ejecución en paralelo: como los tres competidores son independientes entre sí, el orquestador lanza las tres llamadas de extracción al mismo tiempo, en lugar de una tras otra, ahorrando tiempo total.

Paso 5, síntesis: con los tres conjuntos de datos en la memoria a corto plazo, el LLM genera el texto del resumen comparativo, ya formateado.

Paso 6, última herramienta: el agente llama a la herramienta de envío de correo electrónico, pasando el resumen generado como cuerpo del mensaje.

Paso 7, conclusión: el LLM observa la confirmación de envío, verifica que todos los elementos del plan inicial se han cumplido y finaliza el ciclo, respondiendo al usuario que la tarea se ha completado.

Observa que, en ningún momento, el usuario ha necesitado intervenir entre un paso y otro. Esto solo es posible porque cada una de las seis piezas (LLM, memoria, planificación, herramientas, ejecución, bucle de retroalimentación) ha realizado exactamente el papel descrito en las secciones anteriores.

FAQ

¿Un agente de IA siempre necesita memoria a largo plazo?

No. Las tareas simples, resueltas en una sola sesión, pueden funcionar solo con memoria a corto plazo (el historial de la ejecución actual). La memoria a largo plazo importa cuando el agente necesita recordar algo entre diferentes ejecuciones.

¿Cuántas iteraciones suele hacer un agente antes de detenerse?

Varía mucho según la complejidad de la tarea y la configuración del framework utilizado, pero la mayoría de los sistemas de producción definen un límite explícito, generalmente entre 5 y 25 iteraciones, para evitar bucles infinitos.

¿Un chatbot con plugins ya es un agente?

Depende de cuánta autonomía tenga. Si el usuario necesita pedir explícitamente cada acción, es más un chatbot con herramientas. Si el sistema decide por sí mismo la secuencia de acciones necesarias para cumplir un objetivo, eso ya es comportamiento de agente.

¿Qué ocurre si una herramienta falla en medio de la ejecución?

Depende del orquestador. Las implementaciones robustas devuelven el error como parte de la observación, y el LLM decide si lo intenta de nuevo, intenta un enfoque diferente o informa del fallo al usuario, en lugar de bloquear todo el ciclo.

¿Es posible que un agente utilice más de un LLM al mismo tiempo?

Sí, y es cada vez más común. Un modelo más pequeño y barato puede encargarse de decisiones simples de enrutamiento, mientras que un modelo más grande entra solo en los pasos que requieren un razonamiento más profundo, lo que ayuda a controlar el coste total de la ejecución sin perder calidad en las partes que más importan.

Dejando a un lado la jerga, un agente de IA no es una tecnología nueva aislada, sino una forma específica de organizar piezas ya conocidas (un modelo de lenguaje, algún tipo de memoria, acceso a herramientas) en un ciclo que se repite hasta que se cumple un objetivo. Entender estas seis piezas por separado es lo que permite diagnosticar por qué un agente específico falla, se queda en un bucle o entrega un resultado incompleto, en lugar de tratar todo el sistema como una caja negra.