La mayoría de los equipos de IA que buscan mejorar el rendimiento de sus agentes recurren a las mismas palancas: ventanas de contexto más grandes, más documentos y prompts más inteligentes. Este artículo sostiene que ese instinto es completamente equivocado. El ingrediente faltante no es más información. Es el control. Una capa de control bien diseñada distingue a un agente que funciona en una demostración de uno que funciona en producción.
Dar a un agente de IA más memoria, más documentos o una ventana de contexto más larga no lo hace más inteligente, sino más lento y costoso. Las mejoras reales surgen al enseñar al agente a elegir qué necesita y cuándo, en lugar de consumirlo todo a la vez.
La confiabilidad proviene del ciclo, no del modelo. La diferencia entre un agente que impresiona en una demostración y uno que resiste en producción no es la calidad de la IA, sino si el sistema comprueba su propio trabajo. Los agentes que planifican, actúan, observan y verifican cada paso detectan sus propios errores en lugar de equivocarse con total seguridad.
Hoy, la mayoría de los agentes de IA son, en esencia, chatbots con pasos adicionales: carecen de mecanismos para saber si van por buen camino, cuándo detenerse o cuándo probar otro enfoque. Agregar una capa de control adecuada —criterios de éxito claros, un estado estructurado y comprobaciones de validación— convierte un objeto con apariencia de agente en algo realmente confiable.
¿Qué almorzaste ayer?
Probablemente no repasaste cada recuerdo de tu vida hasta encontrar “ayer + almuerzo”. Fuiste directamente a la parte de tu experiencia donde se encuentran esos conceptos. Ese es un modelo mental útil para crear agentes:
Una ventana de contexto gigantesca no es memoria.
Una pila de documentos recuperados no equivale a comprensión.
Una cadena de pensamiento larga no equivale a confiabilidad.
Esos son ingredientes. Pero lo que hace que un agente parezca un agente es lo mismo que evita que tu cerebro repase por fuerza bruta toda tu vida: el control.
Un estudio reciente, Razonamiento agéntico para modelos de lenguaje grandes, resumió (y dio nombre) magistralmente al cambio que muchos percibimos al desarrollar: pasar del razonamiento dentro del modelo al razonamiento mediante la interacción. Esta publicación no resume ese artículo. Intenta traducir ese cambio en un diseño práctico de sistemas:
Si creas agentes como si fueran chatbots con herramientas, seguirás teniendo los modos de falla de los chatbots, pero con errores más costosos.
Durante un tiempo, nuestra estrategia predeterminada para “hacer más inteligente el modelo” fue, en esencia, usar mejores prompts, cadena de pensamiento, autoconsistencia o mejoras basadas en muestreo y, quizá, algo de búsqueda.
ReAct marcó un punto de inflexión porque hizo que “pensamiento → acción → observación” pareciera natural. Pero observa la restricción implícita: gran parte de esto sigue siendo “inferencia con un ejemplo, pero con más tokens”. El enfoque del estudio es más preciso: el razonamiento agéntico enfatiza escalar la interacción durante las pruebas, lo que convierte la inferencia en un proceso iterativo donde el modelo, la memoria y el entorno permanecen dentro del ciclo.
Si has creado o usado agentes que impresionan en demostraciones, pero son frágiles en flujos de trabajo reales, esto es para ti.
Permíteme describir un patrón que he visto a menudo (y del que sin duda yo también he creado versiones):
Tomar un buen modelo de chat
Agregar algunas herramientas (búsqueda, consultas a bases de datos y quizá ejecución de código)
Agregar RAG
Agregar un prompt del sistema que diga “eres un agente autónomo”
Envolver todo en un ciclo while hasta que se detenga o se agote el tiempo
Felicidades, tienes un objeto con apariencia de agente. Pero suele fallar de maneras predecibles:
Contexto inflado: se agrega cada observación y los prompts se convierten en capas arqueológicas.
Uso errático de herramientas: “usar con seguridad la herramienta equivocada” se convierte en el modo de falla predeterminado.
Sin condiciones de parada: continúa porque puede, no porque deba.
Sin disciplina de anclaje: no detecta que está equivocado a menos que lo obligues.
Memoria = historial del chat: lo que básicamente equivale a escribir registros y llamarlo aprendizaje.
Por eso los “agentes” suelen parecer mágicos en las demostraciones y caóticos en producción. Nuestra experiencia al implementar sistemas agénticos en producción también lo demuestra: cuando ya no evalúas un modelo, sino un sistema, los modos de falla incluyen la navegación, el uso correcto de herramientas, la depuración del contexto y el diseño de evaluaciones, no solo si “el modelo respondió correctamente”.
Entonces, la pregunta es: ¿cómo debería ser el agente?
Para hacerlo menos abstracto, veamos un flujo de trabajo sencillo que casi todos pueden imaginar: “Resérvame un vuelo de Londres a Nueva York para el próximo martes. Que llegue antes de las 6 p. m. Que cueste menos de £900. Asiento de pasillo”.
Una implementación común con apariencia de agente funciona así:
Recupera de inmediato numerosos documentos de aerolíneas y políticas de viaje, aunque todavía no sean necesarios.
Llama a una herramienta de búsqueda, pega una larga lista de resultados en el prompt y “elige uno”.
Reserva antes de tiempo sin verificar las restricciones de llegada, equipaje, asiento o políticas.
Si falla, vuelve a intentarlo de una manera un poco distinta, pero sin tener claro qué cambió ni qué aprendió.
El modo de falla no se debe a que el modelo no pueda razonar, sino a que el sistema no controla el flujo de trabajo.
Una versión más agéntica trata la tarea como un proceso interactivo con estados y comprobaciones explícitos:
PLANIFICAR: reformular las restricciones y enumerar la información faltante (p. ej., “¿qué aeropuerto prefieres?” o “¿aceptas una escala?”).
ACTUAR: llamar al buscador de vuelos con una consulta estructurada (intervalo de fechas, restricción de llegada y presupuesto).
OBSERVAR: guardar los resultados en un objeto de estado compacto (los 5 mejores candidatos con precio, llegada y escalas), no como un enorme bloque de texto pegado.
ACTUALIZAR: refinar la consulta si no se cumplen las restricciones (p. ej., “llegar antes de las 6 p. m. es demasiado restrictivo; ¿ampliamos el horario o aumentamos el presupuesto?”).
VERIFICAR: ejecutar validadores (“llegada < 18:00”, “precio ≤ £900”, “cumple las políticas” y “selección de asiento disponible”).
DETENERSE: solo cuando la API de reservas devuelva una confirmación y se aprueben todos los validadores.
El cambio es sutil, pero decisivo. La recuperación es condicional, no un reflejo; el contexto se administra, pues el estado se estructura en lugar de acumularse; y la verificación forma parte del ciclo, en vez de quedar en manos del usuario. Cambia “reservar un vuelo” por “crear una orden de compra”, “emitir un reembolso”, “cambiar una configuración de producción” o “publicar una PR”, y la conclusión será la misma: cuando el agente puede actuar, el ciclo importa más que el prompt.
El estudio mencionado organiza el razonamiento agéntico en tres capas: fundamental (planificación, uso de herramientas y búsqueda), autoevolutiva (retroalimentación y memoria) y colectiva (coordinación multiagente).
Pero la idea de fondo es que el razonamiento se convierte en el principio organizador de la planificación, la toma de decisiones y la verificación, en vez de limitarse a generar una cadena de pensamiento plausible. Esto suena abstracto hasta que lo relacionas con los cambios en tu arquitectura. Hay tres puntos esenciales que debes recordar:
Un buen agente no debería tratar la recuperación como algo que “siempre debe hacer”. Recuperar información es una decisión, no un reflejo.
Esta es una heurística práctica:
Si tu sistema recupera información en cada turno, no creaste un sistema de recuperación: creaste un impuesto al contexto.
Esto se observa constantemente en el trabajo real. Al depurar un incidente en producción, no vuelcas todos los registros en el contexto; decides qué métricas o registros recuperar a continuación según tu hipótesis actual. Eso es la “recuperación agéntica”. Este es un patrón más concreto:
Decidir si necesitas recuperar información
Si es así: redactar una consulta, recuperar, revisar y extraer
Si la evidencia se contradice: recuperar de nuevo
Solo entonces, sintetizar
Aquí también es donde el “RAG agéntico” comienza a diferenciarse del RAG tradicional: la recuperación se convierte en un paso deliberado del razonamiento, no en una etapa predeterminada del flujo.
En cuanto dejas de evaluar “un modelo” y comienzas a evaluar “un sistema”, el seguimiento y el rastreo del estado cobran importancia.
A estas alturas, la industria ya reconoce más explícitamente la importancia de la observabilidad en los flujos de trabajo de agentes. Por ejemplo, el SDK de Agentes de OpenAI incluye rastreo integrado y un panel de Trazas que registra las ejecuciones de los agentes (generaciones, llamadas a herramientas, transferencias, barreras de seguridad y eventos personalizados), específicamente para que puedas depurar y auditar paso a paso lo ocurrido.
No es algo “deseable”. Es la diferencia entre un sistema que puedes depurar y otro que solo puedes evaluar por intuición.
En mi opinión, la parte más práctica del estudio es la franqueza con la que aborda la retroalimentación. Divide la retroalimentación en tres modalidades: reflexiva (generar → evaluar → revisar), adaptación paramétrica (aprender mediante ajuste fino o RL) y retroalimentación basada en validadores (reintentar hasta que se apruebe una validación).
La mayoría de los equipos debería comenzar con la retroalimentación basada en validadores porque es rutinaria y eficaz. Si puedes crear cualquier validador que ejecute pruebas unitarias, compruebe el esquema, establezca reglas o restricciones empresariales (“no hacer reembolsos superiores a X sin escalar el caso”) o verifique los hechos (“se requieren citas”), podrás convertir la salida no determinista del modelo en algo realmente confiable.
Uno de los cambios que no sabíamos que desconocíamos es sencillo: en el mundo de los agentes, la confiabilidad suele depender más del ciclo que del modelo.
Esta es la disciplina de ciclo más sencilla que he encontrado para mejorar el comportamiento de forma confiable y sin entrenamiento:
Trabaja por pasos: planificar → actuar → observar → actualizar.
Después de cada acción, resume la observación en 1 a 3 viñetas.
Detente cuando se cumplan los criterios de éxito o se agote el presupuesto; devuelve el mejor resultado conocido y las incertidumbres restantes.
No se trata de hacer que el modelo sea verboso. Se trata de hacer comprensible el sistema y obligarlo a “confrontar la realidad” en cada paso. Un ejemplo muy cercano para quienes trabajan en ingeniería es el anclaje de ciclo cerrado al estilo de la integración continua:
Planificar: proponer una lista de cambios
Actuar: ejecutar pruebas y linting
Observar: analizar los errores
Actualizar: corregir y reintentar
Estas preguntas suelen revelar diseños de agentes accidentales:
“¿Mi agente decide qué recuperar o siempre recupero información?”.
Si la recuperación es incondicional, pagarás el precio en latencia, costo, dilución del contexto y mayor riesgo de que información basura produzca resultados basura.
“¿Puede mi agente darse cuenta de que está equivocado?”.
Si la única señal de retroalimentación de tu agente es que “el usuario se molesta”, estás haciendo RL a costa del sufrimiento humano. Un ciclo de reintentos basado en validadores es la forma más clara de confrontarlo con la realidad.
“¿Se puede escribir en la memoria y mejora con el tiempo?”.
Si tu “memoria” solo agrega el historial del chat, básicamente estás escribiendo registros. El enfoque del estudio sobre la memoria es importante: esta se convierte en un contexto que crece dinámicamente y que los agentes perfeccionan con el tiempo, no en una simple transcripción.
Los registros indican qué ocurrió; la memoria indica qué hacer la próxima vez. El historial del chat es una transcripción. La memoria es una política en evolución sobre lo que vale la pena conservar.
Un punto de partida práctico es una pequeña tabla de “lecciones aprendidas”, organizada con una clave que incluya el tipo de tarea, la herramienta y el modo de falla, y un valor que indique qué funcionó y qué evitar. El objetivo no es crear un grafo de conocimiento perfecto. El objetivo es generar una mejora acumulativa: la memoria y la retroalimentación convierten a los agentes, de “asistentes sin estado”, en sistemas que mejoran con el tiempo.
La tentación es lanzar más agentes al problema, pero esto suele multiplicar la sobrecarga de coordinación. Un buen patrón de “equipo mínimo viable”:
Coordinador: descompone y asigna
Ejecutor: realiza llamadas a herramientas y aplica cambios
Crítico/evaluador: comprueba la corrección y el riesgo
Gestor de memoria: registra y depura las lecciones
Si no puedes explicar de qué se encarga cada agente, probablemente aún no necesites varios.
Si realmente aceptamos el cambio de paradigma, probablemente dejemos de meterlo todo en los prompts, tratar las fallas como resultados finales y evaluar a los agentes como si fueran chatbots. Y comenzaremos a tratar a los agentes como lo que son: sistemas de software donde el lenguaje es el plano de control y la confiabilidad proviene del ciclo.
Antes de agregar otro modelo, agrega otro ciclo de evaluación. Antes de recuperar todo, haz que la recuperación sea condicional. Implementa un validador antes de implementar diez. Trata la memoria como decisiones de política, no como una base de datos. Y al adoptar un sistema multiagente, comienza con dos agentes, no con veinte. No son reglas, sino los patrones que superaron la prueba de producción.