¿Qué es la compactación de contexto y por qué conviene evitarla al dimensionar tickets?
Compactar parece inofensivo, pero decide por ti qué información se pierde. Por eso los tickets en SDD se dimensionan por lo que cabe en una ventana de contexto sin compactar.
El punto de confusión
Cuando una conversación con un agente se alarga, la herramienta ofrece (o aplica automáticamente) una compactación: el LLM resume lo ocurrido hasta el momento y continúa trabajando sobre ese resumen. Suena a ventaja: liberas espacio y sigues. ¿Dónde está el problema?
El problema es que la compactación implica pérdida de información, y quien decide qué se pierde no eres tú, sino el modelo.
Qué pasa realmente al compactar
Al compactar, el modelo infiere qué es importante y qué no. Lo que para él parece un detalle menor (una línea perdida en la documentación, una restricción mencionada de pasada) puede ser justo lo más relevante para ti. No puedes controlar qué queda dentro y qué queda fuera. La regla práctica es no delegar al azar nada que pueda ser crítico.
Además, la ventana de contexto nunca empieza vacía. Incluso en una sesión recién abierta, parte del espacio ya está ocupado:
| Elemento | Impacto en la ventana |
|---|---|
| System prompt | Ocupa espacio desde el primer mensaje |
| Definición de tools del sistema | Junto al system prompt, en torno a un 1–2 % en una sesión típica |
| MCPs conectados | Cada servidor conectado añade sus tools, se usen o no |
| Reglas / CLAUDE.md | Se cargan en cada interacción |
| Ficheros adjuntos, historial y resultados de tools | Crecen a medida que avanza la tarea |
La consecuencia: tickets del tamaño de una ventana
Tradicionalmente los tickets se dimensionaban con story points o tallas de camiseta, buscando que fueran lo bastante atómicos para no bloquearse y entregar rápido. En un flujo agéntico aparece un criterio nuevo: un ticket debería poder completarse dentro de una sola ventana de contexto sin compactar.
Si al explorar, proponer, implementar y verificar un ticket el agente necesita compactar a mitad de camino, es una señal de que el ticket es demasiado grande o de que se está cargando contexto innecesario. Las tareas pequeñas y atómicas se resuelven mejor precisamente porque todo lo relevante cabe a la vez.
Implicaciones prácticas
No conectes MCPs que no vayas a usar: consumen espacio en cada sesión. No cargues documentación "por si acaso". Igual que no dejas en el código funciones que nadie llama, no dejes en el contexto información que la tarea no necesita. Y si el ticket se queda corto de espacio, divídelo antes de empezar en lugar de confiar en la compactación.
La compactación manual existe y puede sacarte de un apuro, pero debería tratarse como una excepción y no como parte del flujo: lo mismo que no queremos que el sistema compacte por su cuenta, tampoco conviene hacerlo nosotros por costumbre.
Resumen rápido
- Compactar es resumir el contexto, y el modelo decide qué se pierde: puede descartar justo lo crítico.
- La ventana nunca empieza vacía: system prompt, tools y MCPs ya ocupan espacio.
- Dimensiona cada ticket para que quepa entero en una ventana de contexto sin compactar.
¿Quieres aplicar esto en tu equipo?
En Kuuli Technologies llevamos estas metodologías a equipos reales. Escríbenos si quieres una sesión de trabajo o una consultoría sobre agentes IA y SDD.