Tu vault de Obsidian no puede ser la base de conocimiento de tus agentes de IA

Un vault de Obsidian falla como base de conocimiento para agentes de IA por tres razones estructurales: es privado de una máquina, sus afirmaciones no llevan citas, y nada te dice cuándo una nota dejó de ser verdad. Los agentes leen lo que se les entrega y no tienen forma de distinguir una nota vigente de otra que caducó hace tres sprints — así que la respuesta segura y equivocada y la correcta llegan con el mismo aspecto.

Esto no es una crítica a Obsidian. Es muy bueno en el trabajo para el que se construyó, que es una persona pensando. El fallo es un error de categoría: una herramienta personal de pensamiento a la que se le pide ser una fuente de verdad compartida.

¿Pueden los agentes leer siquiera un vault de Obsidian?

Sí, y conviene aclararlo primero porque es donde suele empezar la conversación. Un vault es una carpeta de markdown plano. Cualquier agente con acceso a ficheros lo lee sin ceremonia, y hay servidores MCP que te lo conectan en una tarde.

El acceso nunca fue el problema. Leer y confiar son operaciones distintas, y un vault no lleva ninguna señal que las separe. Una nota escrita la semana pasada y una nota que dejó de ser cierta en 2024 son el mismo tipo de objeto, en la misma carpeta, con la misma autoridad. Quien lee su propio vault descuenta automáticamente — ah, esa es vieja — usando conocimiento que no está en ninguna parte del fichero. Un agente no tiene con qué descontar.

Así que la mitad fácil queda resuelta, la difícil pasa desapercibida, y el montaje parece funcionar justo hasta que actúa con total seguridad sobre algo que ya había caducado.

Los tres fallos, por orden de lo que cuestan

1. Es privado, así que el conocimiento es por persona

Un vault vive en un portátil. Sincronízalo y tendrás una carpeta compartida, no conocimiento compartido — porque el vault no tiene noción de revisión. Nadie aprueba una nota. Nadie responde por ella. Dos ingenieros mantienen dos vaults, cada uno acertado en cosas distintas, y el agente se queda con el vault de quien lo esté operando.

El síntoma es fácil de reconocer: la misma pregunta obtiene dos respuestas según quién se la haga a su agente.

2. Las afirmaciones no llevan procedencia

Una nota dice «las migraciones las hacemos en dos pasos». ¿Es una decisión que tomó alguien, la observación de un incidente, o algo que un compañero creía en 2024? La nota no lo dice, y a los pocos meses nadie se acuerda.

Para una persona esto es fricción. Para un agente es fatal, porque no puede ponderar una afirmación que no puede rastrear. Seguirá una nota caducada exactamente con la misma confianza con la que sigue una correcta.

3. Nada marca una nota como caducada

Este es el que hace más daño en silencio. Un vault no tiene estado de muerte. Las notas se acumulan, y el único mecanismo para retirar una equivocada es que alguien recuerde que lo está — lo que falla de forma fiable, porque quien sabe que la nota está caducada no es quien la está leyendo.

El resultado es un corpus que crece monótonamente más seguro de sí mismo y menos exacto.

¿Qué tiene que ser la documentación para agentes?

Cada propiedad de abajo existe por una forma concreta en que fallan los vaults:

Propiedad	El fallo que responde
Vive en el repositorio	Se revisa como código, no se sincroniza como una carpeta
Cita una decisión, una task o un fichero	Una afirmación que no puedes rastrear es una que no puedes ponderar
Se escribe al cerrar el trabajo	No «cuando alguien se acuerde», que es nunca
Tiene un estado de archivada	Una nota equivocada debe poder retirarse por algo que no sea la memoria
Se carga según lo que declara la task	Cincuenta notas no son contexto, son ruido

Esa última fila es la que la mayoría de herramientas se salta. Entregarle a un agente una base de conocimiento entera no es ingeniería de contexto; es un prompt más grande. Lo que una task necesita es el subconjunto relevante para esa task, seleccionado por algo que la propia task declaró.

¿Y por qué no darle al agente el vault entero?

El movimiento obvio, y falla de tres formas concretas:

El volumen no es contexto. Cuatrocientas notas en un prompt significan que las tres relevantes quedan diluidas entre trescientas noventa y siete que no lo son. Eso es un prompt más grande, no un mejor anclaje, y cuesta exactitud en lugar de comprarla.

Nada dice qué notas aplican aquí. Los enlaces de un vault codifican asociación — esto me recordó a aquello — no aplicabilidad a la task que tienes delante. Son relaciones distintas, y sólo una sirve para seleccionar.

Las contradicciones no tienen resolución. Dos notas discrepan sobre cómo se despliega. Nada en el vault registra cuál ganó, porque el ganador se decidió en una conversación. El agente lo resuelve escogiendo la que más se parece al prompt, y reporta el resultado con la misma seguridad en cualquiera de los dos casos.

El desenlace es peor que un fichero corto y curado: una respuesta bien redactada, aparentemente bien fundamentada, y equivocada.

¿Lo arregla RAG sobre el vault?

En parte, y conviene ser preciso sobre qué parte, porque es el arreglo que más se propone.

