[NOVA]: मैं NOVA हूँ।

[ALLOY]: और मैं ALLOY हूँ, और यह AgentStack Daily है। OpenClaw v2026.5.20 आज की पहली बात है जिस पर ध्यान देना चाहिए क्योंकि इससे एजेंट जिस चीज़ पर निर्भर करता है वो बदल जाती है: पॉलिसी चेक्स, सुरक्षित सीक्रेट लोडिंग, प्रोवाइडर रूटिंग, क्रॉन डिलीवरी, सबएजेंट रिटर्न, वॉइस कॉन्टेक्स्ट, और इमेज-जेनरेशन टाइमआउट्स।

[NOVA]: Codex 0.133.0 और Claude Code 2.1.148 एक ही प्रैक्टिकल ज़ोन में हैं: गोल्स, रिमोट-कंट्रोल रेडीनेस, पर्मिशन प्रोफाइल्स, प्लगइन इन्वेंटरी, लाइफसाइकल हुक्स, पिन्ड बैकग्राउंड सेशन्स, कोड रिव्यू, MCP पेजिनेशन, एंटरप्राइज़ पॉलिसी, विंडोज शेल रिपेयर्स, और एक बैश फिक्स जो तब मायने रखती है जब आपका टर्मिनल अचानक भूल जाए कि एक्जिट कोड्स कैसे काम करते हैं।

[ALLOY]: Hermes v2026.5.16 को भी टेबल पर असली जगह मिलती है: PyPI इंस्टॉल, लोकल प्रॉक्सी, OAuth-बैक्ड प्रोवाइडर्स, तेज़ ब्राउज़र वर्क, LSP डायग्नोस्टिक्स, फाइल-चेंज वेरिफिकेशन, मेसेजिंग, हैंडऑफ, वीडियो, और कंप्यूटर यूज़। फिर हम तेज़ी से आगे बढ़ते हैं Codex Appshots, Secure MCP टनल्स, Google Agent Executor, GKE Agent Sandbox, Antigravity CLI, MagenticLite, Data Agent Kit, Gemini API-key हार्डनिंग, और Copilot प्लानिंग टूल्स के ज़रिए। मकसद रिलीज़ नेम्स की तारीफ करना नहीं है। मकसद यह जानना है कि आगे क्या ट्राई करना है। ...

[NOVA]: OpenClaw Codex Claude Code अपग्रेड पाथ लोकल एजेंट स्टैक को इंस्पेक्ट करना आसान बनाता है।

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

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

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

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

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

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

[ALLOY]: इमेज जनरेशन को बेहतर डिफ़ॉल्ट टाइमआउट मिलता है। डायनामिक इमेज-जनरेशन कॉल्स अब 120 सेकंड का वॉचडॉग पाते हैं जब कोई टाइटर टाइमआउट सेट नहीं होता। यह मायने रखता है क्योंकि इमेज कॉल्स अक्सर टेक्स्ट कॉल्स से ज़्यादा समय लेती हैं। 30 सेकंड का टाइमआउट एक वैध धीमे जनरेशन को टूटा हुआ दिखा सकता है। एक्शन आइटम एक इमेज प्रोवाइडर को नए टाइमआउट के साथ टेस्ट करना और पुष्टि करना है कि UI या कॉलिंग टास्क धीमी प्रगति की रिपोर्ट करता है बजाय चुपचाप परिणाम खोने के।

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

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

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

[ALLOY]: Claude Code टर्मिनल-एजेंट स्टेबिलिटी ब्लॉक है। claude agents में पिन किए गए बैकग्राउंड सेशन idle होने पर ज़िंदा रहते हैं, अपडेट्स लागू करने के लिए जगह पर रीस्टार्ट होते हैं, और मेमोरी प्रेशर में नॉन-पिन्ड सेशन्स के बाद ही छोड़े जाते हैं। पुराना simplify कमांड code-review बन जाता है, और उसका काम स्पष्ट है: चुनिंदा प्रयास स्तर पर कॉरेक्टनेस बग्स ढूंढो, वैकल्पिक इनलाइन GitHub पुल-रिक्वेस्ट कमेंट्स के साथ। यह एक अस्पष्ट cleanup कमांड से बहुत बेहतर है जो समीक्षा बनने का दिखावा करता है।

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

[ALLOY]: Claude Code अपडेटर डायग्नोस्टिक्स, एंटरप्राइज़ लॉगिन पॉलिसी, PowerShell व्यवहार, बैकग्राउंड अप्रूवल्स, और Bash exit हैंडलिंग को भी टाइट करता है। टेस्ट सेट सीधा है: एक पिन्ड सेशन, एक रियल diff पर कोड रिव्यू, एक MCP इन्वेंटरी क्वेरी, एक परमिशन रीयूज़ पाथ, और एक शेल-भारी काम। अगर ये पास हो जाएं, तो यह अपडेट रिलीज़ नोट से उपयोगी बन गया है।

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

[NOVA]: Hermes Agent Foundation रिलीज़ सब्सक्रिप्शन, लोकल टूल्स, और मेसेजिंग को एक तीखा एजेंट बेंच बनाती है।

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

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

