क्लॉड कोड 2.1.158, कोडेक्स विंडोज कंट्रोल, रनटाइम इंस्ट्रक्शन्स और लोकल एजेंट मेमोरी

[NOVA]: मैं NOVA हूँ। [ALLOY]: मैं ALLOY हूँ, और यह AgentStack Daily है...

[NOVA]: आज हम पूरे समय एक ही लेन में रहने वाले हैं: कंट्रोल सरफेस। कोई वाइब्स नहीं, कोई "AI बुद्धिमान हो रही है" वाली बात नहीं, बल्कि वो व्यावहारिक लीवर जो तय करते हैं कि एक एजेंट क्या कर सकता है, कहाँ कर सकता है, और जब कोई रन बिगड़ जाए तो आप उसकी निगरानी कैसे कर सकते हैं।

[ALLOY]: शुरू में रिलीज और प्रोडक्ट न्यूज़ सीमित दायरे में है लेकिन ऑपरेशनली अहम है। Claude Code के लेटेस्ट में मैनेज्ड क्लाउड प्रोवाइडर्स पर ऑटो मोड सपोर्ट जुड़ा है—Bedrock, Vertex, और Foundry—जब आप इसे एनवायरनमेंट फ्लैग से स्पष्ट रूप से enable करते हैं। OpenAI का Codex app अपडेट विंडोज कंप्यूटर यूज़ और मोबाइल या Mac से रिमोट सुपरविजन जोड़ता है जबकि विंडोज होस्ट आपकी repo और runtime को local रखता है, साथ ही तेज़ in-app ब्राउज़र व्यवहार और usage और token एक्टिविटी के लिए एक नया Codex Profiles सरफेस।

[NOVA]: फिर हम Anthropic से एक डेवलपर-फेसिंग API बदलाव में आते हैं जो चुपचाप शक्तिशाली है: Messages API अब messages array के अंदर system entries स्वीकार करता है, जिसका मतलब है कि आपका harness बिना यूजर बनकर चलने के और बिना अपने prompt को लगातार बढ़ते हुए blob में बदलने के runtime instructions को mid-run में अपडेट कर सकता है।

[ALLOY]: और प्रोजेक्ट रडार एक ही थीम है चार अलग-अलग नज़रिए से: आर्किटेक्चरल मेमोरी जिसे आप query कर सकते हैं, एजेंट मेमोरी जो बासी अथॉरिटी न बने इसलिए कमज़ोर होती है, local-only कोडिंग एजेंट जो private iteration को सस्ता बनाते हैं, और graph-backed रिपेयर लूप जो fix में evidence को ज़बरदस्ती डालते हैं। चलिए इसमें गहराई से उतरते हैं। ...

[NOVA]: EP060 में जो थ्रू-लाइन है वो यह है कि "एजेंट क्षमता" अब कम और कम एक सिंगल मॉडल चॉइस जैसी दिख रही है और ज़्यादा से ज़्यादा स्पष्ट contracts का स्टैक जैसी।

[ALLOY]: पहला contract है execution location। अगर एजेंट मैनेज्ड क्लाउड प्रोवाइडर एनवायरनमेंट में काम कर रहा है, तो यह identity, logging, data residency, और बाद में मिलने वाले audit trail को बदल देता है। दूसरा contract है host boundaries। अगर एजेंट विंडोज डेस्कटॉप को कंट्रोल कर रहा है, तो आपको यह जानना होगा कि files और shell रिमोट होस्ट पर हैं या किसी दूसरे एनवायरनमेंट में कॉपी किए गए थे। तीसरा contract है instruction ownership। अगर आपका harness mid-run में system contract को अपडेट नहीं कर सकता, तो मॉडल यह अनुमान लगाने लगता है कि क्या बदला।

[NOVA]: और चौथा contract है memory। बहुत सारी टीमें "एजेंट मेमोरी" के बारे में ऐसे बात करती हैं जैसे जवाब यह है कि हर transcript को हमेशा के लिए रखो और फिर से inject करो। व्यवहार में, यह तरीका एक नया failure mode बनाने की ओर tends करता है: बासी guidance को current policy मान लिया जाता है, और बेकार की details उन कुछ facts को ढक देती हैं जो आपको वास्तव में चाहिए थीं।

[ALLOY]: तो आज के सेट का मकसद यह दिखाना है कि stack ज़्यादा स्पष्ट हो रही है। Auto mode एक एनवायरनमेंट फ्लैग के पीछे gated है ताकि इसे जानबूझकर टेस्ट किया जा सके। विंडोज कंप्यूटर यूज़ होस्ट पर local context रखता है जबकि सुपरविजन मोबाइल से होती है। Message arrays के अंदर system entries "user क्या चाहता है" और "runtime अभी क्या allow करता है" को अलग करते हैं। और जो memory tools हम कवर कर रहे हैं वो ज़्यादातर structure और freshness के बारे में हैं raw accumulation के बजाय।

[NOVA]: अगर आपके एजेंट पिछले महीने में fail हुआ है, तो शायद आप हारे इसलिए नहीं कि मॉडल कोड नहीं लिख सका। आप हारे क्योंकि run में सही guardrails नहीं थे, सही evidence नहीं था, या चीज़ों के बदलने पर assumptions अपडेट करने की सही क्षमता नहीं थी।

[ALLOY]: इस फ्रेम के साथ, आइए एपिसोड की शुरुआत में रिलीज और प्रोडक्ट ब्लॉक से शुरू करते हैं। ...

[NOVA]: पहला आइटम: Claude Code के लेटेस्ट वर्जन में Bedrock, Vertex और Foundry पर Opus 4.7 और Opus 4.8 के लिए auto mode सपोर्ट जुड़ा है, लेकिन सिर्फ तब जब आप CLAUDE_CODE_ENABLE_AUTO_MODE=1 सेट करें।

[ALLOY]: इस छोटे से वाक्य में दो अहम डीटेल छिपे हुए हैं। एक यह है कि यह "auto mode अब हर जगह है" नहीं है। यह "auto mode ज़्यादा प्रोवाइडर लेन में मौजूद है, और आपको opt in करना है।" दूसरा यह है कि प्रोवाइडर लेन उतनी ही अहमियत रखती हैं जितनी खुद फीचर, क्योंकि auto mode मूल रूप से एक permission और routing surface है।

[NOVA]: आइए auto mode को व्यावहारिक तौर पर समझते हैं। एक coding agent में कई तरह के एक्शन होते हैं: फाइलें पढ़ना, सर्च करना, टेस्ट रन करना, dependencies इंस्टॉल करना, dev server शुरू करना, कोड एडिट करना, commits पुश करना, PRs खोलना, और भी बहुत कुछ। "Auto mode" वह लेबल है जिसके तहत सिस्टम तय करता है कि कुछ स्टेप्स अपने आप एक्जीक्यूट हो सकते हैं बिना हर स्टेप पर इंसान की तस्दीक के।

[ALLOY]: यह सिर्फ एक सुविधा टॉगल नहीं है। यह agent run की risk profile बदल देता है। अगर आपका agent अपने आप कमांड रन कर सकता है, तो "safety boundary" अब सिर्फ मॉडल नहीं रहता। यह मॉडल behavior, harness policy, tool permissions, sandbox, और उस provider environment का कॉम्बिनेशन है जहां वो tool calls होते हैं।

[NOVA]: और यहीं पर managed cloud lanes अहम भूमिका निभाते हैं। Bedrock, Vertex और Foundry तब common paths हैं जब किसी टीम को cloud-native identity और compliance के साथ model access चाहिए। उन environments में, अक्सर एक बड़ी पसंद होती है कि requests और logs किसी खास cloud boundary के अंदर रहें, organizational credentials से जुड़े हुए, centrally enforce किए जा सकने वाले access policies के साथ।

[ALLOY]: तो auto mode का वहां सपोर्ट होना इसलिए मायने रखता है क्योंकि आप automatic action behavior को production जैसे ही IAM और audit reality के तहत evaluate कर सकते हैं। अगर आप auto mode को सिर्फ local developer workstation flow में टेस्ट करें और फिर managed cloud context में deploy करें, तो आप एक साथ बहुत सारे surrounding systems बदल रहे हैं—identity, networking, logging, और कभी-कभी तो filesystem access patterns भी।

[NOVA]: explicit environment variable gate दूसरा key point है। अगर आप एक team toolchain operate कर रहे हैं, तो आप आमतौर पर नहीं चाहते कि कोई surprise हो जहां अपडेट behavior को "ask before you do stuff" से "do stuff" में बदल दे। Opt-in gating एक intentional activation point बनाती है।

[ALLOY]: वो gating आपको एक clean testing strategy भी देती है। आप same tasks auto mode के साथ और बिना auto mode के रन कर सकते हैं और outcomes compare कर सकते हैं: tool calls की संख्या, destructive actions attempted की संख्या, agent uncertain होने पर properly escalate करता है या नहीं, और "no writes" या "no network" constraints का पालन करता है या नहीं जब वो effect में हों।

[NOVA]: यहां auto mode को test करने का एक concrete तरीका है जिससे आपकी repo experiment न बने। एक छोटी, disposable project या known safe branch चुनें। तीन task categories define करें।

