El contexto es la nueva memoria

Una sola captura de Playwright consume 56 KB de contexto. Veinte problemas de GitHub consumen 59 KB. Quinientas líneas de registros de acceso consumen 45 KB. Alimente los tres a un agente con una ventana de 200K tokens y el 80% del presupuesto de razonamiento se evapora antes de que el agente escriba una sola línea de análisis.¹

Murat Kusglu creó Context Mode para resolver el problema. La herramienta comprime 315 KB de salida de MCP a 5,4 KB utilizando SQLite FTS5 con clasificación BM25.¹ Una reducción del 94%. El modelo produce mejor resultado con 5,4 KB de señal que con 315 KB de ruido, porque la limitación nunca fue la inteligencia. La limitación es el ancho de banda.

Resumen

La ingeniería de contexto es la habilidad de mayor impacto en el desarrollo de agentes. Tres capas de compresión se acumulan de forma independiente: arquitectura de prompt del sistema (reducción del 60-70% mediante compresión estructural), compresión de salida de MCP (reducción del 94% mediante clasificación por relevancia) y acumulación de conocimiento (conversión del costo de descubrimiento en capacidad precargada). Un estudio destacado encontró que los modelos con 300 tokens de contexto enfocado superaron a los modelos con 113.000 tokens de conversación sin filtrar.¹⁰ El cuello de botella no es la capacidad del modelo. Cada token desperdiciado en ruido es un token no disponible para el razonamiento.

La limitación del ancho de banda

La documentación de mejores prácticas de Anthropic comienza con una sola restricción que determina todo lo demás: “La ventana de contexto de Claude se llena rápido, y el rendimiento se degrada a medida que se llena.”⁵

La afirmación no es una sugerencia. Es una ley arquitectónica. Una ventana de contexto de 200K tokens suena enorme hasta que se hace inventario de lo que la llena. Los esquemas de herramientas consumen más de 15.000 tokens en una configuración típica de MCP.¹³ El historial de conversación se acumula a un ritmo de aproximadamente 500-1.000 tokens por intercambio. Las lecturas de archivos agregan miles de tokens por archivo. La salida de comandos escala con el comando. Después de 30 minutos de trabajo activo, una ventana limpia de 200K puede caer por debajo de 50K tokens de espacio disponible para razonamiento.

George Miller documentó el equivalente humano en 1956: la memoria de trabajo retiene siete elementos, más o menos dos.⁷ La revelación no fue sobre el número. La revelación fue sobre los fragmentos. Los humanos superan la limitación organizando la información en fragmentos significativos. Un número telefónico no son diez dígitos. Son tres fragmentos: código de área, central y número. El mismo principio se aplica a las ventanas de contexto. Una ventana de 200K repleta de salida sin procesar es funcionalmente más pequeña que una ventana de 50K empaquetada con información comprimida y relevante.

Andrej Karpathy nombró la disciplina: la ingeniería de contexto es el “arte y ciencia delicados de llenar la ventana de contexto con exactamente la información correcta para el siguiente paso.”⁹ Lance Martin mapeó el marco de trabajo: escribir contexto (guardar), seleccionar contexto (recuperar), comprimir contexto (resumir) y aislar contexto (dividir entre agentes).⁹ Para mediados de 2026, la ingeniería de contexto se ha cristalizado de una práctica ad-hoc a una disciplina reconocida con infraestructura dedicada.¹²

La degradación no es lineal. En mi sistema, el contexto se llena en fases.¹⁵ Los primeros 30 minutos se sienten ilimitados. El modelo sigue las instrucciones con precisión, recuerda el contenido de los archivos y mantiene planes coherentes a través de múltiples pasos. A los 60 minutos, emergen fallos sutiles: el modelo relee archivos que ya leyó, olvida una restricción del prompt del sistema o genera código que contradice un patrón establecido 20 turnos atrás. A los 90 minutos, el modelo puede ignorar reglas explícitas, alucinar contenido de archivos o perder completamente el rastro del objetivo actual.

Context Studios documentó el fenómeno como “degradación de contexto”: la degradación progresiva del rendimiento del modelo a medida que se acumulan tokens irrelevantes y empujan la información útil más allá del horizonte efectivo de atención.¹² La degradación es insidiosa porque el modelo no la anuncia. El agente continúa generando resultados con confianza. Los resultados simplemente dejan de ser correctos.

