En este artículo
El agente lleva veinte minutos trabajando. Tiene el objetivo, las restricciones, tres decisiones tomadas y una lista de herramientas ejecutadas. De repente, el proveedor devuelve un error de contexto. El agente no sabe qué olvidó, el usuario no sabe qué se perdió y el trabajo se reinicia desde cero. La mayoría de los equipos responde subiendo la ventana. Casi nunca es la solución.
El síntoma
El error de contexto parece un problema de tamaño, pero suele ser un problema de contrato. El agente envió una solicitud que el modelo no podía aceptar, y el rechazo llegó tarde, después de gastar tiempo y tokens. En un agente que hace muchas llamadas, ese fallo se multiplica: cada reintento vuelve a enviar el mismo payload, cada compactación pierde un poco de contexto y el usuario termina con una versión del trabajo que ya no reconoce.
La primera decisión es admitir que el contexto es un recurso con estado. No es una ventana que se agranda; es una conversación que se transforma. Si no se guarda el estado antes de transformarlo, la recuperación es una reconstrucción a ciegas.
Por qué subir la ventana no alcanza
Subir la ventana ayuda, pero no resuelve el problema de fondo. Primero, porque el costo y la latencia crecen con el contexto: un agente que envía 200K tokens por llamada es más caro y más lento que uno que envía 20K bien elegidos. Segundo, porque el modelo no atiende igual a todo el contexto: la información del medio se diluye. Tercero, porque el límite siempre existe; si el flujo crece, volverás a chocar.
La ventana es una capacidad, no una estrategia. La estrategia es decidir qué entra, qué se resume y qué se guarda fuera del prompt. Esa decisión es la que separa un agente que aguanta sesiones largas de uno que se rompe en la primera tarea grande.
Checkpoint antes de compactar
La primera pieza es un checkpoint saneado en disco antes de tocar el contexto. No es un volcado crudo: es un artefacto con el objetivo, las restricciones duras y blandas, las decisiones tomadas, la evidencia y la siguiente acción. Se escribe de forma atómica, con permisos de owner y una cuota, para que un fallo a mitad de escritura no deje un archivo corrupto.
Ese checkpoint cumple dos funciones. Si la compactación falla, el agente puede recuperar el estado desde disco. Si la sesión se interrumpe, el siguiente turno sabe exactamente dónde estaba. Sin él, la compactación es una apuesta: si el resumen omite una restricción, el agente puede tomar una decisión que el usuario ya había prohibido.
Compactación transaccional
La segunda pieza es una compactación que se pueda deshacer. El flujo es: admitir la solicitud, intentar el checkpoint, compactar en memoria, volver a contar los tokens con el tokenizer del modelo y, solo si cabe, enviar. Si no cabe, se rechaza localmente. Si el proveedor falla, se recupera el checkpoint. Una compactación y una recuperación acotada por solicitud; no un bucle infinito de resúmenes.
La palabra “transaccional” es importante. La compactación no debe dejar el contexto en un estado intermedio: o se aplica completa, o se descarta. Los pares herramienta/resultado tienen que mantenerse atómicos; si se parte una llamada de su resultado, el modelo ve una acción sin consecuencia y alucina la siguiente.
“Solicitud original: 100.357 bytes. Candidato compactado: 11.280 bytes. Entrada efectiva: 5.531 tokens.” — Registro de canarios.
Qué se preserva y qué se reconstruye
No todo merece sobrevivir. El objetivo y las restricciones son intocables. Las decisiones tomadas y su justificación también. La evidencia que sostiene una afirmación se guarda con su fuente. Lo que se puede reconstruir —el texto de una herramienta que se puede volver a ejecutar, el contenido de un archivo que está en disco— se descarta sin culpa.
Esa distinción es la que evita el error opuesto: compactar tanto que el agente pierde el hilo. Un resumen que dice “se discutió el problema” no sirve. Uno que dice “se descartó la opción A porque rompía el contrato de admisión; siguiente paso, medir la opción B” sí sirve.
La telemetría cierra el ciclo. Cada admisión, compactación y recuperación deja un registro con tokens de entrada, duración, causa de rechazo y modelo servido. Ese registro no es para vanidad: es lo que permite detectar que una ruta de recuperación está fallando antes de que el usuario lo note. Sin telemetría, el sistema solo sabe que “funcionó” o “falló”; con ella, sabe por qué y puede corregir el contrato.
Canarios reales
En dos pruebas internas verificadas, el governor recuperó solicitudes que superaban el límite del modelo. La primera pasó de 100.357 bytes a un candidato de 11.280 bytes y 5.531 tokens de entrada; la segunda, de 100.354 a 11.277 y 5.540. Ambas terminaron con el marcador esperado y el modelo restaurado. Los bytes originales y los tokens efectivos son unidades distintas: no se comparan directamente.
| Canario | Request original | Compactado | Tokens de entrada | Resultado |
|---|---|---|---|---|
| Lane rápida | 100.357 bytes | 11.280 bytes | 5.531 | Stop exacto, modelo restaurado |
| Lane estándar | 100.354 bytes | 11.277 bytes | 5.540 | Stop exacto, modelo restaurado |
Lo que estos canarios demuestran es recuperación puntual, no continuidad infinita. Una sesión de ocho horas puede fallar de formas que una prueba de un turno no cubre. Por eso el sistema registra telemetría y declara el límite en vez de prometer robustez total.
Para seguir leyendo
Para entender el costo de mantener modelos locales, revisa nuestra guía de 27B–35B. Si tu cuello de botella es la latencia, la pieza de speculative decoding explica qué medir. Y para el lado del razonamiento, la guía de presupuesto ayuda a decidir cuánto contexto necesita una tarea antes de compactar.
El repositorio de llama.cpp documenta el manejo de contexto y KV cache en runtimes locales. La presentación de LFM2.5 muestra por qué los agentes on-device priorizan el costo por token sobre el tamaño del modelo.
Preguntas frecuentes
¿Basta con aumentar la ventana de contexto?
No. Aumenta la capacidad, pero también el costo y la dilución. La estrategia es decidir qué se preserva y qué se reconstruye.
¿Qué debe guardar un checkpoint?
Objetivo, restricciones, decisiones, evidencia y siguiente acción. Lo que se puede reconstruir desde disco no necesita estar en el checkpoint.
¿Esto elimina los fallos de contexto?
No. Convierte un fallo opaco en un rechazo accionable y permite recuperar el estado. Los límites siguen existiendo.
La diferencia entre un agente que aguanta y uno que se rompe no es el tamaño de la ventana. Es la calidad del estado que decide guardar. Un agente que sabe qué olvidar puede trabajar mucho más tiempo que uno que intenta recordarlo todo.
El conocimiento verdadero trasciende a lo público 🌀
Continúa explorando Inteligencia Artificial con piezas relacionadas y evidencia adicional.
Ver relacionados
