Las ventanas de contexto son un presupuesto, no una feature

Los agentes en producción fallan por inflación de contexto mucho antes de alcanzar el límite duro del proveedor. El síntoma parece confusión: el agente repite una pregunta respondida diez turnos atrás, ignora una restricción enterrada en un pegado de 40 páginas, o alucina una ruta de archivo que solo existió en una salida de herramienta truncada. La solución rara vez es una ventana más grande. La solución es un presupuesto de ventana de contexto — un plan de asignación por turno que decide qué entra a la inferencia, qué queda en memoria externa y qué se expulsa antes del siguiente paso. El contexto no es memoria ilimitada. Es un recurso escaso con latencia, costo y trade-offs de atención en cada token.

Los modelos frontier en 2026 anuncian ventanas de 200K a más de 1M tokens. Esa capacidad es real. También es una trampa. Llenar la ventana no hace al agente más inteligente — hace la inferencia más lenta, más cara y más vulnerable al efecto lost-in-the-middle, donde los hechos críticos en el centro de un prompt largo pierden prioridad ante la atención del modelo. Quienes envían agentes confiables tratan el límite anunciado como techo, no como objetivo. La mayoría de los turnos en producción apuntan a 60–75% de utilización, reservando margen para respuestas de herramientas y salida del modelo que llegan después de la llamada inicial.

Los fallos de presupuesto de contexto aparecen como amnesia del agente

Los fallos de contexto son silenciosos. A diferencia de un error de rate limit o un timeout de herramienta, una ventana inflada produce respuestas plausibles pero incorrectas. El agente sigue ejecutándose. Los logs se ven limpios. El costo sube gradualmente. Solo cuando un humano reproduce la sesión emerge el patrón: la información estaba en algún lugar del transcript, pero perdió prioridad frente a contenido más nuevo y ruidoso.

Tres modos de fallo dominan incidentes de producción rastreados hasta gestión de contexto.

Prompts que vuelcan todo. Equipos pegan repositorios enteros, backlogs completos o exports JSON de varios megabytes en el primer turno porque la ventana "lo aguanta". El modelo recibe los datos. No atiende de forma fiable a todos. Restricciones críticas del turno uno compiten con 200 resultados de herramientas en el turno quince.

Salida de herramientas sin límite. Cada loop del agente reenvía entradas y salidas previas de herramientas. Un solo grep en un monorepo o una consulta que devuelve diez mil filas puede consumir más tokens que todo el historial de conversación. Las trazas de herramientas crecen más rápido que los mensajes de chat porque se acumulan textualmente.

Truncado ciego. Cuando el contexto se acerca al límite, ventanas deslizantes ingenuas descartan los mensajes más antiguos — a menudo las instrucciones de sistema, el objetivo original del usuario o la lista de restricciones del inicio de sesión. La summarización sin estructura preserva narrativa pero pierde identificadores: números de ticket, rutas de archivo, códigos de error, montos.

Una ventana de contexto más grande invita a agentes más lentos, más caros y menos enfocados.

El costo no es solo gasto en inferencia. La latencia se compone con el tamaño del input. Un turno que procesa 400K tokens puede sumar segundos de prefill antes del primer token de salida — inaceptable para flujos interactivos. El diseño del presupuesto de ventana de contexto es cómo los equipos frenan ese crecimiento antes de que sea un problema de arquitectura.

Un presupuesto de ventana de contexto asigna capacidad en cuatro capas

Un presupuesto de ventana de contexto no es el máximo del proveedor. Es una decisión de producto: cuántos tokens puede gastar este turno y en qué capas. Tratar la asignación como plan de capacidad, no como detalle posterior.

Estos rangos varían por flujo. Un agente de código con cuarenta herramientas MCP necesita capa de herramientas más grande y retrieval menor. Un agente de soporte con toolset estrecho gasta más en artículos de knowledge base recuperados. El punto es reserva explícita — no llenado accidental.

Definir dos umbrales por sesión. Un umbral blando al ~70% del presupuesto dispara compactación: resumir turnos viejos en un bloque de estado estructurado, comprimir trazas de herramientas en un ledger de viñetas, expulsar chunks RAG obsoletos. Un umbral duro al ~90% detiene retrieval nuevo hasta completar compactación. Esperar un error 400 de la API significa que la sesión ya perdió continuidad.

context_budget:
  max_input_tokens: 120000        # tope de producto, no máximo del proveedor
  soft_threshold: 0.70
  hard_threshold: 0.90
  layers:
    system:
      pinned: true
      max_tokens: 18000
    tools:
      max_tokens: 24000
      cache_stable: true
    working_memory:
      max_tokens: 42000
      verbatim_tail_turns: 6
    retrieval:
      max_tokens: 36000
      strategy: just_in_time

