Obsidian + Claude Code no sustituye al RAG: son dos memorias para problemas distintos

El Cuñado ya tiene la solución definitiva

El Cuñado dice: "Bro, olvídate del RAG. Montas Obsidian, le pegas Claude Code al vault y ya tienes memoria infinita. Vector database, embeddings, retrieval… eso es para los que no saben organizar notas. Yo con mis [[dobles corchetes]] soy imparable."

La realidad es: Obsidian + Claude Code resuelve un problema real (Claude Code es stateless y cada sesión arranca de cero), pero no es un sustituto del RAG. Es otra clase de memoria. Hay una lección conocida en diseño de agentes que ilustra bien la diferencia: cuando las acciones ya ejecutadas se pasan al LLM como prosa narrativa en vez de como dato de sistema, el modelo puede reinterpretarlas como decisiones aún abiertas. El arreglo no fue mejor prompting; fue cambiar el formato del contexto.

Por qué importa saberlo: si confundes memoria guiada (notas enlazadas, rutas conocidas) con recuperación abierta (consulta en lenguaje natural sobre un corpus que no has modelado), el fallo no es teórico. Cuesta dinero.

El problema de verdad: Claude Code no se acuerda de ti

Claude Code no guarda conversaciones, proyectos ni preferencias entre sesiones. Cada vez que abres una sesión empiezas de cero. Eso lo documentan tanto Pasquale Pillitteri (pasqualepillitteri.it, 2026-04-17) como Mejba (mejba.me, 2026-03-03): sin memoria persistente, los proyectos largos se convierten en un bucle de re-explicar el mismo contexto.

Esa fricción es legítima. Nadie quiere pegar el mismo monólogo de onboarding cada lunes. La tentación, entonces, es buscar "el truco" que convierta al agente en alguien con memoria de elefante. Ahí entra el combo Obsidian + Claude Code, y ahí es donde el Cuñado se pasa de frenada y declara muerto al RAG.

Obsidian guarda notas en Markdown local, sin formato propietario. Claude Code lee y escribe archivos de texto. Si lo ejecutas dentro del vault, tiene acceso al conocimiento estructurado sin APIs externas. Las notas hacen de memoria persistente. Pillitteri y Mejba coinciden en el mecanismo base: archivos locales + agente que los lee = continuidad entre sesiones.

Donde empiezan a diferir es en el énfasis. Pillitteri insiste en arquitectura MECE del vault, CLAUDE.md como orquestador y el vault como entregable para clientes. Mejba insiste en el "bucle simbiótico", la vista de grafo y el fracaso previo del monstruo context.md de 3.000 líneas. Las dos lecturas se complementan; ninguna afirma, ni puede afirmar con los datos que traen, que esto reemplace a un pipeline de retrieval semántico.

Seamos justos: el combo Obsidian + Claude Code es una solución elegante para un problema real. No depende de APIs externas, emplea archivos que controlas y te da continuidad entre sesiones sin casarte con un vendor. Para un equipo pequeño con disciplina de documentación, el vault bien mantenido es un multiplicador. El problema no es la herramienta; es venderla como la navaja suiza que jubila al resto del taller.

Qué hace bien Obsidian + Claude Code (y qué no toca)

La gracia del combo no es magia: es determinismo con rutas conocidas.

Estructuras el vault con carpetas que no se pisan y que cubren el dominio (MECE: Mutually Exclusive, Collectively Exhaustive). La base que se propone suele incluir /Business, /Context, /Daily, /Library, /Projects, /Skills y /Team. Encima, un CLAUDE.md que no es un novelón: es el manual de cómo pensar el vault, cuándo crear notas, cómo enlazarlas, qué convenciones de nombre emplear. Frontmatter YAML (tags, date, status) para que el contexto no sea solo prosa suelta.

El flujo diario que describe Pillitteri es casi ritual:

1. "Buenos días", apertura, revisión de la daily note, carga de contexto.
2. "Gracias, por hoy hemos terminado", cierre con decisiones, pendientes y actualización de notas.

Eso crea memoria incremental. Mejba aporta el dato de campo: tras cuatro semanas, menos re-explicaciones y más continuidad, porque Claude leía una base cada vez más rica. También cuenta el anti-patrón que motivó el cambio: un context.md único que en dos semanas se fue a 3.000 líneas y se volvió inmanejable a mano.

