Roan Brasil Monteiro wrote a detailed tutorial on turning an Obsidian vault into a developer's "second brain" run by an LLM agent. His architecture is tidy: three physically separated zones. raw/ is what the human curates, immutable; wiki/ is what the agent owns — concepts and syntheses; dev/ is shared ground for ADRs and post-mortems. On top of it all sits CLAUDE.md with the permissions schema, git acts as the undo button, and once a week the human triggers a synthesis of the week's notes. He states the core rule in one line: «the agent never touches what you curated; you rarely touch what the agent maintains».
I run a persistent-memory stack in production myself, and I read this piece as a practitioner, not a spectator. My thesis is simple: what Monteiro describes is not a competitor to my stack and not "a different take on the same thing." It is a different layer. Most arguments about agent memory are poisoned by the false frame of "who wins" — file-based memory versus vector, wiki versus graph. In reality these are different mechanisms for different jobs, and conflating them means designing a system where one layer does another layer's work badly.
Three layers that do different jobs
My stack holds at least three distinguishable things. The first is file-based memory of discrete facts: one fact per file, an index in MEMORY.md. It's fast, it's addressable, it's what the agent reaches for when it needs the precise answer to "how did we settle question X." The second is semantic memory: MemPalace, with curated wings, a knowledge graph, and tens of thousands of auto-mined sessions. It answers not "give me the fact" but "what at all resembles the current situation." The third is a hand-curated narrative wiki — exactly the one Monteiro builds: the human curates, the agent synthesizes once a week, git versions it.
And here's the honest part: the third layer I barely run. Not because it's bad — because it has its own niche, and that niche doesn't overlap the first two. Discrete facts don't need a weekly "synthesis"; they need to be retrieved instantly. Semantic recall doesn't live in Title-Case pages with wikilinks; it lives in embeddings and graph edges. Monteiro's tutorial describes one mechanism — a human-curated, weekly-synthesized, git-versioned wiki — and describes it well. The mistake arises only when this one mechanism is declared the answer to the whole memory question.
Where he is absolutely right
Zone separation is the right instinct, and I recognize my own discipline in it. I keep a separate "zones of responsibility" document — literally bright lines between what lives in CLAUDE.md, in file-based memory, in MemPalace, and in the wiki; who is allowed to write where. When Monteiro makes raw/ immutable and writes «the agent never touches what you curated», he is articulating the same idea I arrived at independently: the agent should be allowed to write into exactly one layer and to read the rest. This is not directory aesthetics. It's an operational policy that stops the agent from quietly rewriting your source of truth under the guise of "tidying up."
His defense against prompt injection is also sound as far as it goes: allowed-tools without rm, a mandatory plan shown before execution, git diff as a safety net. A human in the loop before any write is the right discipline. I don't dispute it.
Where he stops one step short
But on injection specifically he stops one step short — and it's not a minor one. His threat model assumes a malicious instruction will reveal itself as an action: an attempt to delete files, rewrite the wiki, run a command. The allowlist, the plan, and git all defend against that. What this defense does not catch is an injection that does nothing destructive at ingest time and simply becomes content. An agent that reads an external URL and synthesizes it into a knowledge layer pulls in text written by anyone at all. If an article hides a planted "fact" — a false claim, a forged attribution, a quiet backdoor for a future session — it passes through every one of his defensive layers, because it looks like legitimate synthesis.
And here is the crux: poison that lands in the wiki survives a git diff. The diff shows that the page changed — but the change was supposed to happen; you launched the ingest yourself. The diff does not distinguish an honest paragraph from a planted one: both look like ordinary new content. "Review the plan before approving" saves you from file deletion, but not from a paragraph that reads plausibly and yet lies. The zonal immutability of raw/ protects the source's integrity from the agent — but says nothing about the integrity of the source itself, the one you placed there.
What to do about it
The fix is not a more complex model but one missing layer — scanning content before the agent ever sees it. In my setup, /security-check runs before any ingest into memory or wiki: regex signatures for injection, a hidden-Unicode detector, base64-block parsing. It's a preflight, not a post-mortem. For Monteiro's scheme specifically I would do three things.
- Step 1. Scan at ingest, before synthesis. The external URL goes through a content scan before the agent starts extracting concepts. The injection has to be caught before it becomes a "new wiki page," not after.
- Step 2. Treat
raw/as untrusted input — even what you saved yourself. Immutability protects you from the agent, but it doesn't make the content honest. The web clipper saves exactly what was on the page, including whatever the author planted there. - Step 3. Don't confuse "git diff is clean" with "content is safe." Git catches unauthorized edits. It does not catch an authorized ingest of a poisoned source. These are different guarantees, and git does not replace the second layer of defense.
So I'm not "disagreeing" with Monteiro — I'm extending him by one layer. His three-zone architecture is the right foundation, and his line about "the agent never touches what you curated" should hang over any memory system. But memory is a taxonomy of layers, not one winning mechanism; and any layer that ingests the outside world needs sanitization at the door, because poisoned-but-plausible text is the one threat that neither the allowlist, nor git diff, nor the plan preview can see.