Harness de memoria comprimida para agentes: sin vagancia ni alucinaciones de historial

El experimento de OpenAI que dio origen a esta guía

Cuando OpenAI empezó a experimentar en serio con agentes de larga duración, encontraron un problema que no esperaban: cuanto más rico era el historial, menos herramientas llamaban los modelos.

No era un fallo del modelo en el sentido clásico. Era un fallo del instrumento.

El experimento en cuestión usaba ARC-AGI como banco de pruebas: un conjunto de tareas de razonamiento abstracto diseñadas específicamente para medir si un sistema realmente razona o si está reciclando patrones memorizados. La puntuación base de los agentes antes de intervenir en el harness era mediocre. Cuando OpenAI ajustó cómo el historial se presentaba al modelo (separando contexto comprimido de resultados frescos de herramientas y forzando tool calls en turnos que lo requerían), la puntuación se triplicó en ARC-AGI.

No cambiaron el modelo. No reentrenaron nada. Cambiaron el arnés.

El mecanismo que fallaba era predecible en retrospectiva: los agentes acumulaban resúmenes de conversaciones anteriores, preferencias, decisiones, contexto de todo lo que había pasado, y al llegar un turno que exigía datos frescos (precio, estado, inventario, resultado de búsqueda), el modelo miraba ese historial denso y bien escrito y decía, en esencia: "ya está, ya lo sé todo". Sin una sola tool call.

El patrón tenía nombre: vagancia inducida por el historial. Y la causa no era la arquitectura del modelo sino cómo estaba construida la capa que decidía qué ponerle delante. El resumen comprimido se parecía demasiado a una respuesta resuelta. El modelo no distinguía "contexto previo comprimido" de "dato obtenido ahora", porque nadie lo había marcado de forma diferente.

Triplicar la puntuación en ARC-AGI sin tocar el modelo es el argumento más contundente que existe para tomarse el harness en serio. No como optimización opcional: como condición de funcionamiento. De ahí nació la necesidad de un harness de memoria comprimida con criterio: no solo comprimir para ahorrar tokens, sino diseñar exactamente qué se guarda, qué se descarta, cómo se etiqueta y qué señales disparan la alarma cuando algo falla. Esta guía es eso.

Qué es un harness de memoria comprimida (y para qué sirve)

Un agente no "recuerda" como tú. Tiene una ventana de contexto finita, un montón de turnos detrás y la tentación constante de rellenar huecos con algo que suene bien. El harness de memoria comprimida es la capa que decide qué se guarda, qué se resume, qué se descarta y qué se le vuelve a poner delante cuando el hilo se hace largo.

No es magia. Es fontanería de contexto: comprimes para no reventar tokens, pero sin convertir el resumen en una verdad sagrada que el modelo reutilice como si fuera un resultado fresco de herramienta.

El problema que resuelve es simple de enunciar y difícil de clavar:

• Sin compresión, el historial come la ventana y el agente se vuelve amnésico a lo reciente o carísimo de ejecutar.
• Con compresión cutre, el agente se vuelve vago: mira un resumen bonito, decide que "ya está en el historial" y deja de llamar herramientas.
• Con compresión mentirosa, el agente alucina capacidades o datos: trata un párrafo de resumen como si fuera una API response actualizada.

La promesa de esta guía no es "x10 productividad". Es más prosaica: que sepas montar el arnés (reglas, recall, marcas de resumen, instrumentación) para que comprimir no sea sinónimo de degradar.

Antes de creer un veredicto negativo sobre el modelo, verifica el instrumento. Muchas veces el fallo no es "el LLM es tonto": es que el harness le está mintiendo con la forma del contexto.

El fallo que nadie instrumenta: historial rico, cero herramientas

Hay un patrón que se repite hasta la náusea. El agente acumula un historial "bueno": preferencias del usuario, decisiones previas, un resumen de lo hablado. Llega un turno que exige datos frescos (precio, estado, inventario, log, resultado de búsqueda) y el modelo responde de pecho, sin una sola tool call.

Eso no es eficiencia. Es un fallo de diseño disfrazado de ahorro.