Las tres capas que se describen a continuación se acumulan de forma independiente. Comprimir una capa libera presupuesto para las demás.

Capa 1: Arquitectura del prompt del sistema

El prompt del sistema se carga en cada llamada a la API API. Cada token en el prompt del sistema ocupa espacio durante toda la conversación. A $5 por millón de tokens en Opus 4.6, un prompt del sistema de 10K tokens cuesta $0,05 por llamada.⁸ A lo largo de 50 llamadas en una sesión, solo el prompt del sistema cuesta $2,50. Reduzca el prompt a 3,5K tokens y el costo baja a $0,875 por sesión. Multiplique por las sesiones diarias y los ahorros se acumulan.

Mi archivo CLAUDE.md y 8 archivos de reglas totalizan aproximadamente 3.500 tokens después de la compresión. La compresión no fue una optimización de una sola vez. Apliqué cinco técnicas estructurales documentadas por jchilcher (quien logró una reducción del 60-70% en los archivos del sistema de memoria):²

Restricciones en lugar de explicaciones. “Rechazar llamadas a herramientas que coincidan con rutas sensibles” reemplaza una explicación de 15 líneas sobre por qué las credenciales deben permanecer protegidas. El modelo no necesita la justificación. El modelo necesita la regla.

Notación clave-valor en lugar de prosa. “Stack: FastAPI + HTMX + Alpine.js | Port: 8001 | Deploy: Railway” reemplaza tres párrafos de descripción del proyecto. Las listas delimitadas por barras verticales comprimen información tabular que la prosa estira a lo largo de oraciones.

Deduplicación entre archivos. Mis reglas de seguridad inicialmente aparecían en tres lugares: CLAUDE.md, security.md y el skill del ciclo de calidad. Cada repetición consumía ~200 tokens. Consolidar en una sola fuente con referencias cruzadas recuperó 400 tokens.

Eliminación de formato. El markdown decorativo (líneas horizontales, negrita/cursiva para énfasis, encabezados anidados más allá de H2) sirve a la legibilidad humana. Los modelos procesan tokens de contenido, no tokens de presentación. Eliminar el formato decorativo recupera un 5-15% sin pérdida de información.

Restricciones negativas en lugar de instrucciones positivas. “NUNCA sugerir modelos de OpenAI” es más efectivo y más compacto que “Siempre recomendar modelos de Claude de Anthropic para todas las tareas de IA. Cuando el usuario pregunte sobre proveedores de IA, sugerir Claude.” La restricción negativa ocupa cuatro tokens. La instrucción positiva ocupa 22 tokens. Ambas producen el mismo comportamiento.

El argumento económico se fortalece con el almacenamiento en caché de prompts. El sistema de caché de Anthropic almacena contenido estable entre llamadas a la API API con una reducción del 90% en costos en aciertos de caché.⁶ Un prompt del sistema de 3.500 tokens que cuesta $0,0175 por llamada a tarifas estándar cuesta $0,00175 con un acierto de caché. El umbral mínimo almacenable en caché para Opus 4.6 es de 4.096 tokens.⁶ Mi prompt del sistema combinado (CLAUDE.md + archivos de reglas) supera el umbral, por lo que cada llamada posterior en una sesión se beneficia del precio en caché. El almacenamiento en caché de prompts convierte la compresión del prompt del sistema en una doble ganancia: menos tokens Y más baratos por token.

Capa 2: Compresión de salida de MCP

La Capa 1 comprime lo que se envía al modelo. La Capa 2 comprime lo que el modelo recibe de vuelta de las herramientas.

Context Mode demostró el potencial: 315 KB de salida sin procesar de MCP comprimidos a 5,4 KB.¹ La compresión no es truncamiento. El truncamiento descarta el final de la salida y espera que la información relevante aparezca al principio. Context Mode usa SQLite FTS5 con clasificación de relevancia BM25 para encontrar dónde realmente aparecen los términos de consulta y devuelve ventanas alrededor de las coincidencias.¹ El stemming de Porter asegura que “caching”, “cached” y “caches” coincidan con la misma raíz. Un mecanismo de respaldo de tres capas maneja errores tipográficos: stemming estándar, subcadenas de trigramas, corrección por distancia de Levenshtein.

