Por qué los agentes empeoran a medida que crece el contexto
El deterioro del contexto (context rot) en términos concretos. Cada turno es una única petición autocontenida al modelo; una petición larga o cargada de herramientas reduce de forma medible la precisión de la respuesta. Qué contiene esa petición, qué se descarta cuando no cabe, y por qué la plataforma la vuelve a componer antes de escribir la respuesta en lugar de resumir los resultados de las herramientas.
Un agente que el lunes respondía bien, el viernes responde con vaguedades. Deja de seguir una instrucción que seguía veinte mensajes atrás. Invoca una herramienta, recibe los datos correctos y después escribe una respuesta que ignora la mitad de ellos. Nada falla, nada queda registrado y la conversación parece normal. A esto se le suele llamar context rot, y la explicación habitual — «se llenó la ventana de contexto»— no es lo que medimos.
Un turno, de principio a fin
Un turno empieza como una petición, engorda mientras corren las herramientas y se reconstruye antes de escribir la respuesta. El estado intermedio es el que merece atención: es a partir de él que responden la mayoría de los agentes.
Cada turno es una petición autocontenida
El modelo no guarda nada entre turnos. No hay sesión al otro lado, ni memoria de lo que dijo hace una hora, ni forma de consultar algo que no se le haya entregado. En cada turno la plataforma compone una petición completa y la envía entera; la respuesta se genera a partir de esa petición y de nada más.
Si tienes instinto de redes, se parece a un datagrama: autocontenido, enviado una vez, con todo lo que el receptor necesita y limitado por un tamaño que el emisor debe respetar. Dos cosas rompen la analogía, y ambas importan:
- Nada se pierde en tránsito. Todo lo que envías llega. Lo que varía es cuánto atiende el modelo — la pérdida ocurre dentro del receptor, no en el cable.
- La disposición cambia la respuesta. Un router no se comporta distinto porque reordenes la carga útil. Un modelo sí. Los mismos hechos, en la misma petición, dispuestos de dos maneras, produjeron una respuesta correcta en una disposición y una equivocada en la otra. De ahí sale casi todo lo que sigue.
Qué hay en la petición
El orden es el orden que ve el modelo. La columna de conservar/recortar es la prioridad que aplica la plataforma cuando la petición no cabe; los puestos son relativos, no un número fijo de bloques.
Todo lo que está por encima del historial es un único mensaje de sistema. Es deliberado: los límites del agente, tu base de conocimiento y el idioma de respuesta no son conversación, y un modelo los trata de forma distinta según dónde estén.
Qué se descarta cuando no cabe
Una petición que excede el presupuesto no se trunca por el final. Los bloques se descartan por orden de prioridad hasta que cabe:
- Primero el historial más antiguo — y los turnos descartados se compactan en el resumen acumulado en lugar de perderse, así que lo que se dijo sobrevive aunque no sobreviva la redacción.
- Las memorias peor puntuadas, luego los fragmentos recuperados peor puntuados — desde la cola, de modo que el material más relevante es el último en salir.
- El perfil, después el resumen.
- Nunca las instrucciones del agente, tu base de conocimiento ni la pregunta. Si la pregunta por sí sola desborda el presupuesto, se trunca y se marca como truncada: se le dice al modelo, en vez de dejarlo adivinar por qué una frase se corta a media palabra.
Este orden es la parte honesta de un presupuesto de contexto: algo tiene que salir, y un sistema que no dice qué acabará descartando en silencio lo que quedara al final.
Que quepa no es lo mismo que se lea
Aquí está lo que nos sorprendió. Montamos una prueba en la que los hechos necesarios para responder estaban presentes en todas las condiciones: no se descartó nada, no se truncó nada, no faltaba información en ninguna parte. Lo único que cambiaba era cómo estaba dispuesta la petición. Una tarea de filtrado sobre unos cientos de registros, contra nuestro propio modelo local y contra un modelo en la nube, varios intentos cada uno:
| Cómo se dispusieron los mismos hechos | Correctas |
|---|---|
| Un único mensaje limpio con solo las filas relevantes | 8 / 8 |
| Esas mismas filas devueltas como resultado de una herramienta | 0 / 8 |
| El conjunto completo más cinco resultados de herramientas no relacionados | 0 / 6 |
| Esa acumulación vuelta a componer como un mensaje limpio | 8 / 8 |
Dos controles descartan las lecturas obvias. Dividir la petición limpia en dos mensajes de la misma longitud total siguió dando 8 / 8, así que la variable no es la longitud. Devolver las filas destiladas como resultado de herramienta siguió dando 0 / 8, así que tampoco es que los datos deban estar más cerca de la pregunta. El andamiaje de herramientas y el material irrelevante compiten por la atención del modelo estén donde estén.
El modelo en la nube fue más robusto, pero no inmune: aguantó en casi todas las tareas y aun así cayó a 0 / 3 en una búsqueda de un solo valor en cuanto la petición llevaba los resultados acumulados de un turno.
Dos límites honestos. Es nuestra propia prueba sobre nuestras propias tareas, no un banco de pruebas público. Y no eleva el techo del modelo: una variante más difícil de la misma tarea sacó cero bajo todas las disposiciones, porque ese modelo sencillamente no podía. Reordenar una petición recupera la precisión que la disposición te estaba costando; no compra capacidades que el modelo no tiene.
Así que un turno tiene dos fases: trabajar y responder
Esta es la división que muestra la animación del principio de la página.
Trabajar necesita la petición desordenada. El modelo tiene que ver sus propias invocaciones y sus resultados en bruto para decidir si invoca otra. Esa fase no cambia.
Responder no. Cuando las herramientas terminan, la plataforma compone una petición nueva — las mismas instrucciones de sistema, un breve resumen de la conversación, los hechos que este turno encontró de verdad y la pregunta — y la respuesta que recibes se genera a partir de eso. Las invocaciones, las cargas en bruto y el razonamiento intermedio no aparecen en ella.
El resumen está ahí porque una pregunta real suele ser «sí» o «¿y el segundo?». La disposición de un solo mensaje que mejor midió es de un solo turno, y una conversación no lo es; el resumen se pliega dentro del mismo mensaje en lugar de restaurarse como turnos separados, lo que no cuesta nada medible y mantiene los pronombres resolubles.
Lo que deliberadamente no hacemos
La solución habitual cuando la salida de las herramientas inunda una ventana de contexto es que un modelo resuma cada resultado. No lo hacemos, y la prueba de arriba es el motivo: la disposición que sacó pleno usaba los datos en bruto, vueltos a componer — no hizo falta ningún paso de resumen para recuperar la precisión. Añadir uno significaría pedirle a un modelo que decida qué hechos importan, en un sistema cuyo principio de diseño es no darle a un modelo un trabajo que el código hace exacto. Un resumidor que se deja fuera justo el número por el que preguntaba el cliente falla en silencio y parece una buena respuesta.
Cuando los hechos realmente no caben, se truncan y el truncamiento se declara en la petición, con la instrucción de no rellenar lo que falta. Un agente que dice «solo pude ver los primeros cuarenta pedidos» vale más que uno que se inventa el resto con seguridad.
Qué significa esto para ti
No hay nada que configurar. Así es como funciona cada agente de la plataforma.
Lo que cambia en la práctica:
- Las conversaciones largas siguen siendo utilizables. El turno veinte se compone igual que el primero, y lo que salió de la ventana sobrevive como resumen en vez de desaparecer.
- Una herramienta que devuelve muchos datos no envenena la respuesta. El resultado se limita, y la respuesta se escribe a partir de una petición que ya no lleva la carga en bruto.
- Un turno que usó herramientas cuesta una llamada de modelo extra — alrededor de un segundo en una respuesta corta. El chat muestra lo que está haciendo mientras tanto, en vez de quedarse mudo.
Si ves que un agente ignora algo que sabes que se le dio, la pregunta útil no es «¿la ventana de contexto es demasiado pequeña?» sino «¿en qué bloque estaba, y qué más iba en la petición con él?». Dónde vive una conversación entre turnos responde la otra mitad de esta página: si el modelo no guarda nada, qué hay de nuestro lado a partir de lo cual se compone una petición. Respuestas fundamentadas cubre qué se recupera, Memoria por cliente qué se recuerda, y Herramientas y MCP los presupuestos que impiden que un solo resultado se lleve la ventana entera.