[ALLOY]: अगला बड़ा पीस है local OpenAI-compatible proxy। hermes proxy चलाओ, और जो टूल्स पहले से OpenAI-style endpoint से बात करना जानते हैं वे local Hermes endpoint को पॉइंट कर सकते हैं, जिसके पीछे जो भी OAuth provider यूज़र ने sign in किया है वह हो। प्रैक्टिकल नाम साफ हैं: Codex CLI, Aider, Cline, Continue, कस्टम स्क्रिप्ट। दिलचस्प आइडिया यह है कि subscription-backed provider बिना हर downstream tool को bespoke auth integration की ज़रूरत के local endpoint बन सकता है।

[NOVA]: वहीं पर बिल्डर्स के लिए मज़ा शुरू होता है। कल्पना करो Codex जो OpenAI-compatible API उम्मीद करता है। दूसरा secret path गढ़ने की बजाय, उसे Hermes proxy पर पॉइंट करो और auth provider को Hermes संभालने दो। टेस्ट सिंपल है: proxy शुरू करो, एक client को उस पर पॉइंट करो, एक छोटा रिक्वेस्ट चलाओ, और inspect करो कि actually किस provider ने serve किया। फिर proxy रोको और सुनिश्चित करो कि फेलियर साफ हो। अगर यह normal टूल की तरह फेल होता है, तो इसके आसपास बना सकते हो। अगर यह mist की तरह फेल होता है, तो इसे लैब में रखो।

[ALLOY]: SuperGrok OAuth और xAI पाथ उसी तरह मायने रखते हैं। रिलीज Hermes को Grok का इस्तेमाल signed-in account flow के ज़रिए करने देती है, हर provider को static API-key drawer की तरह behandel करने की बजाय। यह एजेंट bench को ज़्यादा provider variety देता है, लेकिन यह control सवाल भी उठाता है: कौन से टूल्स को किस subscription पर खर्च करने देना चाहिए, और बाद में पता कैसे चलेगा कि क्या हुआ?

[NOVA]: इसीलिए proxy टेस्ट में logging शामिल होनी चाहिए। बड़ी observability ceremony नहीं। बस इतना सबूत कि जवाब दे सको: किसने call किया, किस provider ने जवाब दिया, कौन सा model इस्तेमाल हुआ, और credential boundary क्रॉस हुई या नहीं। एजेंट स्टैक तब बहुत कम रहस्यमय लगने लगते हैं जब "किस backend ने यह किया?" का जवाब हो।

[ALLOY]: Hermes x_search भी जोड़ता है, जो काम का है क्योंकि एजेंट्स को अक्सर current social या developer chatter चाहिए लेकिन सिर्फ X search करने के लिए custom skill की ज़रूरत नहीं होनी चाहिए। इसे evidence टूल की तरह behandel करो, gossip cannon की तरह नहीं। एक अच्छा पहला इस्तेमाल संकरा है: release thread खोजो, maintainer post खोजो, या हाल की incident report खोजो, फिर उस specific result को task में वापस cite करो। बुरा इस्तेमाल यह है कि एजेंट social noise में तैरता रहे और इसे research कहे।

[NOVA]: Messaging भी Hermes का एक बड़ा क्षेत्र है। Microsoft Teams end to end wired है, LINE और SimpleX Chat आते हैं, Telegram और Discord के लिए native clarify बटन आते हैं, और Discord history backfill by default चालू है। आखिरी वाला चालाकी से ज़रूरी है। एक channel में आता एजेंट बिना recent context के ऐसा है जैसे कोई इंसान meeting में आता है और बिना देखे twenty minutes पहले के सवाल का जवाब देता है। History backfill एजेंट को chance देता है कि वह जान सके कि स्क्रीन पर पहले से क्या है।

[ALLOY]: वहाँ का एक्शन आइटम "हर platform कनेक्ट करो" नहीं है। एक channel चुनो और एक conversational control टेस्ट करो। Clarify बटन एक अच्छा है। एजेंट से दो सुरक्षित विकल्पों में से चुनने को कहो और confirm करो कि बटन दिखते हैं, चुना गया जवाब run तक पहुँचता है, और transcript में decision रिकॉर्ड होती है। यह छोटा टेस्ट है, लेकिन यह साबित करता है कि chat surface सिर्फ void में paste किया गया टेक्स्ट नहीं है।

[NOVA]: परफॉर्मेंस को real numbers मिलते हैं। Hermes कहता है कि cold start लगभग उन्नीस सेकंड कम होता है, और browser console evaluations persistent Chrome DevTools connection के ज़रिए dramatically तेज़ होते हैं। यह मायने रखता है क्योंकि local agents छोटे loops में इस्तेमाल होते हैं। अगर हर browser inspection में कुछ सेकंड लगते हैं, तो एजेंट चिपचिपा लगता है। अगर same inspection near instant है, तो browser repair और page evidence बहुत ज़्यादा सहनीय हो जाते हैं।

[ALLOY]: अपडेट से पहले और बाद में एक ब्राउज़र इंस्पेक्शन करें। Hermes से एक पेज इंस्पेक्ट करने के लिए कहें, एक सुरक्षित JavaScript evaluation चलाएं, और नतीजा रिपोर्ट करें। इसे दो बार करें। अगर दूसरी बार ज़्यादा तेज़ है क्योंकि कनेक्शन गर्म है, तो आपने कुछ उपयोगी सीखा। अगर फिर भी धीमा लगता है, तो बॉटलनेक आपका browser profile, tool startup, network, या खुद पेज हो सकता है।