[ALLOY]: श्रेणी एक: केवल पढ़ने वाले कार्य। एजेंट से वास्तुकला सारांश बनाने, एंट्री पॉइंट्स की पहचान करने, इंटीग्रेशन टेस्ट की सूची बनाने और किसी भी स्पष्ट डिपेंडेंसी खतरे को इंगित करने के लिए कहें। ऑटो मोड में, आप चाहते हैं कि यह फाइल रीड्स और सर्च को कुशलतापूर्वक करे बिना अनावश्यक टूल कॉल्स बनाने के।

[NOVA]: श्रेणी दो: सुरक्षित निष्पादन कार्य। इसे टेस्ट सुइट चलाने, डेव सर्वर शुरू करने, या लिंटर चलाने दें—चीजें जो ज्यादातर उलटने योग्य हैं और ज्यादा म्यूटेट नहीं करतीं। यहां आपकी जांच यह है कि एजेंट प्रोजेक्ट और एनवायरनमेंट के लिए उचित कमांड चुनता है या नहीं। उदाहरण के लिए, क्या यह एक रेपो में npm test चलाने की कोशिश करता है जो स्पष्ट रूप से Python का है? क्या यह pnpm-lock देखकर pnpm का उपयोग करता है? क्या यह किसी संकीर्ण बदलाव के लिए न्यूनतम टेस्ट सबसेट चलाता है?

[ALLOY]: श्रेणी तीन: कठोर गार्डरेल के साथ लिखने के कार्य। इसे एक छोटा बदलाव दें, जैसे फंक्शन सिग्नेचर अपडेट करना और कॉल साइट्स अपडेट करना, या एक गायब null check जोड़ना। आपके हार्नेस को अभी भी किसी भी चीज को रोकना चाहिए जिसे आप उच्च जोखिम मानते हैं—जैसे पुश करना, पैकेज पब्लिश करना, सीक्रेट्स फाइल बदलना, या डिप्लॉयमेंट मैनिफेस्ट्स में बदलाव करना—जब तक कि आप स्पष्ट रूप से अनुमति न दें।

[NOVA]: बात यह है कि मापें कि ऑटो मोड उन कार्यों पर घर्षण कम करता है जिन्हें आप तेज करना चाहते हैं, बिना चुपचाप जोखिम बढ़ाए। एनवायरनमेंट वेरिएबल A/B ट्रायल चलाना आसान बनाता है और जब तक आप संतुष्ट न हों तब तक प्रोडक्शन व्यवहार को पिन रखता है।

[ALLOY]: अब बड़ी प्रोडक्ट स्टोरी: OpenAI का 29 मई का Codex ऐप अपडेट। नोट्स में चार व्यावहारिक बदलाव बताए गए हैं जिनका हम उपयोग कर रहे हैं: Windows कंप्यूटर यूज़, मोबाइल या Mac से रिमोट कंट्रोल जबकि Windows होस्ट रहता है, इन-ऐप ब्राउज़र स्पीड और स्थिरता में सुधार, और Codex प्रोफाइल्स जिनमें पहचान, गतिविधि, उपयोग आंकड़े और टोकन गतिविधि शामिल है।

[NOVA]: Windows कंप्यूटर यूज़ से शुरू करें। "कंप्यूटर यूज़" वह श्रेणी है जहां एजेंट डेस्कटॉप UI देख सकता है और उसके साथ इंटरैक्ट कर सकता है: बटन क्लिक करना, फील्ड्स में टाइप करना, विंडोज स्विच करना, और उन ऐप्स को नेविगेट करना जो साफ-सुथरे तरीके से API में लिपटे नहीं हैं।

[ALLOY]: विशेष रूप से Windows पर, यह कई वास्तविक dev वर्कफ़्लो के लिए मायने रखता है। Windows-native ऐप स्टैक, एंटरप्राइज़ इंटरनल टूल्स, और "यह करने का एकमात्र तरीका GUI के माध्यम से क्लिक करना है" काम का एक विशाल भाग है। इंस्टॉलर्स, प्रोप्राइटरी एडमिन कंसोल्स, क्रेडेंशियल मैनेजर्स, और कुछ IDE या डीबगर फ्लो के बारे में सोचें।

[NOVA]: लेकिन किसी भी कंप्यूटर-यूज़ प्रोडक्ट के साथ मुख्य ऑपरेशनल सवाल यह है: निष्पादन कहां होता है, और फाइलें कहां रहती हैं? अपडेट की बाउंड्री स्पष्ट है। आप iOS, Android, या Mac से सुपरवाइज़ कर सकते हैं, लेकिन Windows मशीन प्रोजेक्ट फाइल्स, शेल, ऐप सर्वर और लोकल कॉन्टेक्स्ट के लिए होस्ट बनी रहती है।

[ALLOY]: उस बाउंड्री के कुछ परिणाम हैं जिन्हें बुलाना जरूरी है। पहला, यह डेटा डुप्लिकेशन को कम करता है। एजेंट को चलाने के लिए रेपो को रिमोट एनवायरनमेंट में कॉपी नहीं करना पड़ता। दूसरा, यह "सर्वर चलाओ, ब्राउज़र चेक करो, कोड ट्विक करो, टेस्ट फिर से चलाओ" लूप में विलंबता को कम करता है क्योंकि रनटाइम फाइल्स के करीब स्थानीय है।

[NOVA]: तीसरा, यह ट्रस्ट मॉडल को बदलता है। आपकी सुपरविज़न डिवाइस ज्यादा रिमोट कंट्रोल और मॉनिटरिंग सरफेस जैसी है, वह जगह नहीं जहां काम वास्तव में निष्पादित होता है। यह उपयोगी है क्योंकि इसका मतलब है कि आप डेस्क से दूर जा सकते हैं और फिर भी सेशन को स्टीयर कर सकते हैं, लेकिन आप गलती से पूरे ऑपरेशन को किसी अलग सिक्योरिटी बाउंड्री में नहीं ले जा रहे हैं।

[ALLOY]: समझने योग्य जोखिम यह है कि कंप्यूटर का उपयोग, डिज़ाइन के अनुसार, व्यापक अधिकार देता है। अगर एजेंट क्लिक कर सकता है और टाइप कर सकता है, तो वह संभावित रूप से उस वातावरण में आपके द्वारा किया जा सकने वाला कुछ भी कर सकता है, जिसमें ऐसे कार्य शामिल हैं जिन्हें वापस करना कठिन है। इसलिए अनुशंसित दृष्टिकोण है: इसे किसी कम-जोखिम वाले एप्लिकेशन पर परीक्षण करें, उस पर निर्भर न हों जब तक कि यह महत्वपूर्ण कार्य के लिए तैयार न हो।

[NOVA]: यहाँ कम-जोखिम का मतलब है एक प्रोजेक्ट जिसे रीसेट किया जा सकता है, जो प्रोडक्शन क्रेडेंशियल्स को नहीं छूता, और अगर यह अनपेक्षित कमांड चलाता है तो नुकसान नहीं करेगा। एक अच्छा प्रारंभिक लक्ष्य एक सैंपल वेब ऐप है, एक लोकल-ओनली डेमो सर्विस, या एक रेपो जिसे आप छोड़ सकते हैं।

[ALLOY]: पहला परीक्षण बस विश्वसनीयता का है: क्या यह सामान्य डेवलपर UI स्थितियों के साथ लगातार इंटरैक्ट कर सकता है? जैसे: एक टर्मिनल विंडो जिसे फोकस की जरूरत है, एक UAC प्रॉम्प्ट, एक ब्राउज़र जिसमें कई टैब हैं, एक एडिटर जो पॉप अप करता है "फ़ाइल डिस्क पर बदल गई", एक टेस्ट रनर जिसे फेलियर देखने के लिए स्क्रॉल करना पड़ता है।

[NOVA]: दूसरा परीक्षण सीमित इरादे का है। इसे एक ऐसा कार्य दें जिसकी एक स्पष्ट अंत स्थिति हो, जैसे "टेस्ट चलाएं और मुझे पहले फेल होने वाले टेस्ट का नाम और एरर बताएं।" आप यह देखना चाहते हैं कि एजेंट टास्क पर बना रहता है या साइड पाथ्स में भटक जाता है, जैसे डिपेंडेंसी अपडेट करना या कोड रीफॉर्मेट करना जो अनुरोध नहीं किया गया था।

[ALLOY]: तीसरा परीक्षण रिकवरी का है। जानबूझकर छोटे व्यवधान पैदा करें: डेव सर्वर को मार डालें, नेटवर्क को थोड़े समय के लिए डिस्कनेक्ट करें, कॉन्फिग बदलकर बिल्ड फेलियर पैदा करें, या एक मोडल डायलॉग खोलें। फिर देखें कि एजेंट को पता चलता है कि वह फंस गया है, समस्या की रिपोर्ट करता है, और जब वह किसी सीमा से टकराता है जिसे पार नहीं कर सकता तो मार्गदर्शन माँगता है।

[NOVA]: अब, इन-ऐप ब्राउज़र में सुधार की बात करते हैं। एजेंट वर्कफ़्लो में, ब्राउज़र सिर्फ "बस एक ब्राउज़र" नहीं है। यह अक्सर वेरिफिकेशन सरफेस होता है। यहीं आप पुष्टि करते हैं कि फिक्स वास्तव में काम करती है, जहाँ आप बग को दोबारा बनाते हैं, जहाँ आप नेटवर्क कॉल्स की जाँच करते हैं, और जहाँ आप UI फ्लो को वैलिडेट करते हैं।

