Obsidian + Claude Code: Cómo Gestiono Mi Empresa desde un Vault

Markdown plano como sistema de gestión empresarial

Llevo meses gestionando mi empresa desde un directorio de archivos Markdown. Sin Notion, sin Google Docs, sin herramientas de gestión de proyectos con dashboards bonitos. Un vault de Obsidian conectado a Claude Code con agentes especializados que debaten entre ellos y me ayudan a tomar decisiones.

No es una idea teórica. Lo uso todos los días. Las reuniones de dirección de mis proyectos las hace una mesa redonda de agentes IA. Mis notas de conocimiento se crean y enlazan solas. El estado de cada proyecto se actualiza después de cada reunión.

Y el coste total de esta infraestructura es la suscripción a Claude Max ($100/mes) más un servidor que ya tenía.

Si te interesa cómo montar algo así, te cuento exactamente cómo lo tengo montado.

Por qué Obsidian y no otra cosa

La decisión fue sencilla. Necesitaba algo que cumpliera tres condiciones:

Markdown plano: archivos .md que cualquier herramienta puede leer
Local-first: los datos están en mi máquina, no en un servidor de terceros
Compatible con Claude Code: que el agente pueda leer y escribir sin APIs intermedias

Notion falla en las tres. Necesitas su API para acceder a los datos, el formato es propietario, y dependes de sus servidores. Google Docs, lo mismo. Cualquier herramienta SaaS te encierra en su ecosistema.

Obsidian es un editor de Markdown con superpoderes (graph view, wiki-links, plugins), pero lo que lo hace perfecto para este caso es que debajo solo hay una carpeta con archivos .md. Claude Code abre esa carpeta y ya tiene acceso a todo. Sin configuración, sin tokens de API, sin adaptadores.

Criterio	Obsidian	Notion	Google Docs
Formato	Markdown plano	Propietario	Propietario
Acceso local	✅ Carpeta de archivos	❌ API necesaria	❌ API necesaria
Claude Code nativo	✅ Lee/escribe directo	❌ Necesita MCP	❌ Necesita MCP
Portabilidad	✅ Copiar carpeta	⚠️ Export a Markdown (pierde formato avanzado)	❌ Export limitado
Coste	Gratis	$10/mes (Plus)	Gratis (con Google)
Offline	✅	❌	❌
Bases de datos / Kanban	❌ Necesita plugins	✅ Nativo	❌
Colaboración equipo	⚠️ Git o Sync	✅ Nativa	✅ Nativa

Para ser justo: si necesitas bases de datos relacionales, vistas kanban, o colaboración nativa con equipo, Notion sigue siendo más capaz. El trade-off de Obsidian es perder esas funciones a cambio de simplicidad y acceso directo del agente.

Hay gente usando MCP servers para conectar Notion a Claude Code, y funciona. Pero es una capa intermedia que para mi caso no compensa. Si tus datos ya están en Markdown, el agente los lee directamente. Menos complejidad, menos puntos de fallo.

La estructura del vault

Mi vault se llama brain-dump y tiene esta estructura:

brain-dump/
├── diario/              # Entradas diarias: diario/YYYY/MM/DD.md
├── personas/
│   └── trabajo/         # Compañeros y contactos profesionales
├── trabajo/
│   └── empresa/
│       ├── _sobre.md    # Ficha de la empresa
│       ├── proyecto/
│       │   ├── _sobre.md
│       │   └── {scope}.md
│       └── clientes/
│           └── nombre-cliente/
├── conocimiento/
│   ├── moc/             # Maps of Content (índices narrativos)
│   └── notas/           # 117 notas de conocimiento
├── reuniones/           # Actas de reuniones de dirección
└── CLAUDE.md            # Reglas para Claude Code

Cada carpeta tiene un propósito claro. No hay archivos sueltos en la raíz (excepto el README y el CLAUDE.md). No hay subcarpetas infinitas. La organización es plana y predecible.

