Por qué los agentes de IA fallan en producción: Explicación de la ingeniería de arneses

Imagínese a un desarrollador a las 2 a.m. que ha pasado tres semanas reescribiendo instrucciones, probando el modelo más reciente y ajustando los tamaños de los fragmentos de datos RAG. En un entorno de pruebas, el agente funciona de maravilla. Pero en producción falla estrepitosamente: olvida una decisión tomada dos pasos antes, anuncia éxito justo antes de entregar algo defectuoso, y su tasa de éxito en las tareas se mantiene en el 68% sin importar qué modelo se utilice. Superar el 70% parece imposible.

Muchos equipos reconocen esa situación. El diagnóstico habitual es que el modelo no es lo suficientemente bueno. El diagnóstico más acertado es que el problema radica en el sistema construido alrededor del modelo, y hasta que eso se acepte, ningún cambio de modelo supondrá gran diferencia.

Tres etapas para trabajar con LLMs

El pensamiento sobre las aplicaciones de LLMs ha pasado por tres etapas, y muchos equipos siguen estancados en una o dos de ellas al enfrentarse a los problemas de la tercera etapa.

Etapa uno: ingeniería de prompts

Todos comienzan aquí, preguntándose si el modelo entendió la solicitud. Los LLM son extremadamente sensibles a la forma en que se les dirige. Un rol bien elegido, algunos ejemplos y un formato de salida claro pueden transformar los resultados; además, para tareas simples de un solo turno, una buena formulación del prompt es indispensable.

No obstante, también existe un límite. Por más elegantes que estén redactadas las instrucciones, no pueden proporcionar al modelo los datos que le faltan, hacer que recuerde lo sucedido tres llamadas previas a herramientas ni impedir que invente datos cuando la realidad es decepcionante. La trampa común es creer que un prompt más elaborado puede sustituir a una base de conocimientos insuficiente o al contexto actual. Eso no es posible.

Etapa dos: ingeniería de contexto

La siguiente pregunta es si el modelo cuenta con los datos necesarios. Los equipos incorporan pipelines RAG, recuperación dinámica, resultados de herramientas que se reintegran y un historial de conversaciones introducido con cuidado, y comienzan a prestar atención a lo que el modelo puede ver al tomar decisiones. Este es un verdadero avance, ya que los agentes se vuelven notablemente más inteligentes cuando la información adecuada llega en el momento oportuno.

Lo que el trabajo de contexto no soluciona es la desviación en la ejecución. El agente elabora un plan excelente, lleva a cabo correctamente el primer paso, interpreta mal el valor de retorno de una herramienta en el segundo paso y se desvía del rumbo durante otros doce pasos. Nada en el sistema se da cuenta. Sigue ejecutando un plan que ya se volvió incorrecto hace tiempo.

Un error frecuente aquí es tratar la ingeniería de contexto como si fuera lo mismo que el RAG en bases de datos vectoriales. La gestión real del contexto también incluye inyectar estado dinámicamente, resumir las respuestas de las herramientas y truncar intencionadamente el historial. El RAG es solo el comienzo.

Etapa tres: la ingeniería de control

La pregunta ahora es si el modelo puede seguir funcionando correctamente con el tiempo, y la respuesta resulta algo humillante para quienes esperaban que un modelo mejor lo lograra. La ingeniería de control consiste en construir un marco alrededor del modelo: sistemas deterministas que vigilan sus acciones, detectan sus errores, imponen límites y lo devuelven al camino correcto cuando se desvía. La palabra proviene de las riendas y los arneses de seguridad, equipos utilizados para el control.

Un modelo mental: el agente es igual a modelo más ingeniería de control

Una forma de verlo, popularizada por LangChain, es sencilla: un agente es un modelo más un conjunto de herramientas auxiliares. Casi todo en un código que permite que un agente funcione en producción, aparte de la llamada a la API del modelo base, forma parte de ese conjunto de herramientas.

Imagínese enviar a un colega junior a dirigir una reunión importante con un cliente.

• Los prompts son la agenda: saludar, presentar el producto y preguntar por los requisitos.
• El contexto es la información de fondo: el historial del cliente, la lista de precios y los objetivos de la reunión.
• Las herramientas auxiliares son todo lo demás: la lista de verificación que llevan, una revisión contigo a mitad de camino, una transcripción grabada, una forma de corregirlos si se desvían y los criterios de aceptación para el informe de la reunión.

