आपके एजेंटों को अभिलेख प्रणाली चाहिए

जब कई एजेंट एक ही तथ्यों के आधार पर काम करते हैं, तो वे तथ्य बदलते हैं और सभी एजेंटों को बदलाव का पता एक साथ नहीं चलता। भुगतान की नियत तारीख इस समस्या को साफ़ दिखाती है।

मान लीजिए चालान INV-2041 कहता है कि भुगतान 22 अक्टूबर को देय है, और आपूर्तिकर्ता का बाद में आया ईमेल नियत तारीख 29 अक्टूबर कर देता है। एक एजेंट चालान पढ़ता है, दूसरा ईमेल पढ़ता है, और तीसरा जो कुछ उसे मिलता है उसके आधार पर उस सप्ताह के भुगतान तैयार करता है। पहला 22 अक्टूबर बताता है, दूसरा 29 अक्टूबर, और तीसरा वह तारीख बताता है जो उसे पहले मिली। इस व्यवस्था में ऐसा कुछ नहीं है जो तय करे कि कौन-सी तारीख लागू है, इसलिए एजेंटों को चलाने वाले व्यक्ति को स्वयं जाँच करनी पड़ती है।

इस खास चालान का उदाहरण मैंने बनाया है, लेकिन इसके पीछे की व्यवस्था वास्तविक है। मैं एक Neotoma इंस्टेंस के साथ तीन टूलों में एजेंट चलाता हूँ। ईमेल देखने वाली एक प्रक्रिया आने वाले संदेशों को उनके स्रोत के साथ सहेजती है और जिन संदेशों पर कार्रवाई चाहिए, उन्हें कार्यों में बदलती है; Claude Code, Codex और Cursor के सत्र उन्हीं कार्यों और योजनाओं को उठाते हैं। यही व्यवस्था, और Neotoma को एक व्यापक अभिलेख प्रणाली बनाने का मेरा काम, इस निबंध का आधार है।

याद करना एक अलग काम में अच्छा है

पुनर्प्राप्ति किसी प्रश्न से संबंधित दिखने वाली सामग्री ढूँढ़ती है। वेक्टर इंडेक्स या लंबा चैट इतिहास यह काम अच्छी तरह करते हैं, और कई कार्यों के लिए इतना काफ़ी है। लेकिन इससे यह तय नहीं होता कि क्या लागू है। नियत तारीख पूछने पर पुनर्प्राप्ति चालान और ईमेल लौटाती है, जिन्हें प्रश्न से उनकी समानता के हिसाब से क्रम में रखा जाता है, न कि इस आधार पर कि इनमें से कौन-सा वर्तमान स्थिति बताता है।

अधिक टूल और एजेंट परिवेश इस समस्या को कठिन बनाते हैं। एक एजेंट Markdown फ़ाइल में नोट्स रखता है, दूसरा अपने चैट उत्पाद के भीतर सीखी हुई बात रखता है, और तीसरा साझा फ़ोल्डर पढ़ता है। हर प्रति लिखे जाते समय सही थी। तथ्य बदलने पर प्रतियाँ अलग-अलग समय पर बदलती हैं, या बिल्कुल नहीं बदलतीं। कोई एजेंट यह नहीं पूछ सकता कि किस प्रति को माना जाए, क्योंकि ऐसा कोई स्थान ही नहीं है जहाँ इस सवाल का जवाब हो। अभिलेख प्रणाली किसी एक टूल से बाहर, ऐसी जगह होनी चाहिए जहाँ वे सभी पहुँच सकें।

इस साल की शुरुआत में मैंने Neotoma को स्मृति की परत और सत्य की परत कहा था। मैंने ऐसा कहना बंद कर दिया, क्योंकि मुझे लगा कि Neotoma के लिए “स्मृति” गलत श्रेणी है: यह भ्रम पैदा करती है, और लोग Neotoma की तुलना स्मृति उत्पादों से करते रहे। मुझे एजेंट से बहुत तरह की चीज़ों के बारे में सटीक डेटा, ऐसी शक्ल में, सुरक्षित रखना है जिसका ऑडिट किया जा सके। उस डेटा को रखने की जगह का सीधा नाम अभिलेख प्रणाली है।

अभिलेख प्रणाली से मेरा मतलब वह जगह है जो बताती है कि अभी क्या लागू है, वह कहाँ से आया और उसने किसे बदला। समानता आधारित खोज इन सवालों का जवाब नहीं दे सकती, क्योंकि समानता न समय के बारे में बताती है, न स्रोत के बारे में।

Neotoma आज क्या करता है

मैं Neotoma बनाता हूँ, जो AI एजेंटों के लिए अभिलेख प्रणाली है। यह MIT लाइसेंस के अंतर्गत खुला स्रोत है और स्थानीय रूप से, आपके चुने हुए डेटा डायरेक्टरी में चलता है। आगे बताया गया है कि npm पर प्रकाशित नवीनतम पैकेज आज क्या करता है।

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

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

इकाइयों को आपस में भी जोड़ा जा सकता है: चालान को उसके आपूर्तिकर्ता से, या अनुवर्ती कार्य को उस चालान से जिससे वह संबंधित है। एजेंट ये संबंध स्पष्ट रूप से बनाता है। संबंध बताते हैं कि रिकॉर्ड आपस में कैसे जुड़े हैं, जबकि स्रोत के लिंक किसी अवलोकन के पीछे का PDF या ईमेल दिखाते हैं।

