Personalisierungs-Architektur für KI-Agenten: RAG als Werkzeug
Bei der Code-Erstellung mit Claude oder Gemini legen Entwickler häufig Anweisungen und Aufgaben des Agenten in einer .md-Datei ab. Ein neuer Ansatz beschreibt, wie sich eine solche Personalisierungs-Architektur um RAG als zusätzliches Werkzeug erweitern lässt.

Usually, when writing code using AI such as Claude or Gemini, we may use a.md file to store the responsibilities, instructions, and activities that need to be performed by the Agent. When we create a module using this.md file, the Agent can use the instructions and context provided in the file throughout the conversation.
Likewise, when the user asks a query and wants to save information as a profile, the system can extract the context/info from the user's entered details and store it as user-specific memory.
Here, the Agent can extract the name and place and save them in the user profile.
The Agent already knows that the user is from:
by retrieving it from the profile. So, it will list the Top 10 attractions near Chennai.
Three layers: profile, episodes, procedures
An LLM extracts facts the user states, never guesses.
The system prompt is rebuilt on every call.
Profile - Who the user is now, stored as one small, structured record and recalled on every call.
E.g. name, city, language, level, allergies
Episode - What happened, stored as many small notes and recalled only when relevant.
E.g. trips planned, bugs fixed, complaints
Procedure - How to treat this user, stored as a few rules and recalled always, but edited rarely.
Personalized layers can be stored as JSON-serialized objects, such as dictionaries, lists, or strings, in RAM, a pickle file, or persistent storage. When the app loads next time, deserialize the object and store it as a predefined structure.
Documents will be chunked, embedded, and stored in a vector database. When a user query comes in, the system searches the database, gets the relevant context, and generates the answer using the retrieved context.
The question here is: When do we need to call RAG? Do we need to call it every time?
There is no need to refer to RAG for this kind of question because retrieval can add unnecessary latency and cost.
RAG can be exposed as a tool that the Agent can call. Whenever a question comes in, the Agent decides whether it needs to call the RAG tool based on the question. If RAG is needed, the Agent calls the RAG tool and uses the retrieved context to generate the answer. Otherwise, the Agent can answer directly using the LLM.