Construyendo un segundo cerebro en público

¿Qué construí?

En un fin de semana de marzo de 2026, construí un segundo cerebro. No el tipo de segundo cerebro que vive en una app de notas y acumula polvo — uno con un grafo de conocimiento de 154 nodos y 369 aristas, un pipeline bilingüe español-inglés, y endpoints que cualquier agente de IA puede consultar.

El resultado es jonmatum.com: 131 conceptos, 20 experimentos, 3 notas, ~131,000 palabras en dos idiomas, un grafo interactivo con D3, y una superficie agent-friendly con /llms.txt, /api/knowledge, /api/graph y /api/mcp. Costo mensual: $0.

La inspiración vino de la serie de Nate B Jones sobre segundo cerebro con IA. Su tesis: el segundo cerebro ya no es un sistema pasivo de almacenamiento — es un sistema activo que trabaja mientras duermes. Vi el video, leí los posts, y en lugar de tomar notas sobre cómo construir uno, simplemente lo construí.

Los 8 bloques en práctica

Jones define 8 bloques de construcción para un segundo cerebro funcional. Así se mapean a lo que construí:

Los bloques 3-5 están sólidos. El bloque 7 — surfacing proactivo — es el que falta por completo. Y es, según Jones, el diferenciador entre un sistema de almacenamiento y un segundo cerebro real.

Lo que funcionó

La separación de responsabilidades

Jones insiste en separar memoria, cómputo e interfaz. Sin haber leído ese principio antes de empezar, la arquitectura del monorepo ya lo implementa:

• Memoria: archivos MDX en content/ — texto plano, portable, sin vendor lock-in
• Cómputo: packages/knowledge/ — parser, constructor de grafo, generador de llms.txt, embeddings
• Interfaz: Next.js en apps/web/ — la puerta humana

Esta separación permitió cambiar la interfaz sin tocar el contenido, y viceversa. Cuando la búsqueda semántica falló en producción, pude revertir a búsqueda por keywords sin perder un solo nodo del grafo.

El principio de las dos puertas

Jones describe una «superficie compartida con dos puertas»: el agente entra por una, el humano por la otra. Ambos acceden a los mismos datos.

En jonmatum.com:

• Puerta humana: el sitio web con navegación por tipo, grafo interactivo, búsqueda, i18n
• Puerta del agente: /llms.txt (634 líneas), /llms-full.txt (11,568 líneas), /api/knowledge, /api/graph, /api/concepts/[id], /api/mcp

Lo que falta: la puerta del agente es de solo lectura. Jones propone que ambas puertas lean y escriban. Hoy, un agente puede consultar todo mi grafo de conocimiento pero no puede agregar un nodo. Esa es la brecha más grande con Open Brain.

Arquitectura sobre herramientas

Uno de los principios que emergieron de la comunidad de Jones: «la arquitectura importa más que las herramientas». Un miembro cambió cada herramienta recomendada y obtuvo los mismos resultados.

jonmatum.com valida esto. El stack es deliberadamente genérico: MDX (texto plano), JSON (datos generados), Next.js (interfaz). No hay dependencia en Notion, Obsidian, ni ningún SaaS de PKM. Si mañana quiero migrar la interfaz a Astro o el almacenamiento a Postgres, el contenido MDX sigue siendo el mismo.

Diseñar para reinicio, no para perfección

Cada concepto tiene un campo status: seed | growing | evergreen. Un seed es un stub de 150 palabras con frontmatter válido. No necesita estar completo para existir en el grafo — solo necesita estar correcto.

Esto desbloqueó la velocidad: en lugar de escribir 131 conceptos perfectos, escribí 131 seeds y dejé que crecieran. El grafo se beneficia de la cobertura tanto como de la profundidad.

Lo que falló

Búsqueda semántica en el cliente

Intenté búsqueda semántica con @huggingface/transformers (Xenova/all-MiniLM-L6-v2) corriendo en WebAssembly en el navegador. Falló por tres razones:

1. ~30MB de descarga en la primera búsqueda — inaceptable para un sitio personal
2. Inconsistencias en la API de tensores de Transformers.js v3 — tolist(), .data y output[0] se comportan diferente entre Node.js y WASM del navegador
3. Problemas de compatibilidad en Vercel que no se reproducían localmente

Revertí a búsqueda instantánea por keywords. Las embeddings pre-computadas siguen generándose en build time para uso futuro. La solución viable es una API route server-side — ~$0.10/mes a la escala actual.

Este es un ejemplo concreto de la brecha de implementación que Jones describe: tecnología que debería funcionar en teoría pero se rompe en la práctica.

La fricción de captura

El bloque 1 de Jones — el Dropbox — requiere cero fricción. Capturar un pensamiento en jonmatum.com requiere: crear un archivo MDX, escribir frontmatter con 11 campos obligatorios, escribir contenido en español, crear el archivo .en.mdx con la traducción, y hacer commit. Eso no es cero fricción — es un proceso de 15-30 minutos por concepto.

La velocidad que logré (154 items en 5 días) fue posible porque usé agentes de IA para asistir la generación. Sin esa asistencia, el ritmo sería insostenible. La captura de baja fricción es el siguiente problema a resolver.

La brecha de implementación

McKinsey reporta que el 88% de las organizaciones usan IA en al menos una función de negocio, pero solo el 1% considera sus implementaciones maduras. Jones enmarca esto como la brecha de implementación: el mundo se divide entre la «máquina de hype» y el «complejo industrial de comparación de features». Lo que falta es el puente.

Construir jonmatum.com en un fin de semana me enseñó dónde está ese puente — y dónde no:

El puente existe cuando la arquitectura es simple y las herramientas son maduras. Turborepo, Next.js, MDX, Tailwind — nada de esto fue un obstáculo. La infraestructura se construyó en horas, no días.

El puente no existe cuando la tecnología promete más de lo que entrega en producción. La búsqueda semántica client-side es el ejemplo perfecto: funciona en demos, falla en deploy. El gap no es de conocimiento — es de integración práctica.

El puente tampoco existe para el contenido. 131,000 palabras en dos idiomas no se escriben solas. La IA asistió, pero el juicio editorial — qué incluir, cómo conectarlo, qué nivel de profundidad — sigue siendo humano. El segundo cerebro automatiza el sistema, no el pensamiento.

¿Por qué bilingüe?

Mi idioma nativo es español. Escribir en español es natural — las ideas fluyen sin la fricción de traducir mentalmente. Pero quería compartir conocimiento con mi equipo y comunidad, y el inglés es el idioma universal de la tecnología. Al mismo tiempo, quería que mis amigos y familia que no hablan inglés pudieran acceder al contenido.

La solución: español como idioma primario (el sitio por defecto), inglés como traducción (disponible en /en/...). Cada concepto tiene .mdx (español) y .en.mdx (inglés). El frontmatter incluye title_es/title_en y summary_es/summary_en.

El costo: 73,963 palabras en español + 57,409 en inglés = ~78% más contenido que un sistema monolingüe. Pero el valor es desproporcionado:

• Los agentes de IA consumen /llms.txt en inglés — el idioma en que los LLMs funcionan mejor
• Los humanos hispanohablantes leen el sitio en español — sin barreras
• El grafo de conocimiento es el mismo para ambos idiomas — una sola estructura, dos interfaces

No encontré otros segundos cerebros públicos que sean bilingües. El ecosistema de PKM es abrumadoramente monolingüe (inglés). Esto es una oportunidad, no un problema.

¿Es sostenible a escala? Con traducción asistida por IA + revisión humana, sí. Sin IA, no. A 500+ items, la traducción manual sería un cuello de botella. Pero ese es un problema para resolver cuando llegue — no una razón para no empezar.

¿Qué sigue?