[ALLOY]: अगर इन-ऐप ब्राउज़र धीमा या अस्थिर है, तो एजेंट का वेरिफिकेशन लूप खराब हो जाता है। यह ऑटोमेटेड कोडिंग में सबसे खराब फेलियर पैटर्न में से एक की ओर ले जाता है: एजेंट दावा करता है कि फिक्स सही है क्योंकि वह अंतिम स्टेप को विश्वसनीय रूप से नहीं चला पाता जो उसे गलत साबित कर देगा।

[NOVA]: तो "इन-ऐप ब्राउज़र का तेज़ और स्थिर व्यवहार" एक प्रोडक्ट पॉलिश लाइन जैसा लग सकता है, लेकिन यह सीधे प्रभावित करता है कि एजेंट के पूर्णता दावे कितने भरोसेमंद हैं। एक स्थिर ब्राउज़र पाथ का मतलब है कि एजेंट रेपो स्टेप्स को फिर से चला सकता है और वास्तव में परिणाम देख सकता है।

[ALLOY]: अंतिम Codex अपडेट आइटम Codex Profiles है: पहचान, समय के साथ गतिविधि, प्रोफ़ाइल विवरण, उपयोग आँकड़े, और टोकन गतिविधि। यह सबसे सरल अर्थ में एक नियंत्रण सतह है: निरीक्षण योग्यता।

[NOVA]: लंबे चलने वाले सत्रों में, आपको ऐसे सवालों के जवाब देने की जरूरत है: किस प्रोफ़ाइल ने यह टास्क चलाया, उपयोग का फुटप्रिंट क्या था, और टोकन खपत आपकी उम्मीद के अनुसार है? अगर आप डिवाइस पर दूर से काम की निगरानी कर रहे हैं, तो आप पहचान और गतिविधि ट्रेस की भी पुष्टि करना चाहेंगे, खासकर अगर कई लोग एक Windows होस्ट साझा करते हैं।

[ALLOY]: टोकन एक्टिविटी एक एक्सपोज़्ड सरफेस के रूप में डिबगिंग के लिए मायने रखती है। अगर एजेंट रन अचानक ज्यादा खर्चा करने लगा, तो वजह अक्सर "मॉडल खराब हो गया" नहीं होती। यह आमतौर पर कुछ ऐसा होता है: यह बार-बार एक ही बड़ी फाइल्स पढ़ रहा है, यह बहुत ज्यादा हिस्ट्री को फिर से सम्मरीज़ कर रहा है, यह फेलिंग टेस्ट के लूप में फंसा हुआ है, या यह बहुत बड़े आउटपुट वाले टूल्स को कॉल कर रहा है।

[NOVA]: एक प्रोफाइल सरफेस जो यह दिखाता है, "यह महंगा लगता है" और "हम देख सकते हैं कि किस वर्कफ़्लो स्टेप ने टोकन बढ़ाए" के बीच का अंतर है। और एक बार जब आप इसे देख सकते हैं, तो आप इसे ठीक कर सकते हैं: फाइल-साइज़ कैप लगाएं, लॉग ट्रंकेशन जोड़ें, अधिक स्ट्रक्चर्ड मेमोरी रिट्रीवल स्टेप जोड़ें, या वेरिफिकेशन प्लान को टाइट करें।

[ALLOY]: इन दोनों फ्रंट स्टोरीज़ को एक साथ रखें - मैनेज्ड क्लाउड लेन पर Claude Code ऑटो मोड और रिमोट सुपरविज़न के साथ Codex Windows कंप्यूटर यूज़ - और आपको एक सिंगल थीम मिलती है: एजेंट वर्क मैनेजर की एक सिंगल मशीन से कम और एक्सप्लिसिट गवर्नेंस पॉइंट्स से ज्यादा जुड़ता जा रहा है।

[NOVA]: Bedrock, Vertex, और Foundry पर ऑटो मोड एंटरप्राइज़ क्लाउड एनवायरनमेंट में पॉलिसी-बेस्ड ऑटोमेशन लाने के बारे में है। Codex रिमोट सुपरविज़न इस बारे में है कि एक ह्यूमन को कहीं से भी स्टीयर करने दें जबकि एक्ज़ीक्यूशन उसी होस्ट पर लोकल रहे जिसमें रेपो और रनिंग ऐप है।

[ALLOY]: अनुशंसित कदम "सब कुछ ऑन कर दो" नहीं है। दोनों को कंट्रोल्ड एक्सपेरिमेंट्स की तरह ट्रीट करें। ऑटो मोड को एक्सप्लिसिटली गेट करें, इसे सेफ टास्क्स के साथ टेस्ट करें, और व्यवहार मेज़र करें। Windows कंप्यूटर यूज़ को डिस्पोज़ेबल एनवायरनमेंट में ट्राई करें, और तभी तय करें कि आप किस स्कोप की रियल वर्क पर भरोसा करते हैं।

[NOVA]: अगला, हम एक ऐसे बदलाव के बारे में बात करेंगे जो एंड यूज़र्स के लिए कम दिखाई देता है लेकिन हैरनेस बिल्डर्स के लिए बेहद दिखाई देता है: रनटाइम इंस्ट्रक्शन जो सिस्टम एंट्रीज़ के रूप में मिड-रन अपडेट किए जा सकते हैं। ...

[ALLOY]: Anthropic के Opus 4.8 अनाउंसमेंट में एक डेवलपर-फेसिंग बदलाव शामिल था जो तब भी मायने रखता है जब आप कभी मॉडल स्विच न करें: Messages API अब messages array के अंदर सिस्टम एंट्रीज़ स्वीकार करता है।

[NOVA]: यह सबटल लगता है, तो यहां बताते हैं कि यह एजेंट बनाने के तरीके को कैसे बदलता है। ऐतिहासिक रूप से, बहुत सारे हैरनेस "सिस्टम प्रॉम्प्ट" को रन की शुरुआत में एक फिक्स्ड ब्लॉब की तरह ट्रीट करते हैं। फिर बाकी सब - यूज़र मैसेज, टूल आउटपुट, ऑब्ज़र्वेशन - एक सीक्वेंस में अपेंड होते हैं।

[ALLOY]: लेकिन रियल एजेंट रन स्टैटिक नहीं होते। परमिशन बदलती हैं। बजट बदलते हैं। एनवायरनमेंट बदलता है। हैरनेस नए फैक्ट्स सीखता है जिनका मॉडल को पालन करना चाहिए। और अगर आप सिस्टम कॉन्ट्रैक्ट को साफ़ तरीके से अपडेट नहीं कर सकते, तो आप अजीब पैटर्न के साथ समाप्त हो जाते हैं।

[NOVA]: पैटर्न एक अपडेट को यूज़र टर्न के ज़रिए बाध्य कर रहा है। यह ऑडिट ट्रेल को प्रदूषित करता है, क्योंकि इससे ऐसा लगता है कि यूज़र ने पॉलिसी बदलाव के लिए कहा जबकि वास्तव में रनटाइम स्टेट के अनुकूल हो रहा है।

[ALLOY]: पैटर्न दो यह है कि बढ़ते हुए सिस्टम प्रॉम्प्ट में नई पॉलिसी नोट्स भरना और पूरी चीज़ वापस भेजना। इससे कॉस्ट बढ़ता है, कॉन्टेक्स्ट प्रेशर बढ़ता है, और व्यवहार में कैशिंग ऑप्टिमाइज़ेशन टूट सकते हैं क्योंकि "प्रीफिक्स" लगातार बदलता रहता है।

[NOVA]: पैटर्न तीन यह है कि मॉडल से लॉग्स से बदले हुए स्टेट का अनुमान लगाने को कहना। यह तब तक काम करता है जब तक नहीं करता। अगर मॉडल कोई लॉग लाइन मिस कर जाता है, तो वह ऐसे ही चलता रहेगा जैसे कुछ बदला ही नहीं—जैसे उसे अभी भी फाइलें लिखने की परमीशन है, या अभी भी नेटवर्क एक्सेस है, या अभी भी फुल टेस्ट सूट चलाने के लिए ज्यादा बजट है।

[ALLOY]: मैसेज एरे के अंदर सिस्टम एंट्रीज़ हार्नेस को एक ज्यादा सटीक टूल देती हैं: आप एक सिस्टम-रोल मैसेज इंसर्ट या अपेंड कर सकते हैं जो असर में कहता है, "अब कॉन्ट्रैक्ट बदल गया है," बिना यह झूठ बोले कि यूजर ने यह कहा।

[NOVA]: और यह कंसर्न्स का सेपरेशन होने देता है। यूजर लेन इरादों, अप्रूवल्स, और क्लैरिफिकेशन्स का साफ रिकॉर्ड बना सकती है। सिस्टम लेन रनटाइम के कंस्ट्रेंट्स का आधिकारिक स्टेटमेंट बना सकता है: अलाउड टूल्स, एनवायरनमेंट डीटेल्स, बजट, और ऑपरेशनल रूल्स।

