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 totalmente erróneo. El ingrediente que falta no es más información. Es el control. Una capa de control bien diseñada es lo que distingue a un agente que funciona en una demostración de otro 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 caro. Las mejoras reales llegan cuando se enseña al agente a elegir qué necesita y cuándo, en lugar de consumirlo todo a la vez.
La fiabilidad procede del bucle, no del modelo. La diferencia entre un agente que impresiona en una demostración y otro que resiste en producción no es la calidad de la IA, sino que el sistema compruebe 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 básicamente chatbots con pasos adicionales: carecen de mecanismos para saber si van por buen camino, cuándo detenerse o cuándo probar otro enfoque. Añadir una capa de control adecuada —criterios de éxito claros, un estado estructurado y comprobaciones de validación— transforma un objeto con forma de agente en algo realmente fiable.
¿Qué comiste ayer?
Probablemente no repasaste todos tus recuerdos hasta encontrar «ayer + comida». Fuiste directamente a la parte de tu experiencia donde residen esos conceptos. Es un modelo mental útil para crear agentes:
Una ventana de contexto enorme no es memoria.
Un montón de documentos recuperados no equivale a comprensión.
Una larga cadena de pensamiento no equivale a fiabilidad.
Esos son los 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 grandes modelos de lenguaje, resume y da nombre con gran acierto a un cambio que muchos percibimos al desarrollar: del razonamiento dentro del modelo al razonamiento mediante la interacción. Este artículo no es un resumen de ese trabajo. Es un intento de plasmar ese cambio en un diseño práctico de sistemas:
Si construyes agentes como chatbots con herramientas, seguirás sufriendo los fallos propios de los chatbots, pero los errores saldrán más caros.
Durante un tiempo, nuestra estrategia habitual para «hacer más inteligente el modelo» consistía básicamente en mejores prompts, cadena de pensamiento, autoconsistencia o mejoras basadas en muestreo y quizá alguna búsqueda.
ReAct marcó un punto de inflexión porque hizo que «pensamiento → acción → observación» resultara natural. Pero observa la restricción implícita: gran parte de esto sigue siendo «inferencia con un ejemplo, pero con más tokens». El planteamiento del estudio es más preciso: el razonamiento agéntico pone el acento en ampliar la interacción durante la prueba, convirtiendo la inferencia en un proceso iterativo en el que el modelo, la memoria y el entorno permanecen dentro del bucle.
Si has creado o utilizado agentes que impresionan en las demostraciones, pero resultan frágiles en flujos de trabajo reales, esto es para ti.
Voy a describir un patrón que he visto muchas veces y del que, sin duda, también he creado mis propias versiones:
Elegir un buen modelo de chat
Añadir algunas herramientas (búsqueda, consultas a bases de datos y quizá ejecución de código)
Añadir RAG
Añadir un prompt de sistema que diga «eres un agente autónomo»
Envolverlo todo en un bucle while hasta que se detenga o se agote el tiempo
Enhorabuena: ya tienes un objeto con forma de agente. Pero suele fallar de formas previsibles:
Contexto inflado: se añade cada observación y los prompts se convierten en estratos arqueológicos.
Uso errático de herramientas: emplear «la herramienta equivocada, pero con seguridad» se convierte en el fallo habitual.
Sin condiciones de parada: continúa porque puede, no porque deba.
Sin una disciplina de anclaje: no detecta que se equivoca a menos que lo obligues.
Memoria = historial del chat: básicamente, 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 poner sistemas agénticos en producción también lo demuestra: cuando dejas de evaluar un modelo y pasas a evaluar un sistema, los modos de fallo 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».
Así que la pregunta pasa a ser: ¿cómo es el agente concebido como tal?
Para que resulte menos abstracto, veamos un flujo de trabajo sencillo que casi todo el mundo puede imaginar: «Resérvame un vuelo de Londres a Nueva York para el próximo martes. Que llegue antes de las 18:00. Que cueste menos de 900 £. Asiento de pasillo».
Una implementación habitual con «forma de agente» funciona así:
Recupera de inmediato numerosos documentos sobre aerolíneas y políticas de viaje, aunque todavía no necesite ninguno.
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ítica.
Si falla, vuelve a intentarlo de una forma algo distinta, pero sin tener claro qué ha cambiado ni qué ha aprendido.
El problema no es que el modelo no sepa razonar, sino que el sistema no controla el flujo de trabajo.
Una versión más agéntica trata la tarea como un proceso interactivo con un estado y unas comprobaciones explícitos:
PLANIFICAR: reformular las restricciones y enumerar los datos que faltan (p. ej., «¿qué aeropuerto prefieres?» o «¿aceptas una escala?»).
ACTUAR: consultar el buscador de vuelos con una solicitud estructurada (intervalo de fechas, límite de llegada y presupuesto).
OBSERVAR: guardar los resultados en un objeto de estado compacto (los 5 mejores candidatos con precio, llegada y escalas), no en un enorme bloque de texto pegado.
ACTUALIZAR: ajustar la consulta si no se cumplen las restricciones (p. ej., «llegar antes de las 18:00 es demasiado restrictivo; ¿ampliamos el horario o aumentamos el presupuesto?»).
VERIFICAR: ejecutar validadores («llegada < 18:00», «precio ≤ 900 £», «cumple la política» y «selección de asiento disponible»).
DETENER: solo cuando la API de reservas devuelva una confirmación y se superen todas las validaciones.
El cambio es sutil, pero decisivo. La recuperación es condicional, no un reflejo; el contexto se gestiona, pues el estado se estructura en vez de acumularse; y la verificación forma parte del bucle, en lugar de dejarse al usuario. Sustituye «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 bucle 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 entre varios agentes).
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, no solo de la generación de una cadena de pensamiento plausible. Suena abstracto hasta que lo relacionas con los cambios en tu arquitectura. Hay tres ideas fundamentales que conviene recordar:
Un buen agente no debería considerar la recuperación como algo que «siempre hay que hacer». Recuperar es una decisión, no un reflejo.
Esta es una heurística práctica:
Si tu sistema recupera información en cada turno, no has creado un sistema de recuperación, sino un impuesto sobre el contexto.
Esto ocurre constantemente en el trabajo real. Al depurar un incidente de producción, no vuelcas todos los registros en el contexto, sino que decides qué métricas o registros consultar después según tu hipótesis actual. Eso es «recuperación agéntica». Este es un patrón más concreto:
Decidir si necesitas recuperar información
En caso afirmativo: redactar una consulta, recuperar, revisar y extraer
Si las pruebas se contradicen: volver a recuperar
Solo entonces, sintetizar
Aquí es también donde el «RAG agéntico» empieza a diferenciarse del RAG tradicional: la recuperación se convierte en un paso de razonamiento deliberado, no en una etapa predeterminada de la canalización.
En cuanto dejas de evaluar «un modelo» y empiezas a evaluar «un sistema», el seguimiento y el rastreo del estado cobran importancia.
A estas alturas, el sector ya reconoce de forma más explícita la importancia de la observabilidad en los flujos de trabajo de los agentes. Por ejemplo, el SDK de Agents de OpenAI incluye rastreo integrado y un panel de Traces que registra las ejecuciones de los agentes (generaciones, llamadas a herramientas, transferencias, medidas de protección y eventos personalizados) para poder depurar y auditar paso a paso lo ocurrido.
No es algo que simplemente «está bien tener». Es la diferencia entre un sistema que puedes depurar y otro cuyo funcionamiento solo puedes juzgar por intuición.
En mi opinión, la parte más práctica del estudio es la claridad con la que aborda la retroalimentación. Divide la retroalimentación en tres modalidades: reflexiva (generar → criticar → revisar), adaptación paramétrica (aprender mediante ajuste fino o RL) y retroalimentación basada en validadores (reintentar hasta superar una validación).
La mayoría de los equipos deberían empezar por la retroalimentación basada en validadores porque es poco vistosa, pero eficaz. Si puedes crear cualquier validador que ejecute pruebas unitarias, compruebe el esquema, imponga reglas o restricciones empresariales («no hacer reembolsos superiores a X sin escalarlos») o garantice la veracidad («se exigen citas»), podrás convertir la salida no determinista del modelo en algo realmente fiable.
Uno de esos cambios que ni siquiera sabíamos que desconocíamos es sencillo: en el mundo de los agentes, la fiabilidad suele depender más del bucle que del modelo.
Esta es la disciplina de bucle más sencilla que he encontrado para mejorar el comportamiento de forma fiable y sin entrenamiento:
Trabaja por pasos: planificar → actuar → observar → actualizar.
Después de cada acción, resume la observación en entre 1 y 3 viñetas.
Detente cuando se cumplan los criterios de éxito o se agote el presupuesto; devuelve el mejor resultado conocido y las incertidumbres pendientes.
No se trata de hacer que el modelo sea prolijo. Se trata de hacer comprensible el sistema y obligarlo a «contrastar con la realidad» en cada paso. Un ejemplo muy cercano para cualquier profesional de la ingeniería es el anclaje de bucle cerrado al estilo de la integración continua:
Planificar: proponer una lista de cambios
Actuar: ejecutar pruebas y análisis de código
Observar: analizar los fallos
Actualizar: aplicar correcciones y reintentar
Estas preguntas suelen sacar a la luz diseños de agentes accidentales:
«¿Mi agente decide qué recuperar o lo recupero yo siempre?»
Si la recuperación es incondicional, pagarás el precio en latencia, costes, dilución del contexto y un mayor riesgo de que entren datos basura y salgan resultados basura.
«¿Puede mi agente darse cuenta de que se equivoca?»
Si la única señal de retroalimentación de tu agente es «el usuario se irrita», estás haciendo RL a costa del sufrimiento humano. Un bucle de reintentos basado en validadores es la forma más limpia de obligarlo a contrastar con la realidad.
«¿Se puede escribir en la memoria y mejora esta con el tiempo?»
Si tu «memoria» se limita a añadir el historial del chat, básicamente estás escribiendo registros. La concepción de la memoria en el estudio es importante: se convierte en un contexto que crece dinámicamente y que los agentes perfeccionan con el tiempo, no en una mera transcripción.
Los registros indican qué ocurrió; la memoria, 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 merece la pena conservar.
Un punto de partida práctico es una pequeña tabla de «lecciones aprendidas», organizada por tipo de tarea, herramienta y modo de fallo, que recoja qué funcionó y qué debe evitarse. El objetivo no es crear un grafo de conocimiento perfecto. El objetivo es crear un comportamiento acumulativo: la memoria y la retroalimentación transforman a los agentes, de «ayudantes sin estado» a sistemas que mejoran con el tiempo.
Resulta tentador abordar el problema con más agentes, 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 los riesgos
Responsable de memoria: escribe y selecciona las lecciones
Si no puedes explicar de qué se responsabiliza cada agente, probablemente aún no necesites varios.
Si realmente aceptamos el cambio de paradigma, probablemente dejaremos de meterlo todo en los prompts, de tratar los fallos como resultados definitivos y de evaluar los agentes como si fueran chatbots. Y empezaremos a tratar a los agentes como lo que son: sistemas de software en los que el lenguaje es el plano de control y la fiabilidad procede del bucle.
Antes de añadir otro modelo, añade otro bucle de evaluación. Antes de recuperarlo todo, haz que la recuperación sea condicional. Pon en producción un validador antes que diez. Trata la memoria como decisiones de política, no como una base de datos. Y al adoptar un sistema multiagente, empieza con dos agentes, no con veinte. No son reglas, sino los patrones que han superado la prueba de la producción.