Lo que conecta todo son los wiki-links de Obsidian: [[personas/trabajo/nombre-apellido]], [[trabajo/acme/estado-actual]], [[diario/2026/04/08]]. Cualquier archivo puede enlazar a cualquier otro. Y Claude Code entiende estos enlaces y los sigue cuando necesita contexto.

El archivo CLAUDE.md: las reglas del juego

Esto es clave. En la raíz del vault hay un CLAUDE.md con todas las convenciones: cómo nombrar archivos, qué frontmatter usar, cómo enlazar personas, cómo estructurar las notas de conocimiento. Cuando Claude Code abre el directorio, lee estas reglas y las respeta.

Es la misma idea que expliqué en mi guía de Claude Code: las reglas en CLAUDE.md son el contrato entre tú y el agente. Sin reglas claras, el agente improvisa. Con reglas claras, el agente es consistente.

Cómo Claude Code interactúa con el vault

Abro Claude Code en el directorio brain-dump/ y tengo acceso a varias capacidades configuradas como skills y agentes.

Reuniones de dirección: La Cúpula

Esta es la pieza más potente. Tengo una skill /reunion que arranca una mesa redonda con 7 agentes especializados:

Agente	Rol	Modelo
CEO	Moderador, sintetiza debate	Opus
Estrategia	Decisiones de negocio, prioridades	Sonnet
Marketing	Posicionamiento, campañas, audiencia	Sonnet
SEO	Keywords, tráfico orgánico	Sonnet
YouTube	Canal, contenido, tendencias	Sonnet
UX/UI	Interfaz, accesibilidad	Sonnet
Finanzas	Costes, ingresos, ROI	Sonnet
Producto	Roadmap, MVP, priorización	Sonnet

El flujo es así:

El CEO lee el estado actual de todos mis proyectos (estado-actual.md de cada empresa) y la última acta de reunión
Me presenta un resumen y me pregunta qué quiero tratar
Spawna los agentes relevantes para el tema usando Agent Teams
Los agentes debaten entre sí — no solo reportan al CEO, se cuestionan, piden datos a otros departamentos, construyen sobre opiniones ajenas
El CEO sintetiza el debate y me devuelve la palabra
Itero hasta que quiero cerrar

Cuando cierro la reunión, el CEO genera el acta en reuniones/YYYY-MM-DD.md con los temas tratados, las posiciones de cada agente, las decisiones tomadas y las acciones pendientes. También actualiza los estado-actual.md de los proyectos afectados.

Un ejemplo real de la última reunión: discutimos un side project con los 7 agentes. Estrategia dijo que no encajaba en el portfolio principal (nicho diferente al core). Finanzas calculó el break-even y recomendó subir precio. Marketing propuso headlines más emocionales. SEO detectó que el sitio no estaba indexado en Google. Producto sugirió simplificar la landing quitando un tier sin UI implementada.

Todo eso en una sesión. Con datos reales de los archivos del vault, no inventados. Y quedó documentado en el acta sin que yo escribiera una línea.

El principio fundamental: conversación, no pipeline

Una cosa que aprendí iterando es que la reunión funciona como una conversación, no como un pipeline. No es “primero estrategia, luego marketing, luego finanzas” en secuencia. Los agentes hablan entre sí, se cuestionan, y a veces Finanzas contradice a Marketing directamente.

En esa misma reunión, lo que no esperaba era que SEO le respondiera a Marketing que daba igual el copy si Google no podía ni indexar la SPA. Y que UX confirmara que los templates funcionaban bien pero que la promesa del headline era irrealista. Esas cruces entre departamentos no me las habría planteado yo solo.

Eso genera debates mucho más ricos que pedirle a un solo agente que analice todo. El CEO modera pero no decide — la decisión siempre es mía. Es como tener un consejo de dirección que trabaja para ti, pero que no tiene miedo de llevar la contraria.

Si ya conoces Agent Teams, esto es la misma idea aplicada a gestión en vez de a desarrollo. La diferencia es que en desarrollo los agentes escriben código y en gestión los agentes debaten y generan documentación.