Una mejor información inicial no puede compensar la falta de una estructura de rendición de cuentas. Las dos primeras etapas ayudan a que un modelo piense mejor, y el mecanismo de soporte hace que actúe de manera fiable. El relato de un equipo, que es una anécdota y no un punto de referencia, indica que reestructurar la descomposición de tareas, el manejo de estados, la validación de pasos críticos y la recuperación ante fallos permitió que el mismo modelo, con las mismas instrucciones, pasara de un 70% a más del 95% de éxito en las tareas.

Seis capas de un mecanismo de soporte maduro

Un mecanismo de soporte no es un solo archivo ni una envoltura ingeniosa. Está compuesto por capas, y cada capa aborda un tipo diferente de fallo.

Capa 1: límites de información

Lo que el modelo ve en su contexto inmediato influye en su rendimiento más que casi cualquier otra cosa. Los datos adicionales no lo hacen más inteligente, sino que lo hacen perder el enfoque. Mezclar reglas del sistema, estado de la tarea actual y evidencias externas en un conjunto no estructurado es aún peor, ya que el modelo comienza a descuidar las restricciones y las reglas críticas se convierten en ruido de fondo. El sistema de gestión debe decidir y etiquetar explícitamente qué recibe el modelo: su rol, objetivo actual, criterios de éxito y una separación clara entre los tipos de información.

Nivel 2: el sistema de herramientas

Sin herramientas, un LLM solo puede predecir texto. Con un buen sistema de herramientas, puede actuar en el mundo real. Un error común al principio es proporcionarle demasiadas herramientas. Quince herramientas bien documentadas suenan poderosas, pero la atención se dispersa y el modelo comienza a inventar parámetros que no existen o a usar mal APIs que apenas comprende.

El marco de trabajo debe determinar cuándo se utilizan las herramientas, no solo cuáles existen. Debe impedir que el modelo adivine cuándo debe buscar y que busque cuando ya lo sabe. Y una regla no tiene excepciones: no envíe directamente la salida bruta de las herramientas al LLM. Una respuesta JSON con 50 elementos proveniente de una API envenena el contexto. Filtre, analice y resuma los resultados antes de que el modelo los vea.

Nivel 3: orquestación de ejecución

A menudo, los modelos fallan no por falta de habilidades individuales sino porque no pueden concatenarlas en el orden correcto. Funcionan como un flujo de conciencia, saltando entre pasos, omitiendo verificaciones y generando salida antes de tener lo necesario. El marco de trabajo establece límites claros: entender el objetivo, evaluar qué información se tiene, obtener lo que falta, analizar, generar, verificar y luego emitir la salida.

Eso transforma la gestión de proyectos de un modelo probabilístico a un sistema determinista. El modelo no debería decidir el orden de los trabajos, y esa estructura pertenece al mecanismo de control.

Capa 4: memoria y estado

Un agente sin estado padece amnesia en cada turno, como si cada paso de un trabajo de varias etapas fuera una nueva conversación. Un enfoque viable mantiene estrictamente separados tres tipos de memoria:

1. El estado actual de la tarea, es decir, qué paso está activo, qué está pendiente y qué ya se ha confirmado.
2. Conclusiones intermedias de esta sesión.
3. Memoria a largo plazo y perfiles de usuario, como preferencias y contexto que persisten entre sesiones.

El error más perjudicial es combinar el estado de la tarea con el historial de conversaciones. Esto genera una ventana de contexto cada vez más grande e indefinida que empeora el rendimiento del modelo a medida que avanza la tarea.

Capa 5: evaluación y observabilidad

Los agentes primitivos colapsan aquí. Generan resultados, anuncian el éxito pero no tienen forma de saber si es correcto. Un agente que evalúa su propio trabajo tiene un sesgo optimista inherente: considera código defectuoso como funcional y califica una respuesta como satisfactoria cuando en realidad nunca respondió a la pregunta.