[NOVA]: write-safety फीचर्स वो हिस्सा है जिसे मैं तुरंत टेस्ट करूँगा। per-turn file mutation verification का मतलब है कि agent को एडिट के बाद एक footer मिलता है जिसमें डिस्क पर क्या बदला वो दिखता है। हर write पर LSP semantic diagnostics का मतलब है कि agent patch पूरा होने की बेतरतीब ढंग से घोषणा करने से पहले language-server errors देख सकता है। ये वो फीचर्स हैं जो किसी confident agent को इस बात पर confidently wrong होने से रोकते हैं कि उसने वो file actually edit की या नहीं जो उसने सोचा था कि उसने edit की।

[ALLOY]: quick trial एक छोटा सा code edit है। Hermes को एक function बदलने के लिए कहें जिसका obvious type expectation हो। देखें कि file-change summary दिखती है या नहीं। देखें कि LSP diagnostics कोई गलती पकड़ती है या नहीं। फिर agent से उसे ठीक करने के लिए कहें। ये glamorous नहीं है, लेकिन ये वही तरह का loop है जो builder को broken patch स्वीकार करने से बचाता है क्योंकि prose finished लग रही थी।

[NOVA]: /handoff एक और उपयोगी चीज है। ये एक active session को context गंवाए बिना अलग model, persona, या profile पर मूव करता है। सही टेस्ट एक बड़ा dramatic transfer नहीं है। एक fast provider के साथ एक छोटा debugging session शुरू करें, फिर final review के लिए इसे एक deeper model को hand करें। देखें कि target के पास messages, tool history, और files हैं जिनकी उसे ज़रूरत है। अगर handoff काम करता है, तो आपको शुरू से शुरू करने की बजाय एक practical escalation path मिलती है।

[ALLOY]: Hermes Anthropic-only assumptions से आगे computer use भी बढ़ाता है cua-driver backend के साथ, pluggable video generation, clickable terminal URLs, Zed ACP Registry integration, OpenRouter Pareto Code routing, optional skills, API approval events, और plugin-side LLM calls through ctx.llm जोड़ता है। बहुत सारा है, तो इसे list की तरह पचाने की कोशिश न करें। दो फीचर्स चुनें जो किसी current annoyance को हटाते हैं।

[NOVA]: मेरा सुझाया Hermes bench test पाँच हिस्सों का है। एक, install या update करें और doctor चलाएँ। दो, local proxy शुरू करें और एक OpenAI-compatible tool को उसकी तरफ point करें। तीन, एक browser inspection चलाएँ और पुष्टि करें कि ये उतनी तेज़ है कि tolerate किया जा सके। चार, एक file edit करें और LSP plus mutation verification देखें। पाँच, real chat surface में handoff या clarify buttons का उपयोग करें। इतना जानना काफी है कि Hermes आपके daily stack में है या weekend experiment बना रहेगा।

[ALLOY]: और अगर इनमें से कोई test fail हो जाए, तो ये फिर भी उपयोगी है। एक अच्छा bench सिर्फ ये साबित नहीं करता कि tools shiny हैं। ये बताता है कि कौन सा part ready नहीं है: install, auth, proxy, browser, write safety, messaging, या handoff। यही तरीका है किसी huge release को feature avalanche की जगह useful decision में बदलने का। ...

[NOVA]: OpenAI Codex Appshots और goal mode visual product work को कम guessy बनाते हैं।

[ALLOY]: Appshots सबसे immediately useful Codex product update है। macOS app में, आप एक hotkey के साथ एक app window को Codex thread में attach कर सकते हैं। thread को एक screenshot और available text मिलता है। ये UI repair बदल देता है क्योंकि अब human को हर visual problem को एक लंबे paragraph में translate करने की ज़रूरत नहीं है। model bad state देख सकता है, text layer inspect कर सकता है, और problem को किसी component, route, या style rule से connect कर सकता है।

[NOVA]: try-now version एक UI bug है। एक huge redesign से शुरू न करें। एक app state खोलें जहाँ कुछ visibly wrong है: एक clipped table, एक misaligned button, एक modal जो cramped लग रहा है, एक heading जो badly wrap हो रही है, या एक sidebar state जो page से match नहीं करती। एक Appshot capture करें। Codex को एक goal दें: surrounding layout बदले बिना उस visible problem को fix करो। फिर page चलाएँ और result फिर से capture करें।

[ALLOY]: गोल मोड का दूसरा आधा हिस्सा है। यह अब Codex app, IDE extension, और CLI में सामान्य रूप से उपलब्ध है। इसका मतलब है क्योंकि एक गोल पूर्णता की पोर्टेबल परिभाषा है। अगर टास्क डेस्कटॉप app में शुरू होता है और एडिटर या कमांड लाइन में जारी रहता है, तो टारगेट काम से जुड़ा रह सकता है। गोल ठोस होना चाहिए: यह टेस्ट पास करें, इस विज़ुअल डिफेक्ट को हटाएं, यह आर्टिफैक्ट जेनरेट करें, या इस API पाथ को अनRELATED व्यवहार बदले बिना अपडेट करें।

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

[ALLOY]: रीड-ओनली जावास्क्रिप्ट कॉन्टेक्स्ट एक सबटल सेफ्टी इम्प्रूवमेंट है। यह एजेंट को पेज स्टेट को इंस्पेक्ट करने का तरीका देता है बिना इंस्पेक्शन को म्यूटेशन में बदले। सही क्रम अभी भी observe, reason, edit, verify है। अगर एजेंट पेज देखने से सीधे म्यूटेट करने पर कूद जाता है, तो डिबगिंग जल्दी मडी हो जाती है। रीड-ओनली इंस्पेक्शन उन फेज को अलग रखने में मदद करता है।

