प्रकाशित 20 October 2026
“Agent को memory दे दो” ऐसी ज़रूरतों में से एक है जो सुनने में बहुत आसान लगती है, जब तक आप इसे लागू करने नहीं बैठते। असल में, memory कोई एक फीचर नहीं है — यह अलग-अलग समस्याओं को हल करने वाले कई तंत्रों का समूह है, और इन्हें एक जैसा मान लेना production AI agents के अपने-आप चीज़ें भूल जाने या ऐसी बातें याद रखने का सबसे आम कारणों में से एक है जो उन्हें धीमा, महँगा और कभी-कभी गलत बना देती हैं।
किसी agent में memory जोड़ने से पहले यह साफ़ समझना ज़रूरी है कि उस काम को वास्तव में किस तरह की memory चाहिए, क्योंकि agent systems में short-term और long-term memory बस “एक ही चीज़ के अलग समय-मान” नहीं हैं — ये वास्तुकला के स्तर पर अलग समस्याएँ हैं।
शॉर्ट-टर्म मेमोरी: कॉन्टेक्स्ट विंडो को संभालना
Agent की short-term memory, व्यावहारिक रूप से, context window management है: वर्तमान काम के prompt में क्या शामिल किया जाए ताकि model के पास कार्रवाई करने के लिए ज़रूरी जानकारी हो। इसमें हाल की conversation turns, उसी session में पहले किए गए tool calls के नतीजे, और कोई भी बीच की reasoning शामिल होती है जिसे agent को multi-step task पूरा करते समय ध्यान में रखना होता है।
यहाँ चुनौती storage की नहीं — relevance और cost की है। context window में मौजूद हर token पैसे और ध्यान दोनों खर्च करता है; पूरी conversation history और हर tool result को हर अगले call में ठूँस देने से performance गिरती है और latency तथा spend दोनों बढ़ते हैं। production agent systems को आम तौर पर यह तय करने की स्पष्ट strategy चाहिए कि active context में क्या बना रहेगा: पुरानी turns का summary बनाना, जब tool outputs का परिणाम decision में शामिल हो जाए तो उन्हें हटा देना, और detail को तभी दोबारा fetch करना जब वह सचमुच फिर से चाहिए हो — “बस कभी काम आ जाए” सोचकर उसे वहीं रखे रहने से बेहतर।
लॉन्ग-टर्म मेमोरी: कौन-सी बातें सेशन्स के बीच बनी रहनी चाहिए
Long-term memory बिल्कुल अलग समस्या है: अगली बार जब agent को invoke किया जाए, संभव है दिनों या हफ्तों बाद, किसी अलग session में, शायद किसी अलग user या task के लिए, तब उसे क्या याद रहना चाहिए? यहीं architecture से जुड़े ज़्यादातर फैसले असल में तय होते हैं, क्योंकि long-term memory को ऐसे सवालों के जवाब देने होते हैं जैसे:
- क्या यह किसी specific user या customer से जुड़ा fact है (preferences, history, prior decisions) जिसे हर बार पूरा लोड करने के बजाय ज़रूरत पड़ने पर निकाला जाना चाहिए?
- क्या यह business या domain से जुड़ा fact है (policies, product catalog, past outcomes) जो किसी एक conversation से जुड़े रहने के बजाय shared knowledge store में होना चाहिए?
- क्या यह operational state है — जहाँ multi-step workflow रुका था — जिसे restart या किसी दूसरे agent instance को handoff करने के बाद भी बचा रहना चाहिए?
इनमें से हर एक आम तौर पर storage के अलग pattern से जुड़ता है: retrieval-based memory के लिए vector store या structured database (यही mechanisms retrieval-augmented generation के पीछे भी हैं), workflow और operational state के लिए relational record, और कभी-कभी छोटे, बार-बार इस्तेमाल होने वाले facts के लिए एक बहुत ही सरल key-value store, जिन्हें semantic search की बिल्कुल ज़रूरत नहीं होती।
क्यों “सब कुछ स्टोर करके बाद में निकाल लेना” तरीका अच्छी तरह काम नहीं करता
शुरुआत में होने वाली एक आम गलती long-term memory को एक ही, बिना-फर्क वाली bucket मान लेना है: हर interaction को embed करके store कर दिया जाता है, और हर नया task similarity search से “relevant” memories निकालता है। जैसे-जैसे memory store बड़ा होता है, यह एक तयशुदा तरीके से बिगड़ने लगता है — retrieval ऐसी बातें सामने लाने लगता है जो सुनने में सही लगती हैं लेकिन पुरानी या विरोधाभासी होती हैं, और agent के व्यवहार को समझना मुश्किल हो जाता है क्योंकि कोई भी भरोसे से नहीं कह सकता कि वह किसी भी पल “क्या जानता है”।
Production memory systems को भी वही अनुशासन चाहिए जो किसी और data store को दिया जाता है: facts का source साफ़ होना चाहिए, उन्हें बदलने या invalid करने का तरीका होना चाहिए जब वे बदलें, और ideally ऐसा scope होना चाहिए जो तय करे कि किसी भी task में क्या pulled किया जाएगा। Customer support संभालने वाले agent को हर customer के बारे में stored हर memory तक बिना रोक-टोक पहुँच की ज़रूरत नहीं है — उसे सही memories चाहिए, current customer और current task के दायरे में, और उन्हें wholesale dump करने के बजाय सोच-समझकर retrieve किया जाना चाहिए।
Memory के लिए Guardrails, ज़्यादातर दूसरे agent components से भी ज़्यादा ज़रूरी होते हैं
Memory वही जगह भी है जहाँ agent design के कई कठिन guardrail questions असल में सामने आते हैं। अगर कोई agent अपनी long-term memory में खुद लिख सकता है, तो उसे यह गलत fact स्टोर करने और फिर भविष्य के sessions में उसी गलत fact के आधार पर बार-बार काम करने से कौन रोकेगा? अगर memory users या tenants के बीच बनी रहती है, तो shared retrieval store के ज़रिए एक user का data दूसरे के context में लीक होने से क्या रोकता है? ये edge cases नहीं हैं — ये किसी भी production memory design के मानक सवाल हैं, और इनके जवाब agent के अपनी memory पर write access के साथ live होने से पहले चाहिए, किसी incident के बाद नहीं।
Agent को क्या याद रहना चाहिए, यह तय करने के लिए एक व्यावहारिक framework
“सब कुछ store करो” को default मानने के बजाय, यह ज़्यादा उपयोगी है कि किसी agent को क्या याद रखना है, इसे तीन हिस्सों में बाँटकर हर हिस्से के लिए अलग storage बनाया जाए:
- कार्य-विशिष्ट स्मृति — यह केवल एक ही कार्य या सत्र की अवधि तक रहती है, उसके बाद हटा दी जाती है। सावधानीपूर्वक संदर्भ प्रबंधन के अलावा किसी विशेष अवसंरचना की जरूरत नहीं होती।
- इकाई-विशिष्ट स्मृति — किसी विशिष्ट ग्राहक, मामले या रिकॉर्ड से जुड़ी तथ्यात्मक जानकारी, जो वह इकाई फिर से सामने आने पर पुनः प्राप्त की जाती है। व्यवसायिक एजेंटों में यह “उपयोगी” दीर्घकालिक स्मृति का सबसे सामान्य रूप है।
- क्षेत्र-विशिष्ट स्मृति — साझा ज्ञान जो सभी कार्यों और उपयोगकर्ताओं पर लागू होता है, और जिसे आम तौर पर एजेंट की अपनी स्मृति-व्यवस्था की बजाय एक उचित ज्ञान आधार या RAG प्रणाली से बेहतर संभाला जाता है।
एजेंट स्मृति में अधिकतर मूल्य इस बात से आता है कि इकाई-विशिष्ट स्मृति सही ढंग से काम करे — भरोसेमंद तरीके से, स्पष्ट अद्यतन और अमान्यकरण नियमों के साथ — न कि ऐसी लगातार अधिक जटिल सामान्य-उद्देश्य स्मृति संरचना बनाने से जो तीनों मामलों को एक ही तरह से संभालने की कोशिश करे।
कहाँ से शुरू करें
अगर आप कोई एजेंट प्रणाली बना रहे हैं या उसका मूल्यांकन कर रहे हैं और स्मृति बार-बार एक अस्पष्ट आवश्यकता के रूप में सामने आती है, तो उपयोगी अभ्यास यह है कि एजेंट को करने वाले वास्तविक कार्यों को देखें और हर कार्य के लिए पूछें कि उसे वास्तव में क्या याद रखना है और कहाँ से। अक्सर ऐसा करने पर पता चलता है कि एजेंट को सामान्य अर्थ में बहुत कम “स्मृति” चाहिए और कुछ ही सुव्यवस्थित स्रोतों से कहीं अधिक सटीक पुनर्प्राप्ति चाहिए — जो बनाना और बनाए रखना कहीं आसान और अधिक भरोसेमंद प्रणाली है। हम टीमों को एजेंट आर्किटेक्चर डिजाइन करने में मदद करते हैं, जिसमें स्मृति और पुनर्प्राप्ति परतें शामिल हैं, जो वास्तविक उत्पादन लोड में टिक सकें; संपर्क करें यदि आप अपने एजेंट निर्माण के लिए इस पर काम कर रहे हैं।
संबंधित