Cada pocos días alguien anuncia en redes "el agente de IA que hace X solo". Lo pruebo. Y en la mayoría de los casos es un LLM con acceso a dos o tres herramientas, una sola pasada, sin capacidad real de corregirse si algo sale mal. Eso no es un agente. Es un script con un modelo de lenguaje metido en medio.
No es solo cuestión de vocabulario. La diferencia importa porque determina si puedes confiar en el sistema para algo que tenga varios pasos y algún punto de fallo. Y casi todo lo que hoy se etiqueta como "agente" no aguanta esa prueba.
Qué vendemos cuando decimos "agente"
En marketing, "agente" se ha convertido en sinónimo de "LLM con function calling". Le das acceso a una API, a una base de datos, a un buscador, y ya está: es un agente. Pero eso describe la capacidad de usar herramientas, no la capacidad de actuar con autonomía.
Un termostato programado también "actúa" sobre el mundo. Nadie lo llama agente. Lo que hace agente a un sistema no es que ejecute una acción, es que decida qué acción tomar en función de lo que observa, y que pueda cambiar de plan cuando el resultado no es el esperado.
El bucle que falta
La arquitectura clásica de un agente tiene cuatro fases que se repiten: percibe el estado, planifica un paso, actúa, observa el resultado. Y vuelta a empezar con esa nueva información.
Lo que veo en la mayoría de las implementaciones reales es una versión recortada: percibe, planifica, actúa. Punto. El resultado de la acción se muestra al usuario o se guarda en un log, pero el sistema no lo usa para decidir el siguiente paso porque no hay siguiente paso: la tarea se consideró terminada en cuanto se llamó a la herramienta.
Eso funciona razonablemente bien cuando la tarea es de un solo paso: busca esto y resúmelo, manda este email. Se rompe en cuanto la tarea tiene dependencias: el paso 3 necesita que el paso 1 haya funcionado de una forma concreta, y si no fue así, hay que replanificar, no seguir a ciegas.
Tres señales de que no es un agente, es un script con LLM
Uso estas tres preguntas cuando alguien me enseña su "agente":
- ¿Mantiene estado más allá del historial de mensajes? Si toda la "memoria" del sistema es el contexto de la conversación, no hay estado real del mundo, solo un resumen de lo que se ha dicho.
- ¿Verifica el efecto de sus acciones antes de continuar? Llamar a una herramienta y asumir que funcionó no es lo mismo que comprobar que funcionó. Esa diferencia es, literalmente, la diferencia entre un agente y un disparo a ciegas.
- ¿Puede replanificar si algo falla? Si la única respuesta a un error es reintentar el mismo paso, o directamente pararse, no hay planificación adaptativa. Hay un script con reintentos.
Si la respuesta a las tres es "no", lo que tienes es una cadena de prompts con esteroides. Probablemente útil. Pero no un agente en el sentido que se usa en la literatura de sistemas autónomos desde hace décadas, mucho antes de que existieran los LLM.
Dónde sí estoy viendo agentes de verdad
Los ejemplos más honestos que conozco vienen del terreno del código, y no por casualidad: el código da una señal de verificación barata y objetiva. Un test pasa o no pasa. Un build compila o no compila.
Los agentes de codificación que sí cierran el bucle completo hacen algo así: proponen un cambio, lo aplican, ejecutan los tests, leen el resultado, y si algo falla, ajustan el plan con esa información nueva, no simplemente repiten la misma acción. Ese último paso, usar el fallo como entrada para replanificar en vez de como una excepción que hay que reportar y punto, es el que marca la diferencia.
Fuera del código cuesta más, porque casi ninguna tarea del mundo real da una señal de éxito o fracaso tan limpia como "los tests pasan". Reservar una cita, escribir un email de ventas, investigar un tema: ahí "verificar el resultado" es mucho más ambiguo, y por eso la mayoría de los "agentes" en esos dominios se quedan en percibe-planifica-actúa sin cerrar el bucle.
La pregunta que hago antes de llamarlo "agente"
Cuando evalúo si algo merece el nombre, hago una pregunta muy simple: ¿qué pasa si el primer paso falla?
Si la respuesta es "el sistema se da cuenta, entiende por qué, y decide un plan distinto", estás ante algo con autonomía real. Si la respuesta es "se detiene", "avisa a un humano" o "reintenta lo mismo hasta agotar los intentos", tienes una automatización con LLM. Que puede ser exactamente lo que necesitas, no todo tiene que ser un agente completo, pero no es lo mismo, y llamarlo agente genera expectativas que luego no se cumplen.
No es un problema de que la tecnología no esté ahí. Está ahí, al menos para tareas con señales de verificación claras. El problema es que "agente" se ha convertido en la palabra que se pone en el título para vender, no en la descripción técnica de una arquitectura concreta. Y esa confusión sale cara cuando alguien construye un sistema crítico asumiendo una capacidad de autocorrección que en realidad no existe.
Relacionado: Automatizar tareas sin perder el control del resultado