Google mata el historial: estado estructurado en vez de contexto acumulado (y por qué no es comprimir)

El Cuñado dice: "El contexto largo se arregla comprimiendo. Más ventana, un resumen cada tres pasos, LLMLingua si aprieta. El historial se queda; solo adelgazas."

La realidad es: el paper SKILL.state (arXiv:2608.26263), firmado desde Google LLC y Purdue, no adelgaza el historial. Lo saca del prompt. En cada paso el modelo ve tres cosas: la especificación inmutable de la skill (P), el estado estructurado actual (Σt) y la última observación (Ot). Ni acciones viejas, ni razonamientos previos, ni el chat entero.

Por qué importa saberlo: un runtime conversacional relee un historial que crece en cada turno. Complejidad O(T²) en tokens totales, prompt O(t) por paso. Eso degrada la latencia y abre la puerta al context poisoning cuando el horizonte se alarga. El problema no es la ventana. Es la acumulación.

El recorte de 16x ya cruzó al mainstream técnico en daily.dev. La cifra existe. El asterisco también.

Estado explícito, razonamiento a la basura

SKILL.state sustituye el historial append-only por un estado de ejecución explícito y mutable. El razonamiento intermedio, la traza CoT de ese paso, se descarta de forma permanente justo después de producir una actualización de estado validada. No vuelve a entrar en el prompt. Por eso el prompt deja de crecer con la ejecución.

El estado no es un resumen en prosa. Usa un esquema estructurado definido una vez por dominio, no por tarea. En los 100 retos de InterCode CTF reutilizan un único esquema estático de cinco campos: discovered_flags, tested_hypotheses, active_files, working_dir, cmd_summary. Cinco cajones para cien retos. Si no cabe en el esquema, no es un hecho operativo de esa skill.

En cada paso el modelo genera una terna (Rt, ΔΣt, at): la traza de razonamiento, un parche de estado como diccionario JSON (mutaciones y borrados; null elimina la clave) y la acción a ejecutar. El runtime valida el parche y lo fusiona: Σt+1 = Σt ⊕ ΔΣt. El modelo no reescribe el mundo entero. Propone un diff. Si el diff no pasa la validación, no entra.

El paper promete prompt O(1), acotado e independiente de los turnos previos, y coste acumulado O(T) en horizonte T. La Tabla 1 lo enseña sin metáfora: el prompt medio de SKILL.state se mueve entre 1.736 y 1.905 tokens de T=10 a T=200 (x1,02). El del baseline stateful estilo LangGraph pasa de 3.430 a 72.305 (x21,1). Plano contra explosión. No es un truco de tokenizer: es no reinyectar el pasado.

Encaja con una idea que ya hemos empujado en otra parte: los agentes no tienen que chatear. El chat es un canal. El estado es el trabajo.

Los números, con el asterisco puesto

Entorno sintético de almacén, T=100, Gemini-3-Flash, media de 5 seeds (Tabla 1 del paper; AlphaLab publica las mismas cifras). SKILL.state consume 65.408 ±5.431 tokens con score 0,94 ±0,01. El baseline stateful estilo LangGraph: 1.062.387 ±53.839 tokens y score 0,91 ±0,02. 93,84% menos tokens (16,2x) sin perder accuracy.

En los bancos públicos (Tabla 4) SKILL.state marca el mayor pass rate de los runtimes comparados en las tres tareas: 54,2% en InterCode CTF, 58,3% en τ-Bench Retail y 32,4% en τ-Bench Airline.

Ahí se acaba el titular limpio. El ahorro de tokens no se parece a un 94% plano:

• InterCode CTF: -60,39% vs ReAct y -65,75% vs stateful
• τ-Bench Retail: -22,54% y -11,48%
• τ-Bench Airline: -40,62% y -45,45%

Retail es el contraejemplo que hay que dejar escrito. El prompt medio de SKILL.state (3.325 tokens) es mayor que el de ReAct (2.819), Memory (2.737) y stateful (3.065). Reduce el token acumulado. No reduce el tamaño del prompt por paso. Quien venda "prompts más cortos siempre" está mintiendo con la Tabla 4 delante.

El 93,84% es el almacén sintético a T=100. Fuera de ese banco, contra stateful, el rango va del 11,48% al 65,75%. daily.dev se quedó con el 16x. El paper ya traía el asterisco.

A igual presupuesto, comprimir pierde

La prueba de fuego no es gastar menos. Es gastar lo mismo y ver quién acierta.

Tabla 5, almacén T=100, presupuesto de prompt igualado (~1.800 tokens). Ventana deslizante: score 0,18. Summary-capped: 0,52. ReAct+LLMLingua: 0,22. SKILL.state: 0,94. El ReAct completo, sin acotar, marca 0,84 con un prompt medio de 36.362 tokens; SKILL.state le saca 0,10 de score con 1.905.