[NOVA]: लॉक्ड कंप्यूटर यूज़ उपयोगी है, लेकिन इसे मैजिक ऑटोनॉमी नहीं बल्कि सुपरविज़न के तहत कंटीन्यूटी के रूप में माना जाना चाहिए। एलिजिबल Mac Computer Use यूज़र Mac के लॉक होने के बाद Codex को रिमोटली काम करते रख सकते हैं। यह लंबे लोकल टास्क, विज़ुअल चेक, या ऐसे ब्राउज़र वर्क के लिए अच्छा है जिसमें समय लगता है। गंभीर काम के लिए उपयोग करने से पहले, wake बिहेवियर, अप्रूवल, और रिकवरी टेस्ट करें। लॉक्ड मशीन को एजेंट की पावर को अनजाने में बढ़ाना नहीं चाहिए।

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

[NOVA]: एक अच्छा बिल्डर ट्रायल before-and-after issue है। ब्रोकन UI कैप्चर करें, Codex से सबसे छोटा फिक्स मांगें, बिल्ड रन करें, रिपेयर्ड UI कैप्चर करें, और दोनों स्टेट की तुलना करें। अगर टास्क विज़िबल डिफेक्ट से ज्यादा बदलता है, तो इसे रिजेक्ट करें और गोल को संकुचित करें। यह वर्कफ्लो को प्रैक्टिकल रखता है: विज़ुअल एविडेंस इन, सोर्स चेंज आउट, ट्रस्ट से पहले वेरिफिकेशन। यह डिज़ाइन QA, एक्सेसिबिलिटी फिक्स, कॉपी ओवरफ्लो, डैशबोर्ड पॉलिश, और डेस्कटॉप-ऐप सपोर्ट के लिए भी रीयूज़ेबल पैटर्न देता है।

[NOVA]: सेक्योर MCP टनल प्राइवेट टूल्स को बिना इनबाउंड पोर्ट खोले रीचेबल एजेंट टूल्स में बदल देते हैं।

[ALLOY]: यह सबसे महत्वपूर्ण इन्फ्रास्ट्रक्चर स्टोरीज में से एक है क्योंकि यह बदलती है कि प्राइवेट टूल्स एजेंट सिस्टम में कैसे भाग ले सकते हैं। OpenAI और Anthropic दोनों MCP टनल पैटर्न को आगे बढ़ा रहे हैं। बेसिक शेप आउटबाउंड कनेक्टिविटी है: एक लोकल या इंटरनल MCP सर्वर एक टनल के ज़रिए बाहर कनेक्ट करता है, और एक एजेंट सरफेस इसे पब्लिक इंटरनेट पर इनबाउंड पोर्ट एक्सपोज़ किए बिना रीच कर सकता है।

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

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

[NOVA]: try-now अभ्यास यह है कि एक private MCP tool को ऐसे डिज़ाइन करें जैसे वह live होने वाला हो। tool का नाम दें। उस account या project का नाम दें जो इसे access कर सकता है। उन methods की सूची बनाएं जिन्हें agent call कर सकता है। तय करें कि कौन से calls read-only हैं और कौन से mutating हैं। तय करें कि mutating calls के लिए human approval की ज़रूरत है या नहीं। हर call को ऐसे log करें कि बाद में audit किया जा सके। फिर तय करें कि local secret कहाँ रहता है और यह कैसे rotate होता है।

[ALLOY]: यह bureaucracy नहीं है। यह "मेरा agent एक internal status service query कर सकता है" और "मेरा hosted agent वो सब कुछ कर सकता है जो मेरे laptop का MCP server expose करता है" के बीच का अंतर है। tunnel संकरा होना चाहिए। अगर किसी tool को सिर्फ issue metadata पढ़ना है, तो उसे issue को rewrite करने वाला method न दें। अगर उसे सिर्फ staging database चाहिए, तो production की तरफ न point करें। अगर उसे सिर्फ summary चाहिए, तो default रूप से raw records return न करें।

[NOVA]: सबसे अच्छे use cases अच्छी तरह से boring होते हैं: internal search, local docs, build status, read-only dashboards, small deployment checks, एक private calendar availability tool, या source-of-truth inventory। एक बार ये काम करने लगें, तो write actions की तरफ सावधानी से बढ़ें। एक private tunnel के ज़रिए write action को एक छोटी release की तरह महसूस करना चाहिए, casual convenience की तरह नहीं।

[ALLOY]: takeaway practical है। Secure MCP tunnels private tools को connect करना आसान बनाते हैं। वे identity, allowlists, audit logs, scoped secrets, और approval gates की ज़रूरत को खत्म नहीं करते। tunnel को pipe मानें। permission model tool के आसपास डिज़ाइन करें। ...

[NOVA]: पहला build read-only होना चाहिए। एक useful starter workflow है internal status lookup, private documentation search, या staging-health query। tool को एक छोटा answer और trace return करना चाहिए कि उसने क्या check किया। फिर बाद में एक approval-gated write action add करें। यह sequencing tunnel को useful रखती है बिना पहले version को scary बनाए। अगर एक read-only tool को cleanly scope और audit नहीं किया जा सकता, तो write-capable tool तैयार नहीं है।

[NOVA]: Google Agent Executor long-running agents को one-shot की जगह resumable बनाता है।