Gestión de conocimiento

Tengo 117 notas en conocimiento/notas/ sobre todo lo que considero relevante: desde Claude Code hasta mutation testing, desde MCP servers hasta estrategias de marca personal. Cada nota es un archivo Markdown plano con frontmatter YAML y contenido estructurado.

La clave de la organización no son las carpetas (las notas son planas, sin subcarpetas). La organización la dan los Maps of Content (MOCs).

Maps of Content: la capa de organización

Los MOCs son la idea que más ha cambiado cómo gestiono conocimiento. Un MOC no es una lista de enlaces. Es un texto narrativo que teje wiki-links en el discurso.

Tengo 12 MOCs cubriendo desarrollo, IA, infraestructura, productividad, marketing, inmuebles, gestión, vida, y varios sub-MOCs para temas que crecieron demasiado (control de versiones, integraciones MCP, testing, sistemas multi-agente).

Un fragmento real de mi MOC de IA:

En el lado practico, [[conocimiento/notas/claude-code|Claude Code]] es la
herramienta central del flujo de desarrollo con IA. Sus
[[conocimiento/notas/claude-code-extensiones|extensiones y skills]] permiten
ampliar capacidades sin escribir codigo manualmente. El ecosistema se
complementa con [[conocimiento/notas/rtk|RTK]] como proxy CLI para reducir
tokens y un [[conocimiento/notas/herramientas-desarrollo-ia|indice de
herramientas de desarrollo]] en constante crecimiento.

Fíjate: no es una lista de bullet points con enlaces. Es prosa que conecta ideas de forma natural. Los wiki-links están integrados en el texto como parte de la explicación. Cuando lees el MOC, entiendes las relaciones entre conceptos. Cuando haces clic en un enlace, profundizas.

Por qué narrativo y no bullet points

Lo probé de las dos formas. Con bullet points, el MOC se convierte en un índice muerto que nunca revisitas. Con prosa narrativa, el MOC cuenta una historia que puedes leer de principio a fin y que te da contexto sobre cómo se relacionan las piezas.

Además, cuando Claude Code necesita entender un tema, el formato narrativo le da mucho más contexto que una lista plana de enlaces. Lee el MOC y entiende no solo qué notas existen, sino cómo se relacionan entre sí.

Cuando creo una nota nueva, la añado al MOC correspondiente integrándola en el texto. Si una nota es transversal (por ejemplo, algo sobre Claude Code que aplica tanto a desarrollo como a IA), aparece en varios MOCs. Lo que organiza las notas son los MOCs y los enlaces, no la estructura de carpetas.

Wiki-links: el tejido conectivo

Los wiki-links de Obsidian ([[ruta/al/archivo]]) son lo que convierte una carpeta de archivos en un grafo de conocimiento. En mi vault, todo está conectado:

Las entradas del diario enlazan a personas: [[personas/trabajo/nombre]]
Las personas enlazan a entradas del diario: [[diario/2026/04/08]]
Los proyectos enlazan a personas del equipo: [[personas/trabajo/nombre]]
Las reuniones enlazan a proyectos: [[trabajo/acme/estado-actual]]
Los MOCs enlazan a notas: [[conocimiento/notas/claude-code]]
Las notas enlazan a otras notas

Claude Code sigue estos enlaces. Si le pregunto sobre el estado de un proyecto, lee su estado-actual.md, ve que menciona otra empresa, puede seguir el enlace al _sobre.md de esa empresa para entender la relación. El contexto se construye navegando el grafo.

Esto es algo que Notion no puede replicar. En Notion, las relaciones son propiedades de bases de datos. En Obsidian, las relaciones son texto dentro de archivos que un agente IA puede leer y entender sin necesitar un schema.

El estado actual de cada proyecto

Cada empresa y proyecto tiene un archivo estado-actual.md con una estructura fija:

---
proyecto: Acme Corp
ultima-actualizacion: 2026-04-07
tags: [estado, acme]
---

# Estado Actual — Acme Corp