¿Por qué pasa? Porque un resumen bien escrito se parece demasiado a una respuesta de herramienta. Si no lo marcas, el modelo no distingue "contexto previo comprimido" de "dato obtenido ahora". Y si además metiste cifras con caducidad dentro del resumen (un total, un stock, una fecha de entrega), le diste permiso implícito para reciclar basura con pinta de verdad.

La postura de diseño aquí es clara y poco romántica:

• Cero tool calls en un turno clasificado como "necesita datos" es un fallo, no un ahorro.
• La regla en el prompt ("usa herramientas cuando necesites datos actuales") es necesaria y no suficiente. Sin red que lo compruebe, es decoración.
• El historial comprimido se marca como tal. Cada bloque de resumen lleva marca temporal y una etiqueta explícita del estilo "contexto previo, no dato actual".
• Los datos con caducidad no entran en el resumen. Al comprimir, te quedas con decisiones y preferencias; tiras las cifras. Es la regla más eficaz y la que más se olvida.

Si montas compresión sin estas cuatro piezas, no tienes un harness: tienes un generador de agentes confiados y vagos.

Las cuatro memorias (y por qué cada una pide un mecanismo distinto)

Hablar de "la memoria del agente" en singular es el primer error de novato. En la práctica conviven al menos cuatro capas con trabajos distintos. Mezclarlas en un único saco es como guardar llaves, leche y gasolina en la misma nevera.

1. Memoria de trabajo

Es el contexto activo: system, instrucciones del turno, últimos mensajes, salida de herramientas de esta petición. Vive y muere con la ventana. Si la hinchas de basura, el modelo deja de ver lo importante aunque "esté" en el prompt.

2. Memoria conversacional comprimible (el hilo largo)

El chat que crece. Aquí entra el compresor: resume, recorta, etiqueta. Su trabajo no es archivar la realidad del mundo; es conservar continuidad de la conversación sin pagar el historial entero cada vez.

3. Memoria de doctrina / reglas (lo que debe cumplirse siempre)

Políticas duras: formatos, prohibiciones, invariantes de negocio, estilo, límites de seguridad operativa. Esto no puede depender de que el agente "se acuerde de buscarlo". Si tiene que cumplirse siempre, va delante, no al final de una retrieval feliz.

4. Memoria de recall (lo que quizá necesite)

Notas, documentos, tickets, runs anteriores, conocimiento de proyecto. Aquí sí tiene sentido un buscador o un almacén con recuperación bajo demanda. Es memoria de "por si acaso", no de "o te fusilo".

La trampa clásica: montar un vault precioso con buscador encima y dejarlo todo a la búsqueda. Suena elegante. Falla en silencio. Un agente no busca lo que no sabe que ignora. La regla "el dinero nunca en coma flotante" solo sirve si está presente cuando escribe la línea, no si tiene que sospechar que existe una nota en algún sitio.

El error simétrico también existe: inyectar doscientas notas de oficio en cada turno. Te comes el presupuesto de contexto y, a partir de cierto punto, el modelo deja de distinguir lo sagrado de lo accesorio. Más contexto no es más inteligencia; a menudo es más ruido con traje.

Si quieres profundizar en por qué la memoria de conversación no debería vivir solo en el redactor del prompt, el enfoque de memoria determinista en la capa de datos va en la misma dirección: menos fe en el monólogo del modelo, más estructura fuera del chat.

Reglas siempre delante; recall bajo demanda

Esta es la bisagra del harness y donde la gente se pelea con su propio ego de arquitecto.

Lo que el agente debe saber SIEMPRE va en reglas. Lo que quizá necesite va en recall.

Reglas = invariantes. No negocian. No dependen de un score de similitud. No esperan a que el router "acierte".

Recall = material condicional. Se trae cuando la tarea lo pide, con un mecanismo explícito (búsqueda, lookup por id, herramienta de lectura). Si el recall falla, el agente debe poder decir "no lo tengo", no inventar el PDF mental.

Cómo se traduce eso al montar el sistema, sin venderte una religión de framework:

1. Lista las invariantes de verdad (pocas). Formato de salida crítico, límites de acción, datos que nunca se inventan, unidades, idiomas, políticas de herramientas obligatorias.
2. Mételas en la capa de reglas que se inyecta siempre (system estable o bloque de política versionado). Cortas, comprobables, sin novela.
3. Todo lo demás al almacén de recall con identificadores estables y metadatos (fecha, fuente, caducidad si aplica).
4. Prohíbe que el compresor convierta recall en reglas. Un resumen no promociona una nota opcional a mandamiento.
5. Mide el tamaño de las reglas como presupuesto, no como monumento. Si crece sin control, estás pagando capacidad en cada turno para texto que ya nadie lee con atención.

Esto conecta con otra pieza del mismo tablero: orquestar agentes sin que se pisen el contexto ni te fundan en tokens. Multiagente sin política de qué es regla y qué es recall es una pelea de monólogos con la tarjeta de créditos al fondo.

Cómo montar el harness: el esqueleto, no el culto al framework

No hay una forma estándar universal sellada por un comité. Lo que sí hay es un esqueleto de diseño que evita los modos de fallo más tontos. Trátalo como arquitectura de control, no como receta de tutorial con capturas inventadas.

Paso 1, Clasifica cada turno antes de "ser listo"

Antes de dejar al modelo soltar prosa, el sistema tiene que saber (por router, por reglas de intención, por tipo de herramienta requerida) si el turno es:

• solo razonamiento / redacción sobre lo ya dado, o
• necesita datos del exterior o de un sistema de registro.

Sin esa clasificación, no puedes instrumentar la vagancia. Todo se diluye en "a veces llama, a veces no, misterio del modelo".

Paso 2, Separa los buffers de memoria

Monta canales distintos, aunque vivan en el mismo backend:

• buffer de reglas (siempre presente, versionado);
• buffer de trabajo (turno actual + tool results crudos);
• buffer de historial comprimido (resúmenes etiquetados);
• buffer de recall (recuperación bajo demanda).

Si todo es "messages[]" sin tipo, el compresor y el modelo harán de las suyas. El tipo no es postureo de senior: es lo que te permite políticas distintas de retención y de confianza.

Paso 3, Define la política de compresión (qué vive, qué muere)

Al comprimir un tramo del hilo:

• Conserva: decisiones tomadas, preferencias del usuario, restricciones explícitas, identificadores estables de entidades (ids, no "el de antes").
• Descarta o externaliza: cifras, estados, precios, contadores, resultados numéricos de herramientas, cualquier cosa con caducidad.
• Nunca reescribas un tool result como si fuera narración limpia sin marca. Si necesitas un eco del resultado, guarda el puntero al artefacto o al registro, no un parafraseo maquillado.

El compresor no es un novelista. Es un archivero con tijeras.

Paso 4, Etiqueta el resumen como material de segunda clase epistémica

Cada bloque comprimido debería entrar al contexto con señales inequívocas, del estilo:

• marca de resumen / contexto previo;
• rango temporal o id del tramo compactado;
• aviso de que no sustituye una tool call ni un lookup.

Da igual la redacción exacta; lo que importa es que un resumen no sea indistinguible de una respuesta de herramienta. Si se leen igual, el modelo los usará igual.

Paso 5, Cierra el hueco del router (el vacío no es neutro)

Cuando el enrutador no sabe qué hacer, el camino por defecto de un LLM no es quedarse quieto. Es improvisar con verosimilitud. El hueco del router se rellena solo: inventa una capacidad, finge un dato, simula que consultó algo.

Por eso todo miss del router necesita una respuesta dirigida:

• pedir aclaración,
• caer a un modo seguro,
• forzar una herramienta de desambiguación,
• o negarse con un motivo explícito.

"Que el modelo decida" en un miss no es flexibilidad. Es externalizar el diseño al generador de texto.

Paso 6, Empareja cada guardrail con la instrucción positiva

Todo control nuevo llega en pareja. Si pones un guardrail del tipo "no respondas con datos de stock inventados", tiene que existir la vía positiva: "cuando pidan stock, llama a X / consulta Y / di que no hay fuente".

Si solo castigas el fallo sin abrir el camino correcto, entrenas al sistema a rodear el muro con prosa más elegante. El guardrail sin instrucción positiva es un semáforo en medio del campo: frena a quien ya iba bien y no enseña la carretera.

Paso 7, Instrumenta antes de opinar del modelo