[ALLOY]: इसे कंक्रीट बनाते हैं। कल्पना करो एक कoding agent रन जहाँ आप ब्रॉड परमीशन्स से शुरू करते हो। agent को फाइलें पढ़ने, टेस्ट चलाने, और ब्रांच में बदलाव लिखने की अनुमति है। रन के बीच में, हार्नेस पता लगाता है कि वह प्रोटेक्टेड रेपो स्टेट में है—शायद उसने गलती से प्रोडक्शन वर्कट्री खोल लिया, या ब्रांच पॉलिसी बदल गई, या agent अब एक sensitive डायरेक्टरी पर काम कर रहा है।

[NOVA]: editable सिस्टम एंट्रीज़ के साथ, हार्नेस एक नया सिस्टम मैसेज इंजेक्ट कर सकता है: "अब राइट्स डिसेबल हैं। आप सिर्फ diffs प्रपोज़ कर सकते हो और अप्रूवल माँग सकते हो।" यह इससे काफी साफ है कि मॉडल को यूजर मैसेज में बताना या उम्मीद करना कि वह समझ लेगा।

[ALLOY]: एक और कॉमन सीनारियो: टोकन बजट। कुछ हार्नेस एक जॉब या फेज के हिसाब से बजट अलोकेट करते हैं। रन की शुरुआत में, आप एक्सप्लोरेशन की अनुमति दे सकते हो। बाद में, जब agent के पास प्लान हो, तो बजट टाइट कर सकते हो ताकि वह एक्जीक्यूशन पर फोकस करे।

[NOVA]: सिस्टम एंट्रीज़ के साथ, आप इंस्ट्रक्शन अपडेट कर सकते हो: "बचा हुआ बजट अब कम है। मिनिमल फाइल रीड्स को प्रायोरिटाइज़ करो, सिर्फ टारगेटेड टेस्ट चलाओ, और एक्शन से पहले सारांश दो।" कुंजी यह है कि यह रनटाइम स्टेट से बंधा इंस्ट्रक्शन अपडेट है, यूजर प्रेफरेंस नहीं जो टास्क में मिक्स हो सकता है।

[ALLOY]: एनवायरनमेंट कॉन्टेक्स्ट भी एक है। मान लो हार्नेस पता लगाता है कि सैंडबॉक्स फुल डेव कंटेनर से स्विच हो गया किसी रेस्ट्रिक्टेड एनवायरनमेंट में जहाँ कोई नेटवर्क नहीं। या वह पता लगाता है कि डिपेंडेंसी कैश खाली है, तो इंस्टॉल धीमे होंगे। या वह पाता है कि रेपो एक मोनोरेपो टूल इस्तेमाल करता है जिसके लिए एक विशेष कमांड सीक्वेंस जरूरी है।

[NOVA]: आप उन्हें सिस्टम फैक्ट्स के तौर पर इंजेक्ट कर सकते हो। इसका मतलब मॉडल को हर बार उन्हें फिर से डिस्कवर नहीं करना पड़ता, और उसे पार्शियल ऑब्ज़र्वेशन्स के आधार पर अनुमान नहीं लगाना पड़ता।

[ALLOY]: अब, नोट्स के प्रमुख दावों में से एक है प्रॉम्प्ट-कैश प्रिज़र्वेशन। लंबे सेशन में, कैशिंग मायने रखती है क्योंकि दोहराए जाने वाले कॉल का सबसे महंगा हिस्सा अक्सर दोहराया गया "प्रीफिक्स" होता है—स्थिर निर्देश, रेपो ओरिएंटेशन, और हाई-लेवल कॉन्टेक्स्ट।

[NOVA]: अगर आपका हार्नेस पूरे सिस्टम प्रॉम्प्ट को फिर से लिखने के बजाय सिस्टम मैसेज को अलग-अलग एंट्रीज़ के रूप में जोड़ सकता है, तो आप एक बड़े स्थिर प्रीफिक्स को अपरिवर्तित रख सकते हैं। यह कैशिंग स्ट्रैटेजीज़ की प्रभावशीलता में सुधार करता है, और शुरू में सब कुछ एक एकल मेगा-इंस्ट्रक्शन में कंप्रेस करने का दबाव कम करता है।

[ALLOY]: स्पष्ट कैशिंग के बिना भी, यह स्पष्टता में मदद करता है। एक दर्जन ऐतिहासिक अपडेट वाले एक विशाल सिस्टम प्रॉम्प्ट के बजाय, आपके पास सिस्टम मैसेज की एक टाइमलाइन हो सकती है: प्रारंभिक कॉन्ट्रैक्ट, फिर जैसे-जैसे स्थितियां बदलती हैं अपडेट।

[NOVA]: लेकिन यहां एक अनुशासन आवश्यक है। अगर आप सिस्टम एंट्रीज़ का बेमिसाल इस्तेमाल करते हैं, तो आप विरोधाभासी सिस्टम निर्देश बना सकते हैं। उदाहरण के लिए: प्रारंभिक सिस्टम कहता है "आप रेपो में लिख सकते हैं," बाद का सिस्टम कहता है "राइट्स डिसेबल हैं," और फिर बाद में कहता है "/docs के तहत फाइलों के लिए राइट्स की अनुमति है।" अगर आप प्राथमिकता परिभाषित नहीं करते, तो मॉडल एक साथ सभी को संतुष्ट करने की कोशिश कर सकता है।

[ALLOY]: तो हार्नेस को सिस्टम एंट्रीज़ को स्टेट अपडेट की तरह "लेटेस्ट विंस" या स्पष्ट रूप से स्कोप्ड ओवरराइड के साथ व्यवहार करना चाहिए। यह अक्सर मददगार होता है कि सिस्टम एंट्रीज़ को स्ट्रक्चर्ड तरीके से लिखें, भले ही वे अभी भी प्लेन टेक्स्ट हों।

[NOVA]: उदाहरण के लिए, आप सिस्टम मैसेज के अंदर एक छोटा सेक्शन हेडर फॉर्मेट शामिल कर सकते हैं: "अनुमतियां: रीड हां, राइट नहीं, नेटवर्क नहीं।" "बजट: शेष टोकन कम।" "एक्ज़ीक्यूशन: टेस्ट रन की अनुमति, इंस्टॉल्स की अनुमति नहीं।" लक्ष्य यह बनाना है कि मॉडल के लिए वर्तमान स्टेट को मिलाना आसान हो।

[ALLOY]: आप मशीन-जनरेटेड सिस्टम अपडेट को मानव-लिखित सिस्टम पॉलिसी से अलग रखना चाहते हैं। एक अच्छा पैटर्न है: आपकी स्थायी पॉलिसी और सुरक्षा नियमों के लिए एक प्रारंभिक सिस्टम मैसेज, फिर बाद के सिस्टम मैसेज जो विशुद्ध "रनटाइम फैक्ट्स" हैं।

[NOVA]: रनटाइम फैक्ट्स में शामिल हो सकते हैं: वर्तमान ब्रांच का नाम, वर्किंग ट्री साफ है या नहीं, आखिरी बार कौन से टेस्ट चले और उनके परिणाम, एजेंट ने पहले एक फिक्स की कोशिश की थी और वह विफल हुआ, वर्तमान में कौन से टूल्स उपलब्ध हैं, और एनवायरनमेंट सैंडबॉक्स है या नहीं।

[ALLOY]: आखिरी बिंदु—टूल उपलब्धता—एजेंट स्टैक्स में सबसे बड़े दैनिक फेलियर पॉइंट्स में से एक है। एक एजेंट सोचता है कि वह कुछ कर सकता है क्योंकि उसने रन में पहले ऐसा किया था, लेकिन फिर एक टूल रिवोक हो जाता है या अनुमति बदल जाती है, और वह वही कॉल दोबारा करने की कोशिश करता रहता है।

[NOVA]: एक सिस्टम एंट्री अपडेट उस अंतर को तुरंत बंद कर सकता है। अगर हार्नेस नेटवर्क एक्सेस रिवोक करता है, तो यह इंजेक्ट कर सकता है: "नेटवर्क टूल कॉल अब अनुमत नहीं हैं।" फिर मॉडल को curl, डाउनलोड की आवश्यकता वाले पैकेज इंस्टॉल, या रिमोट API कॉल करने की कोशिश करना बंद कर देना चाहिए।

[ALLOY]: एक और सूक्ष्म लाभ है: ऑडिटेबल पृथक्करण। जब आप बाद में किसी रन की समीक्षा करते हैं, तो आप उसे अलग कर सकते हैं जो उपयोगकर्ता ने मांगा था और जो रनटाइम ने थोपा। यह अनुपालन के लिए मायने रखता है, लेकिन डिबगिंग के लिए भी। अगर कोई रन अजीब तरीके से व्यवहार करता है, तो आप देख सकते हैं कि क्या रनटाइम बाधा ने इसे किसी अजीब रास्ते पर मजबूर किया।

[NOVA]: एजेंट संचालन में, यह "मॉडल ने बुरा विकल्प बनाया" और "हार्नेस ने नियम बदले और मॉडल ने माना" के बीच का अंतर है। ये अलग-अलग समस्याएं हैं जिनके अलग-अलग समाधान हैं।

[ALLOY]: हार्नेस बनाने वालों के लिए एक सुझाई गई परीक्षण: मिड-रन परमिशन फ्लिप लागू करें और सत्यापित करें कि मॉडल सही ढंग से प्रतिक्रिया करता है। एक ऐसे रन को शुरू करें जहां राइट की अनुमति हो। मॉडल को प्रस्तावित करने या संपादन शुरू करने दें। फिर एक सिस्टम एंट्री इंजेक्ट करें जो राइट को अक्षम कर दे और इसे जारी रखने के लिए कहें।