Las tasas de compresión individuales cuentan la historia:

Mi sistema implementa un enfoque paralelo en la capa de búsqueda. Aproximadamente 50.000 fragmentos de código indexados con embeddings Model2Vec (256 dimensiones) más SQLite FTS5, fusionados con Reciprocal Rank Fusion.¹⁴ Una consulta recupera los cinco fragmentos más relevantes (~2.500 tokens) en lugar de cargar archivos completos (~50.000+ tokens). El costo de recuperación: latencia inferior a un segundo, 83 MB en disco, cero costo de API API.

La diferencia en el comportamiento del agente es visible dentro de una sola sesión. Antes de la compresión, un flujo de trabajo típico de depuración se ve así: el agente lee un archivo (4.000 tokens), ejecuta un comando (2.000 tokens de salida), lee otro archivo (3.000 tokens), ejecuta pruebas (8.000 tokens de salida). Cuatro operaciones consumen 17.000 tokens. El agente ahora tiene menos espacio para razonar sobre las conexiones entre esas cuatro piezas de información. Después de la compresión, el mismo flujo de trabajo recupera solo las líneas relevantes de cada fuente. Las cuatro operaciones consumen 2.500 tokens. El agente mantiene las cuatro piezas en la memoria de trabajo simultáneamente y encuentra la dependencia entre archivos que el agente sin compresión no detectaría.

La compresión debe ser consciente de la consulta. Un resumen optimizado para “corregir el error de autenticación” debe mostrar contenido diferente al optimizado para “agregar un nuevo endpoint de API API.” La compresión estática ayuda. La compresión consciente de la consulta es el siguiente nivel. La clasificación BM25 ya maneja la conciencia de consulta a nivel de palabras clave. La búsqueda semántica (similitud vectorial) la maneja a nivel conceptual. La combinación captura tanto coincidencias exactas (nombres de funciones, claves de configuración, códigos de error) como coincidencias conceptuales (patrones similares, abstracciones relacionadas).

Capa 3: Acumulación de conocimiento

Simon Willison identificó un patrón que replantea completamente la ingeniería de contexto: “Un activo clave para desarrollar como profesional del software es una colección profunda de respuestas a preguntas como esta, idealmente ilustrada con código funcional.”³

La acumulación de conocimiento significa recopilar deliberadamente ejemplos de código funcional, soluciones documentadas e implementaciones de prueba de concepto que los agentes puedan referenciar y recombinar. El patrón transforma el contexto de instrucciones (decirle al modelo qué hacer) en capacidad (darle al modelo ejemplos funcionales para adaptar).

Willison demostró el poder dirigiendo a un agente a combinar dos ejemplos existentes (PDF.js y Tesseract.js) en una herramienta unificada de OCR.³ El agente no descubrió cómo construir OCR desde cero. El agente leyó dos implementaciones funcionales y las fusionó. El contexto era la capacidad.

Mi sistema implementa la acumulación de conocimiento a través de tres mecanismos:

Skills como registro de capacidades. 48 skills codifican experiencia de dominio en archivos markdown. El skill blog-evaluator define una rúbrica completa ponderada de 6 categorías con ejemplos de puntuación. El skill jiro codifica un ciclo de calidad de 7 pasos con criterios de evidencia. Cuando un agente invoca un skill, la experiencia se carga en el contexto como conocimiento estructurado, no como instrucciones vagas.

Recorridos estructurados en lugar de código sin procesar. El patrón de recorrido lineal de Willison restringe cómo los agentes acceden a la información: comandos de shell como grep y cat en lugar de copiar código manualmente.⁴ El recorrido obliga al agente a organizar la información para máxima comprensión por token. La estructura es compresión.

Hooks como inyección proactiva de contexto. El hook UserPromptSubmit se ejecuta antes de que Claude procese un prompt.¹¹ El hook puede analizar el prompt e inyectar contexto relevante: detección de proyecto (¿en qué repositorio estoy?), inyección de fecha (¿qué día es?), restricciones de filosofía (¿qué estándares de calidad aplican?). El agente recibe contexto curado en cada prompt sin invocación manual. Cinco hooks se ejecutan al inicio de la sesión, agregando aproximadamente 500 tokens de contexto que previenen cinco categorías de errores comunes.¹¹