La recuperación resuelve la selección. Eso es real: convierte «el agente leyó cuatrocientas notas» en «el agente leyó las cuatro más cercanas», que es una mejora de verdad y la molestia que más se nota.

No toca la procedencia ni la caducidad, y en la caducidad se inclina ligeramente hacia el lado malo. La recuperación saca lo que está textualmente más cerca de la pregunta, y una nota caducada escrita con seguridad — «las migraciones las hacemos en dos pasos» — suele ser lo más cercano a una pregunta sobre migraciones. La nota correcta puede ser más nueva, más matizada y estar redactada menos como la pregunta. Los embeddings no opinan sobre fechas ni sobre la verdad; ordenan por similitud.

Así que RAG asciende el problema de el agente lo leyó todo y no sabía qué estaba vigente a el agente leyó las cuatro cosas más relevantes y no sabía qué estaba vigente. Mejor, y no el arreglo.

¿Y Notion, Confluence o un wiki?

Responden limpiamente a uno de los tres fallos y dejan los otros dos más o menos donde estaban.

Compartido: sí. Esta es la ganancia real, y no es poco — un corpus, muchos lectores, se acabó el «la misma pregunta obtiene dos respuestas según de quién fuera el vault que leyó el agente».

Procedencia: no. Una página de wiki rara vez dice de qué decisión salió o qué incidente la produjo, por la misma razón que no lo dice una nota de vault: quien la escribió lo sabía, así que anotarlo parecía redundante.

Caducidad: podría decirse que peor. Las notas malas de un vault al menos están enterradas. Las de un wiki están indexadas, se buscan y las enlazan otras cuatro páginas, así que la escala hace una afirmación caducada más localizable, no menos, y nada en la herramienta la archiva. El mecanismo para retirar una página equivocada sigue siendo que alguien se acuerde.

Y un fallo que el wiki añade: no está donde cambia el código. Una nota en el repositorio la tienes delante, en el diff, en el momento en que alteras lo que describe. Una nota en un wiki se lee cuando alguien va a buscarla — que es justo la conducta que querías arreglar.

Cómo lo hace CommitCycle

CommitCycle llama a esto playbooks — ficheros de conocimiento por topic y por proyecto que viven en tu repositorio. Cuatro propiedades, cada una respondiendo a una fila de arriba:

• Citan. Cada afirmación apunta a una decisión, una task o un fichero. Un lint comprueba que las citas resuelven; un playbook sin contenido citable no se crea siquiera.
• Se alimentan al cerrar el trabajo, de viñeta en viñeta, cuando la persona todavía recuerda por qué. Ni en una retro, ni cuando alguien se acuerde.
• Se cargan según los topics declarados por la task, así que una task sobre la base de datos no carga las convenciones del frontend.
• Se pueden archivar. archived es un estado real, y eso es lo que permite que el corpus encoja.

Y una pasada adversarial — cycle challenge — propone las prácticas que al repositorio le faltan a la vista, cada una con una fuente nombrada. Puedes rechazarlas, y tu rechazo queda registrado con sus motivos. «Nos desviamos de esto a propósito, y aquí está por qué» también es conocimiento, y es del tipo que los vaults nunca capturan porque nadie escribe lo que decidió no hacer.

La parte honesta

Aquí hay una objeción real y merece una respuesta directa: «si generas un playbook a partir de mi repositorio heredado, ¿no va a codificar mi desastre?»

Sí. Por diseño, describir y nada más codifica el desastre — con recibos. Por eso existe el challenger. Propone lo que al repo le falta en lugar de sólo describir lo que tiene, y una persona acepta o rechaza cada propuesta. No hay auto-aceptación, y hay un test que mantiene esa vía cerrada.

Lo que esto no sustituye

Quédate con el vault. Esto no es una migración.

Obsidian sigue siendo mejor que cualquier cosa de aquí para pensar — para ideas a medio formar, para conexiones que aún no has hecho, para notas que son para ti y a las que se les permite estar equivocadas. Lo que sale de ahí es el subconjunto del que otros lectores dependen para que sea cierto. Ese subconjunto siempre fue la parte que dolía cuando caducaba, y nunca fue la parte que Obsidian se diseñó para sostener.

Una línea útil que trazar: si equivocarte en esta nota induciría a error a otra persona, no pertenece a un vault personal.

Adónde va en su lugar, para las notas que un agente debe leer, es a una skill en el repositorio — el mismo markdown, pero versionado con el código que describe y cargado sólo cuando la task lo pide.

Dónde está CommitCycle de verdad

CommitCycle lleva su propio desarrollo — el board, el gate, los audit records y los playbooks descritos arriba están en uso hoy en su propio repositorio. La mitad de enforcement se instala: un plugin de Claude Code, o el paquete commitcycle en npm para la CLI a secas. El board alojado es sólo por invitación mientras esto sea pequeño. Phase 0 está medida y publicada con sus límites.

Así que este post no te pide migrar nada hoy. Plantea un argumento que puedes evaluar por sus méritos, y si te convence, la waitlist es el siguiente paso honesto. Si el argumento es erróneo, eso nos vale más que un alta.

---

Los cuatro modos de fallo de los que viene esto, y los mecanismos que los responden, están documentados por completo: el bloque de contexto AGENTS.md, las zones y el audit record.