BenBrain: memoria persistente para cada sesión de Claude

Cada sesión de Claude que ejecuto — teléfono, portátil, donde sea — arranca ya sabiendo qué se entregó ayer y qué sigue pendiente.

Hace un mes eso no era así.

Hace un mes, cada nuevo chat empezaba en frío. Abría una pestaña, hacía una pregunta, y Claude me recibía como a un desconocido. Me pasaba los primeros diez minutos re-explicando el proyecto, el stack, las decisiones de la semana anterior, el bug que habíamos rastreado a las 2am. Para cuando el modelo tenía suficiente contexto para ser útil, mi energía mental para el trabajo real ya se había gastado a medias.

Este es el coste del arranque en frío. Es la fricción que hace que "la IA como compañero de pensamiento" parezca una promesa que no termina de cumplirse. Cada sesión es una pizarra en blanco: hay que preparar el escenario de nuevo.

Lo había estado ignorando porque asumía que era simplemente la naturaleza de la herramienta. Los LLMs no tienen memoria entre sesiones; así funciona. Así que te adaptas — fijas un largo preámbulo en tu editor, mantienes un documento de "estado del proyecto" actualizado, lo pegas al inicio de cada chat. Y luego olvidas qué versión de ese documento tiene el estado actual real y pierdes otros diez minutos reconciliando.

Con el tiempo, resultó más barato arreglar la herramienta que seguir pagando ese coste.

Qué construí

BenBrain es una capa de memoria persistente que actúa en segundo plano en cada sesión de Claude. Son dos almacenes, ambos corriendo en mi servidor bare-metal en la UE, ambos detrás de mi red Tailscale, sin comunicarse con nadie más.

Qdrant — el vector store. Embeddings de todo lo que alguna vez se ha escrito. Decisiones, intentos, errores, aprendizajes. La función es la recuperación aproximada: "¿qué decidimos sobre ese crash por OOM hace tres semanas?" funciona aunque las palabras que uso hoy no coincidan con las que usé entonces. La similitud coseno sobre el espacio de embeddings es tolerante de una manera en que la búsqueda de texto no lo es.

Neo4j — el knowledge graph. El mismo contenido, una perspectiva diferente. Cada decisión, intento, error, módulo, sesión y aprendizaje es un nodo tipado con relaciones tipadas hacia otros nodos. Una Decision tiene un Why, bloquea un Error, reemplaza a otra Decision. Navegable como un grafo: desde cualquier punto de partida, puedes preguntar "¿qué llevó a esto?" y seguir las aristas hacia atrás.

El vector store gestiona "encuéntrame cosas como esta." El grafo gestiona "muéstrame cómo se conecta esto." Preguntas distintas, formas distintas, misma fuente de datos.

Esta es la forma aproximada de una entrada en el grafo:

{
  "id": "sophonix:decision:notion-as-blog-cms",
  "type": "Decision",
  "title": "Sophonix blog content lives in Notion, not in-repo MDX",
  "body": "Article rich text + media live in Notion page blocks; the build pulls them at next build and mirrors assets to public/blog/ so deploys are self-contained.",
  "severity": "informational",
  "created_at": "2026-05-11T16:42:00Z",
  "relations": {
    "supports": ["sophonix:initiative:linkedin-pipeline"],
    "informed_by": ["sophonix:learning:notion-rich-text-limits"],
    "blocks": []
  }
}

Esos son los datos. La parte interesante es el bucle que los llena.

El bucle, en cuatro pasos

1. Ejecuto /compact cuando el contexto de una sesión empieza a llenarse. Este es el único paso manual, y volveré a explicar por qué sigue siendo manual.
2. Un hook lee la transcripción. Un hook SessionEnd en Claude Code captura la conversación completa y la pasa a través de un prompt de extracción estructurada a GPT-4o. El prompt solicita entradas tipadas: qué decisiones se tomaron, qué intentos tuvieron éxito o fallaron, qué se aprendió que no era obvio solo con el código.
3. Las entradas se escriben en ambos almacenes. El JSON extraído se incrusta e indexa en Qdrant. Las mismas entradas se convierten en nodos tipados en Neo4j con relaciones al contexto circundante. Una decisión hace referencia a los intentos que la llevaron a ella. Un error hace referencia a las decisiones que evitaron que se repitiera.
4. La siguiente sesión arranca con esa memoria antepuesta. Un hook SessionStart consulta ambos almacenes — entradas recientes, más una búsqueda por similitud indexada en el proyecto actual y cualquier tarea pendiente — e inyecta los resultados como contexto inicial. Para cuando escribo el primer mensaje, Claude ya sabe dónde lo dejamos.