[NOVA]: आप कुछ व्यवहारों की तलाश में हैं। एक: क्या यह राइट एक्शन करने की कोशिश करना बंद कर देता है और प्लानिंग या डिफ प्रस्तावों पर स्विच कर जाता है? दो: क्या यह प्रतिबंधों में बदलाव को स्पष्ट रूप से स्वीकार करता है? तीन: क्या यह वैकल्पिक व्यवहार की कोशिश करता है, जैसे फ़ाइल सामग्री को चैट में "सुझाई गई पैच" के रूप में एन्कोड करना टूल्स का उपयोग करने के बजाय?

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

[NOVA]: एक और अनुशंसित परीक्षण: बजट टाइटनिंग। एजेंट को एक्सप्लोरेशन फेज शुरू करने दें, फिर एक सिस्टम एंट्री इंजेक्ट करें जो एक सख्त बजट और प्राथमिकता सूची सेट करती है। फिर देखें कि क्या यह वास्तव में अपने टूल कॉल को संकुचित करता है: कम फाइलें, छोटे डिफ, टारगेटेड टेस्ट।

[ALLOY]: अगर ऐसा नहीं होता, तो यह एक संकेत है कि आपको बजट निर्देश को अधिक ठोस बनाने की जरूरत है। मॉडल तभी ऑपरेशनल बाधाओं पर बेहतर प्रतिक्रिया देते हैं जब आप बताते हैं कि क्या करना है। उदाहरण के लिए: "केवल वे फाइलें पढ़ें जिन्हें आपने पहले ही संदर्भित किया है। केवल वह एक फेलिंग टेस्ट चलाएं जो फेल हो रहा है। संपादन करने से पहले पांच बुलेट में बदलावों का सारांश दें।"

[NOVA]: इसे पहले की रिलीज स्टोरी से जोड़ें। Claude Code ऑटो मोड और Codex रिमोट सुपरविजन दोनों एक्जीक्यूशन सरफेस को अधिक सक्षम बनाने के बारे में हैं। जैसे-जैसे आप उस सरफेस को चौड़ा करते हैं, मिड-रन रनटाइम बाधाओं को अपडेट करने की क्षमता अनिवार्य हो जाती है। अन्यथा आप एक शक्तिशाली एजेंट को एक भंगुर अनुबंध के साथ चला रहे हैं।

[ALLOY]: अगले, हम प्रोजेक्ट रडार पर जाएंगे, दो पूरक मेमोरी टूल्स के साथ शुरू करते हुए: आर्किटेक्चरल ओरिएंटेशन के लिए OpenLore, और क्षय के साथ पर्सिस्टेंट मेमोरी के लिए Mnemo। ...

[NOVA]: प्रोजेक्ट रडार आइटम एक है OpenLore। इसे सबसे सरल तरीके से वर्णित करें तो: कोडिंग एजेंट्स के लिए एक लोकल आर्किटेक्चरल मेमोरी लेयर जो MCP के माध्यम से क्वेरी करने योग्य हो जाती है।

[ALLOY]: मुख्य सिद्धांत यह है कि एजेंट प्रोजेक्ट की संरचना को फिर से खोजने में कॉन्टेक्स्ट बर्बाद करते हैं। यहां तक कि मजबूत कोडिंग एजेंट भी अक्सर एक सत्र की शुरुआत डायरेक्टरी ट्री पढ़कर, README फाइलों को स्कैन करके, एंट्री पॉइंट्स खोजकर, फंक्शन नेम्स को grep करके, और शुरू से ही एक मानसिक मैप बनाकर करते हैं।

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

[ALLOY]: OpenLore इस समस्या को कोडबेस को स्ट्रक्चर्ड आर्टिफैक्ट्स में इंडेक्स करके हल करता है: स्टैटिक एनालिसिस आउटपुट, कॉल ग्राफ, आर्किटेक्चरल क्लस्टर, "लिविंग स्पेक्स," और ड्रिफ्ट डिटेक्शन। फिर यह MCP टूल्स एक्सपोज़ करता है जैसे ओरिएंटेशन और ग्राफ एक्सपैंशन ताकि एजेंट पहले एक कॉम्पैक्ट डाइजेस्ट मांग सके, और जो जरूरत हो उसी को एक्सपैंड कर सके।

[NOVA]: आइए समझते हैं कि कॉल ग्राफ और क्लस्टर क्यों मायने रखते हैं। कॉल ग्राफ यह मैप है कि कौन से फंक्शन या मॉड्यूल दूसरों को कॉल करते हैं। जब एजेंट को "चेकआउट टोटल्स में बग फिक्स करो" का टास्क दिया जाता है, तो सिर्फ checkout.ts नाम की फाइल ढूंढना काफी नहीं है। आपको यह जानना होगा कि टोटल्स कहां कम्प्यूट होते हैं, कौन उस रिज़ल्ट का उपभोग करता है, और कौन से पाथ कौन से फ्लोज़ द्वारा एक्सरसाइज़ किए जाते हैं।

[ALLOY]: अगर आपके पास कॉल ग्राफ है, तो आप जैसे सवाल पूछ सकते हैं: "इस फंक्शन के अपस्ट्रीम कॉलर्स कौन हैं?" और "अगर मैं इस रिटर्न टाइप को बदलूं तो डाउनस्ट्रीम इफेक्ट्स क्या होंगे?" यही वह तरह का सवाल है जो accidental breakage को कम करता है।

[NOVA]: आर्किटेक्चरल क्लस्टर एक उच्च-स्तरीय अवधारणा है: फाइलों या मॉड्यूल्स को सबसिस्टम्स में समूहित करना। कई रेपोज़ नैओ सर्च के लिए फ्लैट दिखते हैं। आपके पास बीस डायरेक्टरीज़ हो सकती हैं जिनमें सभी "सर्विस" कोड हो, लेकिन केवल कुछ ही टास्क से संबंधित हैं। क्लस्टरिंग एजेंट को रेपो की अप्रासंगिक जगहों को एक्सप्लोर करने से बचने में मदद करती है।

[ALLOY]: "लिविंग स्पेक्स" एजेंट वर्कफ़्लोज़ के लिए विशेष रूप से उपयोगी हैं क्योंकि कोड बदलता है, लेकिन कोड के पीछे का इरादा हमेशा कोड कमेंट्स में नहीं रहता। एक लिविंग स्पेक एक मेंटेन्ड सारांश है कि एक सबसिस्टम कैसे व्यवहार करना चाहिए, जो अक्सर स्टैटिक एनालिसिस प्लस क्यूरेटेड डॉक्यूमेंटेशन से प्राप्त होता है।

[NOVA]: ड्रिफ्ट डिटेक्शन एक गार्डरेल है। अगर स्पेक कुछ कहता है और कोड ड्रिफ्ट हो गया है, तो OpenLore यह फ्लैग कर सकता है। एजेंट के लिए, ड्रिफ्ट डिटेक्शन धीमे होने का संकेत है। इसका मतलब है कि रेपो में असंगत व्यवहार या अधूरे माइग्रेशन हो सकते हैं।

[ALLOY]: MCP लेयर इसे एजेंट स्टैक के लिए तुरंत प्रासंगिक बनाती है। MCP वह इंटरफ़ेस है जिसका उपयोग एजेंट टूल्स कॉल करने के लिए करते हैं। अगर OpenLore "ओरिएंटेशन" और "एक्सपैंड ग्राफ" जैसे MCP टूल्स प्रदान करता है, तो कोई भी एजेंट जो MCP बोल सकता है—Claude Code, Codex in MCP-friendly harnesses, Hermes, OpenClaw-connected sessions—आर्किटेक्चरल मेमोरी को बिना आधा रेपो फिर से पढ़े खींच सकता है।

[NOVA]: टोकन डिसिप्लिन एंगल वह जगह है जहां यह एक व्यावहारिक लाभ बन जाता है। हर बार एक विशाल रेपो सारांश इंजेक्ट करने के बजाय, आप एक छोटा ओरिएंटेशन ब्लॉब पुनर्प्राप्त कर सकते हैं: "यहां टॉप-लेवल सर्विसेज़, मुख्य एंट्री पॉइंट्स, वर्तमान टास्क के लिए प्रमुख कॉल पाथ्स, और संभावित टेस्ट टारगेट्स हैं।" फिर आप एजेंट को विशिष्ट नोड्स को एक्सपैंड करने के लिए कहने दें।

[ALLOY]: वो "सिर्फ जो मायने रखता है उसे बढ़ाओ" वर्कफ़्लो एक उपयोगी मेमोरी लेयर और कॉन्टेक्स्ट बम के बीच का अंतर है। अगर मेमोरी रिट्रीवल हमेशा टेक्स्ट की एक भारी दीवार लौटाती है, तो एजेंट या तो उसकी अनदेखी करेगा या उसमें डूब जाएगा। ग्राफ एक्सपैंशन एक कंट्रोल नॉब है।