Mínimo viable de observabilidad del harness (conceptos, no productitos de moda):

• contador de tool calls por turno;
• alerta cuando un turno etiquetado como "necesita datos" sale con cero llamadas;
• comprobación de que el compresor no arrastra valores numéricos de resultados de herramientas al resumen;
• traza de qué memoria aportó cada bloque (regla / recall / resumen / tool crudo).

Sin esto, debatirás "calidad del modelo" mientras tu tubería le alimenta resúmenes que parecen hechos y le premia por no gastar herramientas.

Cada capa del harness cuesta capacidad (sí, también la tuya de diseño)

Aquí va la stance que evita el monstruo de Frankenstein: cada capa de harness cuesta capacidad. No solo tokens. Cuesta atención del modelo, coste de mantenimiento, superficie de fallo y complejidad de depuración.

Añadir un control puede empeorar el sistema si no revisas el diseño completo. Ejemplos de degradación real, no de slide:

• Un resumen demasiado agresivo borra el matiz que justificaba una tool call posterior.
• Un recall demasiado generoso inunda el turno y diluye las reglas duras.
• Un guardrail que bloquea respuestas sin ofrecer la vía de herramienta empuja a la alucinación educada.
• Un router "inteligente" con huecos sin fallback convierte misses en teatro de capacidades.

La pregunta útil no es "¿qué más le pongo?". Es "¿qué modo de fallo introduce esta capa y qué señal me dirá que se activó?".

Si no tienes esa respuesta, no estás endureciendo el agente: estás coleccionando parches.

Errores comunes (donde la caga casi todo el mundo)

Tratar el resumen como caché de la realidad

El resumen es continuidad conversacional, no réplica del mundo. Si tu compresor guarda "hay 14 unidades" porque lo dijo una tool hace una hora, has fabricado un mentiroso con buena ortografía.

Reglas que solo existen en el vault

Si una política es obligatoria y vive solo en recall, no es política: es folklore. El agente no buscará lo que no sospecha.

Prompt heroico sin red

"Usa siempre herramientas para datos actuales" sin contador, sin test de turno y sin marca de resumen es autoayuda para sistemas. Suena bien en la demo. En producción se pudre.

Meter más memoria cuando el síntoma es vagancia

Cuando el modelo deja de llamar tools, la reacción instintiva es "dale más contexto". A veces es exactamente el combustible del problema: más historial comprimido con pinta de respuesta completa.

Evaluar solo la prosa final

Si mides únicamente si la respuesta "suena bien", premiarás al agente vago. Mide el camino: ¿había que obtener dato? ¿se obtuvo? ¿de qué memoria salió lo que afirma?

Confundir cuatro memorias con un RAG bonito

RAG (retrieval + generación) cubre una parte del recall documental. No sustituye reglas duras, ni marcas de compresión, ni la política de caducidad, ni la instrumentación de tools. Quien vende "pon embeddings y ya tienes memoria de agente" te está vendiendo un cajón, no un sistema. Para el corte y la corrupción silenciosa del retrieval, el terreno de chunking por estructura en RAG es otra guerra; no la mezcles con el harness del hilo.

Un recorrido mental de un turno bien arnésado

Para aterrizar sin inventar APIs de fantasía, mira el flujo como contratos:

1. Entra el mensaje.
2. El sistema clasifica: ¿necesita datos o no?
3. Se cargan reglas siempre.
4. Se adjunta historial comprimido etiquetado (sin cifras caducas).
5. Si hace falta, se dispara recall con consulta explícita, no por telepatía.
6. El modelo planifica; si la clase del turno exige dato, debe emitir tool call(s).
7. Los tool results entran al buffer de trabajo como material crudo y marcado, no como narrativa.
8. Se responde.
9. Al cerrar o al superar umbral de tokens, el compresor archiva el tramo con la política de conservación/descarte.
10. Las métricas del turno se escriben: tools usadas, clase del turno, tamaños por buffer.

Si en el punto 6 el modelo se salta las tools y en el 9 el compresor se traga un número, tienes dos bugs de harness, no "un modelo creativo".

Tips que separan un arnés usable de un altar