La vista de grafo de Obsidian y los enlaces [[doble corchete]] dan una red que tanto tú como Claude podéis parsear. Con más de 2.700 plugins (plantillas diarias, backlinks, Dataview), el vault se acerca a una base consultable… siempre que sepas qué preguntar y dónde mirar.

Eso último es la frontera. El vault brilla cuando el conocimiento está modelado: jerarquías, enlaces, convenciones, rutas. El agente no "descubre" un hecho enterrado en 40.000 PDFs heterogéneos con una pregunta vaga. Sigue caminos que tú (o él, en sesiones anteriores) habéis dejado marcados.

Memoria en archivos locales no es lo mismo que recuperación semántica. Una te da continuidad con dueño; la otra te da alcance sobre lo que no has clasificado.

Si lo que necesitas es colaboración en tiempo real, un proyecto de menos de 10 notas o un equipo que no va a mantener conocimiento personal, Obsidian no es la herramienta. Pillitteri lo deja escrito sin romanticismo.

El RAG no se ha muerto: resuelve otro contrato

El RAG (Retrieval-Augmented Generation) responde a otra pregunta: "dentro de este corpus grande, ruidoso y no totalmente estructurado, ¿qué trozos son relevantes para esta consulta en lenguaje natural?"

Ahí entran embeddings, chunking, ranking, a veces re-rankers, a veces filtros híbridos con BM25. El usuario no navega un grafo de notas; lanza una frase y espera que el sistema traiga evidencia útil. Es el modo correcto cuando:

• el corpus crece sin que nadie lo clasifique a mano cada tarde,
• las preguntas no caben en un árbol de carpetas preacordado,
• necesitas citar fuentes que no escribiste tú en Markdown limpio.

Declarar que Obsidian + Claude Code "mata al RAG" es mezclar memoria de trabajo del agente en un proyecto guiado con recuperación abierta sobre conocimiento no indexado a mano. Son capas distintas. Si quieres profundizar en por qué la memoria tiene que vivir también en la capa de datos, y no solo en el monólogo del redactor, ya lo desgranamos en Tus agentes se pisan el contexto: memoria determinista en la capa de datos.

No hay en el material de este artículo un benchmark cara a cara vault-vs-RAG que permita coronar a uno. Quien lo afirme de tapadillo está vendiendo preferencia, no evidencia.

El formato del contexto manda: la lección de los reembolsos duplicados

En diseño de agentes con tramos mixtos (parte determinista, parte LLM) hay un error de arquitectura que se repite: narrar al modelo lo que ya se ejecutó en vez de pasárselo como dato de sistema.

Cuando las acciones cerradas llegan como prosa ("hemos procesado el reembolso del pedido X"), el LLM puede reinterpretarlas como situaciones aún abiertas que requieren decisión. El resultado son duplicaciones: el modelo ejecuta de nuevo algo que ya estaba hecho. El arreglo no es más prompt engineering; es cambiar el formato. Lo ejecutado entra como estado de sistema, no como narración.

Eso no es una anécdota exótica. Es el fallo de diseño más predecible cuando se mezclan sin criterio tramos deterministas y tramos de lenguaje natural. Y conecta directamente con el debate vault-vs-RAG: el vault de Obsidian, bien enlazado, es exactamente una memoria con topología determinista. El agente navega rutas conocidas; no reinterpreta. El RAG, por su parte, opera en el dominio del lenguaje natural abierto, donde el LLM sí tiene que inferir relevancia. Mezclar los dos modos sin marcar fronteras (hacer que el agente "narre" lo que ya decidió el tramo determinista) es la forma más rápida de crear problemas que parecen alucinaciones del modelo pero son fallos de diseño del contexto.

La regla operativa que sale de ahí es simple:

• Flujos guiados (estados conocidos, notas enlazadas, procedimientos con camino): capa determinista. El vault de Obsidian, bien llevado, es exactamente eso.
• Lenguaje natural abierto (búsqueda, preguntas que no sabes en qué carpeta caen, corpus externo): LLM + validador, y si el corpus lo pide, RAG de verdad.

Dos fuentes, una tensión útil (y cómo se resuelve)

Pillitteri (F1) y Mejba (F2) coinciden en lo gordo:

• Claude Code arranca vacío cada sesión.
• Markdown local + lectura/escritura de archivos = memoria persistente sin API rara.
• El mantenimiento del vault es parte del sistema, no un extra opcional.
• Cambiar de proveedor de LLM es más barato si el conocimiento no vive atrapado en un hilo de chat propietario.

