Second brain con IA: memoria, agentes y escala desde el sistema del CEO de Passwd

Cada vez que abría una conversación con Claude, tenía que explicar desde cero quién soy, qué hace mi empresa, con quién trabaja. Era agotador. Así que concluí que el problema no era el modelo: era la memoria.

MAREK ELZNIC
CEO de Passwd

Marek Elznic lleva meses usando un second brain con IA que combina Obsidian, Claude y sus fuentes de trabajo —Gmail, Slack, transcripciones de reuniones— para que su asistente no empiece cada conversación desde cero.

Lo llama su second brain, aunque yo lo describiría de otra manera: una capa de memoria externa estructurada para un agente, y esa distinción cambia completamente cómo evaluar cuándo tiene sentido construir algo así. Marek lo presentó en una de nuestras Knowledge Sharing, y lo que sigue no es un resumen de lo que explicó, sino las preguntas que me quedaron después.

Qué construyó Marek y cómo funciona

La arquitectura es sencilla; solo tiene tres piezas:

• Obsidian como vault. Un conjunto de notas en Markdown, enlazadas entre sí, almacenadas en local y sincronizadas por iCloud. Personas, empresas, reuniones, señales activas. El grafo de conexiones entre notas es lo que convierte un archivo plano en algo navegable por un agente.
• Claude como motor. No como interfaz de chat, sino como proceso que tiene acceso a ese vault y puede leerlo, actualizarlo y enlazar contenido nuevo. La clave es que trabaja con archivos locales en Markdown, sin integraciones ni servicios de terceros de por medio, lo que simplifica la arquitectura y mantiene el coste operativo bajo en el uso cotidiano.
• Las fuentes como señal continua. Gmail y Slack, principalmente. Cada noche, Claude recorre esas fuentes, actualiza las notas relevantes, vincula personas con proyectos y reuniones, y genera un briefing para el día siguiente: reuniones pendientes, preguntas que conviene hacer, tareas que podrían haberse colado.

Lo que resuelve es concreto: Marek no tiene que explicar el contexto cada vez que abre una conversación. El agente ya sabe —por poner un ejemplo— quién es el responsable de marketing, que llevan cinco años trabajando juntos, y que el tono que Marek usa con él es distinto al que usa con un lead nuevo. Eso, en la práctica, cambia la calidad del output.

El propio equipo de Passwd publicó un artículo sobre el sistema que resume bien la lógica central: el conocimiento solo se vuelve valioso a través de las conexiones que se acumulan en el tiempo y la mayoría de los sistemas colapsan antes de llegar a ese punto porque el mantenimiento resulta insostenible. Delegar esa capa al agente es lo que hace que el efecto compuesto sea alcanzable.

Andrej Karpathy describió públicamente este mismo enfoque: indexar fuentes en bruto —artículos, papers, repos, imágenes— y usar un LLM para «compilar» de forma incremental una wiki, que no es más que una colección de archivos Markdown con resúmenes, backlinks y artículos enlazados que el propio modelo escribe y mantiene, todo visualizado en Obsidian. Marek ha concretado este patrón en un flujo de trabajo real —correo, Slack, reuniones— y lo ha sostenido en el tiempo, que es justo donde la mayoría de estos sistemas se caen.

Second brain con IA: cuándo tiene sentido este patrón frente al contexto nativo

La pregunta que me hice al ver el sistema de Marek fue: ¿cuándo tiene sentido este patrón y cuándo es suficiente el contexto nativo del modelo?

La respuesta depende de tres variables:

• Persistencia del contexto. Si el agente necesita recordar información entre sesiones distintas —personas, decisiones pasadas, historial de interacciones—, el contexto nativo no alcanza. El patrón vault da control explícito sobre qué se recuerda y cómo.
• Volumen y estructura del conocimiento. El vault de Marek acumula meses de notas sobre personas, empresas y proyectos. Meter todo eso en cada conversación como contexto sería prohibitivo en coste y en latencia. La ventaja del vault es que el agente recupera solo lo que necesita en cada momento, como una base de datos, no como un documento adjunto.
• Frecuencia de actualización. Si el contexto cambia poco —un proyecto con requisitos estables, un dominio bien documentado—, basta con pasarlo como contexto al inicio. Si cambia cada día —interacciones, decisiones, señales del negocio—, necesitas un proceso de actualización automatizado. El agente nocturno de Marek es exactamente eso: un proceso de sincronización que mantiene la memoria al día sin intervención manual.