A igual gasto, guardar hechos clave en estado tipado rinde más que truncar o resumir el historial. LLMLingua, la prensa que pedía el Cuñado, se queda en 0,22. El paper se posiciona frente a la compresión con esa tabla: en lugar de procesar o comprimir historiales largos, evita la acumulación manteniendo el estado canónico del siguiente cálculo.

El estado se puede perder sin que nadie grite

El enfoque tiene un modo de fallo feo. Lo mide el paper (sección 5.7) y AlphaLab lo pone en el centro: con el modelo abierto Gemma-4-31B a T=100 (score 0,42), el 68% de los fallos se clasifican como sobrescritura o borrado prematuro de información en el estado. Otro 20% es comprensión del schema o coerción de tipos. El 12% restante, sintaxis JSON. Suman 100%. El riesgo central no es que el prompt se pase de largo. Es que el estado se pise en silencio.

Un estado mutable sin invariantes es el mismo fallo que dejar que un evento viejo pise al nuevo: la última escritura gana, aunque sea la incorrecta.

El estado es memoria de trabajo, no sustituto del registro de auditoría.

AlphaLab lo deja en cuatro palabras: estado corto, log largo. Un log append-only fuera del prompt para auditar, depurar y reponer, con checkpoints e invariantes que el schema por sí solo no cubre. El log no desaparece. Sale del prompt.

El contexto es presupuesto; el log es otra memoria

Llevamos tiempo con una stance corta: el contexto es presupuesto. Lo que no hacemos es seguir empujando una sesión degradada: el coste en tokens sube y la calidad baja a la vez, que es la peor combinación posible. SKILL.state es esa frase llevada al extremo del runtime. En vez de seguir empujando un historial que crece, mantiene un estado canónico limpio.

En el concepto de las cuatro memorias de un agente, la de trabajo es presupuesto, no almacén. La Tabla 5 es esa frase con números: a igual presupuesto, elegir qué entra (estado tipado) rinde 0,94 contra 0,18 de truncar y 0,52 de resumir.

La episódica es otra cosa. "¿Qué decidimos sobre X?" no es una pregunta de similitud; es una consulta con filtro y orden por fecha. El paper separa las dos: estado (memoria de trabajo, dentro del prompt) y log (memoria episódica, fuera). AlphaLab lo confirma. Quien meta el diario entero en el prompt porque "así el modelo se acuerda" está pagando dos veces: tokens y confusión.

Hay un efecto colateral que el paper no mide y conviene no vender como resultado. SKILL.state mantiene un prefijo estático (spec + estado). El prompt caching, en la práctica, es igualdad de bytes del prefijo. Un prefijo que no se pudre con el chat hace el caching trivial. No hay cifras de cache hits en el material. Es mecánica, no milagro.

El historial es deuda

El contexto largo no se arregla comprimiendo. Se arregla no acumulando. Tampoco es gratis: el estado puede perderse en silencio, y por eso el log no desaparece, solo sale del prompt. El historial no es memoria, es deuda. Y la deuda se paga en tokens y en calidad.

Preguntas frecuentes

¿SKILL.state comprime el contexto de los agentes?

No. El paper (arXiv:2608.26263) se posiciona frente a la compresión: en lugar de procesar o comprimir historiales largos, evita acumularlos manteniendo el estado canónico del siguiente cálculo. En cada paso el modelo ve solo la especificación de la skill, el estado estructurado y la última observación. El razonamiento intermedio se descarta tras una actualización de estado validada.

¿Cuántos tokens ahorra SKILL.state?

Depende del banco. En el almacén sintético a T=100, con Gemini-3-Flash, gasta 65.408 tokens frente a 1.062.387 del baseline stateful estilo LangGraph: 93,84% menos (16,2x). En τ-Bench Retail el ahorro vs stateful baja al 11,48%, y el prompt medio de SKILL.state (3.325 tokens) es mayor que el de ReAct, Memory y stateful. No hay un 94% universal.

¿Qué pasa si el agente pierde el estado?

Falla, y a menudo sin avisar. Con Gemma-4-31B a T=100 (score 0,42), el 68% de los fallos se clasifican como sobrescritura o borrado prematuro de información en el estado. AlphaLab lo resume así: el estado es memoria de trabajo, no registro de auditoría. Hace falta un log append-only fuera del prompt, con checkpoints, para reponer lo que el schema no cubre.

¿Hay que borrar el historial si usas un estado estructurado?

No. El historial tiene que salir del prompt, no desaparecer. El estado corto cabe en el presupuesto de cada paso; el log largo sirve para auditar, depurar y reconstruir cuando una mutación se come un hecho. Estado corto, log largo: lo episódico se consulta con filtro y fecha, no se reinyecta entero en cada llamada.