Divergen en el foco narrativo. F1 vende arquitectura y entregable: MECE, CLAUDE.md, ciclo buenos-días/gracias, vault compartible con cliente. F2 vende experiencia de fricción: el context.md hinchado, el bucle simbiótico usuario↔Claude↔vault, grafo y plugins como multiplicadores.

La tensión se resuelve sin drama: F2 explica por qué abandonar el archivo único; F1 explica cómo no montar otro monstruo con más carpetas. Juntas no demuestran superioridad frente al RAG; demuestran que la memoria de proyecto se puede externalizar a un sistema de archivos con convenciones.

Eso conecta con otra ventaja que ambos tocan y que en producción pesa: independencia del modelo. Si el knowledge está en .md, no te casan con un vendor para siempre. El vendor lock-in en IA ya no es teoría de blog; es coste de cambio real, lo tratamos con más detalle en No dependas de un único proveedor de IA.

Anatomía de un vault que no se pudre en tres semanas

Montar el combo y olvidarlo es el camino corto al cementerio de notas huérfanas. Los errores recurrentes que marca el material:

• Carpetas demasiado granulares. Si cada matiz tiene carpeta, el agente (y tú) perdéis tiempo navegando taxonomía en vez de trabajar.
• Frontmatter incoherente. Unos status: done, otros estado: ok, otros nada. El metadato deja de ser señal y se vuelve ruido.
• CLAUDE.md obeso. Si el orquestador compite en longitud con el propio vault, nadie lo mantiene y Claude recibe instrucciones contradictorias.
• Cero mantenimiento. Sin poda periódica, el grafo se llena de nodos muertos y el "segundo cerebro" es un trastero.

El CLAUDE.md tiene que ser documento vivo, no constitución de 40 páginas. Enseña convenciones, no reescribe el dominio entero. Las daily notes y el cierre de sesión son el mecanismo de higiene: si no resumís decisiones y pendientes al acabar, la memoria incremental se convierte en basura incremental.

Dataview y plantillas ayudan, pero no sustituyen criterio. Un plugin no te salva de una ontología mal pensada.

Dónde encaja cada memoria (sin diplomacia de PowerPoint)

Piensa en tres capas, no en una religión:

1. Estado determinista: lo ya ejecutado, IDs, flags, rutas de notas canónicas, resultados de tools. Entra como dato estructurado. Aquí vive el vault bien enlazado y cualquier "ya se hizo X" que no quieres que el modelo reinterprete.
2. Memoria de proyecto: preferencias, convenciones, decisiones de diseño, contexto de cliente, skills del equipo. Obsidian + Claude Code brillan aquí: continuidad entre sesiones sin re-pegar el lore.
3. Recuperación abierta: preguntas en lenguaje natural sobre un corpus que no has (ni vas a) modelar nota a nota. Aquí el RAG sigue siendo la herramienta adecuada; el LLM + validador cierra el loop cuando la respuesta tiene que ser acción, no solo párrafo.

El patrón de ingeniería que se repite cuando esto se hace en serio: la memoria conversacional se trata en la capa de datos, no solo en el redactor que "se acuerda" en el prompt. El reintento con otro modelo, cuando hace falta, se fusiona con lo ya validado; no sustituye el estado entero como si nada hubiera pasado. Y ojo con el modo fallo silencioso: un modelo con historial bien comprimido a veces decide que ya no necesita tools de lectura, parece eficiente y en realidad está volando a ciegas.

Si tu flujo es "sigue el grafo de decisiones del proyecto", empuja determinismo y notas. Si tu flujo es "¿qué decía la norma / el ticket / el PDF del proveedor sobre X?", empuja retrieval. Si los mezclas en un solo prompt-novela, has recreado el escenario de las duplicaciones con otro disfraz.

Trampas típicas del discurso anti-RAG

Trampa 1: "Todo conocimiento vale como nota enlazada". No. Convertir un dump corporativo en vault MECE cuesta una fortuna en curación. El RAG existe precisamente porque esa curación no escala igual en todos los dominios.

Trampa 2: "Como Claude lee archivos, ya tengo búsqueda semántica". Leer [[Nota]] no es nearest-neighbor en un espacio de embeddings. Es navegación. Si la nota no está enlazada o nombrada de forma recuperable, no existe para el flujo guiado.

