Por Qué Tu Agente de IA Pierde el Hilo a los 30 Minutos

Si usas agentes de IA para desarrollar software — Claude Code, Cursor, Copilot, Codex, Gemini CLI — seguro que te ha pasado esto:

Empiezas una conversación. Le explicas la feature. El agente entiende perfectamente, explora el código, propone una solución sólida. Todo va bien.

A los 20 minutos sigue respondiendo bien, pero notas que repite cosas que ya dijo. A los 40 minutos genera código que contradice una decisión que tomasteis juntos 15 mensajes antes. A la hora, estás gastando más tiempo corrigiendo al agente que programando tú mismo.

No es un bug. Es cómo funcionan los tokens — y se puede solucionar.

##Qué son los tokens y por qué importan

Un token es la unidad mínima que un modelo de lenguaje procesa — no exactamente una palabra, más bien un fragmento. "Implementar" puede ser 1-2 tokens; "desestructuración" puede ser 3-4.

Cada modelo tiene una ventana de contexto: la cantidad máxima de tokens que puede "ver" a la vez. En febrero de 2026:

200K tokens suena a muchísimo. Pero cuando trabajas en un proyecto real — archivos de código, conversación acumulada, instrucciones de sistema, respuestas previas — la ventana se llena más rápido de lo que esperas.

Cuando la conversación supera la ventana, el modelo compacta los mensajes anteriores. Tanto Claude como OpenAI incorporan compactación automática: cuando el contexto se acerca al límite, la API resume las partes más antiguas. Esto permite conversaciones técnicamente "infinitas", pero se descartan detalles. Se resumen decisiones. Se pierden matices.

Y el problema real: tú no sabes qué se ha perdido. El modelo no te dice "acabo de olvidar que decidimos usar PostgreSQL". Simplemente actúa como si esa decisión nunca existió. O peor: la recuerda parcialmente y genera algo inconsistente.

Eso son tokens degradados. Tokens que técnicamente existen en el contexto, pero cuya calidad de información se ha deteriorado.

##El enfoque "conversación única": simple pero frágil

El flujo que usa la mayoría de desarrolladores:

1. Abres una conversación
2. Describes lo que necesitas
3. El agente explora, discutís, implementa
4. Corriges, iteras, ajustas hasta terminar

Todo en un solo contexto. Intuitivo y natural. El problema es que cada mensaje se acumula:

Una sesión mediana ya consume entre el 21% y el 58% de una ventana de 200K. Sin contar que las respuestas del modelo también cuentan como tokens de entrada en el siguiente turno.

Cuando se acerca al límite, el sistema compacta. Los síntomas:

• Alucinaciones contextuales: genera funciones que ya existen
• Pérdida de decisiones: olvida restricciones del principio
• Código inconsistente: un archivo sigue un patrón, otro sigue otro distinto
• Repetición: explica cosas que ya explicó

Y lo que nadie mide: el coste de los tokens de corrección. Cada vez que le dices "no, habíamos decidido usar X", estás consumiendo tokens. En una sesión larga, entre el 30% y el 50% de los tokens pueden ser retrabajo puro.

##El patrón de orquestador + sub-agentes

Existe otra forma de trabajar. En vez de una conversación monolítica, divides el flujo en fases, y cada fase la ejecuta un agente independiente con contexto limpio.

Un agente orquestador coordina el flujo. No hace el trabajo — solo decide qué agente lanzar, con qué información, y presenta resultados entre fases.

Piénsalo así: en vez de un empleado que hace todo — investiga, planifica, diseña, implementa, testea — tienes un coordinador de equipo y especialistas. El coordinador solo necesita saber qué se ha hecho, qué falta, y quién lo hace.

###Cómo funciona en la práctica

Fase 1 — Exploración. Un sub-agente lee el código relevante y devuelve un resumen estructurado. Termina y su contexto se libera.

Fase 2 — Propuesta. Otro sub-agente recibe el resumen y produce una propuesta con alcance y criterios de éxito. El desarrollador la revisa.

Fase 3 — Especificación. Otro agente toma la propuesta aprobada y escribe especificaciones detalladas.

Fase 4 — Diseño técnico. Otro agente analiza la spec y produce decisiones de arquitectura.

Fase 5 — Implementación. Otro agente recibe specs + diseño y escribe código. Sin exploraciones ni debates — contexto 100% dedicado a implementar.

Fase 6 — Verificación. Otro agente ejecuta tests y verifica que el código cumple las specs.

Cada sub-agente nace, hace su trabajo y termina. El orquestador solo retiene resúmenes entre fases.

##El modelo adecuado para cada tarea

Con un flujo orquestado, cada sub-agente puede usar un modelo diferente. Y los modelos no solo se diferencian en precio — se diferencian en tipo de pensamiento:

La idea: usa el modelo premium donde un error tiene consecuencias graves, y el modelo eficiente donde el trabajo es más mecánico.

En un flujo de autenticación OAuth2, por ejemplo, usarías un modelo rápido para explorar el código y redactar la propuesta. Un modelo de razonamiento profundo para diseñar la estrategia de tokens y sesiones — donde un error de seguridad es crítico. Y vuelta al modelo eficiente para la implementación que sigue una spec ya validada.

El componente muestra un ejemplo con la familia Claude — pero el principio aplica a cualquier combinación de modelos y proveedores.

##La verdad sobre el consumo de tokens