[NOVA]: OpenLore के लिए एक रिकमेंडेड इवैल्यूशन वर्कफ़्लो है जिसके लिए शुरू में डीप इंटीग्रेशन की ज़रूरत नहीं है। एक ऐसा रेपो चुनें जहाँ एजेंट बार-बार एक ही ओरिएंटेशन गलतियाँ करते हैं। आम उदाहरण: मल्टीपल ऐप्स वाले मोनोरिपो, पुराने और नए दोनों इंप्लीमेंटेशन वाले रेपो, या एनवायरनमेंट के हिसाब से मल्टीपल एंट्री पॉइंट वाले सिस्टम।

[ALLOY]: पहला स्टेप: OpenLore इंडेक्सिंग चलाओ और ओरिएंटेशन टूल से आर्किटेक्चरल डाइजेस्ट बनाओ। दूसरा स्टेप: बिना OpenLore के एक कोडिंग एजेंट सेशन चलाओ और उससे एक बदलाव की प्लानिंग करने को कहो। तीसरा स्टेप: वही प्लानिंग सेशन चलाओ लेकिन पहले OpenLore का ओरिएंटेशन आउटपुट दो।

[NOVA]: प्लान्स की तुलना करो। खासतौर पर: क्या OpenLore-असिस्टेड प्लान अलग फ़ाइलें चुनती है? क्या यह सही एंट्री पॉइंट्स तेज़ी से पहचानती है? क्या यह ऐसे टेस्ट प्रपोज़ करती है जो असल में जुड़े हुए कोड पाथ्स से जुड़े हैं?

[ALLOY]: "फर्स्ट एरर" रेट की भी तुलना करो। कई एजेंट रन में पहली गलती गलत स्टार्टिंग पॉइंट चुनना है। अगर OpenLore उसे कम करती है, तो ये पहले से ही अपना खर्चा वसूल कर रही है।

[NOVA]: अब प्रोजेक्ट रडार आइटम दो: Mnemo। ये एजेंट मेमोरी को एक decaying लोकल नॉलेज ग्राफ की तरह ट्रीट करती है।

[ALLOY]: Mnemo की पोज़िशनिंग है "persistent engineering cognition," जो एक उपयोगी फ्रेज़ है क्योंकि ये सिर्फ फैक्ट्स स्टोर करने से आगे जाता है। इंजीनियरिंग कॉग्निशन में शामिल हैं निर्णय, कन्वेंशन, ज्ञात फेलियर मोड्स, और तरह-तरह का "हमने वो करने की कोशिश की थी और टूट गया" इंस्टीट्यूशनल नॉलेज जो शायद ही कभी कोड में रहता है।

[NOVA]: यहाँ मुख्य ऑपरेशनल फीचर मेमोरी डिके है। एजेंट सिस्टम में, बासी मेमोरी खतरनाक है क्योंकि इसमें ऑथोरिटी का टोन होता है। अगर आप किसी पुराने निर्णय को नए रन में इंजेक्ट करते हैं, तो मॉडल उसे करंट पॉलिसी की तरह ट्रीट कर सकता है भले ही प्रोजेक्ट आगे बढ़ चुका हो।

[ALLOY]: डिके मैकेनिज्म एक तरीका है पुराने कॉन्टेक्स्ट को डिमोट करने का जब तक कि उसे रीइनफोर्स न किया जाए। ह्यूमन टीमों में, मेमोरी नैचुरली डिके होती है क्योंकि लोग पुरानी चीज़ों के बारे में बात करना बंद कर देते हैं। एजेंट मेमोरी स्टोर में, सब कुछ इक्वली रिट्रीवल होता है जब तक कि आप recency और reinforcement बिल्ड इन नहीं करते।

[NOVA]: Mnemo हाइब्रिड रिट्रीवल पर भी ज़ोर देती है: BM25 प्लस वेक्टर प्लस ग्राफ सर्च। वो कॉम्बिनेशन मायने रखता है क्योंकि "आपको क्या चाहिए" क्वेरी टाइप पर निर्भर करता है।

[ALLOY]: BM25 exact term matching के लिए मजबूत है—file names, error messages, specific library names, internal project terms। Vector retrieval semantic similarity के लिए बेहतर है—related decisions को ढूंढना, भले ही wording अलग हो। Graph retrieval structure जोड़ता है—edges को follow करना जैसे "decision relates to subsystem," "convention applies to module," या "failure mode is triggered by dependency।"

[NOVA]: Practical advantage यह है कि memory को flat list of notes होने की जरूरत नहीं है। अगर your memory एक graph है, तो आप ऐसे सवालों के जवाब दे सकते हैं: "What conventions apply to this folder?" या "What prior incidents relate to this error?" या "Which decisions were made about auth flows in this service?"

[ALLOY]: Lifecycle hooks एक और important concept है। Agent harness में, आप decide कर सकते हैं कि memories कब written या reinforced हों। For example: जब एक PR merges, तो आप that decision को describe करने वाली memory को reinforce कर सकते हैं। जब कोई test बार-बार fail होता है, तो आप failure mode और उसके fix को describe करने वाली एक memory entry create कर सकते हैं। जब release होता है, तो आप certain old memories को faster decay कर सकते हैं क्योंकि वे previous version से related हैं।

[NOVA]: Local-first storage यहां operational baseline है। अगर memory store local है, तो आप sensitive project cognition को machine पर या अपने controlled environment के अंदर रख सकते हैं, बजाय इसके कि इसे remote hosted memory service को भेजें।

[ALLOY]: यहां Mnemo के साथ शुरू करने का recommended way है, बिना इसे जल्दबाजी में too much authority दिए। Four kinds की memory items capture करके शुरू करें।

[NOVA]: एक: एक project decision। Something like "we do not use database triggers; all integrity rules live in the service layer।" दो: एक convention। Example: "All new endpoints must include request IDs and structured logging fields।" तीन: एक active task context। Example: "We're migrating from library X to library Y; prefer Y for new code।" चार: एक known failure mode। Example: "This integration test fails if timezone is not set to UTC।"

[ALLOY]: फिर एक second session शुरू करें और query करें कि Mnemo क्या recall करता है। इसे उसी तरह inspect करें जैसे आप compiler या linter से output inspect करते हैं। आप accuracy, relevance, और यह check कर रहे हैं कि decay या ranking reasonable लगती है या नहीं।

[NOVA]: Danger sign यह है जब memory retrieval stale items को fresh ones जैसे same weight के साथ return करती है। अगर your memory store freshness express नहीं कर सकती, तो आप eventually इसे untrusted मानेंगे और इसका use करना बंद कर देंगे।

[ALLOY]: एक और danger sign यह है जब memory "policy injection" channel बन जाती है। Your harness को memory को advisory context के रूप में रखना चाहिए जब तक कि memory item explicitly policy के रूप में tagged न हो। Otherwise model हर retrieved note को एक rule मान सकता है, भले ही वह just एक temporary workaround था।

[NOVA]: OpenLore और Mnemo को एक साथ रखें और आपको "agent memory" से ज्यादा robust story मिलती है। OpenLore codebase की shape याद रखता है—structure, call paths, clusters, specs। Mnemo project's evolving knowledge याद रखता है—decisions, conventions, failures—time sensitivity के साथ।

[ALLOY]: ये दोनों ट्रांसक्रिप्ट स्टफिंग से ज्यादा नियंत्रणीय हैं। ट्रांसक्रिप्ट अस्तव्यस्त होती हैं, अटकलों से भरी, और अक्सर पुरानी धारणाएं होती हैं। स्ट्रक्चर्ड मेमोरी टूल्स का लक्ष्य छोटा, अधिक प्रासंगिक कॉन्टेक्स्ट पुनः प्राप्त करना और आपको लीवर देना है—ग्राफ एक्सपैंशन, डिके, हाइब्रिड रैंकिंग—जिन्हें आप ट्यून कर सकते हैं।

[NOVA]: अगला, हम रडार के लोकल-ओनली और ग्राफ-रिपेयर पक्ष में जाएंगे: OpenMonoAgent और Prometheus। ...

[ALLOY]: तीसरा प्रोजेक्ट रडार आइटम: OpenMonoAgent। यह एक .NET-आधारित लोकल कोडिंग एजेंट है जो llama.cpp के जरिए लोकल इन्फरेंस, Docker सैंडबॉक्सिंग, LSP और Roslyn कोड इंटेलिजेंस, MCP इंटीग्रेशन, और प्लेबुक के इर्दगिर्द बना है।

[NOVA]: जिस वाक्यांश पर ध्यान देना है वह है "ज़ीरो-मीटर लोकल कोडिंग-एजेंट पैटर्न।" इसलिए नहीं कि इसका मतलब है कि आप क्लाउड मॉडल कभी नहीं उपयोग करते, बल्कि इसलिए कि यह आपको एक बेसलाइन देता है जहां कोड पढ़ना और मैकेनिकल एडिट्स करने की कोशिश करना सस्ता, प्राइवेट और दोहरावदार है।

[ALLOY]: चलिए llama.cpp के जरिए लोकल इन्फरेंस से शुरू करते हैं। इसका मतलब है कि मॉडल आपकी मशीन पर चलता है, CPU और वैकल्पिक रूप से GPU का उपयोग करके, बिना डिफ़ॉल्ट रूप से प्रॉम्प्ट या कोड को होस्टेड API पर भेजे। स्पष्ट बेनिफिट्स हैं प्राइवेसी और कॉस्ट कंट्रोल।