Instrumentar cada capa. Si la salida de herramientas supera sistemáticamente su asignación, el problema es diseño de herramientas — no elección de modelo. El artículo sobre servidores MCP como infraestructura de producción cubre por qué respuestas verbosas de herramientas son un problema de control de acceso y diseño de API, no solo de prompt.

El contenido estable va al cache; el volátil, fuera de la ventana

No todo lo que vale la pena saber pertenece a la ventana activa. Los agentes en producción separan estado caliente (necesario para decidir este turno) de estado frío (durable pero recuperable bajo demanda).

El estado caliente permanece en contexto: mensaje actual del usuario, últimos seis turnos textuales, restricciones activas, subtarea abierta y resultados de herramientas de la cadena de razonamiento actual. El estado frío vive fuera: archivos completos de conversación, vector stores, sistemas de archivos, bases de datos y notas estructuradas que el agente escribe entre turnos.

El prompt caching amortiza contenido caliente estable. Instrucciones de sistema, políticas de seguridad y esquemas de herramientas que no cambian entre turnos deben marcarse como cacheables donde el proveedor lo soporte — los tokens de input cacheados suelen facturarse a una fracción del costo de input fresco. La ganancia exige disciplina: mutar el system prompt cada turno anula el cache por completo.

La toma de notas estructurada extiende el estado frío sin inflar el caliente. El agente escribe un artefacto compacto de progreso — todos abiertos, rutas de archivo fijadas, estrategias fallidas a evitar, decisiones ya tomadas — en almacenamiento externo. El siguiente turno inyecta solo ese artefacto más la cola reciente. Este patrón refleja cómo las specs funcionan como contratos de ejecución: el artefacto durable es pequeño, versionado y autoritativo; el ruido generado alrededor es desechable.

La compactación debe preservar entidades, no vibes. Un resumen que dice "el usuario tenía dudas de facturación" es inútil. Uno que dice "factura #8842, estado vencido, reembolso limitado a $240 según política REF-12, intento previo falló por timeout de gateway" sobrevive diez turnos más. Validar la salida de compactación con spot checks: regex para IDs, montos, fechas y rutas de archivo antes de aceptar el resumen en memoria de trabajo.

La salida de herramientas domina el crecimiento de contexto en loops de agente

Los agentes estilo ReAct reenvían la traza completa en cada iteración. Cada llamada a herramienta suma tokens de input (la llamada) y de output (la respuesta). Diez iteraciones con salidas verbosas pueden superar el system prompt, los esquemas de herramientas y el historial del usuario combinados.

Comprimir la salida de herramientas en el límite antes de inyectar. Una consulta que devuelve 10.000 filas se convierte en conteo, muestra de tres filas y nombres de columnas. Una búsqueda de logs de 500 líneas se reduce a las cinco líneas alrededor de la firma de error más la query usada. Una lectura de archivo devuelve la función relevante, no el módulo entero — salvo que la tarea exija contexto de archivo completo.

Asignar prioridad de expulsión cuando se supera el presupuesto:

• Mensaje del usuario y política de sistema fijada: prioridad 100 — nunca expulsar
• Estado de subtarea activa y restricciones abiertas: prioridad 90
• Resultados fallidos de herramientas (los errores informan reintentos): prioridad 80
• Resultados exitosos de la cadena actual: prioridad 60
• Resultados exitosos de subtareas completadas: prioridad 40 — comprimir a ledger
• Chunks RAG obsoletos de subtareas previas: prioridad 20 — expulsar primero

Reiniciar contexto de trabajo en límites de subobjetivo. Cuando un agente termina "diagnosticar latencia de pagos" y empieza "redactar PR de remediación", la traza de diagnóstico se comprime a un ledger de cinco líneas. El estado persiste en memoria externa; el siguiente subobjetivo arranca con capa de trabajo limpia. Los runbooks que gobiernan agentes en producción codifican estos límites explícitamente — cada paso define qué evidencia entra al contexto y qué se archiva.

¿Cómo deben diseñar los equipos un presupuesto de ventana de contexto?

El diseño del presupuesto de ventana de contexto es tarea de ingeniería de primera clase para cualquier agente que salga del demo. Las preguntas siguientes cubren las decisiones que separan agentes confiables de chatbots caros.

¿Qué pertenece dentro de la ventana de contexto versus memoria externa?

Dentro de la ventana: todo lo necesario para elegir la siguiente acción — intención actual del usuario, restricciones activas, turnos recientes textuales, resultados de herramientas de la cadena abierta y chunks de retrieval directamente relevantes a este paso. Fuera de la ventana: historiales completos, documentos grandes, logs crudos, datasets completos y cualquier cosa recuperable por ID o query. La prueba es costo de retrieval versus costo de atención. Si traer un extracto de 2K tokens bajo demanda gana a mantener 50K tokens cargados "por si acaso", mantenerlo externo.