En proyectos de cliente, el umbral para construir este patrón aparece cuando el agente tiene que operar sobre conocimiento organizacional que cambia con frecuencia, que no cabe en el contexto de una sola conversación, y que necesita persistir entre sesiones. Por debajo de ese umbral, el contexto nativo es más sencillo de mantener y tiene menos puntos de fallo.

Lo que cambia cuando dejas de ser un usuario individual

El sistema de Marek está optimizado para una sola persona. Eso no es una crítica: es el contexto correcto para lo que construyó. Pero cuando pensamos en replicar este patrón a escala de equipo —o de organización—, la arquitectura cambia de forma no trivial.

El primer cambio es de propiedad del vault. En el sistema personal, el vault es la representación del contexto de Marek: cómo piensa, con quién trabaja, cómo escribe. A escala de equipo, el vault tiene que representar conocimiento compartido —decisiones de arquitectura, contexto de cliente, historial de proyecto— sin convertirse en el perfil personal de nadie. Eso implica un modelo de datos diferente y, sobre todo, una política clara de qué entra y qué no.

El segundo cambio es de escritura concurrente. Un agente nocturno que actualiza un vault para una persona es trivial de coordinar. Varios agentes actualizando un vault compartido en paralelo —o peor, un agente que recibe señales de múltiples usuarios simultáneamente— introducen problemas de consistencia que no existen en el caso personal.

El tercero es de gobernanza de las fuentes. Marek conecta sus propios canales de Slack y su propio Gmail. A escala de organización, las fuentes son conversaciones de equipo, documentación interna, tickets, PRs. Decidir qué se indexa, quién tiene acceso a qué fragmento del vault, y cómo se trata la información sensible deja de ser una preferencia personal y se convierte en un problema de arquitectura de datos con implicaciones legales y de privacidad.

El patrón sigue siendo válido. Lo que cambia es que la versión corporativa requiere un rediseño desde la capa de datos hacia arriba, no simplemente escalar el sistema personal.

Lo que hay que tener en cuenta antes de llevarlo a producción

Puede que estés pensando en algo que Marek nombró explícitamente: este sistema quedará obsoleto en pocos años. Los propios modelos resolverán el problema de memoria, y cuando eso ocurra, construir y mantener un vault externo dejará de tener sentido. Lo construyó porque hoy la solución nativa no ofrece suficiente control, no porque sea la arquitectura ideal a largo plazo.

Es el punto de partida correcto para evaluar las limitaciones que importan cuando piensas en esto para un cliente.

• Coste de arranque. La fase de seeding inicial —indexar todo el conocimiento existente y construir el vault desde cero— es cara en tokens y en tiempo. En un uso personal, lo asumes una vez. En un despliegue corporativo, ese coste se multiplica y hay que planificarlo.
• Calidad del vault depende de la calidad de las fuentes. Si Slack está lleno de ruido, si las reuniones no se transcriben bien, si los documentos de referencia están desactualizados, el agente construye memoria sobre señal deficiente. Garbage in, garbage out, con la particularidad de que aquí la basura persiste y se propaga a través de la memoria.
• Opacidad acumulada. Un vault que crece durante meses sin revisión manual puede desarrollar inconsistencias que el agente perpetúa. Marek mencionó los orphan files —notas sin conexión— como una señal visible de ese problema. En producción, necesitas un proceso de auditoría del vault, no solo de actualización.
• Fiabilidad del agente nocturno. Todo el sistema asume que ese proceso funciona de forma fiable. Si falla una noche, la memoria se desactualiza. En producción, ese proceso necesita observabilidad, alertas y manejo de errores como cualquier otro pipeline crítico.

La diferencia entre el prototipo de Marek y una versión lista para producción no está en la idea, que es sólida, sino en todas las capas que hacen que un sistema sea mantenible, observable y escalable en el tiempo. Construir esas capas es el trabajo de ingeniería que convierte un experimento personal en una herramienta en la que una organización puede confiar.