El sistema está al 75%. Tiene captura MDX, organización por tipo, grafo de conocimiento con 154 nodos y 369 aristas, resúmenes bilingües, búsqueda por keywords, endpoints agent-friendly (/llms.txt, /api/*), visualización D3 del grafo, i18n completo y deploy en Vercel. Lo que falta:

Búsqueda semántica server-side

La búsqueda actual es por keywords — funciona, pero no entiende significado. El plan: una API route /api/search que cargue las embeddings pre-computadas (ya existen en embeddings.json), calcule el embedding de la query con OpenAI text-embedding-3-small, y haga cosine similarity. A 155 nodos no necesito una base de datos vectorial — todo cabe en memoria. Costo estimado: ~$0.10/mes.

Interfaz conversacional con RAG

Poder preguntarle al segundo cerebro: «¿qué sé sobre infraestructura como código?» y que responda con contexto de mis propios conceptos. La arquitectura: un agente con Strands que use las embeddings para retrieval aumentado y Claude Sonnet vía Bedrock para generación. API route /api/chat con streaming. Costo estimado: ~$1-3/mes dependiendo del uso.

Backlinks en la UI

El grafo ya tiene las aristas — si el concepto A referencia al concepto B, la arista existe. Lo que falta es invertirla en la UI: mostrar en cada página «estos conceptos te referencian». Es un helper getBacklinks(slug) y un componente. Costo: $0.

Captura externa

Hoy la única forma de capturar es crear un archivo MDX manualmente. El siguiente paso: una API route /api/capture que acepte texto + URL de origen, lo almacene como MDX en captures/, y opcionalmente genere embeddings. Esto abre la puerta a un bookmarklet, una extensión de navegador, o integración con Readwise.

Surfacing proactivo

El bloque 7 de Jones — el que falta por completo. Los datos para implementarlo ya existen: fechas created/updated en cada item, el grafo con aristas para encontrar contenido relacionado, y status: seed como señal de prioridad. La implementación más simple: un widget en el homepage que use localStorage para trackear qué conceptos visitaste y cuándo, y te sugiera seeds olvidados o conceptos que no has revisado en semanas.

El servidor MCP

El paso más interesante. jonmatum.com ya expone /api/mcp — el endpoint existe. Un servidor MCP completo expondría herramientas como search_knowledge, get_concept, list_related que cualquier cliente de IA podría invocar. El protocolo fue donado a la Linux Foundation en 2026, tiene más de 1,000 servidores en producción, y es soportado por Claude, ChatGPT, Cursor y prácticamente todo cliente de IA relevante. Esto convertiría la puerta del agente de solo lectura a lectura-escritura — cerrando la brecha con Open Brain.

El costo total

Todo cabe dentro de los límites del plan Pro de Vercel. La ruta de evolución de MDX estático a Postgres + MCP existe cuando la escala lo demande. Por ahora, el costo es ~$0 y la arquitectura es portable. El segundo cerebro no necesita ser perfecto — necesita existir.

Referencias

• Why 2026 Is the Year to Build a Second Brain — Nate B Jones, 2026. El video original con el framework de 8 bloques.
• Open Brain: the $0.10/month fix — Nate B Jones, marzo 2026. Arquitectura Postgres + MCP.
• Learn in Public — Shawn Wang (swyx), 2018. El ensayo fundacional sobre aprender y construir en público.
• 25 Years of Personal Knowledge Management — Sébastien Dubois, 2022. Crónica de 25 años de evolución en PKM.
• Building a Second Brain — Tiago Forte, 2022. El libro que popularizó el concepto y el método PARA.
• Zettelkasten Method — Christian Tietze. Referencia del método de notas interconectadas de Luhmann.
• Model Context Protocol — Specification — Anthropic/Linux Foundation. Especificación del protocolo.
• How Leaders Can Realize Value from GenAI — Forbes, 2026. Resumen del reporte McKinsey State of AI 2025 (88% adopción, 1% madurez).