RAG is a patch, not a foundation

The promise

When retrieval-augmented generation arrived, it sounded like the answer. Connect the model to your documents, fetch the relevant bits at question time, and the hallucinations stop. Every AI vendor shipped it. Most still lead with it.

And to be fair: for “find me the paragraph that mentions X”, RAG works. The trouble starts when you expect it to be your company’s memory.

What retrieval actually does

A RAG system doesn’t know your company. At the moment you ask a question, it runs a similarity search over an indexed copy of your documents, grabs the chunks that score highest, and pastes them into the prompt. Then it forgets everything and does it again next time.

That design has consequences:

• It returns fragments, not understanding. The model gets disconnected paragraphs with no sense of which document is authoritative, which is a draft, and which was superseded three weeks ago.
• It’s read-only. Your agent learned something useful in that conversation? Corrected a wrong assumption? None of it goes anywhere. The index doesn’t get smarter.
• It works on a copy. Somewhere, your knowledge was ingested into an index. Now you have two versions of the truth, and the one your AI reads is the one nobody maintains.
• Permissions become an afterthought. Because everything went into one index, “who can see what” turns into a filter applied at query time - a check on top of a copy, hoping nothing slips through.

A search engine bolted onto a language model is a fine demo. It’s not infrastructure.

What agents need instead

Here’s the thing the RAG era obscured: modern agents can already read files. Give a coding agent a well-organized directory and it navigates, opens what’s relevant, follows references between documents and reasons across them. No chunking, no embeddings, no top-k lottery.

What agents are missing isn’t a cleverer retrieval pipeline. It’s the thing developers have had for decades: a single, versioned source of truth. Real files, in one tree, where:

• the current version is the version - no stale index trailing behind,
• every change has an author and a diff, whether a human or an agent made it,
• agents don’t just read it - they write back, and the correction is reviewable like any other change.

The plain-files approach has a quieter advantage too: your team can read it. A markdown file with history can be audited, corrected and trusted in a way no embedding index or proprietary knowledge graph can. If only the machine can inspect your company’s memory, you don’t own it - you believe in it.

The catch, and the answer

The reason companies don’t already do this is permissions. One tree with everything in it means everyone - and every agent - can see everything, and that dies the moment compensation data or a client’s confidential work enters the picture.

That’s the part Monora was built for: one company brain as a real file tree, where each person and each agent gets only their authorized folders - enforced on the server, so what they can’t see was never on their machine. Not retrieved. Not filtered. Just there for the right ones, and absent for the rest.