Un cerebro central para todos mis agentes: Obsidian + Graphify
Mike Codeur
He dividido por 70 el consumo de tokens de mis agentes de IA. No cambiando de modelo. Cambiando su memoria.
Pero el ahorro de tokens es solo la consecuencia. El tema real está en otra parte, y es más importante.
El problema: cinco empleados brillantes y amnésicos
Uso cinco herramientas de IA distintas. Claude Code en el repo, Claude Desktop para el chat diario, OpenClaw como mayordomo multicanal, Hermes como agente 24/7 en mi VPS, y mi propio OS agéntico para la orquestación.
Cada uno tiene su memoria. Encerrada en él.
Claude Code tiene su CLAUDE.md. Claude Desktop tiene sus conversaciones. OpenClaw tiene su memoria. Hermes la suya. Ninguno sabe lo que los demás han aprendido.
Se acumulan dos problemas:
- Tu contexto está fragmentado y preso. Cambias de herramienta, empiezas de cero. La herramienta desaparece o la cortan, tu cerebro se va con ella.
- Cada agente relee todo, en cada sesión. No tiene mapa, así que abre los archivos uno a uno para entender dónde está.
El primer problema es estratégico. El segundo es financiero. Tienen la misma causa.
La tesis: tu cerebro no debe vivir en ninguna herramienta
Es el principio File over App de Steph Ango, el CEO de Obsidian, llevado a la era de los agentes.
Tu memoria debe vivir en archivos abiertos que tú posees. Las herramientas se conectan a ella. Ninguna la posee.
No es una postura ideológica, es cálculo de riesgo. Una herramienta de IA puede desaparecer, cambiar de precio, ser prohibida, o simplemente dejar de convenirte. Si tu contexto vive dentro, eres rehén. Si vive en markdown que tú posees, cambias de herramienta un martes por la tarde y no pierdes nada.
Un archivo markdown se lee dentro de diez años, por cualquier agente. Sin formato propietario, sin lock-in.
La arquitectura: dos capas, N superficies
┌──────────────────────────────┐
│ CEREBRO CENTRAL │
│ Obsidian (markdown) │ ← decisiones, contexto, contenido
│ + │
│ Graphify (graph.json) │ ← el mapa del código, consultable
│ → formato abierto, tuyo │
└──────────────────────────────┘
▲ ▲ ▲ ▲
┌────────┘ │ │ └────────┐
mi OS Claude Code OpenClaw Hermes
(orquestación) (en el repo) (mayordomo) (agente 24/7)
Cada superficie LEE y ESCRIBE el mismo cerebro. Ninguna lo posee.
Capa 1: Obsidian, la memoria humana
El vault contiene mis decisiones, mi contexto y mi contenido. En markdown puro.
El principio de organización, otra vez Steph Ango: las carpetas indican el tipo, el frontmatter lleva los metadatos. Un archivo nunca se mueve. Para cambiar el estado de una nota, modificas una propiedad, no la desplazas.
Es la capa que yo leo y edito. Y que los agentes entienden de forma nativa, porque es texto.
Capa 2: Graphify, el mapa
Esta es la parte nueva, y la que resuelve el problema de coste.
Sin mapa, un agente que llega a tu repo tiene una sola opción: abrir archivos. Uno a uno. En cada sesión. Ahí es donde se van los tokens.
Graphify transforma tu repo (código, docs, markdown) en un grafo consultable, un graph.json, construido con tree-sitter. Lo importante: el grafo se construye desde el AST, no con un modelo. Cuesta cero tokens.
Después, el agente consulta el grafo en vez de releerlo todo.
Las cifras — son las mediciones publicadas por el proyecto claude-code-memory-setup, sobre su propio benchmark. Las cito como tales, no como verdad universal:
| Enfoque | Coste por sesión |
|---|---|
| Releer ~40 archivos | ~20 000 tokens |
Consultar graph.json | ~280 tokens |
Es decir, una reducción anunciada de hasta 71,5× por sesión, y unas 499× por consulta en su test de 126 archivos TypeScript.
En mi uso, el orden de magnitud se sostiene. De ahí viene el "dividido por 70".
Cómo se conecta en concreto
Graphify produce un graph.json, un GRAPH_REPORT.md y notas de Obsidian (una por función o módulo). Son archivos, en el repo, que el agente lee. Sin magia.
La regla que doy a mis agentes son tres capas, en este orden:
- Consultar el grafo para saber dónde están las cosas y cómo se relacionan.
- Consultar el vault de Obsidian para las decisiones y el contexto.
- Leer el código en bruto solo si es necesario.
Todo está en ese "solo si es necesario". La mayoría de las preguntas no exigen leer el código. Exigen saber dónde está y por qué es así.
El beneficio real: las herramientas se vuelven intercambiables
El cerebro es central. Las herramientas son satélites.
Puedo añadir o quitar una herramienta sin perder nada. El cerebro se queda. Cuando sale un agente nuevo, lo conecto al vault y llega con dieciocho meses de contexto sin que yo tenga que reexplicar nada.
Ese es el beneficio real. El 70× está bien, pero es la consecuencia de una buena arquitectura, no el objetivo.
Lo que puedes sacar de esto
No necesitas mi setup exacto. Necesitas la regla:
- Tu memoria vive en archivos abiertos que tú posees, no en una herramienta.
- Tus agentes necesitan un mapa antes que el territorio. Un mapa se construye una vez y se consulta mil veces.
- El markdown es un formato de archivo. Sobrevivirá a todas tus herramientas.
El método completo, con la demo y el setup, está en el vídeo: Un cerebro central para todos mis agentes
Y si quieres este tipo de método cada semana, está en The Agentic Dev.