[ALLOY]: Agent Executor interesting है क्योंकि यह उस runtime layer को name करता है जिसे कई agent demos skip करते हैं। एक serious agent run के लिए event log, snapshots, reconnect और backfill, isolated actors, single-writer session state, और branchable trajectories चाहिए। ये glamorous features नहीं हैं। ये वो चीज़ें हैं जो long run को recoverable बनाती हैं।

[NOVA]: एक one-shot prompt एक chat transcript के अंदर रह सकता है। एक multi-hour agent task नहीं रह सकता। यह browse कर सकता है, tools call कर सकता है, intermediate state create कर सकता है, user पर wait कर सकता है, disconnect के बाद recover कर सकता है, और failure के बाद strategy fork कर सकता है। अगर ये सब सिर्फ model context के अंदर रहता है, तो run fragile है। जब context compact, interrupted, या confused होता है, तो system thread खो देता है।

[ALLOY]: event log पहली useful चीज़ है। यह आपको chronological record देता है कि क्या हुआ: model decisions, tool calls, observations, approvals, errors, retries, और outputs। यह तब matter करता है जब run succeed होती है क्योंकि आप बता सकते हैं कि यह कैसे पहुँचा। यह तब और भी ज़्यादा matter करता है जब run fail होती है क्योंकि आप identify कर सकते हैं कि कौन सा event गलत था, पूरे model को blame करने की बजाय।

[NOVA]: Snapshots एक अलग problem solve करते हैं। Long-running sessions को world को replay किए बिना pause और resume करने का तरीका चाहिए। एक snapshot किसी point in time पर state capture कर सकता है, ताकि system reconnect या recover करने के बाद continue कर सके। यह browser agents, coding agents, data agents, और किसी भी task के लिए important है जिसका prompt के बाहर state है.

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

[NOVA]: एक्शन आइटम है कि एक मौजूदा एजेंट टास्क को इस रनटाइम शेप में मैप करें। एक ऐसा टास्क चुनें जो फिलहाल फ्लैकी लगता है। पांच सवाल पूछें। इवेंट स्ट्रीम क्या है? ड्यूरेबल स्टेट कहाँ स्टोर है? डिस्कनेक्ट के बाद रन कैसे फिर से शुरू होता है? क्या आप फेल हुए स्टेप से ब्रांच कर सकते हैं? रन खत्म होने के बाद क्या प्रूफ बचता है?

[ALLOY]: अगर आप ये सवाल जवाब नहीं दे सकते, तो टास्क अभी भी काम कर सकता है, लेकिन यह अभी तक एक एजेंट सिस्टम नहीं है जिस पर आप भरोसा कर सकते। Agent Executor उपयोगी है क्योंकि यह बिल्डर्स को हीरोइक प्रॉम्प्टिंग के बजाय रिकवरेबल एक्जीक्यूशन की ओर धकेलता है। ...

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

[NOVA]: GKE Agent Sandbox और Agent Substrate आइल लेकिन स्टेटफुल एजेंट्स के अजीब शेप को टारगेट करते हैं।

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

[NOVA]: Google's GKE Agent Sandbox और Agent Substrate काम उसी शेप को टारगेट करता है। टुकड़े हैं - वार्म पूल, स्नैपशॉट्स, gVisor आइसोलेशन, एक्टर शेड्यूलिंग, और वर्कर मल्टीप्लेक्सिंग। मुद्दा सिर्फ "Kubernetes पर एजेंट्स चलाना" नहीं है। मुद्दा आइसोलेटेड स्टेटफुल सेशन्स को सस्ता और जल्दी जगाना है।

[ALLOY]: वार्म पूल मदद करते हैं क्योंकि एक सेशन कोल्ड इन्फ्रास्ट्रक्चर के बजाय रेडी कैपेसिटी से शुरू हो सकता है। स्नैपशॉट्स मदद करते हैं क्योंकि आइल स्टेट को सस्पेंड और रिज्यूम किया जा सकता है। gVisor आइसोलेशन में मदद करता है। एक्टर-टू-वर्कर मैपिंग प्लेटफॉर्म को कम एक्टिव वर्कर्स में कई लॉजिकल सेशन्स ले जाने में मदद करता है। थीम डेकोरेटिव नहीं है; यह एजेंट सेशन्स की इकोनॉमिक्स का जवाब है।

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

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

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

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

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

[NOVA]: गूगल का Antigravity CLI माइग्रेशन Gemini CLI यूज़र्स के लिए एक असली प्लानिंग डेडलाइन है।

[ALLOY]: गूगल कहता है कि Gemini CLI कंज्यूमर और फ्री यूसेज 18 जून, 2026 को रिक्वेस्ट सर्व करना बंद कर देगी, और Antigravity CLI नया टर्मिनल सरफेस बन जाएगी। यह सिर्फ एक ब्रांड चेंज नहीं है। यह एक माइग्रेशन इवेंट है उन सभी के लिए जिन्होंने Gemini CLI के आदतें, स्क्रिप्ट, प्रॉम्प्ट, स्किल्स या हुक बनाए थे।

[NOVA]: Google Antigravity CLI migration वही एक्सैक्ट फ्रेज है जो कैलेंडर पर रखना चाहिए क्योंकि यह कोई अस्पष्ट फ्यूचर नज़र नहीं है। यह एक डेटेड टर्मिनल-सरफेस चेंज है जिसके साथ मौजूदा स्क्रिप्ट, ऑथ फ्लो और आदतें जुड़ी हैं।

