El término agente de IA se ha convertido en uno de los más repetidos —y menos entendidos— del último año. Se habla de agentes que "razonan", que "deciden" o que "actúan de forma autónoma", pero pocas veces se explica qué hay realmente detrás de esa palabra. En JULDITEC llevamos meses implementando agentes en proyectos reales de automatización con n8n e integraciones con Liferay DXP, y hemos aprendido que entender la arquitectura interna de un agente es la diferencia entre construir algo útil y construir un chatbot glorificado que se cae a la primera excepción.
Un agente de IA no es una tecnología única, sino la combinación de cuatro piezas que trabajan juntas: un modelo de lenguaje (LLM), un conjunto de tools u herramientas externas, un loop de razonamiento que decide qué hacer en cada paso, y un agent harness, el andamiaje de software que orquesta todo lo anterior. Vamos a desgranar cada una.
El LLM: el motor de razonamiento, no el agente en sí
El primer error habitual es confundir el LLM (GPT-4, Claude, Llama, Gemini...) con el agente completo. El LLM es, en realidad, solo el cerebro que genera texto y decide qué acción tomar a partir de un contexto dado. Por sí solo, un LLM no puede consultar una base de datos, enviar un correo o navegar por internet. Solo puede predecir la siguiente secuencia de tokens más probable dado un prompt.
Lo que convierte a un LLM en parte de un agente es que se le proporciona un contexto estructurado —instrucciones, historial de conversación, resultados de acciones anteriores— y se le pide que responda no solo con texto libre, sino con una decisión formateada: "llama a esta herramienta con estos parámetros" o "la tarea ha terminado, esta es la respuesta final".
Tools: las manos del agente
Las tools (herramientas) son funciones externas que el agente puede invocar para interactuar con el mundo real: una API de búsqueda, una consulta SQL, un endpoint REST de Liferay, un webhook de n8n, una calculadora, un scraper web, etc. Cada tool se describe al LLM mediante un esquema (normalmente JSON) que indica su nombre, su propósito y los parámetros que acepta.
Este mecanismo se conoce como function calling o tool calling, y es soportado de forma nativa por la mayoría de proveedores de LLM modernos. Un ejemplo simplificado de definición de tool sería:
{
"name": "buscar_cliente_liferay",
"description": "Busca un usuario en Liferay DXP por email",
"parameters": {
"type": "object",
"properties": {
"email": { "type": "string" }
},
"required": ["email"]
}
}Cuando el LLM decide que necesita esa información, no la inventa: genera una llamada estructurada a esa tool, el sistema ejecuta la función real, y el resultado se devuelve al modelo como nuevo contexto. Aquí es donde entra la tercera pieza: el loop.
El loop: pensar, actuar, observar y repetir
Un agente no resuelve una tarea compleja en una sola llamada al LLM. Funciona mediante un loop iterativo, un patrón muy popularizado bajo el nombre ReAct (Reasoning + Acting), que sigue aproximadamente esta secuencia:
- •Thought (pensar): el LLM razona sobre qué necesita hacer a continuación.
- •Action (actuar): el LLM invoca una tool con unos parámetros concretos.
- •Observation (observar): el resultado de la tool se añade al contexto.
- •Repetir hasta que el modelo determine que ya tiene suficiente información para dar una respuesta final.
Un agente de IA es, en esencia, un LLM ejecutado dentro de un bucle con acceso a herramientas y memoria de lo que ha ocurrido en pasos anteriores.
Este loop es lo que da la ilusión de "autonomía": el agente puede encadenar 3, 5 o 15 pasos sin intervención humana, corrigiendo el rumbo si una tool falla o si el resultado no es el esperado. Pero sin límites bien definidos —número máximo de iteraciones, timeouts, validaciones—, un loop mal diseñado puede entrar en bucles infinitos o gastar tokens de forma descontrolada.
El agent harness: el andamiaje que lo sostiene todo
Aquí llegamos a la pieza menos conocida pero más crítica: el agent harness (literalmente, el "arnés" del agente). Es la capa de software que gestiona el loop, mantiene el estado, formatea el contexto que se envía al LLM, ejecuta las tools, gestiona errores y decide cuándo detener la ejecución. Sin un harness robusto, ni el mejor LLM del mercado se comporta como un agente fiable.
Frameworks y plataformas para construir el harness
Existen varias formas de implementar este andamiaje, cada una con un nivel distinto de control y complejidad:
- •LangChain / LangGraph: frameworks en Python/JS que ofrecen abstracciones para loops de agentes, gestión de memoria y grafos de estados complejos.
- •AutoGPT / frameworks autónomos: orientados a tareas de larga duración con mínima supervisión humana.
- •n8n: nuestra herramienta de cabecera en JULDITEC para construir agentes de forma visual, combinando nodos de LLM, nodos HTTP como tools, y lógica condicional que actúa como el loop de decisión, todo integrado con sistemas empresariales como Liferay DXP, CRMs o ERPs.
- •Implementaciones custom: para casos donde se necesita control total sobre el prompt, el formato de las tools y las políticas de seguridad, especialmente en entornos corporativos con datos sensibles.
En proyectos con clientes que ya usan Liferay DXP como portal corporativo, el harness suele encargarse de exponer las tools como llamadas a la API REST/GraphQL de Liferay, permitiendo que el agente consulte contenidos, gestione usuarios o dispare workflows sin que el modelo necesite conocer los detalles de implementación: solo necesita saber que existe una tool llamada "crear_ticket_soporte" y cómo usarla.
Un ejemplo práctico: agente de soporte con n8n
Imaginemos un caso real: un agente que atiende consultas de clientes integradas en un portal Liferay. El flujo, montado como harness en n8n, sería así:
- •El usuario escribe una consulta en un chat embebido en el portal.
- •El nodo LLM de n8n recibe el mensaje junto con el historial de la conversación (contexto).
- •El LLM decide, mediante function calling, si necesita usar la tool "consultar_estado_pedido" o "escalar_a_humano".
- •n8n ejecuta la tool correspondiente (una llamada HTTP a un microservicio o a la API de Liferay).
- •El resultado se devuelve al LLM como observación, y el loop continúa hasta generar una respuesta final coherente para el usuario.
Todo el ciclo pensar-actuar-observar ocurre en segundos, pero es el harness de n8n el que garantiza que el loop no se descontrole, que los errores de las APIs se gestionen con reintentos, y que existan límites claros de iteraciones.
Por qué esta distinción importa para las empresas
Entender estos cuatro componentes —LLM, tools, loop y harness— no es un ejercicio académico. Es la base para diseñar agentes que sean predecibles, auditables y seguros en producción. Un agente mal diseñado puede filtrar datos sensibles a través de tools mal restringidas, entrar en loops costosos, o tomar decisiones sin ningún control humano en el bucle (lo que se conoce como human-in-the-loop, una capa adicional que muchos harnesses empresariales incorporan antes de ejecutar acciones críticas).
En JULDITEC diseñamos cada agente pensando primero en el harness: qué tools se exponen, qué límites tiene el loop, y qué nivel de supervisión humana requiere cada acción, antes incluso de elegir qué LLM utilizar.
Conclusión
Un agente de IA no es magia ni una entidad autónoma con voluntad propia: es un LLM razonando dentro de un loop controlado, con acceso a tools concretas, todo ello sostenido por un agent harness bien diseñado. Comprender esta arquitectura es el primer paso para construir soluciones de IA fiables, ya sea con n8n, LangChain o desarrollos a medida integrados en plataformas como Liferay DXP.