मैंने पिछले सप्ताह सारा वुडर्स का थ्रेड देखा और तुरंत इसके आधे हिस्से से सहमत हो गया।

वुडर्स, मेमजीपीटी (अब लेट्टा) के सह-निर्माता, [तर्क दिया कि मेमोरी एक प्लगइन नहीं है, यह हार्नेस है](https://x.com/sarahwooders/status/2040121230473457921)। हार्नेस अदृश्य निर्णय लेता है जिसे कोई बाहरी उपकरण नियंत्रित नहीं कर सकता: संघनन से क्या बचता है, संदर्भ कैसे लोड किया जाता है, क्या एजेंट अपने निर्देशों को संशोधित कर सकता है। "एजेंट हार्नेस में मेमोरी प्लग करने के लिए कहना, ड्राइविंग को कार में प्लग करने के लिए कहने जैसा है।"

फ़्रेमिंग को पास करना आसान है. मैं हार्नेस लाइन को व्यवस्थित पृष्ठभूमि के रूप में दोहराता रहता हूं, निरीक्षण के दावे के रूप में नहीं। ऐसा आंशिक रूप से इसलिए है क्योंकि जिस आधे से मैं सहमत हूं वह सही है।

## अदृश्य निर्णय वास्तविक हैं

[क्लाउड कोड में हार्नेस में निर्मित एक बहु-स्तरीय मेमोरी पदानुक्रम है](https://docs.anthropic.com/en/docs/claude-code/memory): CLAUDE.md, सत्र स्थिति, संघनन नियम, सिस्टम संदेश इंजेक्शन। जब [क्लाउड कोड 100K-टोकन वार्तालाप को 20K तक संकुचित करता है](https://docs.anthropic.com/en/docs/claude-code/best-practices), हार्नेस तय करता है कि क्या बचता है। कोई भी बाहरी उपकरण उस निर्णय को दोहरा नहीं सकता या उसे पलट नहीं सकता।

अहमद किदवई, जो [वर्चुअल कॉन्टेक्स्ट](https://github.com/virtual-context/virtual-context) का निर्माण करते हैं, ने उपयोगकर्ता सीट से उसी संरचना का वर्णन किया है [AI अपने जीवन के बारे में पढ़ने में अपना अधिकांश जीवन व्यतीत करता है](https://open.substack.com/pub/virtualcontext/p/ai-spends-most-of-its-life-reading)। प्रत्येक मोड़ पूरे थ्रेड को दोबारा चला सकता है, इसलिए अधिकांश इनपुट टोकन जो पहले से ही हुआ है उसे दोबारा पढ़ने के लिए जाते हैं। जब विंडो भर जाती है, तो संघनन कच्चे इतिहास को सारांश से बदल देता है। आपको जो गायब हुआ उसकी लाइन-आइटम रसीद नहीं मिलती।

एक ही सत्र के भीतर, संदर्भ विंडो में क्या प्रवेश करता है, क्या सारांशित किया जाता है, और क्या छोड़ा जाता है, इसके बारे में हार्नेस के विकल्प प्रभावी मेमोरी सिस्टम हैं। वुडर्स इस बारे में सही हैं।

## तर्क एक दोहन मानता है

सूत्र का निष्कर्ष यह है कि आपको मेमोरी-फर्स्ट हार्नेस का उपयोग करना चाहिए। उस निष्कर्ष के लिए आपको एक के अंदर काम करने की आवश्यकता है।

मैं नहीं। मैं अपने प्राथमिक इंटरफ़ेस के रूप में कर्सर, विशिष्ट कार्यों के लिए क्लाउड कोड, वार्तालापों के लिए चैटजीपीटी और स्वचालन के लिए कस्टम स्क्रिप्ट का उपयोग करता हूं। ये चार हार्नेस हैं, प्रत्येक अपने स्वयं के अदृश्य निर्णय लेते हैं कि क्या याद रखना है।

मैं जिन लोगों से बात करता हूं जो एजेंटों के साथ निर्माण करते हैं वे तीन से पांच उपकरणों का उपयोग करते हैं। प्रत्येक अलग तरीके से संकुचित होता है, संदर्भ को अलग तरह से लोड करता है, स्थिति को अलग तरह से संग्रहीत करता है। उपयोगकर्ता उन सभी के बीच मानव सिंक परत बन जाता है।

अधिक हार्नेस-एम्बेडेड मेमोरी जोड़ने से यह बदतर हो जाता है, बेहतर नहीं। प्रत्येक टूल को बेहतर आंतरिक मेमोरी मिलती है। उनमें से कोई भी सहमत नहीं है.

## तीन चिंताएँ, एक नहीं

वुडर्स संदर्भ विंडो प्रबंधन, सत्र स्थिति और टिकाऊ स्थिति को एक अवधारणा में समेट देती है जिसे वह "मेमोरी" कहती है। ये वास्तुशिल्प रूप से विशिष्ट हैं।

**संदर्भ विंडो प्रबंधन**: अभी प्रॉम्प्ट में क्या फिट बैठता है, क्या संकुचित होता है, मॉडल इस मोड़ को क्या देखता है। यह एक हार्नेस चिंता का विषय है. वुडर्स सही है.

**सत्र स्थिति**: बातचीत के दौरान बनी रहती है। यह भी एक हार्नेस चिंता का विषय है।

**टिकाऊ स्थिति**: उत्पत्ति और संस्करण के साथ सत्रों, उपकरणों और एजेंटों में बनी रहती है। यह बुनियादी ढांचा है, दोहन नहीं।

कोई भी हार्नेस उत्पत्ति के साथ नियतात्मक, स्कीमा-बाध्य, केवल-संलग्न, क्रॉस-प्लेटफ़ॉर्म स्थिति प्रदान नहीं करता है। प्रसंग प्रबंधन प्रेरक है। टिकाऊ स्थिति नेविगेशन डेटा है. यह ड्राइविंग की जानकारी देता है लेकिन ड्राइवट्रेन के अंदर नहीं है।

## यहां तक कि संदर्भ को बाहरी भी किया जा सकता है

किदवई का [वर्चुअल कॉन्टेक्स्ट](https://github.com/virtual-context/virtual-context) एक प्रॉक्सी है जो आपके क्लाइंट और अपस्ट्रीम एलएलएम एपीआई के बीच बैठता है। क्लाइंट 20-मिलियन-टोकन संदर्भ विंडो सेट करता है। मॉडल की वास्तविक विंडो 200K है। वर्चुअल कॉन्टेक्स्ट उनके बीच कंप्रेस, इंडेक्स और पेजों को संपीड़ित करता है। 52 टूल श्रृंखलाओं वाला 937K-टोकन क्लाउड कोड पेलोड क्यूरेटेड सिग्नल के ~65K तक ढह जाता है।

[LongMemEval](https://github.com/virtual-context/virtual-context#benchmark-results) पर, वर्चुअल कॉन्टेक्स्ट ने आधी लागत पर, पूरे कच्चे संदर्भ के साथ क्लाउड सॉनेट 4.5 के लिए 33% की तुलना में 95% सटीकता हासिल की। प्रॉक्सी क्लाउड कोड, कर्सर, ओपनक्लाव या किसी भी क्लाइंट के साथ काम करता है जो बेस यूआरएल स्वीकार करता है। VCATTACH दो ग्राहकों को सभी प्लेटफार्मों पर समान संकलित ज्ञान आधार साझा करने की सुविधा देता है।

तंत्र मायने रखता है. वीसी हार्नेस को बायपास नहीं करता है। हार्नेस अभी भी अपने स्वयं के संघनन और ट्रंकेशन निर्णय लेता है और एपीआई अनुरोध तैयार करता है। वीसी उस अनुरोध को बेस-यूआरएल रीडायरेक्ट के माध्यम से डाउनस्ट्रीम में रोकता है। जब हार्नेस वार्तालाप इतिहास को काट देता है, तो वीसी उस काट-छांट का पता लगा लेता है और अपने स्वयं के टिकाऊ स्टोर से पुनर्प्राप्त कर लेता है। मॉडल तक जो पहुंचता है वह वीसी की क्यूरेटेड विंडो है, हार्नेस का कच्चा आउटपुट नहीं।

वुडर्स का कहना सही है कि कोई भी बाहरी उपकरण हार्नेस के आंतरिक निर्णयों को नियंत्रित नहीं कर सकता है। लेकिन हार्नेस और एपीआई के बीच बैठा एक प्रॉक्सी उन निर्णयों का निरीक्षण कर सकता है और उन्हें आंशिक रूप से उलट सकता है। हार्नेस अपने स्वयं के संघनन के बाद 937K टोकन भेजता है। वीसी मॉडल को 65K क्यूरेटेड सिग्नल भेजता है। हार्नेस अभी भी टूल लूप और एजेंट को चलाता है। वह परत जो यह तय करती है कि मॉडल वास्तव में क्या देखता है, बाहर रहती है।

वह तीन परतें छोड़ता है, दो नहीं। हार्नेस एजेंट चलाता है। एक वैकल्पिक संदर्भ प्रबंधन परत हार्नेस और एपीआई के बीच बैठ सकती है। और एक टिकाऊ स्थिति परत हर चीज के नीचे बैठती है, जो कि सत्य है, उसे कायम रखती है, चाहे किसी भी सत्र के संदर्भ को कैसे भी प्रबंधित किया जाए।

## नियंत्रण बनाम मूल्य

कोई बाहरी उपकरण हार्नेस के संघनन निर्णयों को नियंत्रित नहीं कर सकता। सत्य। लेकिन सवाल यह नहीं है कि क्या राज्य परत संघनन को नियंत्रित करती है। यह है कि क्या यह हार्नेस की मूल स्मृति को मूल्य प्रदान करता है या नहीं।

अधिकांश हार्नेस-मूल स्मृति अल्पकालिक होती है। लेट्टा अपवाद है: यह डिज़ाइन के अनुसार सत्रों में स्मृति को बनाए रखता है। लेकिन लेट्टा की मेमोरी भी उपकरण-विशिष्ट, गैर-पोर्टेबल और गैर-नियतात्मक है। एलएलएम-संचालित टूल कॉल के माध्यम से एजेंट तय करता है कि क्या स्टोर करना है और कब, इसलिए एक ही बातचीत अलग-अलग मेमोरी स्थिति उत्पन्न कर सकती है। कर्सर इसे पढ़ नहीं सकता. क्लाउड कोड इसे नहीं पढ़ सकता. एक टिकाऊ राज्य परत क्रॉस-प्लेटफ़ॉर्म, नियतात्मक, संस्करणबद्ध और स्रोत तक पता लगाने योग्य है।

मूल्यवान होने के लिए आपको हार्नेस को नियंत्रित करने की आवश्यकता नहीं है। आपको हार्नेस के निर्णयों से बचे रहने की आवश्यकता है। केवल परिशिष्ट, टिकाऊ स्थिति डिज़ाइन द्वारा जीवित रहती है। जब कोई हार्नेस संदर्भ को संकुचित करता है, तो राज्य परत पूरा रिकॉर्ड रखती है। जब आप कल एक अलग टूल खोलते हैं, तो राज्य परत में वही होता है जो आपने कल संग्रहीत किया था।

## ट्रिगरिंग बनाम परिवहन

निकोलो बोस्ची (हिंडसाइट/वेक्टराइज़) [वुडर्स से सहमत](https://x.com/nicoloboschi/status/2042145292632379598): "एमसीपी के माध्यम से मेमोरी का उपयोग करना और यह उम्मीद करना कि मॉडल मेमोरी से जानकारी संग्रहीत और खोजेगा, निराशाजनक है।" चिंता वास्तविक है. यदि मॉडल को यह तय करना है कि कब स्टोर करना है और कब पुनर्प्राप्त करना है, तो वह स्टोर करना भूल सकता है। यह महत्वपूर्ण होने पर पुनर्प्राप्ति को छोड़ सकता है।

एमसीपी के बजाय, हिंडसाइट [हुक](https://docs.anthropic.com/en/docs/claude-code/hooks) का उपयोग करता है: स्क्रिप्ट जो सत्र प्रारंभ, शीघ्र सबमिशन, या टूल पूर्णता जैसे जीवनचक्र की घटनाओं पर स्वचालित रूप से चलती हैं। कोई भी एलएलएम यह तय नहीं करता कि उन्हें नौकरी से निकाला जाए या नहीं। हिंडसाइट का क्लाउड कोड प्लगइन प्रत्येक वार्तालाप को स्वचालित रूप से बनाए रखने और प्रत्येक संकेत पर ऑटो-रिकॉल करने के लिए चार जीवनचक्र हुक का उपयोग करता है। यह काम करता है।

लेकिन यह तर्क दो चीजों को जोड़ता है: स्मृति कैसे उत्पन्न होती है और यह कहाँ रहती है।

हिंडसाइट के हुक हिंडसाइट एपीआई को कॉल करते हैं। वे हार्नेस की अंतर्निहित मेमोरी में नहीं लिखते हैं। हुक ट्रिगर हैं. बाहरी सर्वर भंडारण है. वह अलगाव ही संपूर्ण वास्तुकला है। एक हुक जो क्लाउड कोड की मूल मेमोरी को लिखता है, वही सीमाएं प्राप्त करेगा: अल्पकालिक, गैर-पोर्टेबल, कल कर्सर के लिए अदृश्य।

हुक ट्रिगरिंग समस्या का समाधान करते हैं। वे भंडारण की समस्या का समाधान नहीं करते. प्रत्येक टिकाऊ मेमोरी सिस्टम को दोनों की आवश्यकता होती है।

हुक व्यापक रूप से उपलब्ध हैं, हालांकि सार्वभौमिक रूप से उपलब्ध नहीं हैं। क्लाउड कोड में 12+ ईवेंट वाला एक प्लगइन सिस्टम है। कर्सर के पास बीटा में 14+ इवेंट के साथ हुक.जेसन है। ओपनकोड में संघनन नियंत्रण और सिस्टम प्रॉम्प्ट इंजेक्शन सहित 20+ इवेंट हैं। कोडेक्स में टूल-स्तरीय हुक के साथ सत्र हुक विकास में हैं। ChatGPT और क्लाउड वेब ऐप केवल MCP बने रहेंगे। हिंडसाइट स्वयं उन मामलों के लिए एक एमसीपी सर्वर भेजता है।

इसका उत्तर यह है कि जहां हुक उपलब्ध हैं, एमसीपी जहां उपलब्ध नहीं है, दोनों प्रत्येक हार्नेस के नीचे एक ही टिकाऊ स्थिति परत पर लिखते हैं। "एमसीपी निराशाजनक है" विश्वसनीयता को ट्रिगर करने के बारे में एक बयान है, न कि इस बारे में कि स्मृति कहाँ रहनी चाहिए।

## परतें पूरक हैं

पांच अलग-अलग संघनन और संदर्भ निर्णय लेने वाले पांच हार्नेस एजेंट जो जानते हैं उसके पांच अलग-अलग संस्करण तैयार करते हैं। "ड्राइविंग" सादृश्य संदर्भ प्रबंधन के लिए काम करता है। यह तब टूट जाता है जब आप पांच कारें चलाते हैं और उन सभी में लगातार नेविगेशन डेटा की आवश्यकता होती है।

संदर्भ प्रबंधन और टिकाऊ राज्य प्रतिस्पर्धा नहीं कर रहे हैं। एक हार्नेस एजेंट और टूल लूप को चलाता है। एक संदर्भ परत, अंतर्निहित या बाहरी, यह प्रबंधित करती है कि मॉडल प्रत्येक मोड़ पर क्या देखता है। एक राज्य परत यह प्रबंधित करती है कि सत्रों और उपकरणों में क्या सत्य है। कोई हार्नेस या संदर्भ प्रॉक्सी सत्यापन योग्य सत्य, उद्गम, नियतिवाद, स्कीमा सत्यापन या क्रॉस-टूल एक्सेस प्रदान नहीं करता है। हार्नेस-एम्बेडेड मेमोरी के लिए तर्क एक साथ प्रत्येक हार्नेस के नीचे एक साझा राज्य परत के लिए तर्क है।

## मैं क्या निर्माण कर रहा हूं

मैं [नियोटोमा](https://neotoma.io) का निर्माण कर रहा हूं, एक संरचित मेमोरी परत जो किसी भी हार्नेस के नीचे रहती है: इकाई रिज़ॉल्यूशन, समयरेखा, उद्गम, नियतिवाद, क्रॉस-प्लेटफ़ॉर्म पहुंच।

इन धागों ने वह बदल दिया जो मैं आगे बना रहा हूँ। मैंने एमसीपी को एकमात्र एकीकरण सतह माना था। अब मैं जीवनचक्र विस्तार परत के रूप में हुक जोड़ रहा हूं। एमसीपी प्राथमिक एजेंट इंटरफ़ेस बना हुआ है।

अलगाव जानबूझकर किया गया है. एमसीपी एजेंट अनुबंध का मालिक है: सत्र शुरू होने पर एक बार निर्देश लोड किए जाते हैं, संरचित भंडारण उपकरण एजेंट पूरी प्रासंगिक जागरूकता के साथ कॉल करता है। हुक्स हार्नेस अनुबंध के स्वामी हैं: जीवनचक्र की घटनाएं जिन्हें एजेंट नियंत्रित नहीं करता है। एजेंट द्वारा प्रत्येक प्रॉम्प्ट देखने से पहले `UserPromptSubmit` हुक स्वचालित रूप से प्रासंगिक इकाइयों को पुनर्प्राप्त करता है। `पोस्टटूलयूज़` हुक प्रत्येक फ़ाइल संपादन और शेल कमांड को अवलोकन के रूप में कैप्चर करते हैं। यदि एजेंट का अपना समापन स्टोर छूट गया हो तो 'स्टॉप' हुक कच्ची बातचीत को जारी रखता है। एक `प्रीकॉम्पैक्ट` हुक यह देखता है कि हार्नेस क्या त्यागने वाला है।

परिणाम एमसीपी गुणवत्ता सीमा के नीचे एक विश्वसनीयता स्तर है। हुक के बिना, एमसीपी आज की तरह ही काम करता है। एमसीपी के बिना, हुक कच्चा अवलोकन कैप्चर प्रदान करते हैं लेकिन कोई संरचित इकाई निष्कर्षण नहीं देते हैं। दोनों मिलकर नियतात्मक पुनर्प्राप्ति, निष्क्रिय अवलोकन, संघनन जागरूकता और क्रैश रिकवरी देते हैं।

यह हिंडसाइट के दृष्टिकोण से भिन्न है। हिंडसाइट हुक के माध्यम से कच्चे प्रतिलेखों को कैप्चर करता है, फिर संस्थाओं को निकालने के लिए एक अलग सर्वर-साइड एलएलएम चलाता है। इसका मतलब है कि दूसरा मॉडल प्रति ऑपरेशन अतिरिक्त लागत और विलंबता के साथ निर्णय लेता है कि क्या मायने रखता है। नियोटोमा इकाई निष्कर्षण एजेंट-संचालित रखता है: वही मॉडल जो बातचीत को समझता है वह शून्य सीमांत एलएलएम लागत पर निष्कर्षण करता है। हुक नीचे विश्वसनीयता की परत प्रदान करते हैं, बुद्धिमत्ता की नहीं।

क्लाउड कोड, कर्सर, ओपनकोड और कोडेक्स के लिए प्लगइन्स अगले हैं। हुक नियोटोमा को लिखते हैं, हार्नेस की अंतर्निहित मेमोरी को नहीं। वे सभी एक ही टिकाऊ स्थिति परत तक पहुंचते हैं, जहां हुक उपलब्ध हैं और एमसीपी जहां उपलब्ध नहीं है।

वुडर्स सही हैं कि हार्नेस संदर्भ का मालिक है। बोस्ची सही है कि विश्वसनीयता बढ़ाने के मामले में हुक्स ने एमसीपी को मात दी है। किदवई दिखाते हैं कि संदर्भ प्रबंधन को भी बाह्यीकृत किया जा सकता है। उनमें से कोई भी इस सवाल का जवाब नहीं देता कि जब आप पांच हार्नेस का उपयोग करते हैं तो सच्चाई का मालिक कौन होता है। उस उत्तर को उन सभी के नीचे रहना होगा।