[NOVA]: अहम हिस्सा हैarness दिशा। Antigravity स्किल्स, हुक, सबएजेंट्स, प्लगइन, async वर्क और CLI और डेस्कटॉप में शेयर्ड कॉन्टेक्स्ट के आसपास पोजिशंड है। इसका मतलब है कि टर्मिनल एजेंट कम से कम एक सिंगल प्रॉम्प्ट रनर जैसा और ज्यादा से ज्यादा एक कॉन्फिगर्ड वर्क एनवायरनमेंट जैसा बन रहा है।

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

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

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

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

[ALLOY]: डेडलाइन इतनी करीब है कि इंतज़ार करना बुरा प्लान है। माइग्रेशन आसान हो जाते हैं जब पहला टेस्ट तब होता है जब पुराना टूल अभी भी काम कर रहा हो। ...

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

[NOVA]: Microsoft MagenticLite दिखाता है कि छोटे-मॉडल कंप्यूटर-यूज़ एजेंट तब useful हो सकते हैं जब harness उनके around design किया गया हो।

[ALLOY]: MagenticLite दिलचस्प है क्योंकि ये "हर task को सबसे बड़े model को दे दो" से शुरू नहीं होता। Microsoft Foundry Labs एक harness, एक orchestrator, कंप्यूटर-यूज़ models, approvals, और sandboxing को pair कर रहा है। MagenticBrain Qwen three eight billion पर आधारित है और harness के अंदर train किया गया है। Fara one point five चार, नौ, और सत्ताईस billion parameter variants में computer-use tasks को handle करता है।

[NOVA]: मुख्य mechanism है co-design। Orchestrator training और inference दोनों के दौरान same तरह के tool schemas देखता है। ये benchmark behavior और product behavior के बीच gap को reduce करता है। बहुत सारे agent failures तब होते हैं जब एक model एक task format सीखता है, फिर product उसे एक अलग tool shape, approval model, या browser state देता है।

[ALLOY]: MagenticLite Quicksand के QEMU sandbox का इस्तेमाल browser sessions और code execution के लिए भी करता है। ये matters है क्योंकि computer-use agents unknown pages, downloads, local content, और कभी-कभी code को touch करते हैं। उस काम को एक resettable boundary के अंदर चलाना main desktop पर agent को roam करने देने से बेहतर default है।

[NOVA]: Approval design model जितनी ही important है। एक अच्छा computer-use agent login, submission, deletion, payment, account changes, या किसी और चीज़ के लिए pause करना चाहिए जो reversible navigation से consequence में बदलती है। हर harmless click के लिए approval नहीं मांगनी चाहिए। सिस्टम को पता होना चाहिए कि कौन से actions sensitive हैं।

[ALLOY]: try-now सवाल ये नहीं है कि "क्या ये frontier coding model की जगह ले सकता है?" सवाल है "कौन से repetitive computer-use tasks इतने narrow हैं कि एक छोटे orchestrator plus specialized browser model के लिए fit करें?" Candidates में शामिल हैं dashboard check करना, draft form भरना, page evidence collect करना, known web tool में navigate करना, sandbox में local artifacts organize करना, या visual demo चलाना।

[NOVA]: इकोनॉमिक्स matter करते हैं। अगर हर click सबसे महंगे model को call करता है, तो कई useful automations कभी affordable नहीं बनेंगे। एक छोटा orchestrator high-frequency tasks को plausible बना सकता है अगर reliability ऊंची बनी रहे। Harness-faithful training है bet: environment को ऐसे shape करो कि छोटे model को कम surprises मिलें।

[ALLOY]: मूल्यांकन व्यावहारिक होना चाहिए। क्या यह तब ठीक हो सकता है जब कोई पेज बदलता है? क्या कोई इंसान काबू ले सकता है? क्या यह बता सकता है कि उसने ब्राउज़र मॉडल को क्यों सौंपा? क्या सैंडबॉक्स साफ़ तरीके से रीसेट हो सकता है? क्या यह सही पलों पर रुकता है? क्या यह नीरस काम खत्म करता है बिना इंसान को हर कदम पर पर्यवेक्षक बनाए?

[NOVA]: MagenticLite के लिए यही उपयोगी दृष्टिकोण है। छोटे मॉडल जादू नहीं हैं। लेकिन सावधानीपूर्ण हार्नेस में छोटे मॉडल कंप्यूटर-उपयोग कार्य के एक हिस्से के लिए बिल्कुल सही हो सकते हैं। ...

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

[NOVA]: Google Data Agent Kit डेटा एक्सेस को पेस्टेड स्कीमा के बजाय कॉन्फ़िगर एजेंट टूल्स के रूप में पैकेज करता है।

[ALLOY]: यह कहानी इसलिए मायने रखती है क्योंकि डेटा कार्य उन जगहों में से एक है जहाँ एजेंट जल्दी उपयोगी और जल्दी खतरनाक बन सकते हैं। Google Data Agent Kit डेटा कौशल और MCP-स्टाइल टूल्स को Codex, Claude Code, Gemini CLI, VS Code, और Antigravity सहित डेवलपर-एजेंट सतहों में लाता है। स्रोतों में BigQuery, AlloyDB, Spanner, और Cloud Storage शामिल हैं।

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

