Crónica de construir un segundo cerebro con grafo de conocimiento, pipeline bilingüe y endpoints para agentes — en días, no semanas, y lo que eso enseña sobre la brecha entre teoría y sistemas que funcionan.
Un viernes de marzo de 2026, vi un video de Nate B Jones titulado «Why 2026 Is the Year to Build a Second Brain». Su tesis: el segundo cerebro ya no es un sistema pasivo de almacenamiento — es un sistema activo que trabaja mientras duermes. Definía 8 bloques de construcción, y en una publicación posterior una arquitectura con Postgres y MCP con un costo de $0.10-0.30/mes.
Cerré el video y abrí la terminal. No iba a tomar notas sobre cómo construir un segundo cerebro — iba a construirlo. Ese fin de semana.
48 horas después, jonmatum.com existía. Un monorepo con Turborepo que transforma archivos MDX en un grafo de conocimiento navegable. En los días siguientes, el sistema siguió creciendo — y sigue. Al momento de escribir:
/llms.txt, /api/knowledge, /api/graph, /api/mcpLa velocidad fue posible por una decisión temprana: no escribir 131 conceptos perfectos, sino 131 seeds. Un seed es un stub de 150 palabras con frontmatter válido y status: seed. No necesita estar completo para existir en el grafo — solo necesita estar correcto. El grafo se beneficia de la cobertura tanto como de la profundidad.
Pero la velocidad también fue posible porque usé agentes de IA para asistir la generación. Sin esa asistencia, 156 items bilingües en días sería imposible. Jones describe exactamente este modelo: el humano captura el pensamiento, la IA se encarga del resto. Pero en la práctica descubrí que la línea es más borrosa — el humano también decide qué profundizar, qué conexiones importan, y cuándo el output de la IA necesita reescritura. No es captura humana + automatización IA — es un ciclo continuo de juicio humano asistido por IA.
Una vez que el sistema existía, lo evalué contra el framework de Jones. El resultado fue revelador:
Jones: canal privado de Slack, cero fricción.
jonmatum.com: archivos MDX en content/, asistidos por agentes IA.
Estado: parcial. Capturar un pensamiento requiere crear un archivo MDX con 11 campos de frontmatter y hacer commit. La generación de contenido es asistida por IA, pero la fricción de captura sigue siendo alta comparada con escribir en un canal de Slack.
Jones: agente de IA que clasifica automáticamente sin intervención del usuario.
jonmatum.com: type: definido por el autor, tags y cross-refs sugeridos por agentes.
Estado: parcial. La clasificación es una decisión humana — el autor elige si algo es un concepto, nota, experimento o ensayo. Los agentes sugieren tags y cross-references, pero no clasifican automáticamente.
Jones: esquema fijo por tipo (nombre, estado, siguiente acción).
jonmatum.com: frontmatter con 11 campos validados por pnpm validate.
Estado: completo. Cada tipo de contenido tiene un esquema estricto. El pipeline rechaza archivos con campos faltantes o tipos incorrectos.
Jones: bases de datos en Notion para personas, proyectos, ideas, administración.
jonmatum.com: content/{concepts,notes,experiments,essays}/.
Estado: completo. Cuatro directorios por tipo de contenido, cada uno con su propio patrón de maduración.
Jones: Inbox Log que documenta cada clasificación y acción del sistema. jonmatum.com: historial de Git (264 commits) + job summaries de GitHub Actions. Estado: completo. Cada cambio queda registrado con autor, fecha, diff y mensaje. Los workflows de agentes generan summaries con el resultado de cada job.
Jones: score de confianza 0-1; si está por debajo del umbral, el ítem va a revisión en lugar de archivarse.
jonmatum.com: pipeline de validación (validate + generate:content + lint:content) + revisión por agentes antes de commit.
Estado: completo. El pipeline rechaza contenido que no cumple el esquema o el linter. Los agentes crean PRs — nunca commitean directo a main. El humano es el bouncer final.
Jones: digests diarios y semanales enviados automáticamente con información relevante. jonmatum.com: agente QA semanal que audita contenido y abre issues con hallazgos. Estado: parcial. El agente QA identifica conceptos con referencias faltantes, cross-refs rotos, secciones débiles y encabezados incorrectos — y abre issues automáticamente. Es surfacing proactivo de problemas de calidad, pero no de contenido relevante para el usuario. Falta el digest personalizado que Jones describe.
Jones: comandos simples en el chat para reclasificar ítems mal clasificados. jonmatum.com: sistema de tres agentes que audita, corrige y mejora contenido. Estado: completo. El agente QA detecta problemas, el agente de corrección aplica fixes quirúrgicos, el agente de contenido genera upgrades completos. Los tres crean PRs para revisión humana.
Los bloques 3-6 y 8 están sólidos. El bloque 7 pasó de ausente a parcial gracias al agente QA semanal — pero le falta el componente de surfacing personalizado (digests con contenido relevante, no solo problemas). Los bloques 1-2 siguen siendo parciales: la captura tiene fricción y la clasificación es manual.
Lo que la evaluación no muestra es que la arquitectura ya contenía los principios correctos sin haberlos leído. Jones insiste en separar memoria, cómputo e interfaz. El monorepo ya lo hacía:
content/ — texto plano, portable, sin vendor lock-inpackages/knowledge/ — parser, constructor de grafo, generador de llms.txt, embeddingsapps/web/Esta separación se probó cuando la búsqueda semántica falló en producción. Pude revertir a búsqueda por keywords sin tocar el contenido ni el grafo — cambié la interfaz, la memoria quedó intacta. El stack es deliberadamente genérico: MDX, JSON, Next.js. Si mañana quiero migrar a Astro o DynamoDB, el contenido MDX sigue siendo el mismo.
Jones también describe una «superficie compartida con dos puertas»: el agente entra por una, el humano por la otra. En jonmatum.com la puerta humana es el sitio web; la puerta del agente es /llms.txt, /api/knowledge, /api/graph. Pero la puerta del agente es de solo lectura. Jones propone que ambas lean y escriban. Esa es la brecha más grande — y la que más me interesa cerrar.
Intenté búsqueda semántica con @huggingface/transformers (Xenova/all-MiniLM-L6-v2) corriendo en WebAssembly en el navegador. Falló por tres razones:
tolist(), .data y output[0] se comportan diferente entre Node.js y WASM del navegadorRevertí a búsqueda instantánea por keywords. Las embeddings pre-computadas siguen generándose en build time para uso futuro.
Esto es lo que Jones llama 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 6% son «high performers» que atribuyen un impacto significativo en resultados. La búsqueda semántica client-side es un ejemplo perfecto: funciona en demos, falla en deploy. El gap no es de conocimiento — es de integración práctica.
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 es un proceso de 15-30 minutos por concepto. La captura de baja fricción es el siguiente problema a resolver.
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 que mi equipo y comunidad técnica pudieran leer el contenido, y el inglés es el idioma de la industria. Al mismo tiempo, quería que mi familia y amigos que no hablan inglés pudieran acceder a lo que estoy construyendo.
Esa tensión definió una decisión de arquitectura: 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 es real: ~244,000 palabras totales entre ambos idiomas — aproximadamente el doble de contenido que un sistema monolingüe. Pero la decisión creó algo que no esperaba: una separación natural entre las dos puertas de Jones. 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. Un grafo, dos interfaces.
No encontré otros segundos cerebros públicos que sean bilingües. El ecosistema de PKM es abrumadoramente monolingüe. ¿Es sostenible a escala? Con traducción asistida por IA + revisión humana, sí. Sin IA, a 500+ items la traducción manual sería un cuello de botella.
Lo que no anticipé fue cuánto trabajo vendría después del sprint inicial. Crear 131 seeds fue rápido — llevarlos a evergreen es otra historia.
El proceso de maduración sigue un patrón: tomo un concepto seed de ~350 palabras y lo expando a 700+. Agrego tablas comparativas con herramientas reales, ejemplos de código funcional, diagramas mermaid con accTitle y accDescr para accesibilidad, y una sección «¿Por qué importa?» escrita desde la perspectiva de un staff+ engineer. Cada referencia se verifica con curl antes de commitear. Luego replico la estructura exacta en el archivo .en.mdx.
Después de llevar 46 conceptos a evergreen — desde serverless hasta web components, desde embeddings hasta agentic workflows — descubrí algo: el valor no está en el seed inicial sino en las conexiones que emergen durante la expansión. Al profundizar en prompt caching, aparecieron conexiones con inference optimization que no existían en el seed. Al expandir RAG, las aristas hacia embeddings y vector databases se fortalecieron con ejemplos concretos.
Pero el proceso manual no escala. A 10 conceptos por semana, los 85 seeds restantes tardarían más de dos meses. Así que construí algo que no estaba en el plan original: un sistema de tres agentes que automatiza el ciclo de vida del contenido.
Un agente QA audita los 46 conceptos evergreen cada semana — verifica conteo de palabras, referencias, cross-refs, accesibilidad de diagramas, encabezados en el idioma correcto — y abre issues de GitHub con los hallazgos. Un agente de corrección aplica fixes quirúrgicos: agregar una referencia faltante, diversificar tiers de calidad, traducir un encabezado. Un agente de contenido genera reescrituras completas para llevar seeds a evergreen. Los tres usan Strands Agents con Claude Sonnet 4 en Amazon Bedrock, corren en GitHub Actions con autenticación OIDC (sin secrets estáticos), y crean PRs para revisión humana.
El patrón de ejecución es un «diamante»: un job de plan descubre trabajo y genera una matriz JSON, jobs paralelos procesan cada item de forma aislada, y un job de summary consolida resultados. Los workflows con LLM serializan los jobs (max-parallel: 1) para evitar throttling de Bedrock; el QA estructural — que no usa LLM — mantiene paralelismo alto.
El resultado: el humano pasó de escritor a editor. En lugar de expandir cada concepto manualmente, reviso PRs generados por agentes. La calidad sigue siendo mi responsabilidad — el agente propone, yo apruebo — pero el throughput se multiplicó.
El grafo no solo crece en nodos — crece en densidad. Y la densidad es lo que convierte una colección de notas en un sistema de conocimiento. Hoy, después de agregar un sistema de tags con 460 etiquetas navegables, un dashboard con métricas de salud del grafo, skeletons de carga para cada ruta, y diseño mobile-first, el sistema está al 80% de lo que imaginé ese viernes.
jonmatum.com corre hoy en Vercel — deploy instantáneo, SSL automático, CDN global. Para un sitio estático con 155 nodos, es perfecto. Pero los bloques que faltan — captura de baja fricción, surfacing proactivo, puerta de escritura para agentes — requieren backend stateful. Y como ingeniero apasionado por serverless en AWS, esa suite es donde tengo más experiencia y control.
La arquitectura objetivo:
Cada servicio mapea a un bloque de Jones:
| Bloque de Jones | Servicio AWS | Función |
|---|---|---|
| 1. Dropbox (captura) | API Gateway + Lambda | Endpoint /api/capture — acepta texto + URL, crea item en DynamoDB |
| 2. Sorter | Lambda + Bedrock | Clasifica automáticamente el tipo y sugiere tags |
| 3. Form (esquema) | DynamoDB | Esquema validado en la Lambda de escritura |
| 4. Filing Cabinet | DynamoDB | Tablas por tipo de contenido con índices secundarios |
| 5. Receipt | DynamoDB Streams | Cada mutación genera un registro de auditoría |
| 6. Bouncer | Lambda | Validación de calidad antes de persistir |
| 7. Tap on the Shoulder | EventBridge + Lambda + SNS | Cron diario que identifica seeds olvidados y envía digest |
| 8. Fix Button | Bedrock AgentCore | Agente con tools MCP para editar, reclasificar, conectar nodos |
Lo que hace esta arquitectura interesante es que cierra los gaps restantes sin abandonar los principios que funcionaron:
El costo estimado a la escala actual (155 nodos, ~100 consultas/día):
| Servicio | Costo mensual |
|---|---|
| CloudFront + S3 | ~$0.50 |
| API Gateway + Lambda | ~$0.10 |
| DynamoDB (on-demand) | ~$0.25 |
| Bedrock (embeddings + chat) | ~$1-3 |
| EventBridge + SNS | ~$0.01 |
| Total | ~$2-4/mes |
Comparable al $0.10/mes de Jones con Postgres, pero con la ventaja de escalar a miles de nodos sin cambiar la arquitectura. Y sin servidor que mantener.
El paso más interesante no es la búsqueda semántica ni el chat con IA — es lo que pasa cuando la puerta del agente deja de ser de solo lectura.
Hoy, un agente puede consultar todo mi grafo de conocimiento vía MCP. Pero no puede agregar un nodo, conectar dos conceptos, ni marcar un seed como desactualizado. Con Bedrock AgentCore exponiendo tools como add_node, connect_nodes, flag_stale, cualquier cliente de IA podría no solo leer mi segundo cerebro sino contribuir a él.
Eso cambia la naturaleza del sistema. Ya no es un archivo que consulto — es un colaborador que crece mientras trabajo en otra cosa. Un agente que lee un paper y agrega un concepto seed. Otro que detecta que dos nodos deberían estar conectados y crea la arista. El bloque 7 de Jones — surfacing proactivo — deja de ser un cron que envía emails y se convierte en un agente que reorganiza el grafo.
EventBridge ejecuta una Lambda diaria: seeds sin actualizar en 7+ días, conceptos con pocas conexiones, nodos huérfanos. Pero en lugar de solo notificar, el agente puede actuar — proponer expansiones, sugerir conexiones, generar drafts para revisión humana. El humano sigue decidiendo qué se publica. Pero el sistema deja de esperar a que el humano recuerde que tiene seeds pendientes.
Ese viernes, cuando cerré el video de Jones y abrí la terminal, no sabía tres cosas que ahora sé:
La brecha de implementación no es técnica — es editorial. La infraestructura se construyó en horas. El contenido lleva semanas y sigue incompleto. 85 seeds esperan madurar — ahora con agentes que aceleran el proceso. La IA acelera la escritura pero no reemplaza el juicio de qué vale la pena profundizar y qué conexiones importan. El segundo cerebro automatiza el sistema, no el pensamiento.
El grafo es más valioso que los nodos. 156 conceptos individuales son una enciclopedia personal. 412 aristas entre ellos son un sistema de conocimiento. La densidad — las conexiones que emergen cuando profundizas un concepto y descubres que toca otros tres — es lo que hace que el segundo cerebro sea más que la suma de sus partes.
Bilingüe no es un feature — es una postura. Decidir que mi familia pueda leer lo mismo que mis agentes de IA consumen no fue una decisión técnica. Fue decidir para quién construyo. Y esa decisión, más que cualquier Lambda o endpoint, es lo que hace que este segundo cerebro sea mío.
El siguiente paso — llevar este prototipo a producción — lo exploro en «Del prototipo a producción: un segundo cerebro serverless».
Estructuras de datos que representan conocimiento como redes de entidades y relaciones, permitiendo razonamiento, descubrimiento de conexiones y consultas semánticas sobre dominios complejos.
Protocolo abierto creado por Anthropic que estandariza cómo las aplicaciones de IA se conectan con herramientas, datos y servicios externos mediante una interfaz universal.
Campo de la informática dedicado a crear sistemas capaces de realizar tareas que normalmente requieren inteligencia humana, desde el razonamiento y la percepción hasta la generación de lenguaje.
Sistemas autónomos que combinan modelos de lenguaje con razonamiento, memoria y uso de herramientas para ejecutar tareas complejas de múltiples pasos con mínima intervención humana.
Estándar propuesto para publicar un archivo Markdown en la raíz de un sitio web que permite a los modelos de lenguaje entender y utilizar el contenido del sitio de forma eficiente durante la inferencia.
Técnica de recuperación de información que utiliza embeddings vectoriales para encontrar resultados por significado, no solo por coincidencia exacta de palabras clave.
Representaciones vectoriales densas que capturan el significado semántico de texto, imágenes u otros datos en un espacio numérico donde la proximidad refleja similitud conceptual.
Patrón arquitectónico que combina la recuperación de información de fuentes externas con la generación de texto por LLMs, reduciendo alucinaciones y manteniendo el conocimiento actualizado sin reentrenar el modelo.
SDK open source de AWS para construir agentes de IA con un enfoque model-driven. Agentes funcionales en pocas líneas de código, con soporte multi-modelo, herramientas personalizadas, MCP, multi-agente y observabilidad integrada.
Servicio serverless de AWS que proporciona acceso a modelos fundacionales de múltiples proveedores (Anthropic, Meta, Mistral, Amazon) vía API unificada, sin gestionar infraestructura de ML.
Framework de React para aplicaciones web full-stack con Server Components, routing basado en archivos, SSR/SSG y optimizaciones de rendimiento integradas.
Estrategia de organización de código donde múltiples proyectos coexisten en un único repositorio, compartiendo dependencias, configuración y herramientas de build.
Framework CSS utility-first que permite construir diseños directamente en el markup usando clases atómicas, eliminando la necesidad de escribir CSS custom.
Sistemas de almacenamiento especializados en indexar y buscar vectores de alta dimensión de forma eficiente, habilitando búsqueda semántica y aplicaciones de RAG a escala.
Práctica de definir y gestionar infraestructura mediante archivos de configuración versionados en lugar de procesos manuales. Fundamento de la automatización moderna de operaciones.
Modelo de computación en la nube donde el proveedor gestiona la infraestructura automáticamente, permitiendo ejecutar código sin aprovisionar ni administrar servidores, pagando solo por el uso real.
Capacidad de los LLMs para generar llamadas estructuradas a funciones externas basándose en lenguaje natural, habilitando la integración con APIs, bases de datos y herramientas del mundo real.