Trampa 3: "El vault elimina por completo las re-explicaciones". El material de campo dice menos re-explicaciones y más continuidad tras semanas de uso, no cero fricción. Si el vault está desactualizado, Claude leerá con seguridad una mentira bien formateada.

Trampa 4: "Un solo mecanismo de memoria para todo el agente". La lección del formato de contexto es la refutación práctica: el mismo sistema necesita modos distintos según el tramo del flujo sea cerrado o abierto.

Trampa 5: hinchar el combo hasta venderlo como arquitectura universal. Obsidian no es backend multiplayer en tiempo real. No es almacén analítico. No es compliance mágico. Es un vault de Markdown con un agente que lo sabe leer. Punto.

Cómo decidir sin hacer cosplay de arquitecto

Preguntas útiles, sin humo:

• ¿La próxima consulta tiene ruta (sé en qué proyecto, decisión o daily cayó) o tiene intención vaga sobre un mar de documentos?
• ¿Lo que el modelo va a ver son hechos cerrados (ya pagado, ya desplegado, ya aprobado) o hipótesis?
• ¿El conocimiento lo mantenéis vosotros con convenciones, o llega sucio de fuera a ritmo de manguera?
• ¿Necesitáis exportar el contexto como carpeta a un cliente o equipo (ventaja clara del vault) o citar fragmentos de un corpus legal/técnico masivo?

Si las respuestas tiran a ruta, hechos cerrados, mantenimiento propio y entregable en carpeta, Obsidian + Claude Code es candidata fuerte. Si tiran a intención vaga, corpus externo y evidencia recuperada al vuelo, monta RAG de verdad, y valida.

En ambos casos, lo ya ejecutado no se cuenta como anécdota al modelo: se adjunta como estado. Es más barato aprenderlo en un entorno controlado que en producción.

El remate

Nadie ha matado al RAG con un vault bonito. Lo que ha pasado es más interesante: hemos separado por fin dos trabajos que el hype empaquetaba en el mismo eslogan de "memoria para agentes". Uno es continuidad estructurada en un proyecto que controlas. Otro es recuperación cuando no controlas el corpus ni la forma de la pregunta.

Claude Code sigue siendo stateless. Obsidian sigue siendo Markdown con grafo. El LLM sigue siendo pésimo decidiendo dos veces lo que ya estaba decidido si se lo cuentas como cuento. Quita el cuento, pon el dato, elige la memoria según el flujo, y deja al Cuñado con su curso de "segundo cerebro 10x" hablando solo.

Preguntas frecuentes

¿Obsidian + Claude Code sustituye a un sistema RAG?

No. Sustituye la falta de memoria persistente de Claude Code en proyectos con conocimiento estructurado en Markdown, no la recuperación semántica sobre corpus abiertos. El vault da continuidad por archivos y enlaces; el RAG responde preguntas en lenguaje natural sobre colecciones que no has modelado nota a nota. Son complementarios según el tipo de consulta y de corpus.

¿Por qué Claude Code necesita algo como Obsidian?

Porque es stateless: cada sesión arranca sin memoria de conversaciones, proyectos o preferencias. Obsidian aporta notas .md locales que Claude Code puede leer y escribir dentro del vault, simulando memoria a largo plazo sin API externa. Pillitteri y Mejba documentan menos re-explicaciones cuando el vault se enriquece con el uso, no la eliminación total del contexto manual.

¿Qué pasa cuando se mezclan sin criterio tramos deterministas y tramos LLM en un agente?

Si las acciones ya ejecutadas llegan al modelo como prosa narrativa en vez de como dato de sistema, el LLM puede reinterpretarlas como decisiones abiertas y ejecutarlas de nuevo. Es uno de los fallos de diseño más predecibles en pipelines de agentes, y la solución es de formato, no de prompting: estado cerrado como dato estructurado, lenguaje natural solo donde haya ambigüedad legítima.

¿Cuándo no compensa montar un vault de Obsidian para agentes?

Cuando hace falta colaboración en tiempo real, el proyecto tiene pocas notas (menos de 10) o el equipo no va a mantener una metodología de conocimiento. También falla si la estructura es hipergranular, el frontmatter es incoherente, el CLAUDE.md se vuelve inmanejable o nadie poda notas huérfanas: el vault se pudre y el agente lee basura con confianza.