Neotoma प्रत्येक फ़ील्ड के लिए स्कीमा का विलय नियम अपने आप लागू करता है और अवलोकनों से उसका वर्तमान मान निकालता है। अधिकतर फ़ील्डों के लिए सबसे नया अवलोकन मान्य होता है। वही अवलोकन और वही विलय नियम दिए जाने पर यह प्रक्रिया वही स्नैपशॉट बनाती है; हर बार पढ़ते समय मॉडल से फिर चुनाव नहीं करवाना पड़ता।

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

अब चालान पर लौटें। दोनों एजेंटों के लिखे बदलाव एक ही इकाई में जाते हैं। नियत तारीख अब 29 अक्टूबर दिखती है और ईमेल से आए अवलोकन की ओर संकेत करती है। रकम अब भी पहले अवलोकन की ओर संकेत करती है, क्योंकि उसमें कोई बदलाव नहीं हुआ। भुगतान एजेंट 29 अक्टूबर पढ़ता है, और 22 अक्टूबर वाला अवलोकन अपने स्रोत के साथ सूची में बना रहता है।

एजेंट Neotoma तक MCP सर्वर, REST API और CLI के ज़रिए पहुँचते हैं। स्थापना मार्गदर्शिका बताती है कि समर्थित टूल और परिवेश कैसे जोड़े जाएँ। रिकॉर्ड साझा करने के लिए हर टूल को उसी इंस्टेंस और डेटा प्रोफ़ाइल, या उसी MCP प्रवेश-बिंदु, से जोड़ें; अलग प्रवेश-बिंदु अलग डेटाबेस इस्तेमाल कर सकते हैं।

लोग साथ आने वाले Neotoma ऐप में अपने रिकॉर्ड देख सकते हैं।

स्वीकार किया गया हस्ताक्षरित अनुरोध सत्यापित एजेंट पहचान स्थापित कर सकता है। सक्रिय और सीमित दायरे वाले अनुदान तय करते हैं कि कौन-से काम करने की अनुमति है; केवल हस्ताक्षर अनुमति नहीं है।

यह किस दिशा में जा रहा है

अब तक मैंने ऐसी अभिलेख प्रणाली का वर्णन किया है जो एजेंटों के लिए लागू तथ्य तय करती है। आगे की दिशा ऐसी प्रणाली है जिसे लोग और एजेंट मिलकर बनाए रखें, जहाँ कोई भी पूछ सके कि कौन-सा मान वर्तमान है, किस स्रोत ने उसे पेश किया, वह देखा गया था, अनुमान से निकला था या निर्णय से, उसे सुधारने का अधिकार किसके पास था, और किन एजेंटों ने पिछले संस्करण पर भरोसा किया था। नियोजित शासन क्षमताएँ आज मौजूद हस्ताक्षरित पहचान, सीमित दायरे वाले अनुदानों और ऐप से आगे जाती हैं:

• हर क्षेत्र का स्पष्ट ज़िम्मेदार तय करना, जिसे उसी क्षेत्र के रिकॉर्ड सुधारने का सीमित अधिकार हो।
• प्रतिस्पर्धी दावों, अनसुलझे विवादों और आधिकारिक स्थितियों को स्पष्ट रूप से दर्ज करना।
• दिखाना कि कोई मान क्यों लागू है, वह किसके अधिकार का अनुसरण करता है और बदलाव का असर कहाँ पड़ेगा।

Ateles इस दिशा को संचालन की ओर बढ़ाता है। Ateles के एडेप्टर डिज़ाइन में एडेप्टर ईमेल, कैलेंडर और कोड होस्ट जैसे सिस्टमों से जानकारी Neotoma में लाते हैं, और अधिकृत कार्रवाइयाँ उन सिस्टमों तक वापस पहुँचाते हैं। Neotoma रिकॉर्ड रखता है; जुड़े हुए टूल काम करते हैं।

पूरी परिकल्पना और उसके हर भाग की आज की स्थिति README में दी गई है।

साझा इंस्टेंस आज उपयोग में आने वाला आधार है। अगले दो चित्र यहाँ से आगे की दिशा दिखाते हैं।

अभिलेख प्रणाली, केवल पुनर्प्राप्ति नहीं

समाधान बेहतर इंडेक्स नहीं है। पुनर्प्राप्ति एजेंट को कही गई बात ढूँढ़ने में मदद करती है। अभिलेख प्रणाली बताती है कि अभी क्या लागू है। कई टूलों में काम करने वाले एजेंटों को दूसरी चीज़ चाहिए, एक ऐसी जगह जहाँ वे सभी पहुँच सकें। और अभिलेख प्रणाली तभी मदद करती है जब एजेंट उसमें लिखें और उससे पढ़ें।

अगर आप एक से अधिक टूल या परिवेश में एजेंट चलाते हैं, तो ऐसे कार्यप्रवाह से शुरू करें जिसके तथ्य और इकाइयाँ आपस में संबंधित हों:

npm install -g neotoma
neotoma init
neotoma setup --tool claude-code

अपने टूल या परिवेश के लिए सेटअप विकल्प इस्तेमाल करें; स्थापना मार्गदर्शिका अन्य समर्थित एकीकरणों को समझाती है। फिर कार्यप्रवाह के परस्पर जुड़े तथ्य और इकाइयाँ एक एजेंट से सहेजें, और उन्हें उसी कॉन्फ़िगर किए गए इंस्टेंस और डेटा प्रोफ़ाइल या MCP प्रवेश-बिंदु से जुड़े दूसरे एजेंट से पढ़ें।

स्थापना मार्गदर्शिका neotoma.io/install पर है। कोड और समस्याओं का ट्रैकर GitHub पर github.com/markmhendrickson/neotoma में हैं।