इस 19 सिस्टम्स सीरीज़ के अंतिम भाग में थोड़ी देरी हुई, लेकिन देर आए दुरुस्त आए।
उन 19 सिस्टम्स में छह सार्वभौमिक पैटर्न हैं जिन्हें मैं खंगाल रहा हूँ, वे इस सीरीज़ की रीढ़ हैं। लिखने के समय गुणवत्ता में निवेश। तथ्य के साथ उत्पत्ति का सफर। RRF-फ्यूज्ड हाइब्रिड रिट्रीवल। हीट-आधारित प्रमोशन के साथ टियरड स्टोरेज। स्पष्ट संदर्भ बजट। एजेंट सतह पर टूल्स-नॉट-इंजेक्शन। प्रत्येक ने अपना अलग लेख अर्जित किया क्योंकि तीन या अधिक सिस्टम स्वतंत्र रूप से एक ही अनुशासन पर पहुँचे थे।
सार्वभौमिक पैटर्न यहीं समाप्त होते हैं। वहाँ से, उभरते हुए पैटर्न शुरू होते हैं।
यह लेख उन आठ पैटर्न के बारे में है जो सीमा से नीचे बैठते हैं, एक या शायद दो सिस्टम में रहते हैं, जहाँ कार्यान्वयन इतनी स्पष्ट रूप से एक वास्तविक समस्या का समाधान कर रहा है कि यह विश्वास करना कठिन है कि वे दुर्लभ रहेंगे। सात ठीक एक सिस्टम में दिखाई देते हैं। एक दो में दिखाई देता है और स्नातक होने से एक कदम दूर है। पहले को सबसे गहराई से संबोधित किया गया है क्योंकि यह सबसे महत्वपूर्ण है।
जल्दी होने का मतलब है कि इनमें से कुछ सार्वभौमिक नहीं होंगे। देर से होना और भी बुरा है: आप 2026 में एक सिस्टम बनाते हैं जो स्टोरेज-लेयर प्राधिकरण के बिना शिप होता है क्योंकि एक संश्लेषण ने इसे एक बार की विचित्रता कहा था, और आपको 2027 में Hacker News पर एक प्रॉम्प्ट-इंजेक्शन डेमो मिलता है।
स्टोरेज इंजन ही एकमात्र प्राधिकरण है जो टिकता है
पिछले लेख में तर्क दिया गया था कि एजेंट को टूल्स रखने चाहिए। इसे एक SQL टूल दें और सवाल तुरंत उठता है: इसे उस टेबल को क्वेरी करने से क्या रोकता है जिसे नहीं करना चाहिए?
भोले-भाले दृष्टिकोण सर्वविदित हैं और सभी गलत हैं।
प्रॉम्प्ट-स्तरीय निर्देश: "आपको conversations टेबल पढ़ने की अनुमति नहीं है।" एक सहकारी मॉडल के खिलाफ काम करता है। किसी भी मॉडल के खिलाफ विफल रहता है जो निर्देश को गलत समझता है, यह तय करता है कि निषेध उसके वर्तमान कार्य पर लागू नहीं होता है, या जेलब्रेक के तहत काम कर रहा है।
एप्लिकेशन-स्तरीय फ़िल्टर: \sql_query\ टूल मॉडल के SQL को लपेटता है, निषिद्ध टेबल संदर्भों के लिए इसे पार्स करता है, डेटाबेस को पास करने से पहले क्वेरी को अस्वीकार करता है। एक भोले मॉडल के खिलाफ काम करता है। किसी भी मॉडल के खिलाफ विफल रहता है जो टेबल नामों को उद्धृत करता है, \ATTACH\ का उपयोग करता है, रैपर और डेटाबेस के बीच पार्स बेमेल का शोषण करता है, या कहीं और परिभाषित व्यू के माध्यम से रूट करता है।
केवल ORM-मध्यस्थता पहुँच: एजेंट कभी भी कच्चे SQL को नहीं छूता, यह टाइप की गई विधियों को कॉल करता है। तब तक काम करता है जब तक सिस्टम एक डिबगिंग टूल, एक एनालिटिक्स टूल, एक माइग्रेशन टूल, या एक "एजेंट को दो टेबल जोड़ने दें" सुविधा नहीं बढ़ाता, जिस बिंदु पर नियम टूट जाता है और टूटना किसी का ध्यान नहीं जाता।
सीधे शब्दों में कहें: इनमें से कोई भी प्रवर्तन नहीं है। ये संकेत हैं। एक सिस्टम जो वास्तविक उप-एजेंट अलगाव चाहता है, उसे स्टोरेज इंजन से ही पढ़ने से मना करने के लिए कहना होगा, न कि उसके ऊपर की परत से। यह वह अनुशासन है जो क्षमता-आधारित सुरक्षा ऑपरेटिंग सिस्टम संसाधनों पर लागू करती है: कर्नेल 'नहीं' कहता है, एप्लिकेशन नहीं। यह वह अनुशासन भी है जो PostgreSQL की रो-लेवल सुरक्षा मल्टी-टेनेंट SaaS पर लागू करती है: नीति डेटाबेस में रहती है, ORM में नहीं, क्योंकि "जिस इंजीनियर ने नया माइक्रोसर्विस बनाया वह टेनेंट फ़िल्टर लागू करना भूल गया" एक बग क्लास है जिसे केवल स्टोरेज-इंजन नीति ही खारिज कर सकती है।
second-brain इस संग्रह का पहला काम किया हुआ उदाहरण है। इसके स्कोप्ड डेटाबेस में तीन परतें हैं, प्रत्येक आवश्यक है, कोई भी अपने आप में पर्याप्त नहीं है।
प्रति स्कोप्ड एजेंट एक ताज़ा इन-मेमोरी SQLite कनेक्शन। कंस्ट्रक्टर \:memory:\ खोलता है और वास्तविक डेटाबेस को केवल-पढ़ने के मोड में अटैच करता है। एजेंट के कनेक्शन का कोई वास्तविक मुख्य स्कीमा नहीं है, अगली परत जो वहाँ रखती है उसे छोड़कर पढ़ने के लिए कुछ भी नहीं है।
मुख्य स्कीमा में TEMP VIEWs स्रोत में अनुमत टेबलों पर रीडायरेक्ट करते हैं। व्यू परिभाषाएँ एजेंट के प्रोफ़ाइल से आती हैं और कॉलम-स्तरीय रिडक्शन या रो-स्तरीय फ़िल्टर को एनकोड कर सकती हैं। एक व्यू नाम वैलिडेटर प्रोफ़ाइल के माध्यम से दुर्भावनापूर्ण टेबल नामों के इंजेक्शन को रोकता है।
एक SQLite C-API ऑथराइज़र हुक स्रोत स्कीमा के किसी भी पढ़ने से इनकार करता है जो व्यू के माध्यम से नहीं गुजरता है। हुक हर उस SQLite रीड के लिए फायर करता है जो प्रदर्शन करने वाला है, ऑप्टिमाइज़र द्वारा टेबल नाम को हल करने से पहले भी। व्यू बॉडी के अंदर एक रीड की अनुमति है, व्यू स्कोप फ़िल्टर है। एक टॉप-लेवल रीड को स्कोप द्वारा बनाए गए व्यू नामों के सेट के खिलाफ जाँचा जाता है। सीधे स्रोत स्कीमा के खिलाफ कोई भी रीड बिना किसी अपवाद के अस्वीकार कर दी जाती है।
LLM जो चाहे SQL लिख सकता है। यह टेबल नामों को उद्धृत कर सकता है, \UNION\ का उपयोग कर सकता है, \ATTACH\ का उपयोग कर सकता है, SQLite के पूर्ण व्याकरण का उपयोग कर सकता है। यह एक ऐसी टेबल से एक पंक्ति पढ़ने में सफल नहीं हो सकता जो अनुमति सूची में नहीं है, क्योंकि ऑथराइज़र टेबल नाम हल होने से पहले C लेयर पर रीड को इंटरसेप्ट करता है। एप्लिकेशन-स्तरीय फ़िल्टर को बायपास किया जा सकता है। स्टोरेज-इंजन प्राधिकरण को नहीं।
लगभग 50 लाइनें stdlib Python। कोई अतिरिक्त निर्भरता नहीं, कोई अतिरिक्त प्रक्रिया नहीं, कोई स्कीमा माइग्रेशन नहीं। प्रति-क्वेरी ओवरहेड प्रति रीड एक C कॉलबैक है, जो क्वेरी की लागत के मुकाबले अदृश्य है। पैटर्न बाकी सब कुछ के साथ साफ-सुथरा कंपोज़ होता है: एजेंट का टूल रजिस्ट्री अभी भी फीचर-गेटेड हो सकता है, व्यू परिभाषाएँ अभी भी कॉलम-स्तरीय रिडक्शन को एनकोड कर सकती हैं, बातचीत का इतिहास अभी भी लिखने के समय रिडैक्ट किया जा सकता है। उनमें से कोई भी परत स्टोरेज-लेयर प्रवर्तन से कमजोर नहीं होती है। वे इससे मजबूत होती हैं।
फ्रेमिंग मायने रखता है। 19 सिस्टम में हर दूसरा सुरक्षा पैटर्न एक संकेत है। स्टोरेज इंजन प्राधिकरण है।
तीन और जो उल्लेख के लायक हैं
एसिंक क्लीनअप रेस प्रोटेक्शन (llm-wiki)
बैकग्राउंड मेमोरी मेंटेनेंस मूल रूप से फोरग्राउंड उपयोगकर्ता क्रियाओं के साथ रेसी है। एक स्वीप जो प्रोजेक्ट A के खिलाफ शुरू हुआ और प्रोजेक्ट B के खिलाफ समाप्त हुआ, दोनों को दूषित कर चुका है। इसने A के निर्णयों को B के समीक्षा स्टोर में स्थानांतरित कर दिया है, या B की वस्तुओं को A के डेटा के खिलाफ हल के रूप में चिह्नित कर दिया है। यह एक बग क्लास है जिसे पेश करना आसान है, पता लगाना कठिन है, और साफ-सुथरा ठीक करना असंभव है क्योंकि दूषित स्थिति वैध दिखती है।
llm-wiki एक दो-चरणीय बैकग्राउंड समीक्षा लूप चलाता है और, प्रत्येक उपज बिंदु पर, दो रेस-प्रोटेक्शन सिग्नलों की पुन: जाँच करता है: प्रोजेक्ट-स्विच हैंडलर द्वारा फायर किया गया एक एबॉर्ट सिग्नल, और UI स्टोर में वर्तमान प्रोजेक्ट के खिलाफ एक पथ तुलना। कोई भी जाँच विफल होती है, स्वीप बिना निर्णय लागू किए मध्य-उड़ान में लौट आता है। कतार की ओर प्रोजेक्ट-स्विच हैंडशेक तस्वीर को पूरा करता है: यह मेमोरी साफ़ करने से पहले सक्रिय प्रोजेक्ट की स्थिति को डिस्क पर फ्लश करता है, प्रोसेसिंग आइटम को वापस लंबित पर लौटाता है, इन-फ्लाइट LLM कॉल और इन-फ्लाइट स्वीप जजमेंट दोनों को एबॉर्ट करता है, और उसके बाद ही रुके हुए प्रोजेक्ट के पथ पर लिखता है।
मेटा-पैटर्न टेकअवे है: जहाँ नियतात्मक हो सकते हो वहाँ नियतात्मक, जहाँ LLM आवश्यक हो वहाँ LLM, हर जगह एबॉर्टेबल। दो-चरणीय संरचना LLM को उन मामलों से बाहर रखती है जिन्हें सरल अस्तित्व जाँच संभाल सकती हैं। रेस प्रोटेक्शन दोनों चरणों को एबॉर्टेबल रखता है। संयोजन किसी भी सिस्टम में किसी भी बैकग्राउंड मेमोरी मेंटेनेंस लूप के लिए एक टेम्पलेट है।
ऑटो-डिग्रेडेड नो-ऑप कंस्ट्रक्टर (graymatter)
लाइब्रेरी API डिज़ाइन में एक आवर्ती तनाव है। सबसे सरल "हैलो वर्ल्ड" चाहता है कि लाइब्रेरी बस काम करे, एक लाइन कंस्ट्रक्ट करने के लिए, एक कॉल करने के लिए। सबसे रक्षात्मक उत्पादन मुद्रा चाहती है कि यह कंस्ट्रक्शन पर जोर से विफल हो एक संरचित त्रुटि के साथ जिसे कॉलर अनदेखा नहीं कर सकता।
graymatter फेल-साइलेंट चुनता है, लेकिन एक अनुशासन के साथ जो व्यापार को उत्पादक बनाता है। कंस्ट्रक्टर कभी त्रुटि नहीं लौटाता। यदि init विफल होता है, bbolt लॉक है, डेटा निर्देशिका अलिखनीय है, वेक्टर स्टोर नहीं खोला जा सकता है, यह stderr पर लॉग करता है और एक डिग्रेडेड Memory लौटाता है जिसके तरीके सभी नो-ऑप हैं। उत्पादन कॉलर हैंडल पर भरोसा करने से पहले \Healthy()\ के माध्यम से सत्यापित करते हैं। लाइब्रेरी \go get\-योग्य है, तीन लाइनों में आयात करने योग्य है, और डेमो में काम करती है। \Healthy()\ उत्पादन अनुशासन कर है।
पैटर्न लाइब्रेरी को एजेंट हार्नेस में एम्बेड करने के लिए सुरक्षित बनाता है जिनका अपना स्टार्टअप समारोह होता है। एक एजेंट हार्नेस जो बूट के दौरान \[graymatter.New](https://graymatter.new/)(...)\ कॉल करता है, त्रुटि पथ को अनदेखा करता है क्योंकि कोई त्रुटि पथ नहीं है, और जारी रखता है, हैप्पी पथ में एक काम करने वाली मेमोरी लेयर और जब डेटा निर्देशिका केवल-पढ़ने के लिए होती है तो एक नो-मेमोरी फ़ॉलबैक प्राप्त करता है। किसी भी तरह हार्नेस बूट होता है। यह एक विशिष्ट प्रकार की रक्षात्मक रचना है जो फेल-लाउड कंस्ट्रक्टर हर एम्बेडिंग साइट पर स्पष्ट त्रुटि हैंडलिंग के बिना पेश नहीं कर सकते।
शैडो-मोड डुप्लिकेट डिटेक्शन (mem9)
हर सिस्टम जो डुप्लिकेट दमन शिप करता है, उसे एक कोसाइन समानता सीमा चुननी होती है। 0.95 से ऊपर लगभग निश्चित रूप से एक डुप्लिकेट है। 0.7 से नीचे लगभग निश्चित रूप से नहीं है। बीच का स्थान विवादित है, और सही कट एम्बेडिंग मॉडल, डोमेन, क्वेरी वितरण, और इस विशेष सिस्टम में झूठी सकारात्मक बनाम झूठी नकारात्मक की लागत पर निर्भर करता है।
एक को अंतर्ज्ञान के आधार पर चुनने और शिप करने का प्रलोभन भारी है। mem9 ऐसा नहीं करता। यह प्रत्येक तथ्य के लिए डुप्लिकेट-डिटेक्शन क्वेरी चलाता है, कोसाइन स्कोर को Prometheus हिस्टोग्राम में रिकॉर्ड करता है, और कोई कार्रवाई नहीं करता। सीमा तब तक स्थगित रहती है जब तक उत्पादन डेटा इसे उचित नहीं ठहराता। "अवलोकन शिप करें, अनुमान नहीं।"
वही तर्क हर मेमोरी सिस्टम में हर सीमाबद्ध निर्णय पर लागू होता है। रीरैंक सीमा। रिकॉल कॉन्फिडेंस कटऑफ। टियर-प्रमोशन हीट गेट। इनसाइट-मर्ज समानता गेट। 19 में से अधिकांश सिस्टम इन मानों का अनुमान लगाकर शिप करते हैं। mem9 मान को स्थगित करके शिप करता है। अनुशासन दुर्लभ है और परिणाम बेहतर है।
चार और, अधिक संक्षिप्त
प्रति-टेनेंट भौतिक डेटाबेस अलगाव (mem9)।
एक साझा स्टोर पर \WHERE tenant_id = ?\ फ़िल्टर के बजाय, mem9 TiDB Zero के माध्यम से प्रति टेनेंट एक अलग TiDB क्लस्टर प्रदान करता है। अलगाव स्टोरेज-इंजन-साइड है। एप्लिकेशन गलती से टेनेंट के पार क्वेरी नहीं कर सकता क्योंकि क्वेरी करने के लिए कोई साझा स्टोर नहीं है। यह स्टोरेज-लेयर प्राधिकरण के समान अंत-स्थिति का एक मोटा-दाना संस्करण है: इंजन पर लागू अलगाव, एप्लिकेशन पर नहीं। बुनियादी ढाँचे की लागत जिसने ऐतिहासिक रूप से इसे अव्यावहारिक बना दिया था, चली गई है। TiDB Zero ऑटो-प्रोविज़न करता है। Neon PostgreSQL के लिए भी ऐसा ही करता है। Cloudflare D1 SQLite के लिए भी ऐसा ही करता है।
स्पष्ट संदर्भ बजट के साथ स्रोत-टर्न सजावट (mem9)।
एक पुनर्प्राप्त स्मृति एक स्ट्रिंग है। "उपयोगकर्ता Postgres पसंद करता है।" सही, संक्षिप्त, संदर्भ के बिना ग्राउंड करना असंभव। mem9 मूल वार्तालाप मोड़ों को सजावट के रूप में जोड़ता है, क्वेरी के खिलाफ स्कोर किया जाता है और एक बजट ट्रिपल द्वारा सीमित किया जाता है: न्यूनतम स्कोर, प्रति-मेमोरी सीमा, कुल सीमा। "उपयोगकर्ता Postgres पसंद करता है" पढ़ने वाला एजेंट वह मोड़ प्राप्त करता है जहाँ उपयोगकर्ता ने कहा "हमने MongoDB की कोशिश की लेकिन जॉइन ने हमें मार डाला इसलिए मैंने पिछली तिमाही Postgres पर स्विच किया।" कोई दूसरा टूल कॉल आवश्यक नहीं है। ग्राउंडिंग परिणाम में है। पूर्वापेक्षाएँ पहले से ही सार्वभौमिक हैं: प्रोवेनेंस प्लस हाइब्रिड रिट्रीवल। 19 में से अधिकांश सिस्टम इसे दो दिनों में लागू कर सकते हैं।
चौथी फ़ाइल के रूप में purpose.md (llm-wiki)।
Karpathy LLM Wiki पैटर्न में तीन विहित फ़ाइलें हैं: कच्चे स्रोत, विकी कार्य सेट, और संरचनात्मक नियमों के लिए schema.md। llm-wiki एक चौथी जोड़ता है: purpose.md, उपयोगकर्ता द्वारा भरी गई, सिस्टम द्वारा किए गए हर LLM कॉल में इनलाइन की गई। हर इन्जेस्ट प्रॉम्प्ट, हर जनरेशन प्रॉम्प्ट, हर चैट रिट्रीवल इसे पढ़ता है। प्रभाव एक स्थिर दिशात्मक पूर्व है जो हर डाउनस्ट्रीम व्यवहार को कंडीशन करता है। LLM वैसे भी सिस्टम प्रॉम्प्ट पढ़ने वाला है। उपयोगकर्ता के इरादे को जोड़ने में कुछ भी खर्च नहीं होता और सब कुछ उठाता है। अधिकांश अन्य सिस्टमों में अनुपस्थिति llm-wiki में इसकी उपस्थिति की तुलना में समझाना कठिन है।
आधिकारिक एजेंट अनुबंध के रूप में AGENTS.md (Tolaria, OpenContext)। अधिकांश रिपॉजिटरी \AGENTS.md\ या \CLAUDE.md\ के साथ इसे एक संकेत फ़ाइल के रूप में मानते हैं। Tolaria और OpenContext इसे एक अनुबंध के रूप में मानते हैं, हर बाध्यकारी खंड को एक यांत्रिक जाँच के साथ समर्थित करते हैं जो बिल्ड को विफल कर देता है यदि एजेंट इसका उल्लंघन करता है। "प्री-कमिट हुक को छोड़ें नहीं" एक विनम्र अनुरोध नहीं है, यह एक नियम है जिसे CI लागू करता है। "टेस्ट कवरेज सीमा से ऊपर रहना चाहिए" एक दिशानिर्देश नहीं है, यह एक बार है जिस पर टेस्ट रनर रुक जाता है। एक संकेत को अनदेखा किया जा सकता है। एक जाँच द्वारा समर्थित अनुबंध को नहीं। दो सिस्टम पहले से ही ऐसा करते हैं। एक और और यह स्नातक हो जाता है।
कौन से अगले सार्वभौमिक होंगे
स्टोरेज-लेयर प्राधिकरण पहले सार्वभौमिक होगा। यह स्रोत विश्लेषण में सबसे आत्मविश्वासपूर्ण भविष्यवाणी है। हर मेमोरी सिस्टम जो एक उप-एजेंट को SQL पहुँच देता है, स्टोरेज-लेयर प्रवर्तन के बिना एक प्रॉम्प्ट इंजेक्शन से गोपनीयता उल्लंघन से दूर है। बुनियादी ढाँचा पहले से ही मौजूद है। SQLite के पास 2000 के दशक की शुरुआत से \set_authorizer\ है। PostgreSQL RLS मुख्यधारा है। LanceDB और ClickHouse के अपने नीति हुक हैं। बाधा तकनीकी नहीं है, यह जागरूकता है। second-brain ने काम किया हुआ उदाहरण प्रदान किया है। प्रबंधित API की अगली पीढ़ी अनुशासन की नकल करेगी क्योंकि विकल्प अरक्षणीय है।
स्रोत-टर्न सजावट दूसरी सार्वभौमिक होगी। पूर्वापेक्षाएँ पहले से ही सार्वभौमिक हैं। कार्यान्वयन दो क्वेरी प्लस एक बजट है। एजेंट-साइड सूचना लाभ इतना बड़ा है कि जो कोई भी इसे पहले प्रबंधित API में शिप करता है वह दूसरे शिप करने वाले की तुलना में स्रोत संवाद में उत्तरों को ग्राउंड करने में स्पष्ट रूप से बेहतर होगा। नकल करने का दबाव अधिक है। graymatter के पास प्रति तथ्य स्रोत है। supermemory के पास वंशावली है। Hindsight के पास पूर्ण वार्तालाप प्रोवेनेंस है। इनमें से कोई भी पैटर्न से एक PR दूर है।
ऑटो-डिग्रेडेड नो-ऑप कंस्ट्रक्टर तीसरा सार्वभौमिक होगा, और एक अलग भाषा में। Go की सांस्कृतिक स्थितियाँ पैटर्न को सुरक्षित बनाती हैं। अगला अपनाने वाला Python होने की संभावना नहीं है, संस्कृति अपवादों के बारे में बहुत उत्सुक है, लेकिन Rust हो सकता है। यह एक लाइब्रेरी-API डिज़ाइन विकल्प है, मेमोरी विकल्प नहीं, और यह जहाँ भी "डेमो सौंदर्य प्लस उत्पादन अनुशासन" सही व्यापार है, वहाँ फैल जाएगा।
शैडो-मोड डिप्लॉयमेंट डार्क हॉर्स है। तकनीकी रूप से तुच्छ, सांस्कृतिक रूप से कठिन। यदि कोई दूसरा सिस्टम उस पर गेट लगाने से पहले एक सीमा को इंस्ट्रूमेंट करता है, तो पैटर्न तुरंत स्नातक हो जाता है, और तीसरा और चौथा एक रिलीज़ चक्र के भीतर अनुसरण करता है क्योंकि इंजीनियरिंग एर्गोनॉमिक्स एक बार प्रदर्शित होने के बाद अप्रतिरोध्य होते हैं।
शेष चार प्रत्येक एक विशिष्ट डिप्लॉयमेंट आकार के अधिक सामान्य होने पर सशर्त हैं। रेस प्रोटेक्शन सार्वभौमिक होता है जब अधिक सिस्टम मल्टी-कन्वर्सेशन समानांतरता विकसित करते हैं। प्रति-टेनेंट भौतिक अलगाव सार्वभौमिक होता है जब विनियमित उद्यम ग्राहक इसके लिए पूछना शुरू करते हैं। purpose.md सार्वभौमिक होता है जब Karpathy LLM Wiki प्रतिमान को अपना तीसरा या चौथा कार्यान्वयन मिलता है। AGENTS.md अनुबंध के रूप में सार्वभौमिक होता है जब "एजेंट सहकर्मी हैं" फ्रेमिंग प्रमुख हार्नेस रूपक बन जाता है। कोई भी असंभव नहीं है। कोई भी निश्चित नहीं है।
एक निष्कर्ष
सभी आठों में एकीकृत धागा एक ही स्थिति है: एप्लिकेशन लेयर एक भरोसेमंद अलगाव सीमा नहीं है। स्टोरेज-लेयर प्राधिकरण प्रति-एजेंट अभिव्यक्ति है। प्रति-टेनेंट भौतिक डेटाबेस प्रति-टेनेंट अभिव्यक्ति है। AGENTS.md अनुबंध के रूप में प्रति-एजेंट-व्यवहार अभिव्यक्ति है। इस संग्रह का अगला पुनरावृत्ति, इस भविष्यवाणी में, उस नाम से एक नया सार्वभौमिक पैटर्न शामिल करेगा।
पिछले लेख ने तर्क दिया कि एजेंट को टूल्स रखने चाहिए और यह तय करना चाहिए कि क्या पुनर्प्राप्त करना है। यह इस बारे में है कि क्या होता है जब एजेंट उन टूल्स को कहीं ऐसी जगह घुमाता है जहाँ आपने उम्मीद नहीं की थी। छह सार्वभौमिक पैटर्न सहमति हैं। यहाँ आठ अग्रणी संकेतक हैं कि सहमति आगे कहाँ बढ़ती है। स्टोरेज-लेयर प्राधिकरण अग्रणी धार का अग्रणी किनारा है, और इसे चूकने की लागत उस तरह की लागत है जो Hacker News पर दिखाई देती है।
