एजेंट मेमोरी वास्तव में कैसे काम करती है
किसी चैटबॉट से दो अलग-अलग सत्रों में एक ही सवाल दो बार पूछिए और वह दोनों बार एक अजनबी की तरह जवाब देता है। यह कोई बग नहीं है — यही डिफ़ॉल्ट है। एक कच्चे language model के पास कॉल्स के बीच कोई मेमोरी नहीं होती। एक बातचीत के भीतर वह जो कुछ भी "याद रखता" है, वह कॉन्टेक्स्ट विंडो में रहता है, और जब वह बातचीत खत्म होती है, वह गायब हो जाता है।
मेमोरी वह मशीनरी है जिसे आप इसे ठीक करने के लिए जोड़ते हैं: वे सिस्टम जो तय करते हैं कि किसी एजेंट को आगे क्या ले जाना चाहिए, इसे कहाँ संग्रहीत करना चाहिए, और सही टुकड़े को सही क्षण पर वापस कैसे खींचना चाहिए। 2026 में यह एक साइड क्वेस्ट होना बंद हो गया और एजेंट डिज़ाइन का एक फर्स्ट-क्लास हिस्सा बन गया, जिसके अपने बेंचमार्क, फ्रेमवर्क और एक असली रिसर्च साहित्य है। यह पेज वह नक्शा है।
- समझें कि एक कॉन्टेक्स्ट विंडो मेमोरी क्यों नहीं है — और सीमा वास्तव में कहाँ है
- एजेंट जिन चार मेमोरी प्रकारों का उपयोग करते हैं उन्हें अलग-अलग पहचानें: working, episodic, semantic, procedural
- चार स्टोरेज पैटर्न की तुलना करें: full-context, vector/RAG, knowledge-graph, और compaction/summarization
- देखें कि Claude, ChatGPT और Gemini इनमें से हर एक आज मेमोरी को कैसे लागू करता है
- अपने खुद के एजेंट के लिए बिना ओवर-इंजीनियरिंग किए एक मेमोरी दृष्टिकोण चुनें
जिस एक विचार को पकड़े रहना है: context ≠ memory
सबसे आम भ्रम एक बड़ी कॉन्टेक्स्ट विंडो को "मेमोरी" मान लेना है। यह नहीं है। कॉन्टेक्स्ट विंडो एक टर्न के लिए वर्किंग स्पेस है — यह हर कॉल पर शून्य से फिर से भरी जाती है, यह सीमित है, और यह महँगी है। इसमें अटेंशन भी घटता जाता है ("lost in the middle" प्रभाव जिसे Context Engineering में समझाया गया है)।
मेमोरी तीन तरीकों से अलग है:
| कॉन्टेक्स्ट विंडो | मेमोरी | |
|---|---|---|
| जीवनकाल | एक अनुरोध | सत्रों, दिनों, हमेशा भर |
| आकार | निश्चित token सीमा | प्रभावी रूप से असीमित (बाहरी स्टोर) |
| लागत | हर एक टर्न पर चुकाई गई | लिखने के लिए एक बार चुकाई गई; संदर्भ के लिए सस्ती |
| एक्सेस | सब कुछ, हमेशा दृष्टि में | चयनात्मक — केवल वही पुनर्प्राप्त करें जो प्रासंगिक हो |
एजेंट मेमोरी का पूरा खेल इन दोनों के बीच सही जानकारी को स्थानांतरित करना है: टिकाऊ तथ्यों को विंडो से बाहर लिखें ताकि आप उनके लिए हर टर्न पर भुगतान न करें, और उन्हें केवल तभी वापस अंदर खींचें जब इस विशिष्ट चरण को उनकी आवश्यकता हो। उस प्रवाह को सही कर लें और एक एजेंट हफ्तों तक ऐसी कॉन्टेक्स्ट विंडो पर काम कर सकता है जिसमें कभी भी केवल कुछ हजार प्रासंगिक tokens ही होते हैं।
मेमोरी के चार प्रकार
(ढीले तौर पर) संज्ञानात्मक विज्ञान से उधार लेते हुए, 2026 का एजेंट पारिस्थितिकी तंत्र चार श्रेणियों पर एकत्रित हो गया है। आपको शायद ही कभी चारों की आवश्यकता होती है — लेकिन उनका नामकरण आपको एक ऐसा गोला बनाने से रोकता है जो हर चीज़ बुरी तरह करता है।
- अभी कॉन्टेक्स्ट विंडो में जो कुछ है — मौजूदा कार्य, पिछले कुछ टर्न, इस चरण के tool परिणाम। डिज़ाइन के हिसाब से अस्थिर। यह स्क्रैचपैड है, संग्रह नहीं। इसे अच्छी तरह प्रबंधित करना context engineering है; यह स्थायित्व नहीं है।
- जो विशिष्ट चीज़ें घटीं, एक टाइमस्टैम्प के साथ। 'मंगलवार को उपयोगकर्ता ने कहा कि checkout टूट गया था; बुधवार को सपोर्ट ने इसे हल किया हुआ चिह्नित किया।' Episodic memory स्वाभाविक रूप से टेम्पोरल है — क्रम और कब मायने रखता है। यही वह है जो एक एजेंट को एक स्नैपशॉट के बजाय एक इतिहास के बारे में तर्क करने देता है।
- टिकाऊ तथ्य और प्राथमिकताएँ, इससे रहित कि आपने उन्हें कब सीखा। 'उपयोगकर्ता मीट्रिक इकाइयों को प्राथमिकता देता है।' 'यह ग्राहक enterprise plan पर है।' Semantic memory काफी हद तक atemporal है — यह उसका प्रतिनिधित्व करती है जो एजेंट मानता है कि वर्तमान में सत्य है, न कि उस घटना का जहाँ उसे यह पता चला।
- कुछ कैसे करना है — पुन: प्रयोज्य skills, workflows और सीखी गई दिनचर्याएँ। व्यवहार में चारों में सबसे कम परिपक्व। Claude Code जैसे टूल्स में यह अक्सर एक स्वचालित स्टोर के बजाय निर्देश फाइलों (CLAUDE.md) और पुन: प्रयोज्य skills के रूप में रहती है।
एक उपयोगी परीक्षण: यदि आप "वह कब हुआ?" के साथ जवाब देंगे तो यह episodic है; यदि आप "क्या सच है?" के साथ जवाब देंगे तो यह semantic है; यदि आप "यह ऐसे होता है" के साथ जवाब देंगे तो यह procedural है; और यदि यह केवल अगले कुछ सेकंड के लिए मायने रखता है, तो यह working memory है और इसे बिल्कुल भी स्थायी बनाने की आवश्यकता नहीं है।
चार स्टोरेज पैटर्न
एक बार जब आप जान लेते हैं कि क्या याद रखना है, तो आप चुनते हैं कि इसे कैसे संग्रहीत और पुनर्प्राप्त करना है। जटिलता के मोटे तौर पर क्रम में चार प्रमुख पैटर्न हैं। अधिकांश वास्तविक सिस्टम दो या तीन को जोड़ते हैं।
1. Full-context (इसे सब भर दो)
पूरे इतिहास को रखें और इसे हर टर्न पर फिर से भेजें। शून्य इन्फ्रास्ट्रक्चर, संपूर्ण स्मरण — जब तक आप token सीमा, लागत वक्र, या "lost in the middle" तक नहीं पहुँच जाते। छोटे असिस्टेंट के लिए ठीक; किसी भी लंबे समय तक चलने वाली चीज़ के लिए एक मृत अंत। यह वह आधार रेखा है जिस पर हर दूसरा पैटर्न सुधार करता है।
2. Vector / RAG memory
प्रत्येक मेमोरी को एक embedding के रूप में एक vector database में लिखें; क्वेरी के समय, मौजूदा टर्न को embed करें और सबसे समान top-k मेमोरीज़ को पुनर्प्राप्त करें। यह retrieval-augmented generation है जो दस्तावेज़ों के बजाय बातचीत के इतिहास की ओर इंगित की गई है। सस्ती, स्केलेबल, और तथ्यों तथा प्राथमिकताओं के semantic स्मरण के लिए डिफ़ॉल्ट।
इसकी कमज़ोरी: टेम्पोरल या multi-hop प्रश्नों के लिए समानता ≠ प्रासंगिकता। "बजट कटने के बाद हमने क्या तय किया?" एक क्रम का प्रश्न है, और cosine similarity को समय का या दो तथ्यों को एक साथ जोड़ने का कोई बोध नहीं है।
3. Knowledge-graph memory
मेमोरीज़ को entities और relationships के रूप में संग्रहीत करें — nodes और edges, अक्सर edges पर टाइमस्टैम्प के साथ। किसी प्रश्न का उत्तर देने के लिए आप vectors का फ़ज़ी-मैचिंग करने के बजाय ग्राफ़ को ट्रैवर्स करते हैं। यही वह है जो multi-hop और टेम्पोरल तर्क को व्यवहार्य बनाता है ("उस व्यक्ति की जगह किसने ली जिसके पास उस अकाउंट का स्वामित्व था जिसके बारे में उपयोगकर्ता ने शिकायत की थी?")। Zep/Graphiti जैसे फ्रेमवर्क ने अपना पूरा प्रस्ताव टेम्पोरल knowledge graphs के इर्द-गिर्द बनाया। लागत वास्तविक इंजीनियरिंग है: extraction, entity resolution, और ग्राफ़ को सड़ने से बचाए रखना।
4. Compaction और summarization
चलते हुए इतिहास को समय-समय पर एक आसुत सारांश में संपीड़ित करें और उससे आगे बढ़ें — छोटी, सस्ती विंडो के बदले शब्दशः स्मरण का व्यापार करते हुए। यही वह है जो Claude Code में /compact करता है, और जो कई चैट प्रोडक्ट्स में "auto-summary" करता है। यह long-term memory का सबसे सस्ता रूप है और अक्सर वह पहला रूप है जिसकी आपको वास्तव में आवश्यकता होती है। इसका जोखिम: सारांश चुपचाप उस एक विवरण को छोड़ देता है जिसकी आपको आवश्यकता थी। घंटों लंबे रन्स पर यह कैसे सामने आता है, इसके लिए Long-Running Agent Harnesses देखें।
वास्तविक सिस्टम इन्हें परतों में लगाते हैं। एक सामान्य 2026 स्टैक: चलती हुई बातचीत के लिए compaction, semantic तथ्यों के लिए vector, और उसके ऊपर एक graph केवल तभी जब टेम्पोरल/multi-hop क्वेरीज़ वास्तव में आपके ट्रैफ़िक में दिखाई दें। ग्राफ़ तब तक न बनाएँ जब तक आप उस दर्द को महसूस न करें जिसे ग्राफ़ हल करता है।
बड़े तीन इसे कैसे करते हैं
अब हर प्रमुख असिस्टेंट किसी न किसी रूप में मेमोरी के साथ आता है। वे एक ही चीज़ नहीं हैं, और अंतर मायने रखते हैं।
| प्रोडक्ट | यह क्या याद रखता है | यह कैसे काम करता है (मोटे तौर पर) |
|---|---|---|
| Claude | दो परतें: आपकी प्राथमिकताओं की एक ऐप-स्तरीय मेमोरी, और एजेंट्स के लिए एक डेवलपर-फेसिंग memory tool। | Claude app memory चैट्स में तथ्यों को संग्रहीत करती है; API memory tool plus context editing एक एजेंट को एक client-side स्टोर में नोट्स लिखने देती है और लंबे रन्स झेलने के लिए बासी tool परिणामों को स्वतः-प्रून करती है। |
| ChatGPT | "Saved memories" (स्पष्ट तथ्य) और साथ ही आपकी पिछली चैट्स का संदर्भ। | उपयोगकर्ता-द्वारा बताए गए तथ्यों और स्वचालित रूप से निकाली गई प्राथमिकताओं का मिश्रण, जो बाद के टर्नों में सिस्टम कॉन्टेक्स्ट में इंजेक्ट किया जाता है। उपयोगकर्ता द्वारा संपादन योग्य और चालू/बंद किया जा सकने वाला। |
| Gemini | आपकी चैट्स से और, वैकल्पिक रूप से, व्यापक Google account सतह से निकाला गया व्यक्तिगत कॉन्टेक्स्ट। | पिछली बातचीतों से विवरण याद करता है और account कॉन्टेक्स्ट का उपयोग करके निजीकरण कर सकता है, जो आपके गोपनीयता नियंत्रणों के अधीन है। |
दो निष्कर्ष। पहला, उपभोक्ता मेमोरी अधिकांशतः semantic है — प्राथमिकताएँ और तथ्य — न कि पूर्ण episodic रीप्ले। दूसरा, यदि आप एक एजेंट बना रहे हैं, तो प्रोडक्ट की अंतर्निहित मेमोरी आपका मेमोरी सिस्टम नहीं है; वह परत आप अपनी हैं, Claude के memory tool जैसे प्रिमिटिव्स या किसी बाहरी फ्रेमवर्क का उपयोग करते हुए।
एक कच्चे model को नोट लेने वाले एजेंट में बदलें (सबसे सस्ती असली मेमोरी)
You have a file called MEMORY.md that persists between our sessions. At the END of each session, append any durable facts worth keeping: - my stable preferences (tools, formats, style) - decisions we made and WHY - open threads to resume next time At the START of each session, read MEMORY.md first and use it. Keep it under 30 lines — when it grows past that, consolidate and delete anything stale. Never store secrets or credentials.
वह एकल पैटर्न — टिकाऊ नोट्स को एक बाहरी फ़ाइल में लिखना, अगली बार उन्हें वापस पढ़ना — एजेंट मेमोरी का 80/20 है। नीचे दी गई अधिकांश फ्रेमवर्क मशीनरी बिल्कुल इसी का एक अधिक स्वचालित, अधिक स्केलेबल संस्करण है।
मेमोरी मापना: LoCoMo बेंचमार्क
आप जिसे माप नहीं सकते उसे सुधार नहीं सकते, और बेंचमार्क आने तक मेमोरी को मापना कठिन था। सबसे अधिक उद्धृत LoCoMo है ("Evaluating Very Long-Term Conversational Memory of LLM Agents"): बहुत लंबी multi-session बातचीतें — दर्जनों सत्रों में सैकड़ों टर्न — जिनमें पाँच किस्मों में प्रश्न-उत्तर जोड़े होते हैं: single-hop, multi-hop (cross-session), टेम्पोरल तर्क, open-domain, और adversarial।
LoCoMo जो उजागर करता है वह वही पैटर्न है जिसके इर्द-गिर्द डिज़ाइन करना है: सिस्टम single-hop तथ्यात्मक स्मरण पर ठीक करते हैं और टेम्पोरल तथा multi-hop प्रश्नों पर बिखर जाते हैं। वह विफलता मोड ठीक वही कारण है जिसके लिए knowledge-graph memory मौजूद है — यह वह पैटर्न है जो उन दोनों श्रेणियों को सबसे अधिक उठाता है। जब आप अपने खुद के एजेंट की मेमोरी का मूल्यांकन करें, तो multi-hop और टेम्पोरल मामलों को भारी वज़न दें; single-hop स्मरण लगभग हर चीज़ को बढ़ा-चढ़ाकर दिखाता है।
बिना ओवर-बिल्डिंग के एक दृष्टिकोण चुनना
- कुछ न करें। Working memory (कॉन्टेक्स्ट विंडो) पर्याप्त है। यहाँ एक मेमोरी स्टोर जोड़ना शुद्ध ओवरहेड है।
- एक बाहरी फ़ाइल में नोट लेने से शुरू करें, या प्रोडक्ट की अंतर्निहित मेमोरी से। यह लगभग-शून्य लागत पर अधिकांश 'मेरी प्राथमिकताएँ याद रखो' आवश्यकताओं को कवर करता है।
- compaction/summarization जोड़ें। भार-वहन करने वाले तथ्यों को रखें, पल-पल का विवरण छोड़ें। यहीं पर लंबे समय तक चलने वाले एजेंट रहते हैं।
- vector/RAG memory जोड़ें। हर चीज़ फिर से भेजने के बजाय प्रति टर्न top-k प्रासंगिक मेमोरीज़ पुनर्प्राप्त करें।
- केवल अब एक knowledge graph की ओर जाएँ — या एक प्रबंधित फ्रेमवर्क (Mem0, Letta, Zep, LangMem) जो आपको extraction और entity resolution को हाथ से बनाए बिना एक देता है।
जाल चरण पाँच से शुरू करने में है। ग्राफ़ मेमोरी डेमो में प्रभावशाली और प्रोडक्शन में महँगी है। सीढ़ी चढ़ें; उस पहले पायदान पर रुकें जो आपकी वास्तविक समस्या हल करता है।
Check yourself
0/4निचोड़
मेमोरी कोई एक फीचर नहीं है जिसे आप चालू करते हैं — यह एक प्रवाह है जिसे आप डिज़ाइन करते हैं: विंडो से क्या निकलता है, इसे कहाँ संग्रहीत किया जाता है, और यह कैसे वापस आता है। चार मेमोरी प्रकारों का नामकरण करें ताकि आप उन सबके लिए एक गोला न बनाएँ। उस सबसे सस्ते स्टोरेज पैटर्न से शुरू करें जो आपकी समस्या हल करता है और केवल तभी चढ़ें जब आप अगले का दर्द महसूस करें। और टेम्पोरल तथा multi-hop मामलों से मापें, क्योंकि single-hop स्मरण हर चीज़ को उससे अधिक स्मार्ट दिखाता है जितनी वह है।
मेमोरी Context Engineering का दूसरा आधा हिस्सा है: context engineering तय करती है कि इस टर्न विंडो में क्या भरता है; मेमोरी तय करती है कि टर्नों के बीच क्या बचता है। मिलकर वे वही हैं जो एक चैटबॉट को एक ऐसे एजेंट से अलग करते हैं जो आप जितना अधिक समय उसके साथ काम करते हैं उतना बेहतर होता जाता है।
स्रोत और आगे पढ़ने के लिए
- Evaluating Very Long-Term Conversational Memory of LLM Agents (LoCoMo) — विहित बेंचमार्क; project page।
- Effective context engineering for AI agents — compaction, नोट लेने और just-in-time पुनर्प्राप्ति पर Anthropic।
- Claude memory tool & context editing docs — डेवलपर-फेसिंग प्रिमिटिव।
- Agent Memory Techniques — conversation buffers, vector stores, knowledge graphs, episodic/semantic memory, Mem0, Letta, Zep, Graphiti और LoCoMo को कवर करते हुए 30 चलाने योग्य notebooks।
- The State of AI Agent Memory 2026 — मेमोरी आर्किटेक्चर और बेंचमार्क पर वेंडर रिपोर्ट (हमेशा की स्वयं-रिपोर्ट-की-गई-संख्या सावधानी के साथ पढ़ें)।
- AILmanac पर संबंधित: Context Engineering · Long-Running Agent Harnesses · RAG · Claude app memory · Memory & Context Editing (API)।