[NOVA]: लेकिन ऑपरेशनल बेनिफिट एक अलग आयाम में इटरेशन स्पीड है: आप कई छोटे एक्सपेरिमेंट्स चलाने का खर्च उठा सकते हैं। अगर आप एक एजेंट से पांच वेरिएंट्स का प्रपोज़ल मांगना चाहते हैं, या बार-बार रेपो स्ट्रक्चर का एनालिसिस करना चाहते हैं, तो लोकल इन्फरेंस उसे "बोरिंग और सस्ता" बना सकता है "महंगा और मीटर वाला" के बजाय।

[ALLOY]: Docker सैंडबॉक्सिंग अगला टुकड़ा है। एक बार जब एजेंट कमांड्स चला सकता है, तो आपको यह तय करना होता है कि वह किस एनवायरनमेंट में चलता है। एक Docker सैंडबॉक्स फाइलसिस्टम एक्सेस, नेटवर्क एक्सेस, और गलतियों की ब्लास्ट रेडियस को सीमित कर सकता है। भले ही आप एजेंट पर भरोसा करते हैं, आपको हर डिपेंडेंसी इंस्टॉल स्क्रिप्ट या बिल्ड स्टेप पर भरोसा नहीं करना होता जो वह शायद इनवोक करे।

[NOVA]: LSP और Roslyn कोड इंटेलिजेंस वह जगह है जहां यह "टर्मिनल वाले चैटबॉट" से ज्यादा बन जाता है। LSP लैंग्वेज-अवेयर ऑपरेशंस देता है: डेफिनिशन पर जाएं, रेफरेंस खोजें, सिंबल सर्च, डायग्नोस्टिक्स। Roslyn .NET कंपाइलर प्लेटफॉर्म है जो C# और संबंधित भाषाओं के लिए गहरी सेमांटिक समझ प्रदान कर सकता है।

[ALLOY]: जब आप LSP/Roslyn को एजेंट लूप के साथ मिलाते हैं, तो आपको बेहतर टारगेटेड एडिट्स मिलते हैं। बिना सोचे समझे grep किए, एजेंट पूछ सकता है: "इस सिंबल के रेफरेंस कहां हैं?" और फिर सिस्टमेटिकली कॉल साइट्स को अपडेट कर सकता है। यही वह तरह का बदलाव है जो लोकल एजेंट्स अच्छे से कर सकते हैं भले ही उनकी रीजनिंग फ्रंटियर मॉडल्स से कमजोर हो।

[NOVA]: MCP इंटीग्रेशन इसलिए मायने रखता है क्योंकि इसका मतलब है कि OpenMonoAgent एक ब्रॉडर टूल इकोसिस्टम में भाग ले सकता है। आप इसे उनही ओरिएंटेशन टूल्स, मेमोरी टूल्स, या आंतरिक सेवाओं से कनेक्ट कर सकते हैं जिन्हें आप MCP के जरिए एक्सपोज़ करते हैं, बिना एजेंट में हार्डकोडिंग इंटीग्रेशन किए।

[ALLOY]: और प्लेबुक "वर्कफ़्लो कैप्चर" मैकेनिज़्म हैं। एक प्लेबुक सामान्य कार्यों के चरणों को एन्कोड कर सकता है: टेस्ट चलाना, फ़ेल हो रही फ़ाइलें ढूंढना, एक स्टैंडर्ड रिफैक्टर पैटर्न लागू करना, कोड पुनः जनरेट करना, डॉक्स अपडेट करना, और ऐसा ही। लोकल एजेंट कॉन्टेक्स्ट में, प्लेबुक रूटीन ऑपरेशन्स के लिए आवश्यक रीज़निंग की मात्रा कम करने में मदद करते हैं।

[NOVA]: अब, ट्रेडऑफ़। फ्रंटियर होस्टेड मॉडल्स की तुलना में लोकल मॉडल अक्सर गहरी रीज़निंग, लॉन्ग-होराइज़न प्लानिंग, और जटिल क्रॉस-फ़ाइल सिंथेसिस में पिछड़ जाते हैं। इसका मतलब यह नहीं कि वे बेकार हैं। इसका मतलब यह है कि आपको उन्हें ऐसे टास्क पर निशाना लगाना चाहिए जहाँ लोकल कॉन्स्ट्रेंट्स हावी हों और रीज़निंग लोड मध्यम हो।

[ALLOY]: लोकल-एजेंट के लिए अच्छे टारगेट में शामिल हैं: रिपॉजिटरी ओरिएंटेशन, मैकेनिकल रिफैक्टर्स, कोड फॉर्मेटिंग और लिंट फिक्सेस, नेमस्पेस या इम्पोर्ट्स अपडेट करना, बॉयलरप्लेट जनरेट करना, स्पष्ट स्पेस से टेस्ट लिखना, और कमिट्स के बीच क्या बदला उसके स्ट्रक्चर्ड सारांश बनाना।

[NOVA]: लोकल मॉडल्स के लिए जोखिम भरे टारगेट में शामिल हैं: सबटल सिक्योरिटी रिव्यू, लार्ज-स्केल आर्किटेक्चरल रीडिज़ाइन, ट्रिकी कन्करेंंसी बग्स, या कोई भी ऐसी चीज़ जहाँ एजेंट को अस्पष्ट सिग्नल से प्रोडक्ट इंटेंट इनफर करना हो। वे वो जॉब्स हैं जहाँ आप अक्सर एक स्ट्रॉंगर होस्टेड मॉडल चाहते हैं—या एक वर्कफ़्लो जो एविडेंस के लिए लोकल टूल्स और रीज़निंग के लिए होस्टेड मॉडल्स का उपयोग करता है।

[ALLOY]: यह एक प्रैक्टिकल हाइब्रिड वर्कफ़्लो सुझाता है। ए-evidence इकट्ठा करने के लिए एक लोकल एजेंट का उपयोग करें: फ़ाइलें मैप करें, कॉल पैथ्स एक्सट्रैक्ट करें, टेस्ट चलाएं, फेलिंग केसेस पहचानें, और कैंडिडेट एडिट लोकेशन प्रपोज़ करें। फिर, जरूरत पड़ने पर, उस एविडेंस को एक स्ट्रॉंगर मॉडल को पैच स्ट्रैटेजी तय करने के लिए सौंप दें।

[NOVA]: या इसे उलट दें: स्ट्रॉंग मॉडल का उपयोग प्लान प्रपोज़ करने के लिए करें, लेकिन मैकेनिकल स्टेप्स एक्ज़ीक्यूट करने का काम लोकल एजेंट को दें—डिफ लागू करें, रेफरेंस अपडेट करें, टेस्ट चलाएं—एक सैंडबॉक्स के अंदर जहाँ डेटा मशीन से बाहर नहीं जाता।

[ALLOY]: OpenMonoAgent के लिए एक रिकमेंडेड टेस्ट: इसे एक डिस्पोज़ेबल रेपो के खिलाफ बिना किसी क्लाउड प्रोवाइडर कॉन्फ़िगर किए चलाएं। इसे एक रूटीन लेकिन नॉन-ट्रिवियल टास्क करने के लिए कहें, जैसे "एक पब्लिक मेथड का नाम बदलें और सभी कॉल साइट्स अपडेट करें," फिर "यूनिट टेस्ट चलाएं" और "बताएं कि क्या बदला।"

[NOVA]: कुछ चीज़ें मेज़र करें। क्या इसने रेफरेंस खोजने के लिए सही तरीके से कोड इंटेलिजेंस का उपयोग किया? क्या इसने जनरेटेड फ़ाइल्स एडिट करने से बचा? क्या डिफ मिनिमल रही? क्या सही टेस्ट कमांड्स चलाए? क्या कुछ फेल होने पर रुका और रिपोर्ट किया?

[ALLOY]: वे मेज़रमेंट बताते हैं कि यह आपके स्टैक में कहाँ फिट बैठता है। अगर मैकेनिकल एडिट्स और वेरिफिकेशन लूप्स में यह स्ट्रॉंग है, तो यह लो-रिस्क वर्क के लिए आपका डिफ़ॉल्ट बन सकता है, सच में मुश्किल हिस्सों के लिए क्लाउड कॉल्स बचाकर।

[NOVA]: अब, चौथा प्रोजेक्ट रडार आइटम: EuniAI से Prometheus। इसे नॉलेज-ग्राफ़-ड्रिवन सॉफ्टवेयर एजेंट के रूप में प्रस्तुत किया गया है जो जटिल कोडबेस को मैप, समझ और रिपेयर करने के लिए है।

[ALLOY]: कुंजी वाक्यांश है "chat-driven edits की जगह graph-driven repair।" आज कई coding agents ऐसे काम करते हैं: कुछ files पढ़ते हैं, एक hypothesis बनाते हैं, एक patch लिखते हैं, tests चलाते हैं, दोहराते हैं। कमजोर बिंदु यह है कि hypothesis underconstrained हो सकती है। Agent एक patch पर कूद सकता है क्योंकि यह संभावित लगता है, न कि इसलिए कि उसके पास यह साक्ष्य है कि कोड वास्तव में कैसे जुड़ा हुआ है।