¿Cuándo debe un agente disparar compactación de contexto?

Disparar compactación en el umbral blando del presupuesto (~70%), no en el límite duro del proveedor. Triggers adicionales: cada K turnos en sesiones largas, al completar un subobjetivo, cuando los tokens de traza de herramientas superan la asignación de memoria de trabajo, y antes de inyectar un payload grande de retrieval. La compactación debe producir estado estructurado — todos, entidades fijadas, estrategias fallidas — no prosa narrativa. Ejecutar compactación con un modelo más chico si importa la latencia; validar que sobrevivieron identificadores de entidad.

¿Una ventana de contexto más grande elimina la necesidad de presupuestar?

No. Ventanas más grandes aumentan costo por turno, latencia de prefill y riesgo de lost-in-the-middle. Los modelos con capacidad de 1M tokens rinden mejor cuando el prompt contiene tokens de alta señal. El presupuesto es cómo los equipos imponen densidad de señal. El tamaño de ventana fija el techo; el presupuesto fija el objetivo.

Una visión opuesta

Un argumento frecuente sostiene que los límites de ventana de contexto son una restricción temporal de infraestructura — que modelos con 2M o 10M tokens harán obsoleto el presupuesto, y los equipos deberían cargar todo y dejar que los mecanismos de atención ordenen.

Ese argumento funciona para trabajos de análisis por lotes con un solo pase sobre documentos estáticos. Falla para agentes interactivos que ejecutan decenas de turnos con trazas de herramientas acumuladas, subobjetivos cambiantes y restricciones de costo en tiempo real. La investigación sobre retrieval en contexto largo muestra de forma consistente peor recall para información en el medio de prompts muy largos — el tamaño de ventana no elimina la economía de la atención.

Ventanas más grandes también elevan el costo del fallo silencioso. Un agente que "olvida" una restricción a 128K tokens es obviamente roto. Uno que pierde la misma restricción dentro de 800K tokens de ruido parece nunca haber tenido la información. Presupuestar fuerza decisiones explícitas sobre qué importa ahora — que es el trabajo real de la ingeniería de contexto.

Lo que importa recordar

• Un presupuesto de ventana de contexto es un plan de asignación por turno — no el máximo anunciado del proveedor.
• Apuntar a 60–75% de utilización; reservar margen para respuestas de herramientas y salida del modelo en cada turno.
• Asignar explícitamente entre capas de sistema, herramientas, memoria de trabajo y retrieval con reglas de expulsión.
• La salida de herramientas acumula más rápido que el historial de chat — comprimir en el límite antes de inyectar.
• Compactar al 70% preserva entidades y restricciones; el truncado ciego destruye continuidad de sesión.
• Contenido estable (system prompts, esquemas de herramientas) va al cache; estado volátil va a memoria externa.
• Ventanas más grandes aumentan costo y latencia — no eliminan la necesidad de presupuestar.

Conclusión

El paso de prompt engineering a context engineering es en realidad un paso de redacción a asignación. La pregunta ya no es "¿qué debe decir el system prompt?" sino "¿qué merece un token en este turno, y qué queda recuperable hasta que haga falta?" Los equipos que responden con un presupuesto escrito — topes por capa, triggers de compactación, prioridades de expulsión, instrumentación — envían agentes que mantienen coherencia en sesiones largas sin crecimiento lineal de costo. Los que tratan la ventana de contexto como checkbox de feature envían demos que funcionan cinco turnos y degradan en silencio después de veinte.

La siguiente decisión de diseño no es qué modelo tiene la ventana más grande. Es qué artefactos son lo bastante pequeños para fijar, qué salidas de herramientas se resumen por defecto y qué estado sobrevive un pase de compactación. Dejar esas decisiones explícitas antes de que el agente toque producción — porque cuando el fallo de contexto aparece en métricas, la sesión ya perdió el hilo.

Brief de la imagen de portada

Subject: a horizontal bar chart divided into four labeled segments (system, tools, memory, retrieval) with one segment highlighted as over capacity and a secondary gauge showing 72% utilization.

Composition: left-weighted budget bar on 65% of canvas; right 35% reserved for title overlay at H1 weight. Thin tick marks at 70% and 90% threshold lines.

Palette: #0F172A (slate-900 background), #22D3EE (cyan-400 for active layer), #F97316 (orange-500 for over-budget warning), #94A3B8 (slate-400 for inactive layers), #F8FAFC (slate-50 text).

Mood: precise, restrained.

Style guardrails: no 3D charts, no stock photography, no robot mascots, no glowing brain imagery. Flat vector with 1 px hairlines and monospace labels for layer names.

Format: 1200 × 630 PNG, exported at 2× for Retina, under 300 KB.