Un comando de mi parte. Todo lo demás se ejecuta solo.

Por qué bare-metal

Me lo preguntan constantemente: ¿por qué no Pinecone, Weaviate, Neo4j Aura? ¿Por qué ejecutar todo esto en un servidor que tengo que mantener yo mismo?

La respuesta del coste es accidental. Sí, es más barato, pero esa no es la razón.

La respuesta del control es el quid de la cuestión. Esta capa contiene cada decisión que tomo: posicionamiento de clientes, decisiones de arquitectura, compromisos de seguridad, ideas a medio formar sobre el próximo producto. Nada de eso debería vivir en un servidor que no controlo. Ni el de Pinecone. Ni el de Neo4j. Ni el de nadie. La razón por la que quiero memoria persistente es externalizar mi pensamiento — y externalizar tu pensamiento en la base de datos de otra persona es un intercambio estrictamente peor que no externalizarlo en absoluto.

Tailscale cierra el círculo. El servidor solo es accesible dentro de mi red. No hay acceso público a la capa de memoria. Claude Code en mi portátil accede a Qdrant y Neo4j a través de Tailscale; nada más lo hace. Cero exposición a internet en la ruta de datos.

Este es el mismo principio que guía el trabajo de consultoría en Sophonix: construimos para los clientes de la misma manera que construimos para nosotros mismos. Si yo no confiaría en un tercero con mi propio registro de decisiones, no voy a recomendar que un cliente confíe en uno con el suyo.

Lo que todavía se hace a mano

El paso /compact me corresponde a mí invocarlo. Es una decisión deliberada.

La alternativa — captura continua, con el hook disparándose cada pocos miles de tokens de contexto — suena elegante. Pero duplica el gasto en la API de extracción, y significa que el modelo tiene menos control sobre qué cuenta como un límite memorable. Una sesión que divaga por tres temas no relacionados se fragmenta en tres entradas a medias en lugar de un hilo coherente. La compactación manual deja que el humano decida qué aspecto tiene "una sola cosa".

El olvido también sigue siendo manual, en el sentido de que nada olvida todavía. Cada entrada vive para siempre, cada embedding permanece indexado. Eso está bien por ahora, pero es un callejón sin salida conocido. La memoria de solo escritura se degrada en la recuperación mucho antes de degradarse en el almacenamiento: a medida que el corpus crece, la señal en cualquier consulta individual queda enterrada bajo el ruido histórico. La solución correcta es la decadencia — recuperación ponderada por recencia, posiblemente con "lápidas" explícitas de "esto ya no está vigente". Aún no construido. Registrado.

Qué sigue

La hoja de ruta, en orden:

• Captura continua con límites más inteligentes. Detectar cambios de tema en la transcripción y compactar en esos bordes en lugar de esperar a /compact. Sigo queriendo revisión humana de las entradas, pero el marcador de "qué compactar" puede ser automático.
• Decadencia y lápidas. Cuando una decisión es reemplazada, la antigua no debería simplemente coexistir junto a la nueva — debería marcarse como reemplazada, y la recuperación debería penalizar su retorno.
• Primitivas de compartición. Ahora mismo BenBrain es de un solo usuario. La misma arquitectura podría servir a un equipo: un grupo pequeño con una capa de memoria compartida, donde la sesión de cada miembro contribuye al mismo grafo. Aquí es donde apunta el trabajo de consultoría: el mismo problema de durabilidad que BenBrain resuelve para mí, todos los equipos lo acaban encontrando.

El punto clave

La infraestructura siempre ha estado activa. El servidor ha estado ahí. La base de datos en grafo, el vector store, la red — todo ello.

Lo que cambió no es la infraestructura. Lo que cambió es que el pensamiento ahora también está activo. Las decisiones no se evaporan al final de una sesión. Los errores no se vuelven a depurar seis semanas después. El hilo conductor de "qué estamos construyendo y por qué" sobrevive a través de días, dispositivos, contextos.

Esa es la parte que importa. No el stack. No la elección de Qdrant sobre Pinecone o Neo4j sobre Aura. Esos son notas al pie. El punto es que un compañero de pensamiento que recuerda es un tipo de compañero diferente al que no recuerda — y llegar ahí resultó ser un prompt de extracción, dos almacenes y un hook.

¿Cuál es tu capa de memoria?