A developer's blueprint for AI agents that remember users and look things up only when needed

Beyond the instruction file

When developers build with AI tools such as Claude or Gemini, they often keep a Markdown (.md) file that spells out the agent's responsibilities, instructions and tasks. The agent reads it and follows it throughout the conversation. As dev.to reported, that approach works, but it is the same for every user.

The post argues for something more personal. If a user says they are Ravi from Chennai, the agent can pull out the name and city and save them as a profile. Later, when Ravi asks for the top 10 attractions near him, the agent already knows where he is and answers for Chennai without asking again.

Three kinds of memory

The author splits what an agent should remember into three layers, each with its own job.

• Profile: who the user is right now. This is one small, structured record, such as name, city, language, level or allergies, and it is recalled on every call.
• Episodes: what has happened. These are many small notes, like trips planned, bugs fixed or complaints, and they are recalled only when relevant.
• Procedures: how to treat this user. These are a few rules, recalled every time but edited rarely. One example is keeping answers under 5 lines.

The split is useful because the layers behave differently. A profile changes when your life does, while episodes pile up as a history. Procedures act more like standing preferences.

How the memory is learned and kept

The post sums up the design in four questions. What is remembered? The three layers. How is it learned? A large language model (LLM, the AI behind a chatbot) extracts facts the user actually states, and does not guess at things the user never said. Where is it kept? In a store with one folder per user. How is it used? The system prompt, the hidden instructions sent to the model, is rebuilt on every call from that stored memory.

On the storage side, the layers can be saved as JSON-style objects, meaning plain dictionaries, lists or strings. They can live in RAM (temporary memory), in a pickle file (a way to save Python data to disk), or in persistent storage. When the app starts again, it loads the saved object back into a predefined structure.

RAG as something the agent chooses

RAG stands for retrieval-augmented generation. Documents are split into chunks, converted into numerical representations called embeddings, and stored in a vector database, which is built to find text with similar meaning. When a question arrives, the system searches that database, fetches the relevant pieces and writes an answer from them.

The post asks a fair question: should that search run every time? If a user simply says 'Hi', searching a document store is pointless. It slows the reply and adds cost without improving anything.

The fix is to expose RAG as a tool. The agent reads each question and decides whether it needs to look something up. If so, it calls the tool and answers from what comes back. If not, it answers directly with the model.

What this means in practice

The post is a short design note, not a study. It gives no benchmarks or test results, so it does not show how much latency or cost the approach saves. What it offers is a clear way to organize the pieces.

Two ideas stand out for anyone evaluating an agent product. First, ask what the system remembers about you and in which layer, because a stable profile and a log of past events carry different privacy stakes. Second, ask whether lookups happen on every message or only when needed, since that affects speed and what you pay.