¿Conoces el mecanismo para añadir una "segunda mente" a Codex para que el contexto se mantenga incluso si la conversación se interrumpe? Su nombre es Agentmemory. He resumido todo, desde su procedimiento de instalación y configuración hasta los errores más comunes. Esto es lectura obligada para quienes les resulta tedioso explicar lo mismo cada vez y para quienes no quieren desperdiciar tokens.
Cada mañana, inicio Claude Code y escribo "Continuar desde ayer", solo para recibir un "Por favor, indícame el contenido de la sesión anterior". Este es un fenómeno que ocurre casi a diario.
En el momento en que se corta una sesión, el contexto del proyecto se reinicia. Si bien se lee lo que está escrito en CLAUDE.md, el "peso del contexto"—como las discusiones sobre un error de hace tres días o el razonamiento detrás de una decisión de diseño tomada la semana pasada—desaparece por completo.
Un desarrollador escribió:
solo los últimos 30 días del historial de tu sesión de Claude Code se guardan en tu computadora por defecto, tienes que configurar un período más largo si quieres tener memoria de todas ellas.
El período de retención predeterminado para el historial de sesiones es de 30 días. Además, lo que se guarda es solo un "registro como cadena de texto", no un mecanismo que pueda ser invocado como contexto.
Es básicamente lo mismo en el lado de Codex. El contexto de GPT-5.5 es de 1M de tokens vía API y 400K en Codex CLI. El tamaño físico parece suficiente, pero en la práctica, la precisión comienza a disminuir alrededor de los 200K tokens.
Fue entonces cuando llegó Agentmemory, que acaparó titulares tras superar las 4,000 estrellas. Llevo usándolo intensamente una semana. Esta es mi conclusión:
La expresión "añadir memoria infinita" a Codex/Claude Code es mitad exageración y mitad verdad.
En este artículo, explicaré cómo maximizar la parte de "verdad" y cómo evitar la parte de "exageración" cuando te la encuentres.
1. ¿Por qué Codex/Claude Code Sufren "Amnesia"?
Antes de hablar de Agentmemory, permíteme aclarar por qué las herramientas existentes no son suficientes. Si omitimos esto, solo termina con "añadí una herramienta de memoria conveniente" y perdemos la esencia.
Incluso si la ventana de contexto es grande, no se puede utilizar por completo en la práctica.
A fecha de mayo de 2026, las ventanas de contexto de los modelos principales son las siguientes:
● Claude Opus 4.7: 1M de tokens (ampliado desde 200K)
● GPT-5.5: 1M de tokens (API) / límite de 400K en Codex CLI
● Gemini 3.1 Pro: 1M de tokens
En términos de caracteres japoneses, esto equivale a aproximadamente 1.41 millones de caracteres. Es capacidad suficiente para que quepa no solo un libro, sino una serie completa. Mirando las cifras, parece que "todo cabe".
Sin embargo, la propia Anthropic escribió en su blog oficial de ingeniería:
A medida que aumenta el número de tokens en la ventana de contexto, la capacidad del modelo para recordar información con precisión de ese contexto disminuye.
La capacidad física no equivale a la capacidad de mantener la precisión. La experiencia muestra que alrededor de 200K a 400K tokens, Claude comienza a "olvidar lo que acaba de decir". Esto se conoce comúnmente como deterioro del contexto.
El "Colapso del Pensamiento" que ocurrió incluso en el Claude Code oficial
Déjame darte un ejemplo real. El 23 de abril de 2026, Anthropic publicó oficialmente un análisis post-mortem.
Un error implementado el 26 de marzo hizo que la "función para limpiar pensamientos antiguos después de 1 hora de inactividad" se activara en cada turno incluso después de reanudar una sesión.
Como resultado, la longitud media del pensamiento visible cambió de la siguiente manera:
● Enero: 2,200 caracteres
● Marzo: 600 caracteres
Un colapso del 73%. Durante aproximadamente un mes, el Claude Code oficial estaba recortando arbitrariamente su propio contexto.
Esto es importante porque demuestra que el deterioro del contexto no es solo un "error del usuario", sino que también puede ocurrir debido a circunstancias del lado del servicio. Por muy limpio que escribas CLAUDE.md, un simple ajuste de configuración en el lado de la herramienta puede convertir "el contexto de la semana pasada" en papel mojado.
Límites de las soluciones existentes (CLAUDE.md / auto-memory)
Anthropic está tomando medidas. La función de auto-memoria de Claude Code es un mecanismo que recuerda lo aprendido entre sesiones y lo recupera al reiniciar. El equipo de Claude Code lo anunció en mayo.
Sin embargo, esto está estructurado para funcionar en conjunto con la compactación. Realiza un flujo interno de "comprimir contexto → mover información importante a la memoria", y la IA decide "qué conservar" durante cada compresión. Los usuarios no pueden tocar esta lógica de decisión.
Además, la auto-memoria es exclusiva de Claude Code. No hay una API para leerla desde otros agentes como Codex, Cursor, Cline o Hermes. Para aquellos que usan múltiples agentes, la situación de tener que "explicar la misma premisa tres veces" se vuelve la norma.
2. En Qué se Diferencia Agentmemory
Ahora el tema principal. Agentmemory (repositorio oficial: rohitg00/agentmemory) es un motor de memoria de código abierto que alcanzó las 8.8k estrellas a fecha del 15 de mayo de 2026. Se ha más que duplicado desde el informe inicial de "más de 4,000 estrellas". Tiene licencia Apache 2.0, está basado en TypeScript y la última versión es la v0.9.12 (13 de mayo). Es completamente autoalojado, con cero datos enviados a SaaS externos.
Filosofía del Desarrollador
El desarrollador principal, Rohit Ghumare (@ghumare64), resumió la esencia de Agentmemory en una frase:
Construí esto hace 6 meses con agentmemory: memoria persistente para agentes de codificación de IA. Misma idea central: deja de re-derivar, empieza a compilar.
"Deja de re-derivar, empieza a compilar." Esta es la diferencia filosófica con las herramientas existentes.
CLAUDE.md era "entrada para re-derivar cada vez". Estructura del proyecto, convenciones, decisiones pasadas. La IA releía, reinterpretaba y luego las olvidaba en cada sesión. Agentmemory cambia esto reemplazando el "bucle de re-derivación" con una "capa de memoria compilada".
Arquitectura de 3 Niveles (Resumen del README)
Según el README oficial, la estructura interna se divide en tres etapas:
Primero está Captura. Utiliza 12 hooks del ciclo de vida de Claude Code para capturar datos automáticamente, por lo que no es necesario ejecutar memory_save manualmente.
Segundo está Pipeline. Organiza las observaciones a través de un flujo de deduplicación → filtro de privacidad (eliminación automática de claves API/PII) → compresión basada en IA.
Tercero está Recuperación. Fusiona tres tipos de búsqueda híbrida (BM25 / vectorial / gráfica) usando RRF k=60. BM25 maneja palabras clave con raíces y expansión de sinónimos, la vectorial maneja la similitud coseno de embeddings densos, y la gráfica maneja la navegación por grafos de conocimiento. Al fusionarlos con Reciprocal Rank Fusion, si un método falla, el otro lo complementa. Los resultados se devuelven con dispersión de sesión (máximo 3 por sesión), resolviendo el problema de obtener resultados solo de la misma sesión.
Memoria de 4 niveles (Inspirada en Ebbinghaus)
Otro aspecto interesante es el diseño que divide la memoria en cuatro niveles que "crecen" con el tiempo.
El nivel inferior es Working, que es memoria a corto plazo como observaciones brutas de ejecución de herramientas, registros de errores e historial de comandos. Subiendo a Episodic, se convierte en resúmenes de sesión de "lo que sucedió". En el nivel Semántico, se transforma en "lo que sé", conocimiento extraído y patrones. El nivel superior es Procedural, que consiste en flujos de trabajo y procedimientos sobre "cómo proceder".
Las memorias a las que se accede con frecuencia se fortalecen, mientras que las memorias no referenciadas se deterioran según la curva de olvido de Ebbinghaus. Es un mecanismo modelado a partir de la estructura de la memoria humana. Esta es la verdadera naturaleza de "deja de re-derivar y empieza a compilar".
Posicionamiento Frente a Competidores
Para ser honesto, mirando solo las estrellas de GitHub, Agentmemory es todavía pequeño en comparación con los competidores.
● Mem0: 55.7k estrellas, capa de memoria de propósito general, API/Nube primero
● Letta (antes MemGPT): 22.7k estrellas, sistema operativo de agentes, gestión de contexto virtual
● Agentmemory: 8.8k estrellas, especializado en agentes de codificación, SQLite local
Pierde en un juego de números. Sin embargo, donde Agentmemory brilla es en su especialización para agentes de codificación y diseño desacoplado. El propio Rohit escribió:
Si quieres una arquitectura de memoria extendida real, entre agentes, portátil, no bloqueada a un agente en particular, echa un vistazo a agentmemory. Está diseñado como una capa de memoria desacoplada que funciona en múltiples arneses.
Puedes conectarlo a Cursor, Cline, Claude Code, Codex y Hermes usando la misma memoria. Esta es la diferenciación de Mem0 y Letta. Mem0 es demasiado general y tiene una captura automática débil para contextos de codificación, mientras que Letta es un sistema operativo de agentes, lo que dificulta extraer solo la capa de memoria.
Agentmemory da en el blanco para el nicho de "desarrolladores que usan múltiples agentes de codificación simultáneamente."
3. Comenzar en 3 Minutos — Instalación y Configuración Inicial
Vamos a la práctica. El flujo básico es el mismo para Mac, Linux y Windows, siempre que tengas un entorno Node.js.
Paso 1: Iniciar el Servidor de Memoria
Simplemente abre un terminal y ejecuta esto:
Inicia el servidor de memoria (mantenlo en ejecución)
npx @agentmemory/agentmemory
La primera vez tarda de 1 a 2 minutos en descargar las dependencias. Una vez exitoso, se iniciará una API REST en http://localhost:3111. Puedes verificar el estado con:
curl http://localhost:3111/agentmemory/health
→ {"status":"ok","version":"0.9.12"}
También se inicia un visor, por lo que puedes visualizar el contenido de la memoria abriendo http://localhost:3113 en tu navegador.
Paso 2: Insertar Datos de Demostración
Es difícil visualizar con contenido vacío, así que agreguemos datos de muestra.
Ejecuta en un terminal separado
npx @agentmemory/agentmemory demo
Esto escribe un historial de sesión ficticio en SQLite, haciéndolo observable en el visor.
Paso 3: Integrar en Claude Code
La forma más rápida desde el lado de Claude Code es a través del mercado de plugins.
Ejecuta dentro de Claude Code
/plugin marketplace add rohitg00/agentmemory
/plugin install agentmemory
Esto registra automáticamente lo siguiente:
● 12 hooks (todos los ciclos de vida, incluyendo SessionStart / PostToolUse / Stop)
● 4 skills (recall / consolidate / export / governance)
● 51 herramientas MCP (AGENTMEMORY_TOOLS=all para todas, el valor predeterminado son 15 herramientas principales)
Paso 4: Integrar en Codex CLI
Codex sigue un estilo similar.
codex plugin marketplace add rohitg00/agentmemory
codex plugin install agentmemory
Para Codex, AGENTMEMORY_URL=http://localhost:3111 se establece automáticamente como variable de entorno. Ten en cuenta que Codex es más estricto con la sincronicidad de MCP que Claude Code, por lo que dará error inmediatamente si el servidor está caído. No olvides mantenerlo en ejecución.
Paso 5: Conectar a Cursor / Cline, etc.
Para usarlo a través de Cursor, añádelo a ~/.cursor/mcp.json:
{
"mcpServers": {
"agentmemory": {
"command": "npx",
"args": ["-y", "@agentmemory/mcp"],
"env": { "AGENTMEMORY_URL": "http://localhost:3111" }
}
}
}
Cline, Hermes y otros editores compatibles con MCP se conectan con el mismo patrón. Hay una trampa: los ajustes de MCP de Cursor no se reflejan solo con cerrar y reabrir; detallaré esto en la sección "5 Errores".
Paso 6: Ritual de Verificación de Estado
Después de la configuración, esta es la lista de verificación obligatoria:
1. Conectividad del servidor de memoria
curl http://localhost:3111/agentmemory/health
2. Verificar la versión de iii-engine (se requiere v0.11.2)
iii --version
3. Verificar la memoria en el visor
Si ves observaciones registradas en el visor, la configuración fue exitosa. Si Node.js ya está instalado, toma menos de 3 minutos.
4. Las 3 Acciones Básicas — Guardar, Buscar, Auto-Comprimir
El uso de Agentmemory se puede organizar en tres acciones principales.
Acción 1: Guardar (La Captura Automática es la Predeterminada)
En Mem0 o Letta, es normal guardar usando comandos manuales como memory_add(...). Agentmemory tiene una filosofía diferente: captura todo automáticamente usando 12 hooks.
Por ejemplo, las siguientes observaciones se registran sin que hagas nada:
● Comandos y salida durante la ejecución de la herramienta Bash (hook PostToolUse)
● Diffs antes y después de la edición de archivos (hook PreToolUse / PostToolUse)
● Inyección automática de memoria relacionada al inicio de la sesión (hook SessionStart)
● Compresión del resumen al final de la sesión (hook Stop)
El mayor valor es que la "carga de decidir qué guardar por parte del usuario" se vuelve cero. Mientras antes pensábamos "esto es importante, anotémoslo" o "eliminemos esto" en CLAUDE.md, la idea aquí es dejar esa lógica de decisión a la IA.
También puedes guardar manualmente. Llamando a memory_save a través de una herramienta MCP, puedes marcar explícitamente "esto es importante". Es más seguro guardar manualmente las decisiones de diseño críticas en lugar de depender únicamente de la captura automática.
Acción 2: Buscar (Híbrido de 3 Sistemas + RRF)
La búsqueda se realiza a través de herramientas MCP o llamando directamente a la API REST. Aquí están las herramientas MCP representativas:
● memory_recall — Recupera memoria relacionada usando lenguaje natural
● memory_smart_search — Versión completa de la búsqueda híbrida
● memory_sessions — Lista por sesión
● memory_timeline — Ordena por tiempo
● memory_relations — Recorrido de grafos de entidades relacionadas
Si se llama directamente a la API REST:
Buscar "corrección anterior sobre autenticación de Supabase"
curl -X POST http://localhost:3111/agentmemory/search \
-H "Content-Type: application/json" \
-d '{"query": "supabase auth fix", "limit": 5}'
Los resultados devueltos son una fusión de BM25 / vectorial / gráfica usando RRF k=60. La latencia es inferior a 20ms en P50 (rápido porque es SQLite local).
La precisión en los benchmarks oficiales (LongMemEval-S, 500 preguntas, ICLR 2025) es la siguiente:
● R@5: 95.2% (Probabilidad de que la respuesta correcta esté entre los 5 primeros candidatos)
● R@10: 98.6%
● MRR: 88.2%
Ten en cuenta que esto es "precisión de búsqueda", no "precisión de QA de extremo a extremo". Es la probabilidad de que la respuesta correcta esté en algún lugar de los candidatos; si Claude la usa para responder correctamente es un asunto separado. No confíes demasiado en ello confundiendo ambos conceptos.
Acción 3: Auto-Compresión (Creciendo 4 Niveles con el Tiempo)
Cada vez que se ejecuta el hook Stop, ocurren tres etapas de compresión en orden:
Primero, Working → Episodic colapsa los registros brutos de herramientas en resúmenes de sesión. A continuación, Episodic → Semantic extrae "patrones" y "conocimiento" de múltiples eventos de sesión. Finalmente, Semantic → Procedural solidifica los pasos repetidos con frecuencia en "flujos de trabajo".
Esto resuelve automáticamente el problema de "guardar todo y crear ruido de búsqueda". El presupuesto de tokens inyectados al inicio de la sesión es de 2,000 tokens por defecto. Esto está diseñado para restaurar el "contexto anterior" de una forma necesaria y suficiente.
5. Flujo de Trabajo para Usar Codex / Claude Code en Paralelo
Ahora para la aplicación práctica. Para aquellos que usan seriamente tanto Codex como Claude Code, aquí hay tres patrones de flujo de trabajo.
Patrón 1: Flujo Diario para Desarrollo en Solitario
Manteniendo el servidor de agentmemory en ejecución, el hook SessionStart se activa cuando Claude Code se inicia, inyectando automáticamente la memoria Episodic del día anterior. Incluso sin decir "Continuar desde ayer", la conversación comienza con Claude ya entendiendo "Continuemos la discusión sobre el bloqueo con RLS de Supabase".
Durante la codificación, el hook PostToolUse sigue escribiendo comandos, salidas y diffs en SQLite. Cuando se cierra la sesión, el hook Stop comprime Working en Episodic. A la mañana siguiente, eso se lee automáticamente, completando el ciclo.
Patrón 2: Gestión de Múltiples Proyectos
Agentmemory puede dividir la memoria en tres ámbitos. El ámbito user está vinculado al individuo y contiene "hábitos personales" como preferencias de convenciones de codificación. El ámbito project se gestiona por separado para cada proyecto, con archivos SQLite separados. El ámbito local permanece solo en esa máquina y no sale ni siquiera en modo de uso compartido en equipo.
Al cambiar la variable de entorno a AGENTMEMORY_PROJECT=foo-app al cambiar de proyecto, se referencia un archivo SQLite diferente. Esto es increíblemente efectivo para personas que ejecutan múltiples proyectos en paralelo. El fenómeno por el cual las decisiones de diseño del Proyecto A se filtran en las discusiones del Proyecto B ocurría a menudo con CLAUDE.md. Con Agentmemory, están físicamente separados, por lo que no hay interferencia.
Patrón 3: Uso Compartido en Equipo y Desarrollo Conjunto con Empresas Cotizadas
Actualmente estamos co-desarrollando agentes de IA con empresas cotizadas, y el modo de uso compartido del servidor MCP es sutilmente efectivo aquí. Al establecer el indicador collab=true, múltiples instancias de Codex / Claude Code pueden hacer referencia al mismo servidor de memoria.
Lado del servidor
AGENTMEMORY_COLLAB=true npx @agentmemory/agentmemory --bind 0.0.0.0
Al hacer referencia a través de una VPN de equipo, múltiples personas pueden trabajar mientras comparten la "memoria del mismo proyecto". Sin embargo, el filtro de privacidad debe configurarse de forma estricta. Si se mezclan claves API o información personal, se compartirán con todo el equipo, por lo que la configuración de exclusión en .agentmemoryignore es obligatoria. Abordaré esto en la sección "Errores".
Errores Únicos al Usar Ambos en Paralelo
Al cambiar entre Codex y Claude Code en el mismo proyecto, la memoria se comparte, pero la sintaxis de los comandos es diferente. El comando /plugin de Claude Code no funciona en Codex, y el codex plugin install de Codex no funciona en Claude Code. Incluso si es una "herramienta que funciona para ambos", se requieren configuraciones individuales. Muchas personas se quedan atascadas aquí en la primera semana.
6. Cómo Leer los Benchmarks — Traduciendo Números a "Experiencia"
Traduciré las cifras oficiales a sensaciones prácticas.
La Verdad Detrás de la "Reducción del 92% de Tokens"
La "reducción del 92%" promocionada en flashes de noticias y artículos de Medium es por sesión.
● Operación manual convencional con CLAUDE.md: aproximadamente 22,000 tokens por sesión
● A través de Agentmemory: aproximadamente 1,900 tokens por sesión
● Tasa de reducción: aproximadamente 91-92%
Los tokens de inyección de contexto al inicio de una sesión se reducen drásticamente. Anualmente, las cifras cambian, y la tabla de Ahorro de Tokens en el README dice:
● Operación resumida por LLM: aproximadamente 650K tokens / año (aproximadamente $500 / año)
● Agentmemory: aproximadamente 170K tokens / año (aproximadamente $10 / año)
En términos de tokens, es aproximadamente una reducción del 74%, pero en términos de costo, es una reducción del 98%. $500 se convierten en $10. La razón de la diferencia es que Agentmemory se ejecuta en SQLite local + embeddings locales. A diferencia de Mem0 o Letta, que ejecutan compresión basada en LLM cada vez, el costo operativo es mínimo.
Qué Significa "LongMemEval-S R@5 95.2%"
LongMemEval-S es un benchmark de memoria a largo plazo publicado en ICLR 2025 (500 preguntas, aproximadamente 48 sesiones por pregunta, aproximadamente 115K tokens de contexto). Comparando las herramientas principales:
Herramienta | R@5 |
|---|---|
Agentmemory | 95.2% |
Mem0 (Nuevo algoritmo, abril 2026) | 94.8% |
Letta | 83.2% |
Cognee | 72.5% |
Zep | 71.0% |
Mem0 (Algoritmo antiguo) | 68.5% |
Mem0 se está acercando con su nuevo algoritmo, por lo que no es justo llamarlo una "victoria aplastante" basándose solo en números. Sin embargo, dado que Agentmemory logra el 95.2% en combinación con un mecanismo de captura automática especializado para agentes de codificación, la evaluación actual es que se encuentra en un punto óptimo para la compensación entre "precisión vs. carga operativa".
Para reiterar, R@5 es precisión de búsqueda, no la probabilidad de que Claude o Codex den finalmente la respuesta correcta. Confundir estos conceptos lleva a una sobrevaloración.
Codex 400K vs Opus 4.7 1M: "Físico vs. Práctico"
Mirando las cifras de los benchmarks, noté otro punto importante.
Claude Opus 4.7 amplió su contexto a 1M de tokens. GPT-5.5 también es de 1M de tokens vía API. Mirando solo esto, parece que "ya no necesitamos herramientas de memoria".
Sin embargo, Codex CLI está realmente limitado a 400K. El límite físico y el límite práctico están desalineados. Además, como la propia Anthropic escribió, el deterioro del contexto comienza en 200K-400K tokens a medida que el contexto aumenta.
En otras palabras, incluso si el tamaño físico aumenta, la necesidad de un motor de memoria no disminuye. Más bien, "cómo usar eficientemente una ventana de contexto amplia" se ha convertido en un nuevo desafío técnico.
7. 5 Errores — Minas Terrestres en las que Realmente Pisé
Seré honesto aquí. Estas son 5 minas terrestres en las que pisé mientras lo ejecutaba realmente, que no aparecen en el README oficial ni en los tweets de los influencers. Solo he seleccionado aquellas reproducibles de GitHub Issues.
Error 1: Desajuste de Versión de iii-engine v0.11.2
Inmediatamente después de la configuración, algunas personas obtienen este error:
iii: command not found
O
Version mismatch: expected v0.11.2, got v0.11.0
Agentmemory depende internamente de un binario llamado iii-engine, y la versión está fijada en v0.11.2. Si ya hay otra versión instalada, falla en la etapa de inicio. La solución es obtener la versión fija de los lanzamientos para cada sistema operativo.
macOS arm64
curl -fsSL https://github.com/iii-hq/iii/releases/download/iii/v0.11.2/iii-aarch64-apple-darwin.tar.gz \
chmod +x ~/.local/bin/iii
Linux x64
curl -fsSL https://github.com/iii-hq/iii/releases/download/iii/v0.11.2/iii-x86_64-unknown-linux-gnu.tar.gz \
Verificación
iii --version # Debería mostrar v0.11.2
Si omites esto, todo lo demás fallará más tarde, así que asegúrate de superar esto primero.
Error 2: Problema #181 — Producción Masiva de Sesiones Fantasma a Través de un Bucle Infinito
Este es seriamente peligroso. Un error fatal reportado en v0.9.1 donde llamar a /summarize desde el hook Stop sin tener configurada una clave API provoca una generación infinita de sesiones hijas.
Stop hook → /summarize → Se genera una sesión hija
↓
El hook Stop de la sesión hija también se activa → /summarize → Más sesiones hijas
↓
(Bucle infinito)
Hay un informe en GitHub Issue #181 de que se generaron alrededor de 579 sesiones fantasma en unos pocos minutos. Hay tres soluciones:
Opción 1: Deshabilitar el modo agent-sdk (Recomendado)
export AGENTMEMORY_ALLOW_AGENT_SDK=false
Opción 2: Forzar error con una clave API falsa
export AGENTMEMORY_ANTHROPIC_API_KEY="fake-key"
Opción 3: Establecer una clave API real
export AGENTMEMORY_ANTHROPIC_API_KEY="sk-ant-..."
Para uso en producción, la Opción 1 o 3 es segura. La Opción 2 es solo para el primer día cuando "solo quieres que funcione".
Error 3: Problema #159 — MCP y API REST Ejecutándose en KVs Separados
Este es otro fenómeno que te deja rascándote la cabeza si no lo conoces. Llamar a una herramienta MCP (como memory_search) devuelve resultados vacíos cada vez, pero la API REST (POST /agentmemory/search) encuentra coincidencias con los mismos datos.
API REST: GET /agentmemory/sessions → 69 observaciones
Herramienta MCP: memory_sessions → [] (vacío)
La causa es que el paquete @agentmemory/mcp y el servidor de Agentmemory están diseñados para tener almacenes KV completamente separados (Problema #159). MCP es "KV local" y el servidor es "otro KV", sin una ruta de comunicación entre ellos. A fecha de mayo de 2026, el problema permanece abierto. Las soluciones son:
● Opción 1: Usar la API REST directamente (a través de curl o fetch en lugar de herramientas MCP)
● Opción 2: Deshabilitar temporalmente el hook /mcp y ejecutar solo el servidor
Hay planes para solucionar esto en el futuro, pero por ahora, debes trabajar alrededor de esta especificación.
Error 4: MCP no se Refleja en Cursor / VSCode
Editaste ~/.cursor/mcp.json y reiniciaste Cursor, pero Agentmemory no aparece en /mcp list. Esto sucede no solo con Cursor, sino con las aplicaciones de la Windows Store en general.
Cerrar con el botón "X" de la GUI deja el proceso en segundo plano de WindowsApps ejecutándose por defecto. El proceso antiguo continúa ejecutándose con la configuración antigua en memoria. Se requiere un ritual de terminación completa.
macOS
pkill -9 Cursor
open /Applications/Cursor.app
Windows (PowerShell)
→ Reiniciar
Si conviertes "verificar procesos residuales" en tu primer paso antes de dudar del archivo de configuración, ahorrarás tiempo aquí.
Escollo 5: Observaciones descartadas silenciosamente por el filtro de privacidad
El fenómeno de "el servidor está funcionando, pero las observaciones no aparecen en el visor" también ocurre a menudo durante la primera semana. Si revisas los registros, verás advertencias como esta:
[warn] observation dropped: private_tag detected
[warn] observation dropped: private_email detected
Esto es por diseño, no un error. El filtro de privacidad de Agentmemory detecta automáticamente claves API, contraseñas, direcciones de correo electrónico e información personal identificable, y descarta esas observaciones sin registrarlas. Es una gran función de seguridad, pero si no lo sabes, pensarás que "no funciona". La estrategia de coexistencia es:
Excluir por archivo usando .agentmemoryignore
echo ".env" >> .agentmemoryignore
echo ".env.local" >> .agentmemoryignore
echo "*/.key" >> .agentmemoryignore
echo "*/password*" >> .agentmemoryignore
Especialmente al ejecutar código experimental que incluye claves API en las observaciones, es seguro colocar este archivo de antemano.
8. Resumen — "Memoria infinita" no es solo expansión de la ventana de contexto
Después de usar Agentmemory intensamente durante una semana, esta es la sensación que más me impactó: La expresión "memoria infinita" no se trata de la expansión física de la ventana de contexto.
Incluso si aumenta a 1M de tokens, si la precisión cae a los 200K, al final no tiene sentido. Siento que la carrera del tamaño físico ya terminó. En cambio, lo que Agentmemory te permite obtener es un cerebro externo semántico.
Mantén la memoria estructurada fuera de la sesión, no dentro. Invoca solo lo que necesitas cuando lo necesitas, y ciérralo cuando termines. Las cosas que vale la pena recordar crecen con el tiempo, mientras que las que pueden olvidarse se desvanecen silenciosamente. Es la misma estructura que usan los humanos para la memoria.
El cambio que ocurre en la mente de un desarrollador se puede describir en una frase: la transición de "todo termina cuando se corta la sesión" a "la memoria crece entre sesiones".
Toda la industria se mueve en esta dirección. El curso de memoria para agentes de DeepLearning.AI, el mensaje de Mem0 de "hacer que los agentes sin estado tengan estado", el artículo de MemGPT "LLMs como sistemas operativos"; en última instancia, todos se tratan de memoria externa, y Agentmemory es una solución en el contexto de los agentes de codificación.
Ya sea Mem0, Letta o tu propia implementación, para quienes usan Codex / Claude Code en serio, es actualmente la herramienta más rápida para probar la "sensación de memoria infinita". Francamente, vale la pena instalarlo.
9. Acerca de esta cuenta
Para quienes han llegado hasta aquí: esta cuenta @Codestudiopjbk está administrada por tres usuarios hardcore de Codex.
● Participación en programas de desarrollo para estudiantes de posgrado y posdoc
● Ganaron 300,000 yenes en premios
● Actualmente co-desarrollan agentes de IA con empresas cotizadas
Nuestro contenido habitual incluye:
● Ejemplos de implementación usando GPT-5.5 / OpenAI Codex
● Utilización de Codex, automatización de CLI y tendencias de desarrollo
● Traducción y verificación de la información más reciente de GPT-5.5 / Codex del extranjero
● Comparaciones prácticas con Claude Code (basadas en cientos de horas de uso)
● Aprendizajes del desarrollo conjunto con empresas cotizadas
Publicamos a diario sobre todo el proceso de llevar un producto funcional al mundo, desde la filosofía de desarrollo hasta el diseño, la implementación y la mejora. Si te interesa, por favor síguenos y échale un vistazo. Valdrá la pena.
Para consultas relacionadas con desarrollo, envíanos un mensaje directo. No dudes en contactarnos para la introducción de Codex, diseño de automatización o implementación de agentes de IA.
Referencias y citas
● [Rohit Ghumare (rohitg00/agentmemory)] (2026-05-13) Agentmemory v0.9.12 — Motor de memoria para agentes de codificación — Repositorio oficial, Apache-2.0, 8.8k estrellas, TypeScript
● [Rohit Ghumare] (2026-04) "Construí esto hace 6 meses con agentmemory: memoria persistente para agentes de codificación de IA" — Filosofía del desarrollador
● [GitHub Issue #181] Stop-hook → /summarize → recursión infinita de agent-sdk — Fuente principal del Escollo 2
● [GitHub Issue #159] Las herramientas MCP independientes no se conectan al servidor agentmemory en ejecución — Fuente principal del Escollo 3
● [Anthropic Engineering] Ingeniería de contexto efectiva para agentes de IA — Guía oficial sobre ingeniería de contexto
● [Anthropic] (2026-04-23) Informe postmortem del 23 de abril — Prueba social del incidente de colapso en la longitud de pensamiento de Claude Code
● [Mem0] Presentando Mem0 — Filosofía de Mem0 y cita de Taranjeet Singh
● [Letta] Evaluación comparativa de la memoria de agentes de IA — Fuente de los números de evaluación de Letta
● [Charles Packer et al.] (2023-10) MemGPT: Hacia LLMs como sistemas operativos — Artículo sobre gestión de contexto virtual, predecesor teórico de Agentmemory
● [DeepLearning.AI] Memoria de agentes: construyendo agentes conscientes de la memoria — Curso de Andrew Ng / Oracle