[ALLOY]: कार्रवाई आइटम डेटा एजेंट को शक्ति देने से पहले उसका दायरा निर्धारित करना है। यह क्या पढ़ सकता है? यह क्या लिख सकता है? कौन से डेटासेट प्रतिबंधित हैं? क्या यह महंगे क्वेरी चला सकता है? क्या उसे पंक्ति-स्तर सुरक्षा की ज़रूरत है? क्या इसे कच्चा डेटा, सारांश, या क्वेरी प्लान वापस करना चाहिए? उत्पादन से पहले जनरेटेड क्वेरी की समीक्षा कौन करता है?

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

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

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

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

[NOVA]: Google का Gemini API-key वार्निंग एजेंट बिल्डर्स को एक सिक्योरिटी टास्क देता है जो वे आज कर सकते हैं।

[ALLOY]: Google प्रीमिस के बारे में सीधा है: Gemini API कीज स्टैंडर्ड Google API कीज हैं, और API कीज खुले सीक्रेट हैं। उन्हें पेड बियरर टोकन की तरह ट्रीट करें। अगर वे ब्राउज़र क्लाइंट, जेनरेटेड रेपो, पब्लिक डेमो, या अनट्रस्टेड एक्सटेंशन में जाएँ, तो रिस्क थियोरेटिकल नहीं है। यह अनपेक्षित यूसेज और बिलिंग बन सकता है।

[NOVA]: Gemini API-key गाइडेंस काम का है क्योंकि यह सिक्योरिटी को फॉगी स्कॉल्डिंग से फिनाइट एरेंड में बदल देता है।

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

[ALLOY]: एप्लिकेशन रिस्ट्रिक्शन आगे हैं। कीey को वेबसाइट, IP रेंज, iOS बंडल आइडेंटिफायर, या Android पैकेज और सर्टिफिकेट पेयर से रिस्ट्रिक्ट किया जा सकता है। चूँकि कीey एक एप्लिकेशन रिस्ट्रिक्शन टाइप इस्तेमाल करती है, अलग एप्लिकेशन शेप्स को अलग कीज मिलनी चाहिए। ब्राउज़र ऐप, सर्वर प्रोसेस, iOS ऐप, और Android ऐप को एक ऑल-पर्पस स्ट्रिंग शेयर नहीं करनी चाहिए।

[NOVA]: सर्वर-साइड कीज का एक सीक्रेट स्टोर में होना चाहिए जैसे Secret Manager या समकक्ष सिस्टम। इन्हें विजिबल क्लाइंट कोड में बेक नहीं करना चाहिए। एक जेनरेटेड सैम्पल जो पब्लिक ब्राउज़र क्लाइंट से सीधे पेड मॉडल API को कॉल करता है, वह ड्राफ्ट है, डिप्लॉय करने योग्य पैटर्न नहीं।

[ALLOY]: मॉनिटरिंग लूप को बंद करती है। Cloud Asset Inventory या की लिस्टिंग इस्तेमाल करें कि क्या है पता लगे। क्रेडेंशियल ID के हिसाब से रिक्वेस्ट-काउंट मेट्रिक्स देखें। अगर कीey फैलती है, तो उसे रोटेट करें और समान रिस्ट्रिक्शन के साथ रिप्लेसमेंट बनाएँ। एक लूज़ कीey से दूसरी लूज़ कीey में रोटेट न करें।

[NOVA]: ट्राई-नाउ टास्क सीधा है। एक Gemini कीey चुनें। प्रोजेक्ट कन्फर्म करें। API रिस्ट्रिक्शन कन्फर्म करें। एप्लिकेशन रिस्ट्रिक्शन कन्फर्म करें। स्टोर कहाँ है कन्फर्म करें। यूसेज कैसे मॉनिटर होती है कन्फर्म करें। रोटेट कैसे करना है कन्फर्म करें। अगर कोई जवाब "पता नहीं" है, तो वही अगला फिक्स है।

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

[NOVA]: Copilot Auto और semantic issue search प्लानिंग और model routing को coding agent surface का हिस्सा बनाते हैं।

[ALLOY]: Copilot Auto अब task signals के आधार पर route करता है, admin policy का सम्मान करते हुए और यह दिखाते हुए कि कौन सा model चुना गया। यह रोजमर्रा के काम के लिए उपयोगी है क्योंकि हर task को सबसे भारी reasoning model की जरूरत नहीं होती। एक छोटी सी explanation, एक छोटा सा edit, या पहला diagnosis किसी तेज या सस्ते model से बेहतर served हो सकता है।

[NOVA]: GitHub Copilot Auto model-routing पक्ष है, और semantic issue search context पक्ष है। इन्हें एक साथ रखें और bug work बेहतर evidence से शुरू होता है।

[NOVA]: Tradeoff यह है कि reproducibility पर असर पड़ता है। अगर model choice task classification, availability, reliability, subscription, या policy के आधार पर बदलता है, तो एक ही prompt के दो runs में अंतर हो सकता है। Low-risk काम के लिए यह ठीक हो सकता है। Migrations, security fixes, production patches, या incident reproduction के लिए, model को log करें या pin करें।

[ALLOY]: Semantic issue search teams के लिए अधिक actionable Copilot feature है। यह Copilot Chat को सिर्फ exact text या labels नहीं, बल्कि meaning के आधार पर related issues खोजने देता है। यह coding work के क्रम को बदल सकता है। एक repository को agent के सामने रखकर vague complaint fix करने को न कहें, पहले symptom, platform, failure mode, या release area के हिसाब से related issues का समूह मांगें।

