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 zonas horarias. Es lo más parecido que tengo a un empleado júnior.
Y durante semanas, seguía olvidando cosas.
No de una manera 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. Mencionaba una decisión de hacía 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 funciones y dediqué 5 días, en mis ratos libres, 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 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 de forma gradual, 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 sucedieron.
El culpable era la compactación. Cuando la conversación llena la ventana de contexto, OpenClaw comprime los mensajes antiguos en un resumen para hacer espacio para los nuevos. El resumen captura la esencia pero pierde 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 n.º 3 recibe el mismo trato que una charla casual del mensaje n.º 7.
Lo que hice:
Habilité el vaciado de memoria antes de la compactación. Esto le indica al agente que guarde el contexto importante en el disco antes de que se ejecute el compresor.
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 los hechos duraderos en memory/YYYY-MM-DD.md antes de que la compactación los elimine. El agente escribe lo que importa, se ejecuta la compactación y lo importante sobrevive en el disco incluso si el resumen del contexto lo pierde.
Lo que aprendí:
La compactación no es tu enemiga. Perder información durante la compactació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 se saltaba coincidencias obvias.
El problema era el motor de búsqueda. La búsqueda predeterminada de OpenClaw basada en SQLite usa embeddings vectoriales (similitud semántica) para encontrar fragmentos relevantes. Funciona para consultas amplias, pero falla con coincidencias exactas. Buscaba un nombre de cliente específico y obtenía resultados sobre un tema completamente diferente que casualmente 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 vectoriales y un reranker. Así que cuando busco "error de pago de Charles", encuentra resultados que contienen esas palabras exactas Y resultados que están semánticamente relacionados, luego los reordena 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 + reranking) es significativamente mejor para la memoria de agentes del mundo real. Si tu agente no puede encontrar algo que sabes que está en sus archivos, el motor de búsqueda es probablemente 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 existía claramente 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 correctas, no consultará las cosas.
Lo que hice:
Agregué instrucciones explícitas de recuperación a la secuencia de inicio. 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 revisar 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 cosas. La infraestructura de búsqueda maneja la primera parte. Las instrucciones de inicio y los hábitos de recuperación manejan la segunda. Prueba ambas por separado.
Día 4: Haciéndolo Resistente a la Compactación
Para entonces ya tenía el vaciado de memoria, la búsqueda híbrida y las instrucciones de recuperación. Pero seguía perdiendo contexto en un escenario específico: sesiones muy largas donde la compactación se ejecutaba varias veces.
El problema era que el vaciado de memoria solo se activa una vez por ciclo de compactación. Si la sesión era lo suficientemente larga para dos o tres compactaciones, solo la primera recibía el tratamiento de vaciado. Todo lo demás estaba en riesgo.
Lo que hice:
Configuré la poda de contexto para que funcionara junto con la compactació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 vaciado de memoria, esto significa que el agente escribe lo importante en el disco temprano, y el contexto antiguo se limpia antes de causar un desbordamiento.
También agregué un protocolo de prueba de MARCADOR: 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 compactación. Si el marcador sobrevive, el cambio funcionó. 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 compactación. Son las sesiones de trabajo profundo de 2 horas donde pierdes el 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 hizo clic. 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 inicio en competencia: una en BOOT.md (que OpenClaw ni siquiera reconoce) y otra enterrada 200 líneas dentro de AGENTS.md.
Peor aún, cada vez que cambiaba de modelo, Chiti lo olvidaba todo. Sin protocolo de traspaso. Sin escritura del contexto actual. Simplemente se perdía.
La causa raíz:
OpenClaw lee automáticamente 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 debe leerlos por sí mismo usando herramientas. Si la instrucción para leer esos archivos no está en uno de los archivos cargados automáticamente (específicamente AGENTS.md), el agente nunca los verá.
Mi BOOT.md tenía la secuencia de inicio completa. Pero OpenClaw no carga BOOT.md automáticamente. Así que las instrucciones simplemente estaban allí, sin leer, sin hacer nada.
Lo que hice:
Hice una auditoría y limpieza completa:
- Moví la secuencia de inicio 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 incorporación único, ya completado, desperdiciaba 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
- Añadí disciplina de escritura: cada tarea registra su resultado, cada error se convierte en una regla
- Añadí un protocolo de traspaso: antes de cualquier cambio de modelo o fin de sesión, el agente escribe el contexto actual en el registro diario
La secuencia de inicio 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 la sesión principal, nunca en grupos)
- Lee PROTOCOL_COST_EFFICIENCY.md
- Imprime: CARGADO: USER | LEARNINGS | DAILY | MEMORY | PROTOCOL
La disciplina de escritura:
markdown
Después de cada tarea:
- Registra la decisión + el resultado → memory/YYYY-MM-DD.md
- Si es un error → añádelo a learnings/LEARNINGS.md
- Si hay contexto significativo → actualiza MEMORY.md (solo durante revisiones heartbeat, nunca directamente durante las tareas)
El protocolo de traspaso:
markdown
Antes del fin de sesión o cambio de modelo:
Escribe la sección TRASPASO 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. El mismo agente. Los mismos modelos. Solo menos ruido.
Lo que aprendí:
La verdadera solución no fue añadir más archivos. Fue eliminar los que no estaban haciendo nada. Cada token en el prompt del sistema es una 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 en silencio.
Las Reglas Que Me Habría Gustado Saber 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 cargan automáticamente: 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 inicio, el agente no lo verá. BOOT.md no es algo real en OpenClaw. Yo lo tuve durante semanas. No hizo nada.
2. La secuencia de inicio va al principio de AGENTS.md.
No en el medio. No al final. Al principio. Los archivos cargados automáticamente se inyectan en el prompt del sistema, por lo que las instrucciones de inicio 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 se escriba de vuelta. Si el agente no registra las decisiones, los resultados y los errores en el disco, esas cosas solo existen en la ventana de contexto. Y la ventana de contexto se compacta. 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ñadidura. MEMORY.md es la memoria a largo plazo curada. Si dejas que el agente vuelque cualquier cosa en MEMORY.md, se infla hasta convertirse en un desastre de 200 líneas en cuestión de 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 sin curar hasta que fue inútil.
5. LEARNINGS.md es el archivo más infravalorado.
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 revisar el estado de git". "No leas MEMORY.md completo en chats de grupo". "Confirma siempre 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 entre sesiones, prueba entre cambios de modelo. Si el agente no puede encontrar lo que almacenaste ayer, el almacenamiento no importa.
7. El protocolo de traspaso 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 cargados automáticamente. Sin un protocolo de traspaso 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 débil 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, para funciones que nunca había tocado.
9. La búsqueda híbrida supera a la búsqueda puramente semántica.
BM25 (palabras clave) + vectores (significado) + reranking da resultados significativamente mejores que los vectores solos. Nombres de clientes, números específicos, frases exactas: la búsqueda semántica los pasa por alto. La búsqueda por palabras clave los atrapa. Usa ambas.
10. La compactación no es la enemiga. El contexto no escrito sí lo es.
Pasé días peleando contra la compactació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 se ejecute la compactación. El vaciado de memoria maneja esto automáticamente. Si está en el disco, sobrevive a la compactación. Si solo está en la conversación, está en riesgo.
Mi Configuración Actual
Como referencia, así es como se ve mi espacio de trabajo ahora:
workspace/
├── AGENTS.md (secuencia de inicio + disciplina de escritura + protocolo de traspaso)
├── SOUL.md (personalidad y comportamiento)
├── IDENTITY.md (nombre, rol)
├── USER.md (información del propietario)
├── TOOLS.md (directrices 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 la 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.
Me llevó 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 es. 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 la ejecución de agentes OpenClaw en producción en X: @code_rams