Seamos honestos: un flujo orquestado consume más tokens en total. Cada sub-agente necesita cargar contexto desde cero — instrucciones, artefactos previos, código fuente. Hay duplicación inevitable.

La diferencia está en una línea que no aparece en la tabla: retrabajos por contexto degradado: 0.

La ventaja no aparece en features pequeñas. Si tu tarea cabe en 20 minutos, no necesitas orquestación. La diferencia se vuelve radical en features que requieren más de una hora, que cruzan múltiples dominios (frontend, backend, infra), o que se extienden a lo largo de varios días. En una conversación única, el coste de retrabajos crece exponencialmente conforme el contexto se degrada. En un flujo orquestado, cada sub-agente trabaja con la misma calidad en la fase 6 que en la fase 1.

Y aunque los proveedores ofrecen compactación automática, sigue siendo compresión con pérdida — el resumen descarta información que, para tu tarea concreta, podría ser crítica.

##El problema de la amnesia entre agentes

Si cada sub-agente nace con contexto limpio, ¿cómo sabe qué ha pasado antes?

La respuesta obvia es pasarle todo el output anterior. Pero eso recrearía la acumulación de contexto del enfoque monolítico. Lo que necesitamos es memoria selectiva: que cada agente acceda a lo que necesita, sin cargar todo el historial.

###Engram: memoria persistente para agentes

Engram resuelve esto con un enfoque de "progressive disclosure aplicado a tokens".

Es un binario en Go con SQLite y búsqueda full-text, compatible con cualquier agente MCP. Sin dependencias externas. Se instala en un minuto con Homebrew, y engram setup claude-code configura todo.

Tres conceptos clave:

Observaciones: la unidad de memoria. Cada una es un resumen estructurado — una decisión, un bug resuelto, un patrón establecido. Con título, tipo, contenido y timestamp.

Sesiones: contexto temporal. Al terminar, el agente genera un resumen. La siguiente sesión arranca con ese contexto.

Topic keys: claves que permiten upserts. Si guardas una decisión con clave auth/strategy y después la actualizas, Engram modifica la existente. La memoria evoluciona, no crece indefinidamente.

###El patrón de progressive disclosure

Cuando un sub-agente necesita información anterior, no carga el artefacto completo:

Paso 1 — Búsqueda: busca en Engram con una query. Recibe resultados compactos — título, fragmento y un ID. Cada resultado: ~100 tokens.

Paso 2 — Recuperación selectiva: solo si necesita el contenido completo, recupera la observación por ID.

Un sub-agente de implementación puede buscar "decisiones de diseño para feature X", obtener 5 resultados por ~500 tokens, leer en detalle solo los 2 relevantes, y no cargar nunca los otros 3.

A escala de un flujo completo con 6 sub-agentes, esta diferencia acumulada puede suponer entre 15.000 y 30.000 tokens menos. No es un ahorro espectacular en coste absoluto, pero son tokens que no ocupan espacio en la ventana, dejando más margen para el trabajo real del sub-agente.

##Los outputs de herramientas: el vector olvidado

Hay un vector de consumo que casi nadie menciona: los outputs de las herramientas que el agente usa.

Cuando un agente trabaja, usa herramientas MCP: lee ficheros, ejecuta comandos, hace snapshots del navegador. Cada resultado entra directamente en la ventana de contexto.

Datos reales: navegué con Playwright al repo de Engram, listé 20 issues de vercel/next.js con gh, y procesé logs y tests generados con datos realistas. Solo esas cinco operaciones suman ~278 KB — más del 100% de una ventana de 200K tokens. Cloudflare identificó este problema con sus servidores MCP: con 81 herramientas activas, 143K tokens se consumían antes del primer mensaje del usuario.

###Context Mode: sandbox para outputs

Context Mode se interpone entre el agente y los outputs de sus herramientas. Los datos crudos nunca entran en la ventana — se procesan en un sandbox aislado, y solo un resumen entra en la conversación.

El resultado medido en operaciones reales: 278 KB de output crudo → 2,1 KB. Una reducción del 99,3%.

El efecto acumulado: el tiempo antes de que el agente empiece a degradarse pasa de ~30 minutos a ~3 horas.

##Las cuatro capas juntas

Cada capa ataca el problema desde un ángulo distinto:

• Orquestación → contexto limpio por fase
• Selección de modelo → coste vs calidad optimizado
• Engram → memoria selectiva entre agentes
• Context Mode → outputs de herramientas comprimidos

No todo necesita las cuatro capas. Para una tarea de 30 minutos en 1-3 archivos, una conversación directa es perfecta. Considera orquestación cuando la feature requiere más de una hora, cruza múltiples dominios, o necesitas retomar al día siguiente. Añade memoria persistente cuando trabajas en un proyecto durante días y las decisiones de hoy afectan al código de mañana.

##El futuro: tokens como recurso

Las ventanas de contexto se disparan. Claude Opus ya tiene 1M en beta. Gemini 2.5 Pro trabaja con 1M de serie. Pero más contexto no significa mejor contexto — cuanto más contenido hay en la ventana, más difícil es para el modelo centrarse en lo relevante.

La optimización real no es meter más tokens. Es asegurarte de que cada token en la ventana es relevante para la tarea actual.

Tokens enfocados. Tokens frescos. Tokens elegidos. Tokens al precio justo.

No es gastar menos. Es gastar mejor.