## Resumen
Empresa propia con tres productos:
Producto A (crecimiento activo), Producto B (autopilot),
Producto C (en validación, kill criteria 30 días).

## Métricas clave

| Métrica | Valor | Tendencia |
|---------|-------|-----------|
| Producto A — MRR | 850€ | ↑ |
| Producto A — Impresiones/semana | 340 | ↑ |
| Producto B — Precio | 49€ pago único | → |
| Producto C | Kill criteria 30-abr | ↓ |

## Decisiones recientes
## Próximos pasos
## Bloqueos/Riesgos

Estos archivos se actualizan tras cada reunión de dirección. Y son lo primero que lee el CEO cuando arranca la siguiente reunión. Es el ciclo: reunión → acta → actualización de estado → siguiente reunión lee el estado actualizado.

Sin este ciclo, cada reunión empezaría de cero. Con él, hay continuidad. Los agentes recuerdan las decisiones anteriores porque están escritas en archivos que leen al inicio.

No soy el único haciendo esto

En Twitter veo cada vez más gente combinando Obsidian con agentes IA. El patrón se repite: alguien se da cuenta de que pagar 5 SaaS diferentes es absurdo cuando un agente con acceso a una carpeta de Markdown puede hacer lo mismo. Y empieza a montar su propio sistema.

Lo que varía es la complejidad. Hay quien tiene un solo agente que lee notas y genera resúmenes. Hay quien monta 8 agentes autónomos con roles diferenciados (organización, escritura, taxonomía, distribución). Mi setup con 7 agentes debatiendo en mesa redonda está en algún punto intermedio.

La idea de fondo es siempre la misma: archivos Markdown como interfaz entre humanos e IA. Sin APIs intermedias, sin formatos propietarios. Texto plano que tanto tú como el agente podéis leer y escribir.

El coste real y qué reemplaza

Vamos a los números:

Concepto	Coste	Qué reemplaza
Claude Max subscription	$100/mes	Consultoría, segundo cerebro, asistentes
Obsidian	$0	Notion ($10/mes), herramientas de gestión
Servidor local	Ya lo tenía	—
Total	$100/mes	—

¿Qué reemplaza en la práctica?

Herramientas de gestión de proyectos: El estado-actual.md + reuniones de dirección cubre lo que haría Jira o Linear para un solopreneur o equipo pequeño
Notion/Coda como base de conocimiento: Las notas + MOCs hacen lo mismo con mejor portabilidad
Consultoría estratégica informal: Tener 7 agentes debatiendo sobre tu negocio no sustituye a un consultor real, pero te obliga a articular tus decisiones y te da perspectivas que no habrías considerado solo
Asistente para actas de reuniones: Las actas se generan solas con formato consistente

No reemplaza todo. Sigue necesitando contabilidad real, un CRM real si tienes muchos clientes, y herramientas colaborativas si trabajas con equipo grande. Esto funciona bien para solopreneurs y equipos pequeños donde una persona toma las decisiones.

Trade-offs honestos

No todo es perfecto. Estos son los problemas reales que he encontrado:

Lo que funciona bien

Velocidad de acceso: Claude Code lee el vault al instante, sin latencia de API
Consistencia: Las reglas del CLAUDE.md garantizan que todo sigue el mismo formato
Continuidad: El ciclo reunión → acta → estado → siguiente reunión mantiene el contexto entre sesiones
Flexibilidad: Añadir un nuevo proyecto es crear una carpeta y un _sobre.md

Lo que no funciona tan bien

Curva de entrada: Montar todo esto lleva tiempo. El CLAUDE.md de mi vault tiene cientos de líneas de convenciones. No es “instala y funciona”
Dependencia del modelo: La calidad de las reuniones depende mucho del modelo. Con Opus los debates son ricos. Con modelos más baratos, los agentes dicen obviedades
Sin colaboración nativa: Obsidian es personal. Si necesitas que 5 personas editen el vault, necesitas Git o Obsidian Sync, y ambas tienen limitaciones
Mantenimiento de MOCs: Los MOCs narrativos son mejores que las listas, pero también son más difíciles de mantener. Cada nota nueva requiere editar prosa, no añadir un bullet

