Ingeniería de aprovechamiento de agentes: estado, verificación y control alrededor del modelo
Una visión en tiempo real de los agentes de producción: por qué las instrucciones y el contexto no son suficientes, y cómo el estado duradero, la aplicación de normas, la verificación y la observabilidad cierran esa brecha.
Fuentes: Agent Harness Engineering: The Runtime Architecture Behind Reliable AI Agents
Cuando un modelo potente sigue fallando
Imagínese un agente que cuenta con el mejor modelo del mercado, una instrucción de sistema cuidadosamente ajustada, docenas de herramientas y una ventana de contexto lo suficientemente grande como para albergar todo un conjunto de código. Aún así, puede fracasar en una tarea que cualquier ingeniero competente consideraría rutinaria. Elige la acción correcta pero la ejecuta mal. Encuentra el dato clave y luego lo pierde cuando se reinicia el contexto. Edita diez archivos correctamente, pero introduce una regresión sutil en el undécimo. Pasa una hora depurando un problema que él mismo creó. Incluso podría redactar un informe convincente afirmando que el trabajo está terminado, cuando en realidad no se verificó nada.
La reacción habitual es trabajar en el prompt: otra instrucción, otro ejemplo, más contexto, un ruego para ser cuidadoso. Eso ayuda por un tiempo y luego deja de funcionar. El defecto más profundo radica en el modelo mental, que trata al modelo como el agente y todo lo demás a su alrededor como configuraciones. Esa visión se derrumba en cuanto el agente debe funcionar de forma continua en un entorno real.
Un agente de producción no es simplemente un modelo rodeado de instrucciones. Es un sistema en tiempo de ejecución: mantiene un estado, ejecuta acciones, se comunica con sistemas externos, maneja fallos, recibe retroalimentación y necesita formas de recuperarse, verificar y ser controlado. La disciplina que se desarrolla alrededor de ese sistema en tiempo de ejecución se denomina ingeniería de entornos para agentes. Compárela con el trabajo de creación de instrucciones. La ingeniería de instrucciones se centra en cómo guiar al modelo para que se comporte de cierta manera, mientras que la ingeniería de entornos se enfoca en cómo construir un entorno donde el modelo pueda alcanzar un objetivo de manera fiable. Esto no es una instrucción mejorada; es una abstracción diferente que abarca no solo lo que escribe el modelo, sino también lo que puede hacer el sistema, qué sobrevive a un fallo, qué está permitido y qué se considera completado.
Un entorno en tiempo de ejecución para un modelo probabilístico
La imagen más simple de un agente es un modelo con una instrucción y unas pocas herramientas. Eso es suficiente para comprender una sola inferencia, pero resulta insuficiente para un agente de producción, que es mejor considerado como un entorno en tiempo de ejecución basado en un modelo probabilístico.
El modelo se encarga del razonamiento. El mecanismo de control determina las condiciones bajo las cuales ese razonamiento se convierte en ejecución: qué ve el modelo, a qué puede acceder, qué acciones están permitidas, qué estado persiste y qué evidencia se necesita antes de poder declarar el éxito.
Tomemos un agente de programación cuya instrucción indica inspeccionar primero la arquitectura, ejecutar las pruebas y dejar intactos los componentes no relacionados. Esas líneas solo expresan la intención y no imponen ninguna regla concreta. Un framework puede hacer que ciertos archivos sean modificables y otros no, ejecutar validaciones después de cada cambio, bloquear operaciones prohibidas, guardar el progreso y negarse a cerrar la tarea sin evidencia. Así, la instrucción indica qué debe hacer el agente, mientras que el framework decide qué permitirá el sistema y qué se considerará completado. El modelo aporta la inteligencia, y el framework la convierte en algo operativo.
Tres capas de ingeniería
La ingeniería de agentes ha evolucionado a través de tres niveles cada vez más abstractos: las instrucciones, luego el contexto y finalmente el framework.
La ingeniería de prompts consiste en definir qué debe hacer el modelo. Mejora las instrucciones, los ejemplos, las descripciones de herramientas y los límites de comportamiento, y para tareas simples funciona de manera sorprendentemente eficaz. Pero un prompt es solo una instrucción y no tiene poder para hacerla cumplir. Un agente al que se le pide que ejecute pruebas aún puede afirmar haber tenido éxito sin realizarlas. Decirle que deje los archivos de producción en paz sirve de poco si el entorno de ejecución le brinda acceso ilimitado. Pedirle que recuerde una decisión durante seis horas coloca esa solicitud en conflicto con todo lo demás que llega al contexto.
La ingeniería de contexto aborda el siguiente problema: qué debe saber el modelo en el momento de tomar una decisión. La recuperación de información, las habilidades, la memoria, los resultados de las herramientas, el estado estructurado, la divulgación progresiva y la compactación contribuyen a crear un contexto de decisión más adecuado, y el objetivo pasa de contar con más contexto a disponer de uno mejor. Aun así, el modelo puede elegir una acción incorrecta, dañar el estado, omitir la validación, quedar atascado en un bucle o declarar éxito demasiado pronto.
A partir de ese momento comienza la ingeniería de aprovechamiento, con la pregunta de qué sistema debe rodear al modelo para que la tarea se realice de manera fiable. Este aporta lo que los prompts y el contexto por sí solos no pueden ofrecer: un estado duradero, herramientas con restricciones, permisos, aislamiento, verificación, recuperación, evaluación y capacidad de observabilidad. También modifica el ciclo de ingeniería: un fallo ya no solo requiere reformular el prompt, sino que plantea la pregunta de qué control faltaba, y la respuesta podría ser un validador, un contrato de herramientas más estricto, un límite de política, un punto de control, una estrategia de recuperación o una mejor visibilidad. Cada fallo termina en un cambio en el sistema.
El resultado es una trinqueta para arneses: un fallo, luego la falta de control, después una mejora en el arnés, seguida de verificación y finalmente un punto de referencia más sólido. La ingeniería de prompts mejora lo que se le dice al modelo, mientras que la ingeniería de contexto mejora lo que él sabe. La ingeniería de arneses mejora las condiciones bajo las cuales funciona el modelo y hace que sea cada vez más difícil que falle de la misma manera dos veces.
De qué se encarga el tiempo de ejecución
Si el arnés es el tiempo de ejecución, ¿qué contiene? En lugar de enumerar prompts, herramientas, memoria y código de orquestación, es más útil nombrar las responsabilidades del tiempo de ejecución.
- El contexto determina qué necesita saber el modelo para tomar su próxima decisión: instrucciones, material recuperado, habilidades, resultados de herramientas relevantes y observaciones actuales.
Estos no son siete características independientes, ni necesariamente tienen que ser siete servicios. Juntos forman un bucle de control alrededor de un modelo probabilístico. Una vez que ese bucle funciona durante horas en lugar de minutos, superando los límites del contexto, las fallas, los intentos de reintentar y los cambios en los procesadores, la arquitectura comienza a parecerse a algo que los ingenieros ya conocen bien: un sistema distribuido.
La ventana de contexto no es un almacén de estado
Uno de los errores más comunes en el diseño de agentes es tratar la ventana de contexto como memoria.
Ese es un hábito tentador. El modelo puede ver toda la conversación, las llamadas a herramientas anteriores, las decisiones y los resultados intermedios, por lo que parecería inofensivo agregar más contenido. Sin embargo, esa ventana es un conjunto de trabajo y no una base de datos. Nada en ella es duradero: un reinicio, una truncación o un proceso de compactación pueden reducirla o reemplazarla por completo. Ampliarla añade capacidad, pero mantiene la durabilidad exactamente donde estaba.
En el caso de un agente que funciona durante mucho tiempo, el estado autoritativo de las tareas debe almacenarse en otro lugar: los objetivos, el trabajo finalizado y pendiente, las decisiones, los artefactos, los puntos de control, los resultados de validación y los enlaces a recursos externos. El contexto se reconstruye luego a partir de ese estado según lo que necesite el modelo en cada momento. La distinción es sencilla: el contexto es lo que ve el modelo, y el estado es lo que sabe el sistema.
La compactación lo hace evidente. Un agente que pasó tres horas modificando un repositorio puede acumular cientos de llamadas a herramientas, enfoques abandonados y observaciones realizadas. Comprimir ese historial puede hacer que el contexto siguiente sea utilizable, pero un resumen sigue siendo una interpretación de lo sucedido, por lo que el estado crítico no debería depender de lo que conservó el compactador. En su lugar, el sistema puede armar un contexto nuevo a partir del estado duradero, en este orden: estado de la tarea, artefactos relevantes, observaciones actuales, habilidades y, finalmente, el contexto del modelo.
Los puntos de control aplican el mismo principio ante fallos en los procesos, y las transferencias estructuradas lo aplican entre agentes o trabajadores. Un sucesor necesita el estado necesario para continuar correctamente, no toda la conversación de su predecesor. La pregunta arquitectónica se convierte en cuál información debe sobrevivir de forma independiente del contexto, y una vez planteada esa cuestión, la gestión del contexto se transforma en un problema de gestión de estados.
Los agentes de larga duración son sistemas distribuidos
Cuando un agente funciona durante horas o días, el conocido modelo de solicitud y respuesta deja de funcionar. Un proceso puede terminar. Una herramienta puede agotar su tiempo de ejecución. Un trabajador puede desaparecer después de completar una operación pero antes de informar al respecto. Dos trabajadores pueden hacerse cargo de la misma tarea. El contexto de un modelo puede desaparecer a mitad del proceso. Nada de esto es algo excepcional, ya que se trata de problemas clásicos de los sistemas distribuidos, y un mecanismo de ejecución a largo plazo necesita semánticas explícitas para manejarlos.
Si el trabajo puede sobrevivir al trabajador, es necesario establecer límites en la propiedad del mismo. Un arrendamiento permite que un trabajador se haga cargo de una tarea por un tiempo determinado, y las señales periódicas proporcionan a un observador externo una indicación de que el trabajador sigue activo. Cuando el trabajador desaparece, el arrendamiento expira y otro puede continuar desde el estado persistente.
Las reintentos requieren un manejo cuidadoso. Imagine a un agente que envía una implementación y la llamada se vence antes de obtener cualquier resultado. Un reintento automático podría ejecutar la implementación dos veces. Por lo tanto, las herramientas para agentes necesitan las garantías que existen en otros sistemas distribuidos: identificadores de operaciones, idempotencia, estados de fallo explícitos y un responsable claro para el comportamiento de reintentos.
Luego está la reanudación. Una tarea prolongada debe representarse como un progreso duradero y no como una conversación en memoria, siguiendo un ciclo de punto de control, ejecución, observación, persistencia y continuación. Si la ejecución se detiene a mitad de camino, el sistema debe determinar si el paso actual es seguro para intentarlo nuevamente, ya está confirmado, parcialmente completado o necesita compensación. Reanudar no significa reproducir todo; significa reconstruir el estado mínimo necesario para continuar de forma segura. Las transferencias siguen el mismo patrón: un nuevo trabajador recibe el objetivo, las decisiones, los resultados, el estado de validación y el trabajo pendiente, sin incluir nada del historial de conversaciones de otro trabajador.
Eso establece el límite central de fiabilidad. Una vez que un agente puede sobrevivir más tiempo que su proceso, el proceso deja de ser la unidad de fiabilidad; lo es la tarea duradera.
La verificación es la otra mitad de la agencia
Un agente puede escribir código, ejecutar una implementación, crear una consulta a la base de datos o modificar la infraestructura. Generar algo no es lo mismo que hacerlo correctamente, y el patrón riesgoso consiste en dejar que el agente sea quien decida por sí mismo si su trabajo tuvo éxito, como en un mensaje que indica que el flujo de autenticación se completó y que todas las pruebas pasaron. El sistema de gestión no debería aceptar eso como evidencia; en su lugar, debe ejecutar las pruebas. De la misma manera, una afirmación de que el servicio está en buen estado debería activar verificaciones de salud y no finalizar la tarea, y una migración de datos debería evaluarse en función del esquema y las invariantes de los datos, y no según la interpretación que el modelo haga de sus propias llamadas a herramientas. La creencia del agente de que ha tenido éxito no constituye una señal fiable de finalización.
Por eso la producción utiliza tres roles separados. El planificador decide qué debe suceder. El ejecutor realiza tareas definidas. El evaluador determina si el estado del sistema resultante cumple con los requisitos. Un mismo modelo puede desempeñar los tres roles, pero sus responsabilidades siguen siendo distintas.
La verificación debe basarse en elementos que puedan observarse, y la evidencia determinista es la primera opción siempre que esté disponible: compiladores, ejecutores de pruebas, validadores de esquemas, comprobaciones de estado, estado de despliegue, verificaciones de políticas o simples afirmaciones. La calificación basada en modelos resulta útil cuando la corrección es intrínsecamente semántica, pero requiere criterios concretos y no una pregunta vaga sobre si el resultado parece bueno. La finalización entonces se convierte en una propiedad del sistema y no algo que diga el modelo: requisitos cumplidos, validación superada, artefactos necesarios presentes, verificaciones de políticas aprobadas, y solo después se considera que la tarea está terminada. En otras palabras, la verificación genera evidencia y el evaluador la analiza para decidir si se puede continuar con la ejecución; por lo tanto, el evaluador actúa como el sensor en el bucle de retroalimentación del sistema. El agente impulsa el progreso mientras que el sistema establece la evidencia correspondiente.
De las instrucciones a la aplicación
Puede indicarse a un agente que no haga algo sin que eso impida que lo realice. Frases como “no modifique la producción”, “solo escriba dentro del área de trabajo” y “nunca exponga credenciales” son útiles, pero ninguna constituye una barrera de seguridad si el entorno en tiempo de ejecución sigue permitiendo dicha operación. Las instrucciones comunican la intención, mientras que la aplicación establece invariantes.
El diseño de la herramienta muestra claramente esta diferencia. Al entregar a un agente una función genérica execute_sql(), su superficie de acciones es muy distinta a la de un agente que cuenta con una interfaz de consulta de solo lectura y con alcance definido. La versión con alcance definido permite verificar la autorización, validar los parámetros, auditar las operaciones y reducir el alcance de sus efectos. Las herramientas MCP, APIs, sistemas de archivos, shells y servicios externos funcionan de la misma manera: el modelo propone una acción y el mecanismo de control decide si dicha acción puede llevarse a cabo y bajo qué identidad, permisos, entorno y políticas.
Una regla práctica para clasificar las restricciones según su costo es la siguiente:
- Si incumplir una restricción es tolerable, puede ser suficiente con dar una instrucción.
- Si incumplirla tiene un alto costo, se debe añadir una verificación.
- Si incumplirla es peligroso, hay que aplicarla en los límites permitidos.
El entorno aislado introduce una segunda dimensión. La autorización determina si se permite una acción. Un entorno aislado regula lo que ocurre cuando el agente se comporta de manera inadecuada, sin importar nada más. Los límites en el sistema de archivos y la red, los límites de recursos y las credenciales con un alcance restringido evitan que los efectos negativos de un comportamiento inesperado sean graves. Las soluciones más avanzadas también imponen transiciones en los flujos de trabajo, no solo llamadas a herramientas individuales. Un despliegue en producción podría permanecer fuera de alcance hasta que se completen las pruebas, el entorno de pruebas esté en buen estado y alguien lo apruebe. El modelo puede sugerir el cambio, pero son las reglas en tiempo de ejecución las que determinan su legalidad. Eso se acerca más a una máquina de estados que a confiar en una oración en lenguaje natural. El objetivo no es restringir la inteligencia, sino limitar la capacidad y el alcance de sus efectos.
No se puede operar con lo que no se puede observar
La observabilidad habitual se centra en determinar si un servicio está funcionando bien, dónde aumenta la latencia y qué dependencia está fallando. Los sistemas de agentes necesitan una capa adicional. Cuando un agente falla, la pregunta es qué ocurrió y también por qué su trayectoria lo llevó a ese estado. ¿Qué intentaba lograr? ¿Qué contexto recibió? ¿Qué herramientas utilizó? ¿Qué políticas permitieron o bloquearon esas llamadas? ¿Qué estado cambió? ¿Qué evidencia lo convenció de que había completado su tarea? Esa es la observabilidad de trayectorias.
Las métricas estándar de los LLM como tokens, latencia, costo, versión del modelo y entradas/salidas son necesarias pero insuficientes, ya que una llamada al modelo es un solo evento dentro de una cadena más amplia: intención, contexto, decisión, acción, observación, estado, verificación y resultado. Supongamos que un agente pasa cuarenta minutos migrando un servicio y luego falla. Saber que consumió 80K tokens no dice casi nada. Una trayectoria útil podría mostrar que el sistema utilizó una guía de migración obsoleta, que el agente eligió una API desactualizada, que la implementación tuvo éxito técnicamente, que las pruebas de integración fallaron y que la recuperación intentó nuevamente exactamente la misma estrategia. Eso sí es un diagnóstico real.
Eso significa que el contexto necesita una procedencia clara: una forma de saber qué habilidades, documentos, estados y resultados de herramientas dieron forma a una decisión determinada. Las llamadas a herramientas también requieren un contexto causal, que incluya el paso de la tarea que las activó, la identidad utilizada, la política que se evaluó y las consecuencias. Las decisiones de política y las transiciones de estado también deben ser visibles, al igual que las acciones que tuvieron éxito. Las métricas más reveladoras resultan ser las de comportamiento: tasa de éxito en las tareas, fallos en la verificación, éxito en la recuperación, finalización prematura, denegaciones de políticas, patrones de fallo recurrentes, escaladas humanas y número de pasos por tarea exitosa.
La observabilidad es lo que completa el mecanismo de seguridad. Una falla debería dejar más que solo un registro en el log. Su trayectoria debe permitir clasificar qué salió mal y identificar el control que faltó, ya sea una fuente de contexto, un evaluador, una política, los límites de una herramienta, un punto de control o una estrategia de recuperación. El objetivo es un sistema que no pueda fallar de la misma manera dos veces.
Una nueva disciplina en sistemas
Cuando se pregunta cómo hacer que los agentes trabajen mejor, la respuesta se amplía a medida que crece la autonomía. La ingeniería de instrucciones ajusta las indicaciones dadas. La ingeniería de contexto modifica la información disponible en el momento de tomar decisiones. La ingeniería de mecanismos de seguridad ajusta toda la trayectoria de ejecución: estado, acciones, límites, retroalimentación, recuperación, verificación y observabilidad. Estas disciplinas no se sustituyen entre sí, sino que representan ámbitos cada vez más amplios.
Una división útil de las tareas sirve como base para todo: el modelo se encarga del razonamiento bajo incertidumbre, mientras que el entorno de ejecución se ocupa de las invariantes. Un archivo que nunca debe cambiar cuenta con un límite en el sistema de archivos. Un sistema en producción al que no se debe modificar cuenta con verificaciones de autorización. Una migración que debe tener éxito se verifica en relación con el estado resultante, y el estado de las tareas que deben sobrevivir a un reinicio se persiste. Las garantías de que el entorno de ejecución pueda suministrar resultados de manera más fiable no deben solicitarse al modelo.
Los agentes de producción van a fallar, y la señal de un sistema maduro radica en lo que hace a continuación. Cada fallo se refleja en el tiempo de ejecución. Si el mismo error persiste, se crea un evaluador específico para él. Si una acción resulta arriesgada, la capacidad que la sustenta se vuelve más limitada. Si se pierde el progreso, aparece un punto de control en el lugar donde faltaba, y si las tentativas de recuperación siguen fallando, entra en vigor una política de escalada. La ejecución genera pruebas, esas pruebas revelan controles ausentes, y esos controles hacen que la siguiente ejecución sea más sólida.
También cambia la forma en que se evalúan los agentes. La pregunta deja de ser cuán bueno es el modelo y pasa a ser hasta qué punto todo el sistema puede completar este tipo de tareas de manera fiable. La ingeniería de aprovechamiento no es otro marco de orquestación; es una disciplina sistémica destinada a hacer que la inteligencia probabilística sea confiable. Una demostración demuestra que un agente puede hacer algo una vez. Un sistema en producción debe hacerlo de forma fiable, verificable, recuperable y repetida, con cada fallo mejorando la ejecución siguiente. Gran parte del trabajo más difícil se encuentra por debajo de las instrucciones, en la arquitectura de estados, retroalimentación, verificación, recuperación y bucles de control que convierten el razonamiento del agente en un comportamiento sistémico duradero.
Lecturas relacionadas
- Un agente AI es igual a un modelo AI más un harness: qué hace el harness y por qué — Un agente es un modelo más un harness. Conozca cómo los harnesses añaden herramientas, memoria, bucles y medidas de seguridad, cuáles son las diferencias entre agentes de código abierto y de peso abierto, y por qué son importantes las evaluaciones.
- Aislar a un agente de programación y mantener su ventana de contexto ligera — Añada un entorno aislado tipo Seatbelt o Bubblewrap a un agente y gestione el contexto mediante archivos de desbordamiento, stubs, compactación e inyección tardía compatible con caché de prefijos.