El sistema necesita verificaciones automatizadas e independientes. La revisión humana posterior es demasiado lenta y no es escalable. Esta capa se encarga de la validación automática de los resultados, los entornos de prueba, el registro detallado, las métricas y la atribución de errores. El sistema debe seguir demostrando que sus acciones son correctas y nunca asumirlo simplemente.

Capa 6: restricciones, validación y recuperación

El fallo es el estado normal en producción. Las APIs se agotan, el JSON se daña y los resultados de búsqueda son incorrectos. Un agente sin mecanismo de recuperación necesita que un humano reinicie todo después de cada error. Se necesitan tres elementos:

• Restricciones: reglas codificadas de forma fija que indican qué acciones el agente nunca debe realizar.
• Validación: verificaciones previas y posteriores a la generación de salida, como la validación del esquema, comprobaciones de formato y verificación de las restricciones.
• Recuperación: intentos repetidos, rutas de respaldo y retorno al último estado estable conocido.

Ansiedad por el contexto

En tareas que involucran decenas de pasos, surge un fenómeno extraño al que los investigadores de Anthropic han dado un nombre: ansiedad por el contexto. A medida que la ventana de contexto se acerca a su límite, los modelos pierden detalles importantes, dejan de lado los objetivos principales y parecen apresurarse para terminar. Inventan conclusiones a las que nunca llegaron y omiten la verificación, actuando con tanta prisa que terminan siendo descuidados.

La solución obvia es la compresión: resumir el historial, insertar ese resumen y continuar. Esto reduce la cantidad de tokens, pero no restablece el estado cognitivo del modelo ni la dilución de atención. Lo que funciona es algo más drástico: reiniciar completamente al agente. Cuando el contexto se vuelve demasiado grande, el resumen comprimido se envía a una instancia completamente nueva del agente, con un contexto limpio y sin ninguna confusión acumulada. Es como solucionar una fuga de memoria reiniciando el proceso en lugar de recurrir a una recolección de basura desesperada. La etiqueta utilizada para este enfoque es “context reflect”.

La exposición de herramientas se beneficia de una idea similar llamada divulgación progresiva. En lugar de cargar toda la biblioteca de herramientas al inicio, el modelo solo ve elementos mínimos. Cuando indica que necesita una capacidad específica, el sistema inserta entonces la documentación detallada y el esquema de parámetros. Optimizar el contexto no consiste en darle más al modelo, sino en proporcionarle el material adecuado bajo demanda, justo en el momento en que lo necesita.

Separación de la generación de la evaluación

Una de las ideas más útiles proviene de cómo Anthropic crea agentes autónomos que producen productos funcionales completos durante horas sin revisión humana. La base es una división estricta en tres partes:

• El planificador convierte las solicitudes generales de los usuarios en especificaciones técnicas precisas.
• El generador toma esas especificaciones y las lleva a cabo paso a paso.

El evaluador actúa como un rol independiente de control de calidad, funcionalmente separado del generador.

Un evaluador no se limita a leer el código del generador. Interactúa con el resultado. En el caso de trabajos de interfaz de usuario, navega por ella, examina el diseño y prueba los estados interactivos. Verifica contra el mundo real y no contra la descripción que da el generador del mundo real.

OpenAI fue aún más allá. Una vez que los agentes comenzaron a escribir código más rápido de lo que los humanos podían revisar las solicitudes de integración, les proporcionaron un pipeline CI/CD automatizado propio. El agente ejecuta su trabajo dentro de entornos aislados, toma capturas de pantalla mediante navegadores sin interfaz, examina sus propios registros y sigue repitiendo el proceso hasta que la implementación es exitosa, todo sin que nadie lo supervise. “Listo” ya no significa simplemente que se generó texto; significa que el código se ejecutó, se revisaron los registros, se encontró y corrigió un error, y se verificó la implementación en el entorno aislado.

Donde realmente está el límite

La inteligencia de un modelo base establece el límite teórico en una tabla de clasificación de pruebas. La calidad con la que está diseñado el marco que lo utiliza determina si dicha inteligencia puede sobrevivir, recuperarse y generar valor en condiciones reales complejas. Más allá de un cierto nivel, el modelo deja de ser el cuello de botella. La diferencia entre una tasa de éxito del 70 % y una del 95 %, que también corresponde a la distancia entre una demostración y un producto, radica en el marco utilizado.