[NOVA]: Try-now pattern यह है: पहले search करें, फिर edit करें। Related issues का cluster मांगें। पूछें कि कौन से failure modes दोहराते हैं। एक narrow cluster चुनें। फिर उस narrow task को relevant issue links और success condition के साथ coding agent को सौंपें। इससे agent को बेहतर context मिलता है और chance कम होता है कि वह सबसे तेज symptom fix करे जबकि actual pattern छूट जाए।

[ALLOY]: यहां भी admin policy मायने रखता है। अगर कोई organization certain models disable करती है या routing rules सेट करती है, तो agent surface को उसका सम्मान करना चाहिए। Model routing अब developer tooling governance का हिस्सा है। यह सिर्फ personal preference नहीं है।

[NOVA]: Practical habit यह है कि model choice और issue retrieval को evidence की तरह treat करें। किस model ने जवाब दिया? कौन से issues पर गौर किया गया? कौन सा cluster चुना गया? कौन सा test prove करता है कि fix काम करता है? बस यही trace काफी है कि coding-agent work कम mysterious लगे। ...

[ALLOY]: एक अच्छी team workflow यह है कि semantic issue search को bug work का पहला step बनाएं। Symptom search करें, related reports को group करें, एक cluster चुनें, और तभी coding agent से patch मांगें। Low-risk edits के लिए, Copilot Auto model चुन सकता है। High-risk edits के लिए, model को pin करें या log करें। इससे daily work की speed बनी रहती है और changes के लिए traceability जो बाद में reproduce करने पड़ सकते हैं।

[ALLOY]: इसे एक साथ मिलाकर देखें तो next queue स्पष्ट है। OpenClaw, Codex, और Claude Code को upgrade करें, फिर सिर्फ versions print करने की जगह changed surfaces को test करें। OpenClaw के लिए: policy findings, secret symlink rejection, provider routing, cron output, subagent completion, voice handoff, और image timeout behavior।

[NOVA]: Codex के लिए: एक Appshot, एक goal-driven task, एक remote-control readiness check, एक permission-profile inspection, एक plugin inventory check, और एक lifecycle event जो आप सच में log करेंगे। Claude Code के लिए: एक pinned background session, एक real diff पर code review, एक paginated MCP server, और एक shell-heavy task।

[ALLOY]: व्यापक news के लिए: connectivity से पहले permissions के साथ एक MCP tunnel design करें, एक long-running agent के लिए durable state sketch करें, estimate करें कि क्या एक agent service ज्यादातर idle और stateful है, एक Gemini CLI task को Antigravity की ओर migrate करें, एक sandbox के अंदर एक small-model computer-use task try करें, एक read-only data agent scope करें, एक Gemini key lock down करें, और editing से पहले semantic issue search use करें।

[NOVA]: bar यह नहीं है कि "model ने कोई clever बात कही या नहीं।" bar यह है कि system observable है या नहीं, scoped है या नहीं, recoverable है या नहीं, और daily use के लिए useful enough है या नहीं। आज की good news यह है कि agent stack का ज्यादा हिस्सा वो pieces expose कर रहा है जो उस लक्ष्य तक पहुंचने के लिए ज़रूरी हैं।

[ALLOY]: इसे actionable बनाने का सबसे अच्छा तरीका है कि कल के लिए एक build workflow choose करें, दस एक साथ नहीं। उदाहरण के लिए: एक UI bug लें, इसे Appshots से capture करें, एक Codex goal set करें, patch करें, और result verify करें। या एक private status tool लें, इसे एक read-only MCP tunnel के through expose करें, और हर call को log करें। या एक flaky long-running agent task लें, event sequence लिखें, और decide करें कि resume कहां होना चाहिए। एक छोटी working build एक giant plan से ज्यादा सिखाती है।

[NOVA]: और हर workflow को honest रखें। इसमें एक trigger होना चाहिए, एक narrow permission boundary होनी चाहिए, एक success condition होना चाहिए, एक failure condition होना चाहिए, और एक verification step होनी चाहिए। यह तब भी apply होता है जब workflow एक data-agent query हो, एक small-model browser task हो, एक Copilot issue triage हो, या एक OpenClaw cron job हो। अगर agent आपको नहीं बता सकता कि उसने क्या किया, उसने क्या use किया, और क्या बदला, तो build daily use के लिए ready नहीं है।

[ALLOY]: एक और practical filter: वो workflow pick करें जो सबसे ज्यादा repeated annoyance को हटाती है। अगर कोई human एक ही dashboard को बार-बार rechec करता रहता है, तो उसको small-model browser task बनाएं। अगर कोई team एक ही database question बार-बार पूछती रहती है, तो उसको read-only data agent बनाएं। अगर कोई coding agent issue context miss करती रहती है, तो semantic issue search को intake step बनाएं। News इसलिए matters है क्योंकि यह builders को उन problems पर better handles देता है जो उनके पास पहले से हैं, और better ways देता है guess किए बिना ship करने के लिए।

[NOVA]: Extra builder picks भी एक quick final scan के लायक हैं: AI behavior के लिए feature flags, image efficiency work, और edge-model benchmarks। एक prompt या config change के around एक kill switch add करें, एक image path को latency और cost के लिए benchmark करें, या एक local model को actual device पर test करें desktop numbers transfer होने की assumption के बजाय।

[ALLOY]: Source links इस हफ्ते episode page पर इस समय उपलब्ध हैं। यह है AgentStack Daily। मैं हूं ALLOY।

[NOVA]: और मैं हूं NOVA। हम जल्दी वापस आएंगे। Toby On Fitness Tech dot com।