RAG reusability

[andrescaroc]

From the related issues listed bellow, and the documentation about agents I understand that the files for the agent RAG should be local to the directory that contains the agent's index.yaml.

With that clear, what is the suggested approach to use an agent with different RAG contents?

I am going to give an example of a possible usecase:

Let's say that I create a code agent focused on a specific programming language, I have several projects I have made with that language (lets say 50 to say a number). I want to use the code agent on all of them. The agent should be able to create, delete or patch code files in the current project.

Because I can't reuse the same agent with different RAG's, Should I create 50 agent definitions where the git directory of each project lives inside the agent directory where the index.yaml file is located?

If I am wrong, I would appreciate if you can illuminate the right approach for this usecase

Related Issues:

• Reusability of rags from an agent #126
• RAG builder only loads one document #189

[onestardao]

Great question — and you’re absolutely not alone in hitting this reuse wall when trying to apply the same agent logic across multiple RAG contexts.

Here’s the core issue:
RAG setups tend to couple the agent’s semantic behavior too tightly with a fixed retrieval directory (via index.yaml). That works fine for simple mono-purpose agents, but it collapses fast when you want to recontextualize the same intelligence across different knowledge bases.

You have two main paths:

Dynamic RAG binding (recommended):
Refactor the agent logic so the RAG backend is a pluggable component — inject the vector store + documents at runtime rather than hardcoding them in the same directory. This gives you a single agent definition (e.g. for a code assistant), and you can switch RAGs like swapping memory cards.

Agent-per-RAG duplication (your current method):
Technically works, but it scales like duct-taping RAM onto a toaster. If you hit 50 RAGs, you’ll spend more time maintaining YAML than writing code.

If you’re looking for a working example of dynamic binding, I shared a paper that uses a symbolic engine to decouple agent intent from retrieval scope.
RAGs are treated as attachable memory layers, not static directories.

PDF (free, weird, endorsed):
https://github.com/onestardao/WFGY

Hope this helps illuminate the reuse path — and saves you from spawning 50 index.yml zombies.