• Versiona las reglas como código. Un cambio de política sin versión es gaslighting al equipo de evaluación.
• Prefiere ids a descripciones en los resúmenes ("pedido #4812", no "el pedido del martes ese").
• Caducidad explícita en lo recuperable: si un dato expira, el recall debería poder negarse a servir basura vieja en lugar de colarla al prompt.
• Tests de harness, no solo de prompt. Un caso con historial rico que afirma un hecho cambiante debe exigir tool call. Otro caso debe verificar que el compresor no arrastra números de tool results.
• Menos capas, mejores contratos. Si una capa no tiene señal de fallo, sobra.
• Desconfía del silencio del router. El miss sin fallback es una invitación a la alucinación de capacidades.

Qué no te estoy vendiendo

Conviene ser adultos: aquí no hay una métrica pública universal que demuestre "este harness reduce alucinaciones un X%". No hay un estándar único de implementación ni un kit oficial que debamos fingir. Lo que hay es un conjunto de modos de fallo bien conocidos en ingeniería de agentes (vagancia con historial rico, resúmenes que se hacen pasar por hechos, reglas que dependen de búsqueda, routers con agujeros) y un diseño que los ataca en el instrumento, no en el discurso.

Seamos justos: hay contextos donde un compresor agresivo funciona. Si el agente opera en un dominio cerrado con hechos estables, un resumen denso puede ser suficiente y el coste de instrumentar cada tool call no se justifica. El problema no es comprimir; es comprimir sin distinguir cuándo el dato caduca y cuándo el turno exige frescura. La postura de esta guía asume el caso difícil (entornos con estado cambiante) porque es donde el harness se la pega sin que nadie se entere.

Si alguien te garantiza que con "memoria comprimida" se acabaron las alucinaciones, enseña el banco de pruebas o cierra la boca. El harness no absuelve al modelo; le quita excusas y te quita a ti la fe de carpintero.

Cierre

Montar memoria comprimida de verdad es menos "resumir el chat" y más decidir qué puede mentir sin que te enteres. El experimento de OpenAI lo dejó negro sobre blanco: triplicar resultados en ARC-AGI sin tocar el modelo, solo arreglando cómo el historial llegaba al contexto. Marca lo comprimido, saca las cifras del resumen, pon las invariantes fuera del recall, cierra los huecos del router e instrumenta el cero-tools como alarma. Y cuando el agente falle, antes de fusilar al modelo, abre el arnés: a menudo el que está alucinando es el diseño.

Preguntas frecuentes

¿Qué es un harness de memoria comprimida en un agente de IA?

Es la capa que decide qué parte del historial se resume, qué se descarta, qué reglas se inyectan siempre y qué se recupera bajo demanda. Su objetivo es alargar conversaciones sin reventar la ventana de contexto y sin que el resumen se confunda con datos frescos de herramientas. No es solo "acortar texto": es política de confianza sobre cada bloque de memoria.

¿Por qué un agente con buen historial deja de usar herramientas?

Porque un resumen bien escrito se parece a una respuesta ya resuelta. Si no está etiquetado como contexto previo y además arrastra cifras antiguas, el modelo puede dar el turno por cubierto sin tool calls. Eso es vagancia inducida por el instrumento, no un ahorro inteligente. Se mitiga marcando resúmenes, sacando datos con caducidad de la compresión e instrumentando turnos "necesita datos" con cero llamadas como fallo.

¿Qué debe ir en reglas y qué en recall?

En reglas va lo que debe cumplirse siempre: invariantes, límites y políticas que no pueden depender de una búsqueda. En recall va lo que quizá necesite para una tarea concreta y puede recuperarse bajo demanda. Si una norma crítica solo vive en el almacén buscable, el agente no la aplicará cuando no se le ocurra buscarla. Al revés, hinchar las reglas con todo el conocimiento come contexto y diluye lo importante.

¿Comprimir el historial elimina las alucinaciones del agente?

No hay base para afirmar eso como regla general ni con un porcentaje mágico. La compresión mal hecha puede incluso facilitar respuestas inventadas al presentar resúmenes como si fueran hechos actuales. Un harness serio reduce modos de fallo concretos (reúso de cifras viejas, huecos de router, reglas ausentes) pero no absuelve al modelo ni sustituye evaluación con casos reales.