Comparativa · Fase 2 — la memoria
Cortex vs engram.
Las dos memorias persistentes para agentes de IA. engram (de Alan / Gentleman Programming) y Cortex resuelven el mismo problema — que el agente no olvide entre sesiones. Acá no hay innovación paralela: Cortex es, declaradamente, una reimplementación inspirada en engram.
Qué es cada uno.
Mismo problema, dos posturas — y una de ellas nació de la otra.
Un producto de memoria, maduro y standalone
Un binario Go de cero dependencias — "set it up once and forget about it". SQLite + FTS5, y cuatro interfaces (MCP, HTTP, CLI, TUI). Local-first, sync por git, cloud self-host opcional. Pensado para instalarse en cualquier agente y desaparecer.
Una capa de memoria para una plataforma
Una reimplementación en Node.js, "inspirada en Engram, construida para
automatización". SQLite + FTS5 también — pero multi-tenant (cada
fila lleva workspace_id) y servida vía un gateway en
CeroClawd. No es un producto suelto: es la memoria del ecosistema zero.
Bloques componibles
Productos standalone. engram — memoria persistente (binario Go). gentle-ai / gentle-pi — harness SDD + skills.
La memoria como servicio adentro
Cortex — capa de memoria del workspace. zero / zero-pi — pipeline SDD + autotune. CeroClawd — la plataforma que lo hospeda.
Cómo se ve una memoria.
Las dos son tipadas y estructuradas — Cortex copió el molde y le sumó campos.
engram — observation
Cortex — memory
Casi el mismo modelo. Las dos diferencias que importan: Cortex deriva el
scope del tipo (y con eso comparte entre proyectos) y le da a
cada memoria un relevance_score que decae — engram no tiene ni
una ni la otra. A cambio, engram vincula memorias entre sí
(supersedes, conflicts_with) — Cortex no.
La comparativa.
| Dimensión | engram | Cortex |
|---|---|---|
| Runtime | binario Go, 0 dependencias — un archivo estático | Node.js ESM, 2 deps (better-sqlite3, MCP SDK) |
| Storage | SQLite WAL + FTS5 | SQLite WAL + FTS5 — mismo enfoque |
| Interfaces | ✓MCP · HTTP · CLI · TUI | ~MCP (stdio) · HTTP REST · CLI — sin TUI |
| Modelo de memoria | observation tipada (7 tipos) + What/Why/Where/Learned | memory tipada (10 tipos) + title/what/why/where_at/learned |
| Upsert / dedup | ✓topic_key + normalized_hash |
✓topic_key + normalized_hash + ventana de dedup de 15 min |
| Búsqueda | ~FTS5 BM25 lexical — sin semántica en el core | ✓FTS5 + híbrido FTS+vector opcional (RRF) cuando se activa |
| Relaciones entre memorias | ✓links tipados — supersedes, conflicts_with; detección de conflictos al guardar; LLM-judge |
✗solo un grafo derivado (topic_key / archivo / proyecto) — sin links de significado |
| Decay / olvido | ✗nada — las memorias se acumulan para siempre | ✓relevance_score que decae + memoria_forget + soft-delete |
| Cross-project | ✗namespaced por proyecto — sin transferencia entre proyectos | ✓scope shared + retrieval por stack-match entre proyectos del mismo stack |
| Sesiones | ✓sessions + summary estructurado | ✓sessions + summary + suggested_memories (heurístico bilingüe) |
| Multi-tenancy | ~single-user local; cloud self-host (Postgres) | ✓workspace_id en todo + gateway CeroClawd con API keys |
| Memoria de equipo | ✗archivo local single-user — un dev, una memoria, nadie aprende de nadie | ✓cloud — API keys compartibles; varios devs o equipos alimentan un mismo workspace |
| Sync multi-máquina | ✓git-chunk sync, vivo y funcionando | ✗sync.mjs existe pero es código muerto, sin endpoint |
| Tools MCP | 19 — incluye mem_judge, mem_compare, mem_doctor |
15 — incluye memoria_recall, memoria_timeline, memoria_forget |
| Agentes | ✓engram setup <agente> — ~9 agentes, instalador por agente |
~Claude Code y pi vía el server MCP cortex |
| Madurez | ✓v1.15.13, 83 releases | ~v1.1.0 — joven |
El producto más completo.
Honesto: engram es hoy más maduro y más completo. Sin vueltas.
Relaciones y conflictos entre memorias
engram, al guardar, busca memorias relacionadas y deja registrar
verdictos tipados — supersedes, conflicts_with —
con un LLM-judge opcional. Los resultados anotan "esto reemplaza a #42".
Es higiene de memoria real. Cortex solo acumula.
Binario Go, cero dependencias
Un solo archivo estático — sin Node, sin Python, sin Docker. Trivial de auditar, deployar y respaldar. Cortex necesita Node y su runtime.
v1.15.13 vs v1.1.0
83 releases, instaladores por agente (engram setup), TUI,
sync por git vivo, cloud self-host con dashboard de equipo. Cortex tiene
el sync.mjs como código muerto y ningún dashboard propio.
Agente-agnóstico de verdad
engram se instala en ~9 agentes (Claude Code, OpenCode, pi, Gemini, Codex, Copilot, Cursor…) con wiring automatizado. Cortex hoy se usa desde Claude Code y pi vía su server MCP.
Más angosto — pero distinto.
Más joven, sí — pero apuesta a varias cosas que engram no hace. Y una cambia el juego apenas trabajás con más gente.
Una brain que aprende de todo el equipo, no de una persona.
Cortex es cloud y multi-tenant: las API keys del gateway se comparten. Un equipo entero — o varios devs, o varios equipos — apunta al mismo workspace. Cada decisión, cada bug resuelto, cada patrón que descubre cualquiera entra a la misma memoria.
El efecto compuesto: la brain no es unipersonal. Aprende de todos a la vez, así que aprende rápido — diez devs llenándola rinden como diez veces un dev. Y alguien que se suma hereda, desde el día uno, todo lo que el equipo ya sabe. engram es un archivo local single-user: cada persona arranca de cero y el conocimiento no circula.
Memoria que cruza proyectos
El scope: shared (derivado del tipo: pattern/lesson/preference)
hace que un patrón aprendido en un proyecto aparezca solo en otro
del mismo stack. engram aísla cada proyecto. Es transferencia de
aprendizaje, no solo almacenamiento.
La memoria se olvida
Cada memoria tiene un relevance_score que decae si no se
toca en 30+ días; memoria_forget poda lo viejo. engram no
tiene decay — en un proyecto largo la memoria crece sin techo.
Multi-tenant por diseño
Cada fila lleva workspace_id; el gateway de CeroClawd
valida API keys y resuelve el workspace. Cortex está hecho para ser un
servicio de memoria de una plataforma, con muchos usuarios.
Búsqueda híbrida — encuentra por significado
Cortex fusiona FTS5 léxico y similitud vectorial (RRF) en modo semántico: busca por lo que quisiste decir, no solo por las palabras exactas. Guardás "arreglé el redirect de auth", meses después buscás "login loop" — Cortex lo trae igual. El core de engram es FTS5 léxico solo: esa misma memoria, con otras palabras, queda invisible. En una brain de equipo, donde cada uno nombra las cosas distinto, esto es la diferencia entre que el conocimiento se reuse o se pierda.
Quién gana en qué.
Sin maquillaje: engram es hoy la mejor memoria para usar standalone — más madura, más completa, agente-agnóstica de verdad, y con un diferenciador fuerte (relaciones y conflictos entre memorias) que Cortex no tiene. El propio Cortex lo reconoce: "inspired by Engram".
Cortex no le gana a engram en features ni en madurez — y pretender lo contrario sería deshonesto. Su apuesta es otra: ser la capa de memoria de una plataforma, no un binario local. De ahí sale lo suyo — búsqueda semántica, memoria que cruza proyectos, decay/olvido, y sobre todo una memoria de equipo: muchos devs alimentando una misma brain que aprende de todos a la vez.
La jugada para Cortex: robarle a engram las relaciones entre memorias (su mejor idea) y cerrar el gap de madurez — sin perder lo suyo. Cortex no necesita "ganarle" a engram: necesita ser la mejor memoria integrada al ecosistema zero. Ahí no compiten en lo mismo.