Roan Brasil Monteiro escribió un tutorial detallado sobre cómo convertir un repositorio de Obsidian en el «segundo cerebro» de un desarrollador, gobernado por un agente LLM. Su arquitectura es limpia: tres zonas físicamente separadas. raw/ es lo que cura el humano, inmutable; wiki/ es lo que posee el agente —conceptos y síntesis—; dev/ es terreno compartido para ADR y post-mortems. Por encima de todo está CLAUDE.md con el esquema de permisos, git actúa como botón de deshacer, y una vez por semana el humano dispara una síntesis de las notas de la semana. Formula la regla central en una línea: «the agent never touches what you curated; you rarely touch what the agent maintains» — el agente nunca toca lo que tú curaste; tú rara vez tocas lo que el agente mantiene.
Yo mismo opero en producción un stack de memoria persistente, y leí este texto como practicante, no como espectador. Mi tesis es simple: lo que Monteiro describe no compite con mi stack y no es «otro enfoque de lo mismo». Es otra capa. La mayoría de las discusiones sobre memoria de agentes están envenenadas por el marco falso de «quién gana» —memoria basada en archivos contra vectorial, wiki contra grafo—. En realidad son mecanismos distintos para tareas distintas, y confundirlos significa diseñar un sistema en el que una capa hace mal el trabajo de otra.
Tres capas que hacen trabajos distintos
En mi stack viven al menos tres cosas distinguibles. La primera es memoria de hechos discretos basada en archivos: un hecho por archivo, un índice en MEMORY.md. Es rápida, es direccionable, es a lo que recurre el agente cuando necesita la respuesta precisa a «cómo resolvimos la cuestión X». La segunda es memoria semántica: MemPalace, con alas curadas, un grafo de conocimiento y decenas de miles de sesiones auto-minadas. No responde a «dame el hecho», sino a «qué se parece en absoluto a la situación actual». La tercera es un wiki narrativo curado a mano —exactamente el que construye Monteiro—: el humano cura, el agente sintetiza una vez por semana, git versiona.
Y aquí la parte honesta: la tercera capa apenas la opero. No porque sea mala —sino porque tiene su propio nicho, y ese nicho no se solapa con los dos primeros—. Los hechos discretos no necesitan una «síntesis» semanal; necesitan recuperarse al instante. El recall semántico no vive en páginas Title-Case con wikilinks, vive en embeddings y aristas del grafo. El tutorial de Monteiro describe un mecanismo —un wiki curado por humanos, sintetizado semanalmente, versionado con git— y lo describe bien. El error surge solo cuando se declara que ese único mecanismo es la respuesta a toda la cuestión de la memoria.
Dónde tiene toda la razón
La separación por zonas es el instinto correcto, y reconozco en ella mi propia disciplina. Yo mantengo un documento aparte de «zonas de responsabilidad» —literalmente líneas nítidas entre lo que vive en CLAUDE.md, en la memoria basada en archivos, en MemPalace y en el wiki; quién tiene permitido escribir dónde—. Cuando Monteiro hace raw/ inmutable y escribe «the agent never touches what you curated», está articulando la misma idea a la que llegué de forma independiente: el agente debería poder escribir en exactamente una capa y leer las demás. Esto no es estética de directorios. Es una política operativa que impide que el agente reescriba en silencio tu fuente de verdad bajo el disfraz de «ordenar».
Su defensa contra la inyección de prompts también es sensata hasta donde llega: allowed-tools sin rm, un plan obligatorio mostrado antes de ejecutar, git diff como red de seguridad. Un humano en el bucle antes de cualquier escritura es la disciplina correcta. No lo discuto.
Dónde se detiene un paso antes
Pero precisamente en las inyecciones se queda un paso corto —y no es uno menor—. Su modelo de amenaza supone que una instrucción maliciosa se revelará como una acción: un intento de borrar archivos, reescribir el wiki, ejecutar un comando. De eso defienden la allowlist, el plan y git. Lo que esta defensa no atrapa es una inyección que no hace nada destructivo en el momento del ingest y simplemente se convierte en contenido. Un agente que lee una URL externa y la sintetiza en una capa de conocimiento absorbe texto escrito por cualquiera. Si un artículo esconde un «hecho» plantado —una afirmación falsa, una atribución forjada, una puerta trasera silenciosa para una sesión futura—, atraviesa todas y cada una de sus capas defensivas, porque parece síntesis legítima.
Y aquí está el quid: el veneno que aterriza en el wiki sobrevive a un git diff. El diff muestra que la página cambió —pero el cambio debía ocurrir; tú mismo lanzaste el ingest—. El diff no distingue un párrafo honesto de uno plantado: ambos parecen contenido nuevo corriente. «Review the plan before approving» te salva del borrado de archivos, pero no de un párrafo que se lee de forma plausible y, aun así, miente. La inmutabilidad zonal de raw/ protege la integridad de la fuente frente al agente —pero no dice nada sobre la integridad de la fuente misma, la que tú depositaste ahí—.
Qué hacer al respecto
La solución no es un modelo más complejo, sino una capa que falta: escanear el contenido antes de que el agente lo vea siquiera. En mi configuración, /security-check corre antes de cualquier ingest en memoria o wiki: firmas regex para inyecciones, un detector de Unicode oculto, el análisis de bloques base64. Es un preflight, no un post-mortem. Para el esquema de Monteiro en concreto haría tres cosas.
- Paso 1. Escanear en el ingest, antes de la síntesis. La URL externa pasa por un escaneo de contenido antes de que el agente empiece a extraer conceptos. Hay que atrapar la inyección antes de que se vuelva «página nueva del wiki», no después.
- Paso 2. Tratar
raw/como entrada no confiable —incluso lo que guardaste tú mismo—. La inmutabilidad te protege del agente, pero no vuelve honesto el contenido. El clipper web guarda exactamente lo que había en la página, incluido lo que el autor plantó allí. - Paso 3. No confundir «git diff está limpio» con «el contenido es seguro». Git atrapa ediciones no autorizadas. No atrapa un ingest autorizado de una fuente envenenada. Son garantías distintas, y git no reemplaza la segunda capa de defensa.
Así que no «contradigo» a Monteiro —lo extiendo una capa—. Su arquitectura de tres zonas es la base correcta, y su frase sobre «el agente nunca toca lo que tú curaste» debería colgar sobre cualquier sistema de memoria. Pero la memoria es una taxonomía de capas, no un único mecanismo vencedor; y cualquier capa que ingiere el mundo exterior necesita saneamiento en la puerta, porque el texto envenenado pero plausible es la única amenaza que ni la allowlist, ni git diff, ni la previsualización del plan pueden ver.