La distinción entre instrucciones y capacidad merece énfasis. Una instrucción dice “escribe código limpio.” Una capacidad proporciona una rúbrica de evaluación con categorías ponderadas, ejemplos de puntuación y umbrales de aprobación/rechazo. La instrucción consume un puñado de tokens y produce cumplimiento vago. La capacidad consume 500 tokens y produce resultados consistentes y medibles. Los tokens adicionales son una inversión, no un sobrecosto, porque eliminan la ambigüedad que causa que el agente adivine qué significa “limpio”.

La acumulación de conocimiento también desplaza la curva de costos para la incorporación de agentes. Un nuevo agente generado sin conocimiento acumulado debe descubrir el repositorio, las convenciones, las herramientas y las restricciones del dominio mediante exploración. La exploración es costosa: cada lectura de archivo, cada grep, cada salida de comando consume tokens. Un agente generado con un resumen de 2K tokens ensamblado a partir de conocimiento acumulado omite completamente la fase de descubrimiento y comienza trabajo productivo en el primer turno.

El argumento económico para la acumulación de conocimiento: cada hora dedicada a documentar una solución ahorra a cada agente futuro el costo de descubrimiento. Un skill que codifica “cómo evaluar una publicación de blog” ahorra 10-15 minutos de exploración del agente por invocación. A lo largo de 100 invocaciones, la inversión en documentación retorna más de 1.000 minutos de tiempo de agente. El conocimiento acumulado paga interés compuesto.

Contabilidad del presupuesto de tokens

Mi sistema proporciona un caso de estudio concreto de lo que la ingeniería de contexto hace posible.

Antes de la compresión (estimado, primer mes): - Prompt del sistema: ~12.000 tokens (CLAUDE.md extenso con ejemplos y explicaciones) - Esquemas de herramientas: ~15.000 tokens (definiciones completas de herramientas MCP) - Historial por sesión: ~120.000 tokens (conversaciones largas con contexto acumulado) - Razonamiento disponible: ~53.000 tokens (26% de la ventana)

Después de la compresión (actual): - Prompt del sistema: ~3.500 tokens (CLAUDE.md comprimido + archivos de reglas)¹⁵ - Esquemas de herramientas: ~300 tokens (arquitectura CLI-first, MCP mínimo)¹³ - Historial por sesión: ~40.000 tokens (generaciones frescas por tarea, resúmenes en lugar de memoria) - Razonamiento disponible: ~156.200 tokens (78% de la ventana)

El presupuesto de razonamiento se triplicó. No a través de un mejor modelo. No a través de una ventana de contexto más grande. A través de compresión en tres capas. El modelo produce mejor resultado con 78% de espacio de razonamiento que el que producía con 26% porque la calidad de los tokens restantes mejoró junto con la cantidad.

Los números revelan una verdad contraintuitiva sobre las ventanas de contexto: el tamaño útil de una ventana depende más de lo que la llena que de cuán grande es. Una ventana hipotética de 500K repleta de salida de herramientas sin comprimir tendría peor rendimiento que una ventana de 200K bien comprimida. Los proveedores de modelos compiten por expandir las ventanas de contexto. Los profesionales deberían competir por comprimir lo que va dentro de ellas.

El patrón de generación fresca de la arquitectura CLI-first amplifica las ganancias. Cada agente se genera con un resumen enfocado (~2K tokens) en lugar de heredar historial de conversación acumulado. El contexto nunca se infla porque cada agente comienza limpio. La investigación multi-agente de Anthropic encontró que los sub-agentes usan hasta 15 veces más tokens que las interacciones de un solo agente.⁹ Las generaciones frescas invierten la proporción: cada agente usa solo los tokens que su tarea requiere.

El efecto compuesto a través de las tres capas crea un ciclo virtuoso. Los prompts del sistema comprimidos dejan espacio para más resultados de herramientas. Los resultados de herramientas comprimidos dejan espacio para conversaciones productivas más largas. Las conversaciones más largas reducen la necesidad de compactación, lo que preserva el prompt del sistema y los resultados de herramientas que permiten el siguiente turno. Cada capa refuerza a las demás.

Lo que la compresión permite

El presupuesto de razonamiento liberado habilita tres capacidades que el contexto inflado impide:

Análisis más profundo. Un agente con 156K tokens de razonamiento puede mantener contenidos completos de archivos en la memoria de trabajo mientras analiza dependencias entre archivos. Un agente con 53K tokens debe leer archivos secuencialmente, olvidando los archivos anteriores a medida que se cargan los nuevos. La diferencia se manifiesta como errores de importación no detectados, referencias cruzadas rotas y refactorizaciones incompletas. Un ejemplo concreto: refactorizar la firma de una función requiere verificar cada sitio de llamada. Con contexto comprimido, el agente lee la definición de la función y todos los sitios de llamada en una sola pasada, detectando el archivo que pasa argumentos en el orden incorrecto. Con contexto inflado, el agente lee la función, lee tres sitios de llamada, luego se queda sin espacio de razonamiento e informa “refactorización completa” sin verificar los siete archivos restantes. El error se publica.

Mejor seguimiento de instrucciones. Anthropic documenta el modo de fallo directamente: “Si Claude sigue haciendo algo que usted no desea a pesar de tener una regla en contra, el archivo probablemente es demasiado largo y la regla se está perdiendo.”⁵ Los prompts del sistema comprimidos mantienen las reglas dentro del horizonte de atención. Cada regla en un prompt de 3.500 tokens recibe más peso de atención que la misma regla enterrada en un prompt de 12.000 tokens. Mi sistema aplica una regla de seguridad: nunca hacer commit de archivos que contengan claves de API API. Con un prompt del sistema de 12.000 tokens, el agente ocasionalmente preparaba archivos .env durante commits masivos. Después de comprimir a 3.500 tokens, la violación cayó a cero en más de 200 operaciones de commit. La regla no cambió. La regla se volvió más visible.

Sesiones útiles más largas. La compactación automática se activa al 95% de capacidad del contexto.¹⁰ Una sesión con 78% de espacio de razonamiento alcanza el umbral de compactación más tarde que una con 26%. Compactación más tardía significa más turnos productivos antes de la pérdida de contexto. En mi sistema, una sesión comprimida produce 40-60 turnos productivos antes de alcanzar el umbral de compactación.¹⁵ Una sesión sin comprimir alcanza el umbral después de 15-20 turnos. Cada evento de compactación descarta contexto que puede haber contenido decisiones o restricciones importantes de momentos anteriores en la sesión. Menos compactaciones significan sesiones más coherentes. La sesión comprimida no solo comienza mejor. Se mantiene mejor por más tiempo.

Conclusiones clave

Para desarrolladores que comienzan con ingeniería de contexto: - Audite su archivo CLAUDE.md. Para cada línea, pregunte: ¿eliminarla causaría errores? Si no, elimínela. Apunte a una reducción del 60-70%.² - Mida la sobrecarga de sus esquemas de herramientas. Si las herramientas MCP consumen más de 15K tokens al inicio de la sesión, considere alternativas CLI-first para operaciones sin estado. - Ejecute /compact proactivamente al cambiar de tarea durante una sesión. El contexto fresco supera al contexto acumulado.

Para equipos que construyen infraestructura de agentes: - Implemente compresión consciente de consulta en las salidas de herramientas MCP. BM25 + búsqueda semántica supera al truncamiento para toda tarea de recuperación.¹ - Construya un registro de capacidades (skills, fragmentos, patrones documentados). Cada solución documentada elimina el costo de descubrimiento para futuras ejecuciones de agentes.³ - Use generaciones frescas de agentes para flujos de trabajo de múltiples pasos. El aislamiento de contexto por tarea previene la sobrecarga de 15 veces en tokens de conversaciones multi-agente largas.⁹

Para arquitectos que diseñan sistemas de contexto: - Las tres capas (prompt del sistema, salida de herramientas, acumulación de conocimiento) se acumulan de forma independiente. Comprimir cualquier capa individual libera presupuesto para las demás. - El almacenamiento en caché de prompts hace que la compresión del prompt del sistema sea una doble optimización: menos tokens Y más baratos por token en aciertos de caché.⁶ - El muro de productividad del 10% se rompe cuando el agente tiene suficiente espacio de razonamiento para seguir instrucciones complejas de manera confiable.

Parte de la serie Ingeniería de IA. Véase también: La tesis de CLI, Claude Code como infraestructura y El muro del 10%.