El nombre de mi agente es Chiti. Funciona en Telegram, gestiona el soporte al cliente de dos productos SaaS, redacta tweets, administra facturas y coordina con mi cofundador a través de husos horarios. Es lo más parecido a un empleado junior que tengo.
Y durante semanas, seguía olvidando cosas.
No de forma sutil. Pasaba una hora configurando un cron diario, cambiaba de modelo, y en la siguiente sesión Chiti actuaba como si nunca hubiéramos hablado. Referenciaba una decisión de hace dos días y recibía una mirada en blanco. Le pedía que continuara una tarea y empezaba desde cero.
Así que dejé de construir funcionalidades y dediqué 5 días, cuando tenía tiempo, solo a arreglar la memoria. Esto es todo lo que encontré, todo lo que rompí y todo lo que realmente funcionó.
Día 1: El agente lo olvida todo después de conversaciones largas
El primer problema era fácil de describir y doloroso de diagnosticar.
Después de conversaciones largas, Chiti empezaba a perder el contexto anterior. No gradualmente, simplemente desaparecía. Cosas que le había dicho hace 20 mensajes ya no estaban. Decisiones que tomamos al inicio de la sesión? Nunca ocurrieron.
El culpable era la compresión. Cuando la conversación llena la ventana de contexto, OpenClaw comprime los mensajes más antiguos en un resumen para hacer espacio a los nuevos. El resumen captura la esencia pero pierde los detalles. Nombres, números, decisiones exactas: desaparecen.
Esto es por diseño. La ventana de contexto es finita. Pero el comportamiento predeterminado trata todo por igual, lo que significa que tu instrucción cuidadosamente elaborada del mensaje #3 recibe el mismo tratamiento que una charla casual del mensaje #7.
Lo que hice:
Activé el volcado de memoria antes de la compresión. Esto le dice al agente que escriba el contexto importante en el disco antes de que el compresor se ejecute.
1{2 "compaction": {3 "memoryFlush": {4 "enabled": true,5 "softThresholdTokens": 40006 }7 }8}
Cuando la sesión se acerca al límite de contexto, OpenClaw activa un turno silencioso que le recuerda al agente guardar hechos duraderos en memory/YYYY-MM-DD.md antes de que la compresión los elimine. El agente escribe lo que importa, la compresión se ejecuta, y lo importante sobrevive en el disco incluso si el resumen de contexto lo pierde.
Lo que aprendí:
La compresión no es tu enemiga. Perder información durante la compresión sí lo es. La solución es asegurarse de que cualquier cosa que valga la pena recordar se escriba en un archivo antes de que el compresor la toque. Si solo está en la ventana de contexto, es temporal. Si está en el disco, sobrevive.
Día 2: La búsqueda devuelve basura
Con los registros diarios acumulándose y MEMORY.md creciendo, necesitaba que el agente realmente encontrara cosas. La búsqueda de memoria integrada devolvía resultados irrelevantes o no encontraba coincidencias obvias.
El problema era el motor de búsqueda. La búsqueda predeterminada de OpenClaw basada en SQLite usa embeddings de vectores (similitud semántica) para encontrar fragmentos relevantes. Funciona para consultas amplias, pero tiene dificultades con coincidencias exactas. Buscaba un nombre de cliente específico y obtenía resultados sobre un tema completamente diferente que usaba un lenguaje similar.
Lo que hice:
Cambié a QMD como motor de búsqueda de memoria. QMD combina BM25 (coincidencia de palabras clave) con embeddings de vectores y un reclasificador. Así que cuando busco "fallo de pago de Charles", encuentra resultados que contienen esas palabras exactas Y resultados que están semánticamente relacionados, luego los reclasifica por relevancia.
También configuré las rutas de QMD para incluir mi carpeta de aprendizajes:
1{2 "memory": {3 "qmd": {4 "paths": [5 {6 "path": "/Users/ramya/clawd",7 "name": "memory-root",8 "pattern": "MEMORY.md"9 },10 {11 "path": "/Users/ramya/clawd",12 "name": "memory-alt",13 "pattern": "memory_alt.md"14 },15 {16 "path": "/Users/ramya/clawd/memory",17 "name": "memory-dir",18 "pattern": "**/*.md"19 },20 {21 "path": "/Users/ramya/clawd/learnings",22 "name": "learnings",23 "pattern": "**/*.md"24 }25 ]26 }27 }28}
Lo que aprendí:
La búsqueda puramente semántica suena bien en teoría, pero falla con nombres propios, números específicos y frases exactas. La búsqueda híbrida (palabras clave + vectores + reclasificación) es significativamente mejor para la memoria de agentes en el mundo real. Si tu agente no puede encontrar algo que sabes que está en sus archivos, el motor de búsqueda probablemente sea el cuello de botella, no los archivos en sí.
Día 3: El agente lo encuentra pero no lo usa
Este fue el día más frustrante. Confirmé que la búsqueda funcionaba, podía consultar manualmente y obtener los resultados correctos. Pero durante las conversaciones reales, Chiti no recuperaba el contexto relevante, incluso cuando claramente existía en la memoria.
El problema era que la recuperación no es automática. El agente tiene que decidir buscar. Y si la conversación no activa las señales adecuadas, no buscará nada.
Lo que hice:
Agregué instrucciones explícitas de recuperación en la secuencia de arranque. En lugar de esperar que el agente buscara cuando fuera necesario, le dije cuándo buscar:
markdown
Antes de comenzar cualquier tarea:
- Busca en los registros diarios el contexto relacionado
- Revisa LEARNINGS.md para reglas sobre este tipo de tarea
- Si se menciona un cliente, busca su historial
También construí una prueba de recuperación. Plantaba un marcador específico en el registro diario — algo como "MARCADOR: 2026-02-20 — Recuerda siempre verificar el estado de git antes de afirmar que el código está subido." Luego esperaba, iniciaba una nueva sesión y preguntaba: "¿Cuál fue el marcador de ayer?" Si el agente lo encontraba, la recuperación funcionaba. Si no, algo estaba roto.
Lo que aprendí:
Hay una diferencia entre "la información existe" y "el agente usa la información". Necesitas ambas. La infraestructura de búsqueda maneja la primera parte. Las instrucciones de arranque y los hábitos de recuperación manejan la segunda. Prueba ambas por separado.
Día 4: Haciéndolo resistente a la compresión
Para entonces ya tenía volcado de memoria, búsqueda híbrida e instrucciones de recuperación. Pero seguía perdiendo contexto en un escenario específico: sesiones muy largas donde la compresión se ejecutaba varias veces.
El problema era que el volcado de memoria solo se activa una vez por ciclo de compresión. Si la sesión era lo suficientemente larga para dos o tres compresiones, solo la primera recibía el tratamiento de volcado. Todo lo posterior estaba en riesgo.
Lo que hice:
Configuré la poda de contexto para que trabajara junto con la compresión:
1{2 "contextPruning": {3 "mode": "cache-ttl",4 "ttl": "6h",5 "keepLastAssistants": 36 }7}
Esto poda agresivamente el contexto antiguo después de 6 horas, manteniendo las últimas 3 respuestas del asistente. Combinado con el volcado de memoria, esto significa que el agente escribe lo importante en el disco temprano, y el contexto antiguo se limpia antes de causar desbordamiento.
También agregué un protocolo de prueba de marcadores: después de cualquier cambio de configuración significativo, planto un marcador en el registro diario y pruebo la recuperación a través de los límites de compresión. Si el marcador sobrevive, el cambio funciona. Si no, algo se rompió.
Lo que aprendí:
Las sesiones largas son donde los sistemas de memoria realmente se ponen a prueba. Las conversaciones cortas rara vez alcanzan la compresión. Son las sesiones de trabajo profundo de 2 horas donde pierdes contexto y no puedes entender por qué. Prueba tu sistema de memoria bajo carga, no solo en chats rápidos.
Día 5: El prompt del sistema estaba inflado un 28%
Este fue el día en que todo encajó. Ejecuté /context detail y me quedé mirando los números.
Mi agente estaba cargando 11,887 tokens de prompt del sistema antes siquiera de leer mi mensaje. 51 habilidades, 20 de las cuales nunca había usado. MEMORY.md tenía 200 líneas de wiki de la empresa cargadas en cada sesión. Y tenía dos secuencias de arranque en competencia: una en BOOT.md (que OpenClaw ni siquiera reconoce) y otra enterrada 200 líneas abajo en AGENTS.md.
Peor aún, cada vez que cambiaba de modelo, Chiti lo olvidaba todo. Sin protocolo de transferencia. Sin volcado del contexto actual. Simplemente desaparecía.
La causa raíz:
OpenClaw auto-carga estos archivos en cada nueva sesión: AGENTS.md, SOUL.md, TOOLS.md, IDENTITY.md, HEARTBEAT.md, MEMORY.md.
Todo lo demás — LEARNINGS.md, registros diarios, documentos, archivos de referencia — el agente tiene que leerlos por sí mismo usando herramientas. Si la instrucción para leer esos archivos no está en uno de los archivos auto-cargados (específicamente AGENTS.md), el agente nunca los verá.
Mi BOOT.md tenía toda la secuencia de arranque. Pero OpenClaw no auto-carga BOOT.md. Así que las instrucciones simplemente estaban allí, sin leer, sin hacer nada.
Lo que hice:
Hice una auditoría completa y limpieza:
- Moví la secuencia de arranque al principio de AGENTS.md (el único lugar confiable para las instrucciones de inicio)
- Eliminé BOOT.md (no reconocido por OpenClaw)
- Eliminé BOOTSTRAP.md (archivo de configuración único, ya completado, desperdiciando 361 tokens cada sesión)
- Reduje MEMORY.md de 200 líneas a 90 moviendo los documentos de referencia a una carpeta docs/
- Eliminé 20 habilidades de marketing no utilizadas que consumían 3,000 tokens por sesión
- Agregué disciplina de escritura: cada tarea registra su resultado, cada error se convierte en una regla
- Agregué un protocolo de transferencia: antes de cualquier cambio de modelo o fin de sesión, el agente escribe el contexto actual en el registro diario
La secuencia de arranque ahora se ve así:
markdown
Antes de hacer NADA:
- Lee USER.md
- Lee learnings/LEARNINGS.md
- Lee memory/YYYY-MM-DD.md (hoy + ayer)
- Lee MEMORY.md (solo en sesión principal, nunca en grupos)
- Lee PROTOCOL_COST_EFFICIENCY.md
- Imprime: CARGADO: USER | LEARNINGS | DIARIO | MEMORY | PROTOCOLO
La disciplina de escritura:
markdown
Después de cada tarea:
- Registra decisión + resultado → memory/YYYY-MM-DD.md
- Si es error → agrega a learnings/LEARNINGS.md
- Si hay contexto significativo → actualiza MEMORY.md (solo durante revisiones de heartbeat, nunca directamente durante las tareas)
El protocolo de transferencia:
markdown
Antes de finalizar sesión o cambiar de modelo:
Escribe sección HANDOVER en memory/YYYY-MM-DD.md:
- Lo que se discutió
- Lo que se decidió
- Tareas pendientes con detalles exactos
- Próximos pasos restantes
Resultados:
- Prompt del sistema: 11,887 → 8,529 tokens
- Habilidades: 51 → 32
- Tokens de sesión: 18,280 → 14,627
- 28% más ligero. Mismo agente. Mismos modelos. Solo menos ruido.
Lo que aprendí:
La verdadera solución no era agregar más archivos. Era eliminar los que no estaban haciendo nada. Cada token en el prompt del sistema es sobrecarga que el agente lleva en cada mensaje. Habilidades no utilizadas, archivos de memoria inflados, archivos que el sistema ni siquiera lee: todo se acumula silenciosamente.
Las reglas que desearía haber sabido desde el día 1
Después de 5 días rompiendo cosas y arreglándolas, estas son las reglas que le daría a cualquiera que configure la memoria de OpenClaw:
1. Solo estos archivos se auto-cargan: AGENTS.md, SOUL.md, TOOLS.md, IDENTITY.md, USER.md, HEARTBEAT.md, MEMORY.md.
Todo lo demás necesita una instrucción de lectura explícita en AGENTS.md. Si no está en la secuencia de arranque, el agente no lo verá. BOOT.md no es algo real en OpenClaw. Yo tuve uno durante semanas. No hizo nada.
2. La secuencia de arranque va al principio de AGENTS.md.
No en el medio. No al final. Al principio. Los archivos auto-cargados se inyectan en el prompt del sistema, así que las instrucciones de arranque deben ser lo primero que procese el agente.
3. La disciplina de escritura importa más que la disciplina de lectura.
La mayoría de la gente configura archivos para que el agente los lea, pero nunca exige que escriba de vuelta. Si el agente no registra decisiones, resultados y errores en el disco, esas cosas solo existen en la ventana de contexto. Y la ventana de contexto se comprime. La escritura de vuelta es cómo el contexto temporal se convierte en memoria permanente.
4. Nunca escribas directamente en MEMORY.md durante las tareas.
Los registros diarios son en bruto y de solo añadido. MEMORY.md es memoria a largo plazo curada. Si dejas que el agente vuelque cualquier cosa en MEMORY.md, se infla en un desastre de 200 líneas en semanas. Cura MEMORY.md durante revisiones periódicas (heartbeat o cron) destilando información de los registros diarios recientes. Aprendí esto de un compañero usuario de OpenClaw que atrapó a su agente haciendo exactamente esto: inflando MEMORY.md con ruido no curado hasta que quedó inservible.
5. LEARNINGS.md es el archivo más subestimado.
Cada error que comete el agente debería convertirse en una regla de una línea. "Nunca afirmes que el código está subido sin verificar el estado de git." "No leas MEMORY.md completo en chats grupales." "Siempre confirma la zona horaria del usuario antes de programar." Estas reglas se acumulan. Después de unas semanas, tu agente tiene un manual de operaciones personal construido a partir de sus propios fracasos.
6. Prueba la recuperación, no solo el almacenamiento.
Almacenar información y recuperarla son problemas diferentes. He tenido archivos indexados y buscables pero nunca accedidos porque el agente no sabía que debía buscarlos. Planta marcadores, prueba a través de sesiones, prueba a través de cambios de modelo. Si el agente no puede encontrar lo que almacenaste ayer, el almacenamiento no importa.
7. El protocolo de transferencia es la solución para el cambio de modelo.
Los agentes de OpenClaw pierden todo el contexto cuando cambias de modelo. El nuevo modelo comienza con una ventana de contexto fresca — solo ve los archivos auto-cargados. Sin un protocolo de transferencia que vuelque el estado actual al registro diario antes del cambio, el nuevo modelo no tiene idea de lo que estaba pasando. Este fue mi mayor punto de dolor durante semanas.
8. Ejecuta /context detail regularmente.
Este comando muestra exactamente qué está consumiendo tus tokens. Habilidades que olvidaste que instalaste, archivos que crecieron sin que te dieras cuenta, herramientas que nunca usas. Encontré 20 habilidades no utilizadas quemando 3,000 tokens por sesión. Eso son 3,000 tokens de sobrecarga en cada mensaje, por funcionalidades que nunca había tocado.
9. La búsqueda híbrida supera a la búsqueda puramente semántica.
BM25 (palabras clave) + vectores (significado) + reclasificación da resultados significativamente mejores que los vectores solos. Nombres de clientes, números específicos, frases exactas: la búsqueda semántica los pierde. La búsqueda por palabras clave los captura. Usa ambas.
10. La compresión no es la enemiga. El contexto no escrito sí lo es.
Pasé días luchando contra la compresión antes de darme cuenta de que la solución era más simple: asegurarse de que cualquier cosa importante se escriba en un archivo antes de que la compresión se ejecute. El volcado de memoria maneja esto automáticamente. Si está en el disco, sobrevive a la compresión. Si solo está en la conversación, está en riesgo.
Mi configuración actual
Como referencia, así se ve mi espacio de trabajo ahora:
workspace/
├── AGENTS.md (secuencia de arranque + disciplina de escritura + protocolo de transferencia)
├── SOUL.md (personalidad y comportamiento)
├── IDENTITY.md (nombre, rol)
├── USER.md (información del propietario)
├── TOOLS.md (pautas de uso de herramientas)
├── HEARTBEAT.md (comportamiento de verificación autónoma)
├── MEMORY.md (memoria a largo plazo curada, ~90 líneas)
├── PROTOCOL_COST_EFFICIENCY.md
├── learnings/
│ └── LEARNINGS.md (reglas de errores)
├── memory/ (registros diarios: YYYY-MM-DD.md)
├── docs/ (documentos de referencia movidos de MEMORY.md)
│ ├── tweetsmash-arch.md
│ ├── knowledge-transfer.md
│ ├── infrastructure.md
│ └── group-chat-rules.md
└── skills/ (32 habilidades, de 51)
Prompt del sistema: 8,529 tokens. Tokens de sesión: 14,627 de 200,000 de ventana de contexto (7.3%). El agente arranca, lee lo que necesita, escribe lo que aprende y transfiere el contexto antes de los cambios de modelo.
Tomó 5 días llegar aquí. La mayor parte fue desaprender la suposición de que más archivos equivalen a mejor memoria. No es así. La disciplina sí lo hace. Mi experimento aún continúa.
Estoy construyendo TweetSmash y LinkedMash — herramientas de marcadores de redes sociales con mi cofundador. Comparto lo que aprendo sobre ejecutar agentes de OpenClaw en producción en X: @code_rams