[NOVA]: Graph context इसे constrain कर सकता है। अगर agent entities का एक graph बनाता है—modules, classes, functions, dependencies, call edges—तो वह इस graph का उपयोग यह तय करने के लिए कर सकता है कि fix कहां होना चाहिए और यह क्या तोड़ सकता है।

[ALLOY]: एक bug report के बारे में सोचें: "लॉगिन कभी-कभी null reference error के साथ विफल हो जाता है।" एक chat-driven agent "null" और "login" खोज सकता है और पहली चीज़ को patch कर सकता है जो वह देखता है। एक graph-driven agent login flow को map कर सकता है: UI handler → auth service → token parser → user loader → database adapter। फिर यह specific edge खोज सकता है जहां null पेश किया जा सकता है और उस path का अनुसरण कर सकता है।

[NOVA]: Verification loop का हिस्सा critical है। "Repair" सिर्फ patch generation नहीं है; यह right evidence चुनना भी है जो patch को validate करे। एक graph tests चुनने में मदद कर सकता है। अगर graph दिखाता है कि एक function केवल दो integration tests द्वारा exercised है, तो उन tests को verification plan में होना चाहिए।

[ALLOY]: यह failure recovery में भी मदद कर सकता है। अगर एक patch tests में विफल होती है, तो agent likely blast radius की पहचान करने के लिए graph का उपयोग कर सकता है। क्या उसने एक shared interface बदला जिसका उपयोग कई nodes द्वारा किया जाता है? क्या उसने एक serialization format बदला? क्या उसने एक low-level utility को छुआ जो कई call sites पर फैला हुआ है?

[NOVA]: व्यवहार में, आप एक graph-driven repair project का मूल्यांकन यह पूछकर करते हैं: क्या graph agent के निर्णयों को मूल रूप से बदलता है? या यह सिर्फ एक fancy index है जिसे agent नजरअंदाज करता है?

[ALLOY]: एक उपयोगी मूल्यांकन दृष्टिकोण एक benchmark-style task पर या एक disposable repo पर Prometheus चलाना है जहां आप व्यवहार का निरीक्षण कर सकते हैं। फिर दो artifacts की तुलना करें: graph evidence और final patch। आप direct linkage खोज रहे हैं।

[NOVA]: उदाहरण के लिए, अगर patch एक function बदलता है, तो क्या graph दिखाता है कि वह function सही choke point क्यों है? अगर यह call sites को update करता है, तो क्या graph उन्हें comprehensively enumerate करता है? अगर यह tests चुनता है, तो क्या graph affected nodes के coverage के आधार पर चयन को justify करता है?

[ALLOY]: एक और test यह है कि intentionally misleading signal पेश करें। एक file name रखें जो relevant दिखती है लेकिन नहीं है, या एक outdated comment छोड़ दें। Chat-driven agents अक्सर इनके द्वारा bait हो जाते हैं। Graph-driven systems अधिक resilient होने चाहिए क्योंकि वे surface text के बजाय actual code relationships पर निर्भर करते हैं।

[NOVA]: Prometheus, OpenLore, और Mnemo भी conceptually जुड़े हुए हैं। OpenLore orientation के लिए architectural graphs प्रदान करता है। Mnemo decay के साथ project cognition के लिए एक knowledge graph प्रदान करता है। Prometheus repair और verification को drive करने के लिए graphs का उपयोग करता है। Stack-level विचार यह है कि graphs agents के लिए एक grounding layer के रूप में काम कर सकते हैं—structure जो free-form narrative की तुलना में hallucinate करना कठिन है।

[ALLOY]: और यह मायने रखता है क्योंकि coding agents के लिए अगला कदम सिर्फ बड़े models नहीं है। यह loop को साबित करना है कि उसने क्या समझा: relevant edges दिखाओ, evidence दिखाओ, सही tests चलाओ, और बताओ कि बदलाव क्यों सुरक्षित है।

[NOVA]: अब हम एक व्यावहारिक "what to try next" queue के साथ बंद करेंगे जो आज के control-surface theme से मेल खाता है। ...

[ALLOY]: यह EP060 से व्यावहारिक queue है, उस क्रम में जो risk को कम करता है।

[NOVA]: पहला: managed clouds पर Claude Code का latest auto mode। इसे एक feature flag की तरह treat करो क्योंकि यह एक feature flag है। इसे सिर्फ CLAUDE_CODE_ENABLE_AUTO_MODE=1 के साथ enable करो, और उस provider lane से शुरू करो जिसका तुम वास्तव में उपयोग करने की योजना बना रहे हो—Bedrock, Vertex, या Foundry—ताकि तुम्हारे tests तुम्हारे real identity और logging environment को reflect करें।

[ALLOY]: तीन task types चलाओ: read-only orientation, safe execution जैसे tests और lint, और strict guardrails के साथ एक छोटा write task। tool-call behavior को measure करो, बिना पूछे कितनी बार यह आगे बढ़ता है, और जब uncertain हो तो क्या यह appropriately escalate करता है।

[NOVA]: दूसरा: Codex Windows computer use। एक low-risk app से शुरू करो और explicitly test करो reliability, bounded intent, और recovery। Reliability है "क्या यह UI को operate कर सकता है बिना फंसे।" Bounded intent है "क्या यह तुम्हारे दिए गए task पर बना रहता है।" Recovery है "क्या यह blockers को recognize करता है और flailing करने के बजाय guidance के लिए पूछता है।"

[ALLOY]: अगर तुम mobile या Mac से supervise करने की योजना बना रहे हो, तो remote-control boundary को explicitly test करो। Windows host पर एक run शुरू करो, चले जाओ, एक अलग device से connect करो, और confirm करो कि तुम meaningfully steer कर सकते हो: questions का जवाब देना, steps को approve करना, और progress को check करना। लक्ष्य यह validate करना है कि execution local रहता है जबकि supervision practical रहता है।

[NOVA]: Codex Profiles को operational evidence की तरह भी treat करो। Confirm करो कि identity वही है जो तुम expect करते हो, और usage और token activity को watch करो एक run पर जहाँ तुम्हें roughly पता है कि क्या होना चाहिए। अगर token usage spikes है, तो उसे debugging prompt की तरह use करो: repeated file reads, log verbosity, tool loops, या poor test targeting।

[ALLOY]: तीसरा: अगर तुम एक agent harness build या maintain करते हो, तो Messages API change को study करो: messages array के अंदर system entries। इसका use करो user intent को runtime policy और runtime facts से separate करने के लिए। कम से कम एक mid-run system update implement करो—permission change या budget change—और verify करो कि model अपने behavior को change करके respond करता है, सिर्फ text को acknowledge करके नहीं।

[NOVA]: system updates को structured रखो और contradictory instruction timelines से बचो। runtime facts के लिए "latest state summary" messages को prefer करो एक long chain of partial updates के बजाय जिसे model को reconcile करना पड़ता है।

[ALLOY]: चौथा: सिर्फ एक मेमोरी एक्सपेरिमेंट चुनें ताकि आप इसे ईमानदारी से evaluate कर सकें।

[NOVA]: अपने दर्द का इलाज OpenLore से करें अगर वो architectural rediscovery का है—agents बार-बार गलत entry points चुन रहे हों, key call paths miss कर रहे हों, या same directories पढ़ने में context जला रहे हों। writes allow करने से पहले OpenLore के orientation output के साथ और बिना edit plan compare करें।

[ALLOY]: अपने दर्द का इलाज Mnemo से करें अगर वो lost project knowledge का है—वो decisions, conventions, और known failure modes जो sessions के बीच carry होने चाहिए। एक छोटे से memories set से शुरू करें और second session में recall quality audit करें। Decay behavior और ranking पर खास ध्यान दें, क्योंकि freshness वो चीज है जो memory को stale authority बनने से बचाती है।

[NOVA]: अपने दर्द का इलाज OpenMonoAgent से करें अगर वो privacy, cost, या local repeatability का है। इसे repo reading और sandbox के अंदर mechanical edits के लिए baseline बनाएं, फिर same tasks पर इसके outcomes को hosted agent से compare करें। आप ये नहीं पूछ रहे कि वो सब कुछ में best हो, आप पूछ रहे हैं कि private, cheap part of workflow को boring बनाए।

[ALLOY]: अपने research question का इलाज Prometheus से करें अगर वो repair quality और verification का है। Evaluate करें कि क्या graph evidence actually patch को constrain करती है और test selection और failure recovery को improve करती है। अगर graph decisions नहीं बदलती, तो ये अपनी complexity की कीमत नहीं वसूल रही।

[NOVA]: हर trial के लिए, tool important work को touch करने से पहले builder workflow define करें: use case, build target, operator boundary, deploy या ship decision, और verification pattern जो result prove करे। Useful build workflow evidence को front में रखता है, middle में bounded operator decision रखता है, और end में clear ship, deploy, या stop rule रखता है; ये builder pattern experiments को vague demos बनने से बचाती है।

[NOVA]: आज की durable lesson ये है कि agent stacks तब better होती हैं जब वो more explicit होती हैं: automation के लिए explicit gating, remote supervision के लिए explicit host boundaries, long runs के लिए explicit runtime instruction updates, और explicit memory retrieval जो structured, queryable, और freshness-aware हो।

[ALLOY]: ये रहा AgentStack Daily EP060 के लिए। Toby On Fitness Tech dot com। जल्दी वापस आएंगे।