En el montaje de un agente las instrucciones se acumulan con el tiempo. Se añade una regla por cada problema, se escribe una barrera por cada error y un año después queda un montón de texto que nadie lee entero.
Eric Provencher, de OpenAI, sostiene en una nota para desarrolladores sobre los modelos nuevos que ese montón se ha vuelto una partida de coste. Las instrucciones detalladas escritas para modelos antiguos ahora estorban a uno más capaz.
Esta guía abre esa nota a través de cuatro errores asentados y dice qué hacer con cada uno. La idea de fondo cabe en una frase: un modelo más capaz pide que se le lleve menos de la mano. El consejo se dio para el modelo de OpenAI, pero el problema no depende del proveedor; la misma acumulación ocurre en todo montaje de agentes y la solución pasa por el mismo sitio.
Por qué las instrucciones viejas hacen daño
Un texto de instrucciones se moldea según las debilidades del modelo para el que se escribió. Si el modelo se saltaba algo, añadiste una regla que lo hacía obligatorio; si lo interpretaba mal, escribiste una secuencia paso a paso.
Cuando cambia el modelo esas reglas no desaparecen, pero sus motivos sí. Queda un texto que limita algo que el modelo nuevo ya sabe hacer.
- Las reglas se acumulan y ninguna se borra.
- Cada regla ocupa sitio en la ventana de contexto.
- Las reglas restrictivas impiden que el modelo elija un camino mejor.
- El origen del problema queda invisible, porque cada regla parece razonable por separado.
El contexto es un presupuesto
Bajo el debate sobre aligerar hay una restricción medible: la ventana de contexto no es infinita y cada línea que metes desplaza a otra.
Al crecer las instrucciones, se estrecha el sitio que queda para el trabajo real: la tarea y el código. El modelo ve menos código y lee más reglas, y el resultado se invierte: reglas pensadas para mejorar el trabajo se vuelven el obstáculo.
- Cada regla de lectura obligatoria arrastra un documento entero al contexto.
- Las listas largas de habilidades se recargan en cada llamada.
- Las reglas sin usar cuestan lo mismo; no existe la regla muerta.
- Cuando el contexto se llena, lo primero que se pierde suele ser la propia tarea.
Error uno: descripciones largas de habilidades
La primera advertencia de Provencher es sobre las definiciones de habilidades. Las instrucciones acumuladas consumen contexto y las descripciones demasiado largas dificultan que el modelo elija la habilidad correcta.
El problema no es solo el espacio. Las descripciones largas pueden truncarse, y una descripción truncada lleva al modelo a elegir la habilidad equivocada.
El enfoque recomendado es claro: los nombres y descripciones deben indicar con nitidez cuándo aplica esa habilidad. No un párrafo largo sobre lo que hace, sino una frase corta sobre cuándo usarla.
Hay una prueba práctica: quien lea la descripción de una habilidad, ¿entiende de una sola pasada cuándo debe invocarse? Si una persona no puede, el modelo tampoco, y la elección se acerca al azar.
Error dos: lectura obligatoria en cada cambio
Los equipos suelen fijar una regla para el agente: antes de cualquier cambio, lee la documentación de arquitectura, base de datos y despliegue.
La regla es bienintencionada pero innecesaria en arreglos simples. Leer un documento de arquitectura para corregir una errata gasta contexto, tiempo y dinero.
| Documento | Cuándo leerlo |
|---|---|
| Nota de arquitectura | Cuando se tocan los límites entre servicios |
| Documentación de base de datos | Cuando cambia el esquema |
| Documentación de despliegue | Cuando cambia el flujo de publicación |
| Ninguno | En una corrección pequeña |
No prohíbes los documentos, los condicionas. En lugar de "lee siempre", la regla pasa a ser "si cambias esto, lee aquello".
La tabla marca además un límite: leer un documento es una partida de coste, no una medida de seguridad. Hacer que el modelo lea documentación no vuelve correcto el cambio; solo añade información al contexto. Si esa información hace falta depende del tipo de cambio.
Error tres: reglas de aprobación rígidas
En montajes antiguos tenía sentido que el agente pidiera aprobación antes de cada paso arriesgado; no se confiaba en su criterio. Esas mismas reglas resultan contraproducentes con un modelo más capaz.
Según Provencher, las barreras rígidas pueden hacer que Astra abandone el trabajo antes de tiempo. Al no poder superar la regla que tiene delante, el modelo da por terminado un trabajo sin acabar.
La solución es conceder permiso explícito para operaciones seguras: pruebas desechables, archivos de un solo uso y correcciones de error no deberían exigir confirmaciones repetidas. Cuanto más estrecha la lista de permisos, más se atasca el agente; cuanto más amplia, más fluye el trabajo.
Dónde está el equilibrio no es evidente y varía según el equipo. Pedir aprobación para una operación que toca la base de datos de producción sigue siendo correcto; pedirla para crear y borrar un archivo temporal solo produce demora. Lo que las separa es si la operación es reversible.
Error cuatro: no decir cuándo termina
El cuarto punto quizá sea el más útil. En vez de poner consultas a mitad de tarea, define de entrada cuándo está hecho el trabajo.
Escribe por adelantado todos los pasos necesarios: implementa, prueba, verifica, corrige si hay errores. El agente lee esa lista como condición de fin y no se detiene antes de completarla.
- Las consultas a mitad de tarea crean puntos de parada prematura.
- Sin condición de fin escrita, el modelo fija su propio umbral.
- Listar pasos no es lo mismo que secuenciarlos: uno dice qué hacer, el otro cómo hacerlo.
- Poner el paso de verificación en la lista es, por sí solo, lo que más rinde.
El orden dentro de esa lista también cuenta. El paso de verificación va en el medio y no al final, para que cuando se encuentre un error el paso de corrección siga dentro de la lista.
Un ejemplo concreto
Ver los cuatro puntos en un ejemplo lo hace más fácil. Imagina una instrucción típica dada a un agente de código en su forma antigua: "Antes de cualquier cambio, lee la documentación de arquitectura, base de datos y despliegue. Pide aprobación antes de cada cambio de archivo. Pide aprobación antes de ejecutar pruebas. Avisa cuando el cambio esté hecho."
En ese texto hay cuatro problemas distintos y cada uno parece razonable por separado. La versión aligerada queda así: "Si tocas los límites entre servicios lee la nota de arquitectura; si cambias el esquema lee el documento de base de datos. Puedes crear y borrar archivos de prueba temporales. El trabajo se considera terminado cuando estos pasos estén completos: implementa, prueba, verifica, corrige si hay errores."
- La lectura obligatoria se condicionó en lugar de eliminarse.
- Se permitieron de forma explícita las operaciones seguras.
- Se quitaron las consultas a mitad de tarea.
- La condición de fin se definió en una frase.
El segundo texto es más corto que el primero pero más determinante. La diferencia no está en el número de reglas sino en a qué pregunta responden: el primero dice "cómo trabajar", el segundo dice "cuándo está hecho".
El coste de detallar cada paso
La idea de fondo de la nota es esta: las secuencias detalladas paso a paso limitan sin necesidad el criterio del modelo ante el matiz y la ambigüedad.
Eso no significa dejar de escribir instrucciones. Decir qué hay que hacer es necesario; escribir paso a paso cómo hacerlo es lo que impide al modelo encontrar un camino mejor.
Cuándo hacer la limpieza
El momento natural para este trabajo es un cambio de modelo. Al pasar a uno nuevo, el texto de instrucciones que tienes fue escrito para las debilidades de un modelo que ya no existe.
Reescribir el texto entero en cada actualización tampoco es realista. El camino práctico es mantener las instrucciones anotadas con el problema por el que se añadieron; cuando ese problema desaparece, quitar la regla se vuelve fácil.
Las reglas sin anotar son las más peligrosas. Como nadie recuerda por qué se añadieron, nadie se atreve a borrarlas y el texto sigue creciendo durante años.
El orden para aligerar tu montaje
En vez de reescribir todo el texto de una sentada, es más seguro avanzar midiendo.
- Acorta primero los nombres y descripciones de habilidades; ahí está la ganancia más visible.
- Condiciona las reglas de lectura obligatoria en lugar de borrarlas.
- Revisa la lista de aprobaciones y libera explícitamente las operaciones seguras.
- Añade una condición de fin a cada tarea y quita las consultas intermedias.
Después de cada paso, vuelve a ejecutar las mismas tareas y registra el resultado. Si la limpieza funcionó solo puede medirse contra un conjunto fijo de tareas.
No cambies sin medir
Lo insidioso de aligerar es que ni la mejora ni el empeoramiento se ven de inmediato. Quitas una barrera y el agente termina la mayoría de tareas más rápido; el problema solo aparece en un caso límite concreto.
Por eso hace falta un conjunto fijo de tareas. Basta una lista pequeña de quince; lo importante es que la lista no cambie y que se repita tras cada limpieza.
- Tasa de éxito: cuántas tareas terminaron sin intervención humana.
- Parada prematura: en cuántas el agente dejó el trabajo a medias y pidió aprobación.
- Uso de contexto: tokens gastados por tarea.
- Elección errónea de habilidad: en cuántas se invocó una habilidad irrelevante.
El cuarto punto muestra directamente si acortar las descripciones funcionó. Los otros tres miden el precio de las barreras que quitaste.
Dónde detenerse
Todo este consejo se apoya en un supuesto: que el criterio del modelo que usas es mejor que la regla que escribiste. Eso no es cierto para todos los modelos.
Si trabajas con un modelo pequeño y rápido, la barrera que quitaste puede hacer falta de verdad. Haz la limpieza cuando cambies de modelo y mide cada vez; es un ajuste que depende del modelo, no una regla general. Que el mismo texto dé resultados distintos en dos modelos no significa que la instrucción esté mal escrita; solo muestra que importa para quién se escribió.