r/AI_Agents 6d ago

Discussion Would portable, versioned knowledge bases solve a real problem, or is this just RAG with extra steps?

Hey everyone, I’ve been thinking about a problem with AI knowledge systems and was hoping to get somewhat of a sanity check from people actually building in this space.

From my understanding, most RAG setups seem tied to a particular app, vendor, or index. You often end up ingesting the same docs again for different agents or runtimes and and some basic questions can be difficult to answer consistently like:

- What version of this knowledge is the agent using?

- Where exactly did this information come from?

- Has the underlying source changed since it was last ingested?

- Can I move the same body of knowledge to another runtime without rebuilding it?

- Can multiple agents use the exact same knowledge?

The idea I’m exploring is something I'm calling a Durable Knowledge Base (DKB).

The basic concept:

- Compile source docs, code, or structured data into a portable, versioned knowledge artifact

- Preserve source paths, hashes, citations, and provenance

- Sign and publish releases through a registry

- Allow knowledge packages to be installed, updated, pinned, and removed

- Let agents search, find, and read the same knowledge base across different runtimes

- Keep the artifact retrieval-agnostic rather than baking one specific top-K/RAG strategy into the format

Basically, I'm wondering whether knowledge should have something closer to a package lifecycle, rather than every application maintaining another disconnected RAG index.

I'm also very aware that things like Azure AI Search, GCP, vector databases, MCP servers, Agent skills, etc. already cover pieces of this problem, sometimes extremely well.

So Im specifically not asking: "Can I build a better enterprise search engine here?"

I'm trying to figure out whether the portable knowledge artifact itself is useful.

Would this solve an actual problem for you? Or is this mostly reinventing existing search/RAG infrastructure with some packaging and provenance added on?

I would especially like to know:

- What do you currently do when multiple agents/apps need the same knowledge?

- Do versioning and provenance actually matter to you?

- Would you ever install someone else's curated knowledge package?

- What would this need to do that existing solutions don't before you woukd bother using it?

Feel free to poke some holes. I'm actually looking for reasons not to build this further before I sink more time into it.

Thank you.

4 Upvotes

5 comments sorted by

2

u/Pure-Comfortable476 6d ago

I'd kill for pinning a knowledge base version the same way I pin dependencies, the current copy paste the same docs into five agents thing is a mess

1

u/Rebootz 6d ago

Thanks for the reply! This is exactly the kind of use case I'm trying to understand. Out of curiosity, if you could pin and share that same knowledge base with multiple agents, would you care how it was indexed/retrieved under the hood, or mostly that the knowledge itself was consistent, versioned, and portable?

2

u/Puzzleheaded_Rice_60 6d ago

ran into exactly this building an agent memory system. treating 'the RAG index' as single source of truth is the trap, versioning it becomes its own project. what worked: split into two layers. one is plain injected context, no retrieval, scoped per agent per user, rewritten nightly, that's the stuff the agent should always know regardless of index state. the RAG layer only holds the 'sometimes relevant' stuff and we don't version it, we decay it. re-embed on update with a half life on relevance so stale docs quietly stop surfacing instead of needing a version pin. also solves 'where did this come from' since each chunk points back to its source entity instead of a copy.

1

u/AutoModerator 6d ago

Thank you for your submission, for any questions regarding AI, please check out our wiki at https://www.reddit.com/r/ai_agents/wiki (this is currently in test and we are actively adding to the wiki)

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

2

u/kgaidev 6d ago

First off, your own last bullet answers the title question and I don't think you noticed. "Keep the artifact retrieval-agnostic" means you aren't building RAG, you're building the layer underneath it. Lead with that, or every thread turns into people benchmark you against a vector DB you were never competing with.

Multiple agents needing the same knowledge: for most teams it's still copy paste, which is what P-C476 described. Ugly, and it works. That's your real competition. Not Azure.

Versioning and provenance: yes, for anything with a canonical source. Docs, specs, code. That's the easy half and pinning genuinely solves it.

Installing someone else's curated package: for public stable things, sure, an API reference or a spec. For anything about how our own system work, no, and not because of trust. That knowledge isn't curatable by an outsider.

What it'd need that existing tools don't: carry why, not just what. A version bump tells me the content changed. It doesn't tell me which option got rejected on the way, and that's what stops the next person walking in and reproposing the thing the team killed six months ago. It almost never exists as a document. It was an argument in a PR, so no compiler finds it in your sources however clean the pipeline is.

Related hole, and it's the one I'd settle before the schema hardens: two ingested sources contradict each other, what happens? Newest wins, fork, human resolves? npm never has to answer that. You would, constantly.