Lo que todavía estoy iterando

Procesamiento de inbox desde Gmail con triage automático
Creación automática de notas de conocimiento desde contenido curado
Mejor integración entre el vault y los repositorios de código de cada proyecto

El diario como registro operativo

Una pieza que no he mencionado y que me ha dado más juego del que esperaba: el diario. Cada día tiene una entrada en diario/YYYY/MM/DD.md con frontmatter (date, tags) y un resumen de lo relevante del día.

No es un diario personal al estilo “querido diario”. Es un registro operativo. Qué decidí, qué problemas encontré, qué cambié de rumbo, con quién hablé. Todo enlazado con wiki-links a personas, proyectos y reuniones.

Cuando Claude Code necesita contexto temporal — “¿qué pasó la semana pasada con el Producto A?” — lee las entradas del diario y reconstruye la cronología. Es la memoria a corto plazo del sistema. Los estado-actual.md son la foto fija; el diario es la película.

También funciona como sistema de rendición de cuentas. Cuando reviso el diario de la semana, veo si avancé en lo que dije que iba a avanzar. Y Claude Code puede hacer esa revisión por mí: “compara las acciones pendientes de la reunión del lunes con las entradas del diario de esta semana”.

Cómo empezar si te interesa

No montes todo de golpe. El camino que recomiendo:

Semana 1: Crea un vault de Obsidian con una estructura básica. diario/, trabajo/, conocimiento/notas/. Escribe un CLAUDE.md con 10 reglas básicas de formato. Abre Claude Code en ese directorio y úsalo para crear notas y entradas de diario.

Semana 2: Añade los archivos de estado-actual.md para tus proyectos. Empieza a enlazar cosas con wiki-links. Crea tu primer MOC como texto narrativo que conecte 5-10 notas.

Semana 3: Experimenta con agentes especializados. No necesitas 7 desde el principio. Un agente de “revisión de estado” que lea tus estado-actual.md y te haga preguntas ya aporta valor.

Semana 4+: Si has leído mi artículo sobre Agent Teams, prueba a montar una reunión con 2-3 agentes debatiendo. Itera desde ahí.

La clave es que la estructura del vault importa más que los agentes. Si tus archivos están bien organizados, con frontmatter consistente y wiki-links, cualquier agente puede hacer cosas útiles. Si tus archivos son un caos, ni el mejor agente del mundo va a sacar nada en claro.

Esto conecta con lo que expliqué en el artículo de SDD: especificar antes de ejecutar. El CLAUDE.md del vault es la especificación del sistema. Los agentes son los ejecutores. Sin spec, caos.

Un vault de Obsidian como segundo cerebro operativo

Mi sistema es un vault de Obsidian con 117 notas de conocimiento, 12 Maps of Content, actas de reuniones con 7 agentes debatiendo, estados de proyecto que se actualizan solos, y un diario que enlaza todo con wiki-links. Corre en Claude Code sin APIs intermedias, sin MCP servers para acceder a los datos, sin bases de datos.

Es Markdown. Carpetas. Archivos de texto. Conectados por wiki-links y procesados por agentes IA que siguen reglas escritas en más Markdown.

No es la solución para todos. Si trabajas en un equipo de 20 personas, necesitas herramientas colaborativas. Si no usas Claude Code, necesitarás algún MCP server para conectar tu vault con tu agente IA. Pero si eres solopreneur o tienes un equipo pequeño y ya usas Claude Code, un vault de Obsidian bien estructurado es la forma más directa de darle contexto completo sobre tu negocio.

Al final, la herramienta más potente para trabajar con IA no es un SaaS con dashboard bonito. Es una carpeta de archivos .md bien organizada.

P.D.: Si montas algo parecido, cuéntamelo en Twitter como @lmmartinb. Me interesa ver cómo otros estructuran sus vaults y qué agentes les funcionan mejor.