La conversación con un agente se evapora. Cierras la terminal y se lleva el contexto, las decisiones y ese "ya lo habíamos acordado". Un segundo cerebro no es un chat más largo. Es un vault de Obsidian que los agentes pueden leer y escribir, con las mismas reglas que tú.

En Ashi Labs trabajamos así: el vault es la memoria, MCP es el cable, y el agente de turno (Hermes, Claude Code u OpenCode) es un operador intercambiable. Cambias de cliente y el cerebro sigue siendo el mismo.

Qué estás montando

El cerebro: Un vault de Obsidian con carpetas predecibles.

El sistema nervioso: El plugin Local REST API with MCP (Adam Coddington).

Los operadores: Cualquier cliente MCP.

Sin esas tres piezas el agente improvisa sobre el disco, pisa notas enteras o, si el vault vive en iCloud, ni siquiera puede listar archivos. El MCP habla con el índice de Obsidian, no con un -"find" a ciegas.

Un vault que un agente pueda navegar

No hace falta un sistema perfecto. Hace falta que un modelo adivine dónde va cada cosa sin preguntarte cada vez. Esta forma nos ha funcionado:

Convenciones que sí importan:

  • Frontmatter YAML en cada nota (tags, status, aliases si hace falta).

  • Wikilinks para lo interno. URLs normales para lo externo

  • Una idea por nota cuando el tema va a reaparecer. El hub y los índices atan el grafo.

  • Callouts de Obsidian si escribes para humanos. Los agentes los respetan.

Captura de pantalla de una aplicación de gestión de notas con una interfaz de grafo que muestra conexiones entre archivos. A la izquierda, una estructura de carpetas; en el centro, el mapa de nodos; a la derecha, el panel de detalles del índice.

El hub: Second-Brain.md

Este archivo es el system prompt del vault. El agente lo lee al empezar (por MCP, o porque se lo pides). Si no existe, cada sesión reinventará tus reglas.

Mínimo que tiene que tener:

  • Quién eres y en qué estás (sin datos que no quieras que un modelo recicle).

  • Mapa de carpetas, en texto, no en la cabeza.

  • Reglas de escritura. Obsidian nativo, notas atómicas, wikilinks, no reescribir una bitácora entera.

  • Un bloque de estado que se actualiza (aprendizaje, proyectos, siguientes pasos).

  • Prompts copiables para los flujos que ya usas.

El plugin Local REST API with MCP

En Obsidian será necesario este plugin. Lo puedes instalar desde Ajustes → Plugins comunitarios → Explorar. Luego, lo puedes activar. En ajustes, tendrás que gestionar la Local REST API. Copia la API key (64 caracteres). Trátala como un secreto local: no va al git.

Por defecto el plugin sirve HTTPS en https://127.0.0.1:27124/ con un certificado autofirmado. El endpoint MCP es:

https://127.0.0.1:27124/mcp/

Ese certificado rompe clientes. Claude Code corre sobre Bun y no lee el llavero de macOS. Hermes a veces falla el handshake. La salida limpia, en local, es HTTP.

En Ajustes → Local REST API, activa Enable HTTP server (el servidor inseguro). Queda así:

A partir de aquí el mismo endpoint MCP se pega en tres clientes. Elige HTTP en local. Reserva HTTPS para cuando hayas confiado el certificado.

Cablear los agentes

Claude Code habla HTTP MCP de nativo. Lo más corto, a nivel usuario (todos los proyectos):

claude mcp add --scope user --transport http obsidian
http://127.0.0.1:27123/mcp/
--header "Authorization: Bearer TU_API_KEY"

Luego, comprueba la conexión: claude mcp list. También puedes configurar a nivel de proyecto a través de un .mcp.json. Importante decirte que si insistes en HTTPS, vas a pelearte con el certificado autofirmado. En local no vale la pena.

Otro detalle es que no abras el vault de iCloud como proyecto de Claude Code para que "lea todo". Eso infla el contexto y, en macOS, el sandbox a veces ni entra a ~/Library/Mobile Documents.

El MCP es la puerta. CLAUDE.md sí puede vivir dentro del vault como nota, y se lo das con @ cuando haga falta.

Para los demás agentes, como Opencode o Hermes el procedimiento no varía demasiado.

Enseñar al agente a no romper el vault

Conectar MCP no basta. Un agente con vault_write y sin reglas te machaca una bitácora de tres meses en un turno.

Reglas que conviene dejar por escrito en el hub (y repetir en skills / CLAUDE.md / AGENTS.md si quieres cinturón y tirantes):

  • Crear una nota nueva: vault_write.

  • Añadir a una nota que ya tiene historia: vault_append o vault_patch. Nunca write sobre una bitácora.

  • Antes de parchear un heading, leer el document map.

  • No reemplazar el H1 de un log. Ese heading es el padre de todas las entradas.

  • Verificar con vault_read o una búsqueda, no con un cat al archivo de iCloud(u otro sistema de la nube). El bind mount a veces miente unos segundos.

Cuando un curso, un repo o una investigación no caben en un turno, no le gritas al agente un párrafo de 80 líneas cada vez. Guardas el briefing como nota.

Cómo se trabaja un día cualquiera

Flujos que ya están rodados. Cópialos al hub y ajústalos.

Procesar una lección: "Lee esta nota de curso. Resume, saca 3 notas atómicas con wikilinks, 5 preguntas de repaso y actualiza el estado."

Arrancar un proyecto: "Crea 02-Proyectos/<slug>/ con Index, bitácora y las preguntas que hay que cerrar antes de codear." En Ashi Labs el cuaderno va antes que el repo cuando el alcance aún se discute.

Cerrar el día: "Actualiza el Estado de transición con lo de hoy. No reescribas el resto del hub."

Pasar de un agente a otro: No exportas el chat. El siguiente operador abre el mismo vault, lee el hub y la bitácora. Si el lote es largo, le pasas la nota de handoff.

El chat es volátil a propósito. Lo que importa quedó en markdown.

Cosas que rompen el setup (y no son el modelo)

Obsidian cerrado. No hay MCP. No hay REST. El agente se pone creativo con el filesystem y, en iCloud(de nuevo, puede ser cualquier sistema de la nube), se come un Operation not permitted.

  • No reiniciar después de activar HTTP. El data.json ya dice enableInsecureServer: true y el puerto sigue muerto.

  • vault_write sobre una nota viva. Es un overwrite. Las bitácoras se parchean.

  • Heading a medias. El plugin casa el path completo. Pide el document map.

  • Key en el repo. Un .mcp.json commiteado con Bearer es un secreto publicado. Usa scope user, env, o un archivo gitignored.

  • Veinte MCP a la vez. Cada tool description come contexto. Obsidian + uno o dos más. El resto, apagado.

  • Tratar el chat como archivo. Si no está en el vault, no existió.

Consejos finales

Esto no es un plugin de chat dentro de Obsidian. No es sincronizar el vault a un vector store en la nube. No es un agente "con memoria" del proveedor. Es más aburrido y más sólido: archivos markdown, un servidor local autenticado, y clientes que ya sabes usar.

Cuando Hermes no esté, queda Claude Code. Cuando Claude Code se atasque, queda OpenCode. El segundo cerebro no se muda con ellos.