Por qué la memoria importa más de lo que parece
La promesa de un agente útil no es que escriba código, es que entienda tu codebase. Y entenderlo toma tiempo: aprenderse las convenciones, las decisiones pasadas, los workarounds que existen "porque sí". Si cada sesión empieza con un agente que olvidó todo, le pagas a esa curva de aprendizaje cada vez que lo enciendes.
Agentmemory persiste esa curva. La primera sesión es cara — tienes que explicarle el proyecto. De la segunda en adelante, ya sabe. Lo que cambia el cálculo no es el ahorro por sesión, es el efecto compuesto a lo largo de semanas.
Cómo se compara con otras "memory layers"
El mercado está lleno de soluciones que prometen memoria para agentes: vector stores, RAG sobre conversaciones pasadas, "context engines" varios. La diferencia de agentmemory está en tres cosas:
- Es MCP nativo. No reinventa el wire protocol. Funciona con cualquier cliente compatible sin adapters.
- Knowledge graph, no solo embeddings. La estructura permite consultas más precisas que "busca lo más similar".
- Confidence scoring + lifecycle. Las memorias caducan, se actualizan, se promueven. No es un append-only de todo lo que pasaste.
Limitaciones honestas
El proyecto es relativamente nuevo (16k stars, mayo 2026). La calidad del knowledge graph depende mucho del uso: en proyectos con poco material o con decisiones poco explícitas, la memoria queda rala. Y aunque el autor publica benchmarks, los resultados varían según cliente y tipo de tarea — no esperes un milagro inmediato.
Mi recomendación
Si ya invertiste en hacer que tu equipo use bien un agente de coding, agentmemory es la siguiente capa lógica. Si todavía estás peleando para que adopten Claude Code o Cursor, esto no es prioridad — primero la práctica, después la memoria.