[NOVA]: मैं NOVA हूं। [ALLOY]: मैं ALLOY हूं, और यह AgentStack Daily है... [NOVA]: Codex .136 में TUI diagnostics को clearer बनाया गया, app-server lifecycle handling को tighten किया गया, named hooks को permission scopes के साथ introduce किया गया, और threads, turns और error propagation के आसपास Python और Node SDK behavior में सुधार किया गया। OpenClaw 5.28 strong session recovery, subagent boundaries, browser validation और automation guardrails के साथ current stable harness line बना हुआ है; Hermes .15.2 multi-agent kanban, worktree isolation, swarm coordination और promptware defense के साथ stable Hermes Agent line बना हुआ है; और Claude Code 2.1 latest CLI package track करने वाली teams के लिए फिर से move हुआ है। [ALLOY]: Harness news पहले आता है क्योंकि यहीं agent reliability दिखती है: sessions को cleanly resume करना होगा, plugins और hooks को clear permissions के तहत run करना होगा, auth और provider routing को governable रहना होगा, browser और terminal surfaces को plainly fail करना होगा, और SDK callers को errors चाहिए जो application तक survive करें। Runtime layer के बाद, stack बाहर की ओर shift होती है: Stanford के agent guidelines viral engineering reference बन गए, OpenAI ने frontier models और Codex को AWS Bedrock पर रखा, और Expanse ने दिखाया कि cluster-specific telemetry कैसे frontier models को GPU resource needs predict करने में मात दे सकती है। ... [NOVA]: उपयोगी thread concrete infrastructure है। Codex .136 local agent runtime को inspect और automate करना आसान बनाने के बारे में है। Stanford के CS336 guidelines informal agent behavior को explicit conventions में बदलने के बारे में हैं। OpenAI on AWS Bedrock major model families को एक enterprise control plane के पीछे रखने के बारे में है। Expanse cluster के अपने hardware signals पर trained model के साथ wasted GPU capacity कम करने के बारे में है। [ALLOY]: यह एक stack story है, लेकिन abstract तरीके से नहीं। एक coding agent real world में fail होती है क्योंकि terminal ने झूठ बोला, server ने stale state रखी, गलत model शुरू हुआ, network गिर गया, एक hook repos के बीच drift हो गया, एक permission boundary बहुत flat थी, या team ने कभी नहीं लिखा कि agent को code edit करने से पहले क्या करना चाहिए। ये ordinary failures हैं, और ordinary failures हैं जो demos को systems से अलग करती हैं जिन्हें people बार-बार use कर सकते हैं। [NOVA]: Model distribution piece उसी reason से matter करती है। अगर OpenAI और Anthropic models दोनों AWS Bedrock के through reachable हैं, तो AWS में agents run करने वाली team providers को compare कर सकती है बिना identity, networking, logging, billing और compliance को हर experiment के आसपास redesign किए। Model routing configuration जैसी ज्यादा और special integration project जैसी कम हो जाती है। [ALLOY]: Expanse underneath physical economics जोड़ता है। अगर GPU jobs बहुत ज्यादा VRAM, memory और time request करते हैं क्योंकि कोई real usage predict नहीं कर सकता, तो expensive accelerators allocated लेकिन underused बैठे रहते हैं। DCGM और CUPTI telemetry पर trained specialized model जान things जो frontier chat model prompt से नहीं जान सकता: यह cluster कैसे behave करता है, ये users कैसे over-request करते हैं, और real utilization declared intent से कहां diverge करता है। [NOVA]: तो practical signal स्पष्ट है: agent stack mystical से कम और operational ज्यादा हो रही है। Better diagnostics, stronger conventions, cloud-native routing और specialized telemetry models सब responsibility को vague model confidence से बाहर और surfaces में move करते हैं जिन्हें operators inspect कर सकते हैं। ... [ALLOY]: Codex .136 front release है क्योंकि यह उन surfaces को बदलती है जो determine करते हैं कि local agent run explainable है या नहीं। Headline एक नया model नहीं है। यह diagnostics, lifecycle handling, hooks, permissions, SDK behavior और installation automation है। यह скромा लग सकता है, लेकिन यही वे areas हैं जो तब दर्द देते हैं जब एक coding agent daily engineering work का हिस्सा बन जाती है। [NOVA]: TUI और codex doctor से शुरू करते हैं। एक फ़ेल्ड एजेंट रन चैट साइड से सरल दिख सकता है: असिस्टेंट रुक गया, कोई टूल वापस नहीं आया, या टर्मिनल ने एरर दिखाया। अंदर की तरफ, कारण कई जगह हो सकता है। शेल एनवायरनमेंट में कोई डिपेंडेंसी मिसिंग हो सकती है। प्रोवाइडर क्रेडेंशियल मौजूद हो सकता है लेकिन गलत तरीके से स्कोप्ड। रेपो उस स्टेट में हो सकता है जिसकी रनटाइम को उम्मीद नहीं थी। रिमोट ट्रांसपोर्ट ड्रॉप हो सकता है। ऐप सर्वर गलत मॉडल के साथ शुरू हो सकता है। या मॉडल कॉल फ़ेल हो सकता है जब रनटाइम पहले से अगला टर्न तैयार कर चुकी हो। [ALLOY]: बेहतर doctor आउटपुट ऑपरेटर को स्क्रॉलबैक और लॉग्स से रीकंस्ट्रक्ट करने के बजाय सबूत देता है। यह रिलीज पठनीयता बेहतर करती है और एरर्स में मजबूत लोकेशन और कारण की जानकारी जोड़ती है। यह मायने रखता है क्योंकि "कुछ फ़ेल हुआ" एक्शनेबल नहीं है। "रिमोट ट्रांसपोर्ट थ्रेड इन्वेंटरी स्टेप पूरा होने से पहले रिकवर नहीं हुआ" एक अलग लेयर की ओर इशारा करता है, "इस प्रोवाइडर कॉन्फ़िगरेशन के तहत स्टार्टअप के दौरान मॉडल सेलेक्शन फ़ेल हुआ" की तुलना में। [NOVA]: macOS और Linux पर TUI स्टेबिलिटी का काम उसी एविडेंस कैटेगरी में आता है। टर्मिनल UIs पैसिव टेक्स्ट डंप नहीं हैं। एक कोडिंग-एजेंट TUI मॉडल आउटपुट स्ट्रीम करता है, टूल कॉल्स दिखाता है, अप्रूवल्स डिस्प्ले करता है, डिफ्स रेंडर करता है, स्टेटस ट्रांज़िशंस ट्रैक करता है, और एरर पेन्स अपडेट करता है जब कई एसिंक्रोनस इवेंट्स हो रहे होते हैं। अलग-अलग टर्मिनल एमुलेटर्स, शेल्स, फॉन्ट्स, पेन्स, और कंट्रोल सीक्वेंसिज़ सभी एज केस एक्सपोज़ कर सकते हैं। [ALLOY]: जब डिस्प्ले ग्लिच करती है, ऑपरेटर अक्सर एजेंट के रीज़निंग को दोष देते हैं भले ही अंडरलाइंग टूल एक्ज़ीक्यूशन ठीक रही हो। एक स्टेल स्पिनर किसी पूर्ण हुई टास्क को हंग दिखा सकता है। एक हिडन एरर पेन लोकल कॉन्फ़िगरेशन फ़ेलियर को मॉडल कंफ्यूज़न जैसा दिखा सकता है। एक डुप्लिकेटेड लाइन ट्रांसक्रिप्ट को अनपवनर बना सकती है। क्लीनर रेंडरिंग मॉडल को स्मार्ट नहीं बनाती, लेकिन यह रनटाइम को कम भूतिया बनाती है। [NOVA]: ऐप-सर्वर लाइफसाइकल हैंडलिंग अगला बड़ा बदलाव है। Codex में एक लोकल रनटाइम शेप होता है जहां ऐप सर्वर अनुभव के महत्वपूर्ण हिस्सों को कंट्रोल करता है, इसलिए स्टार्टअप और शटडाउन सिर्फ हाउसकीपिंग नहीं हैं। ये एक रन और दूसरे के बीच, एक प्रोवाइडर कॉन्फ़िगरेशन और दूसरे के बीच, और एक रिमोट सेशन स्टेट और दूसरे के बीच की सीमा तय करते हैं। [ALLOY]: स्टार्टअप पर मॉडल सेलेक्शन अधिक भरोसेमंद होना एक गंभीर ऑपरेटर सुधार है। मॉडर्न एजेंट सेटअप तेजी से मल्टी-प्रोवाइडर हो रहे हैं। एक टीम एक एनवायरनमेंट में डायरेक्ट OpenAI एक्सेस, दूसरे में Bedrock, कम-रिस्क इंस्पेक्शन के लिए लोकल मॉडल्स, और कंस्ट्रेंड वर्क के लिए अलग प्रोवाइडर इस्तेमाल कर सकती है। अगर रनटाइम गलत मॉडल या गलत प्रोवाइडर असम्पशंस के तहत शुरू होता है, तो एजेंट अलग तरह से व्यवहार कर सकता है, अलग तरह से कॉस्ट कर सकता है, और यूज़र को पता चलने से पहले राउटिंग एक्सपेक्टेशन्स का उल्लंघन कर सकता है। [NOVA]: क्लीनर शटडाउन उतना ही ज़रूरी है। एक सर्वर जो ठीक से नहीं रुकता, पोर्ट कॉन्फ्लिक्ट्स, स्टेल स्टेट, ऑर्फंड प्रोसेसेस, या मिसलीडिंग कंटिन्यूटी छोड़ सकता है। एजेंट के साथ, स्टेल सर्वर स्टेट सिर्फ परेशान करने वाली नहीं है। यह किसी नए रन को ऐसी चीज़ें जानती हुई दिखा सकता है जो उसे नहीं चाहिए, या किसी पुराने रन को जीवित दिखा सकता है जब ऑपरेटर समझता था कि वह खत्म हो गया है। [ALLOY]: रिमोट ट्रांसपोर्ट रिकवरी एक और प्रैक्टिकल फिक्स है। रिमोट सुपरविज़न तभी काम करता है जब वह साधारण नेटवर्क रियलिटी से बचे। लोग WiFi और सेल्युलर के बीच जाते हैं। लैपटॉप स्लीप होते हैं। होम नेटवर्क हिचकप होते हैं। रिमोट होस्ट कॉर्पोरेट गेटवेज़ या अपूर्ण टनल्स के पीछे बैठे होते हैं। अगर हर इंटरप्शन एक फुल रीस्टार्ट फोर्स करता है, तो रिमोट एजेंट वर्क भंगुर हो जाता है। किसी अस्थायी नेटवर्क प्रॉब्लम के बाद तेज़ रिकवरी रनटाइम को रन शेप प्रेज़र्व करने और हर हिचकप को रिज़्यूम-ऑर-अबैंडन डिसीज़न में बदलने से बचने देता है। [NOVA]: Hooks named hooks और परमिशन स्कोप्स के ज़रिए ज़्यादा स्ट्रक्चर्ड हो रहे हैं। Hooks वो जगह हैं जहां ऑपरेटर्स लाइफसाइकल इवेंट्स पर व्यवहार अटैच करते हैं: शेल कमांड से पहले, फाइल एडिट के बाद, कमिट बाउंड्री के आसपास, प्लान के बाद, टेस्ट रन के बाद, या जब किसी प्रोजेक्ट पॉलिसी को एनफोर्स करने की ज़रूरत हो। बिना रीयूज़ के, टीम्स same hook कॉन्फ़िगरेशन हर repo में कॉपी करती हैं। [ALLOY]: कॉपी-पेस्ट किया हुआ hook कॉन्फ़िगरेशन एक रिलायबिलिटी ट्रैप है। यह सुविधा के तौर पर शुरू होता है और ड्रिफ्ट बन जाता है। एक प्रोजेक्ट में पुराना hook है। दूसरे में नया। तीसरे में कोई लोकल एडिट है जिसे कोई याद नहीं। अगर hook लॉगिंग, नोटिफिकेशन्स, फॉर्मेटिंग, पॉलिसी चेक्स, या परमिशन्स को कंट्रोल करता है, तो वह ड्रिफ्ट असली ऑपरेशनल रिस्क है। [NOVA]: नामित हुक एक व्यवहार को एक बार परिभाषित करने देते हैं और कॉन्फ़िगरेशन में रेफरेंस के रूप में उपयोग करने देते हैं। यह Codex को एक-रेपो असिस्टेंट की जगह एक स्क्रिप्टेबल एजेंट रनटाइम के करीब ले जाता है। एक टीम के पास मानक प्री-कमांड ऑडिट हुक, पोस्ट-एडिट फॉर्मेटिंग हुक, या नोटिफिकेशन हुक हो सकता है जो हाथ से मैंटेन किए गए स्निपेट की जगह एक शेयर्ड बिल्डिंग ब्लॉक बन जाता है। [ALLOY]: परमिशन स्कोप दूसरा आधा हिस्सा है। छोटे उपयोग के लिए फ्लैट परमिशन सेट ठीक है, लेकिन असली एजेंट वर्क में ट्रस्ट जोन होते हैं। फाइलें पढ़ना फाइलें एडिट करना नहीं है। यूनिट टेस्ट रन करना माइग्रेशन रन करना नहीं है। लोकल डॉक्स सर्च करना नेटवर्क कनेक्शन खोलना नहीं है। पब्लिक डॉक्स रेपो में काम करना इन्फ्रास्ट्रक्चर कोड में काम करना जैसा नहीं है। स्कोप उन अंतरों को सीधे प्रस्तुत करने देते हैं। [NOVA]: Python SDK और Node SDK अपडेट बड़े सिस्टम में Codex को एम्बेड करने के लिए महत्वपूर्ण हैं। थ्रेड मैनेजमेंट टास्क और कन्वर्सेशन स्टेट को साफ-सुथरे ढंग से दर्शाने के बारे में है। टर्न हैंडलिंग मॉडल आउटपुट, टूल एक्जीक्यूशन, यूजर इंटरवेंशन और अगले मॉडल कॉल के बीच की बाउंड्री के बारे में है। एरर प्रोपेगेशन पर्याप्त जानकारी बनाए रखने के बारे में है ताकि कॉलर यह तय कर सके कि रीट्राय करना है, मॉडल बदलना है, अप्रूवल माँगना है, कॉन्फ़िगरेशन ठीक करना है, या रुक जाना है। [ALLOY]: नॉन-इंटरैक्टिव इंस्टॉलेशन आखिरी प्रैक्टिकल पीस है। Codex नॉन-इंटरैक्टिव एनवायरनमेंट फ्लैग के साथ इंस्टॉल करने पर ज्यादा भरोसेमंद तरीके से काम करता है। यह कॉन्फ़िगरेशन मैनेजमेंट, कंटेनर सेटअप, रिमोट वर्कस्टेशन इमेज और CI-एडजेसेंट एनवायरनमेंट के लिए मायने रखता है जहाँ कोई प्रॉम्प्ट के जरिए क्लिक नहीं कर रहा होता। यह खुद में पूर्ण डिप्लॉयमेंट स्ट्रैटेजी नहीं है, क्योंकि टीमों को अभी भी क्रेडेंशियल प्लेसमेंट, सैंडबॉक्सिंग, राउटिंग पॉलिसी और अपडेट कंट्रोल की जरूरत है, लेकिन ऑटोमेटेड रोलआउट के लिए यह जरूरी प्रिमिटिव है। [NOVA]: OpenClaw 5.28 उसी भरोसेमंदता ट्रेंड को अलग हैचेस से देखता है। इसकी स्टेबल लाइन ने सesh recovery, टाइमआउट और abort क्लीनअप, सबएजेंट बाउंड्रीज, ब्राउज़र वैलिडेशन और ऑटोमेशन इनपुट हैंडलिंग को हार्डन किया है। ये बदलाव अस्पष्ट स्टेट को कम करते हैं: घोस्ट सेशन, स्टेल कंटिन्यूएशन, malformed टूल कॉल और हैपर वर्कस्पेस में स्टेट लीक करते हैं। अलग प्रोडक्ट, वही ऑपरेटर डिमांड: एजेंट को दुनिया बदलने की अनुमति दी जाए तो सुसंगत स्टेट बनाए रखना। [ALLOY]: Hermes .15.2 में मल्टी-एजेंट कोऑर्डिनेशन एंगल जुड़ा है। इसका कानबन सरफेस, ऑटो-डीकंपोजीशन, स्वॉर्म कोऑर्डिनेशन, शेड्यूल्ड टास्क, वर्कट्री-पर-टास्क आइसोलेशन, मॉडल ओवरराइड, प्रॉम्प्टवेयर डिफेंस और सीक्रेट्स-मैनेजर सपोर्ट एक टर्मिनल में एक एजेंट से कई मैनेज्ड वर्कर्स की तरफ जाने के बारे में है। कोर सवाल विजिबल ओनरशिप बन जाता है: कौन क्या कर रहा है, किस वर्कस्पेस में, किस मॉडल के तहत, किस परमिशन के साथ, और किस सबूत के साथ? [NOVA]: Claude Code दो दशमलव एक लेटेस्ट वेरिफाइड रिलीज पिक्चर में छोटा है, लेकिन पैकेजिंग डिस्टिंक्शन मायने रखती है। कई टीमें npm के जरिए CLI ट्रैक करती हैं। लेटेस्ट चैनल और स्टेबल चैनल एक ही ऑपरेशनल चॉइस नहीं हैं। जो ग्रुप स्टेबल पिन करता है वह कंट्रोल्ड रोलआउट के लिए ऑप्टिमाइज कर रहा है। जो लेटेस्ट फॉलो करता है वह तेज गति स्वीकार कर रहा है। इंजीनियरिंग वर्कफ्लो में एम्बेडेड CLI के लिए, यह सप्लाई-चेन पोस्चर है, सिर्फ वर्जन ट्रिविया नहीं। [ALLOY]: इन हैचेस अपडेट में रिएक्शन लगातार है। ऑपरेटर्स उन रिलीज को reward करते हैं जो अस्पष्टता कम करती हैं। बेहतर डायग्नोस्टिक्स, नामित हुक, परमिशन स्कोप, रिकवरेबल ट्रांसपोर्ट, आइसोलेटेड वर्कट्री और एक्सप्लिसिट पैकेज चैनल भव्य नहीं हैं, लेकिन वो सतहें हैं जो तय करती हैं कि एजेंट गंभीर वर्कफ्लो के अंदर बिना इनविजिबल रिस्क बने चल सकते हैं या नहीं। [NOVA]: एहतियात यह है कि भरोसेमंदता के दावे सिर्फ गड़बड़ वातावरण में खुद को साबित करते हैं। ट्रांसपोर्ट सुधार कॉर्पोरेट प्रॉक्सी के पीछे अभी भी अलग तरह से व्यवहार कर सकता है। डॉक्टर कमांड अभी भी किसी अजीब शेल पथ को मिस कर सकता है। नामित हुक डुप्लिकेशन कम कर सकते हैं जबकि अभी भी गवर्नेंस की जरूरत है। दिशा मजबूत है क्योंकि रिलीज सही फेलियर सतहों पर हमला कर रही हैं; जब वो सतहें असली काम में बच जाती हैं तो वैल्यू दिखती है। ... [ALLOY]: स्टैनफोर्ड का CS336 कोर्स, Language Modeling from Scratch, ने एक औपचारिक AI एजेंट गाइडलाइन दस्तावेज प्रकाशित किया, और डेवलपर समुदाय ने इसके साथ एक कोर्स आर्टिफैक्ट से ज्यादा व्यवहार किया। 24 घंटे से कम समय में 1,863 स्टार्स मिलना, किसी फाइल के लिए जिसका मकसद स्टूडेंट्स को कोडिंग एजेंट के साथ काम करने का तरीका बताना है, यह एक नाटकीय संकेत है। [NOVA]: दिलचस्प बात यह नहीं है कि स्टैनफोर्ड ने एजेंट गाइडलाइन बनाई। कई टीमों के पास पहले से ही कुछ न कुछ होता है: CLAUDE dot md, AGENTS dot md, cursor rules, project instructions, repo policy, local conventions, या वो प्रॉम्प्ट जो लोग सेशन की शुरुआत में पेस्ट करते हैं। दिलचस्प बात यह है कि एक formal course ने उन convention को explicit बनाया और broader community ने immediately उस जरूरत को पहचाना। [ALLOY]: दस्तावेज़ में task decomposition, tool-use conventions, context management, verification expectations, और agent output quality के बारे में reasoning शामिल है। यही वो जगहें हैं जहाँ agent का काम अक्सर टूट जाता है। मॉडल कोड लिख सकता है, लेकिन task खराब तरीके से decompose हो सकता है, tool sequence गलत हो सकता है, context पुराना हो सकता है, verification सतही हो सकता है, या मॉडल uncertainty को proof की तरह describe कर सकता है। [NOVA]: academic सेटिंग में, ये मुद्दे fairness और reproducibility को प्रभावित करते हैं। अगर एक student agent को autocomplete की तरह इस्तेमाल करता है और दूसरा इसे unsupervised worker की तरह, तो learning outcome की तुलना करना मुश्किल हो जाता है। अगर students generated code submit करते हैं जिसे वो explain नहीं कर सकते, तो course का assessment problem हो जाता है। अगर agent usage hidden है, तो instructors नहीं बता सकते कि काम understanding, tool operation, या blind acceptance को reflect करता है। [ALLOY]: Formal guidelines boundary को visible बनाती हैं। वो बता सकती हैं कि किस तरह की मदद acceptable है, क्या verify करना जरूरी है, generated output को कैसे inspect करना चाहिए, और किस responsibility का human के साथ रहना है। यह anti-agent नहीं है। यह agents को real tools मानता है जिन्हें operating rules चाहिए। [NOVA]: यही logic software teams पर भी लागू होता है। Informal agent habits invisible process बन जाते हैं। एक engineer agent को पूरा module rewrite करने देता है और diff accept कर लेता है। दूसरा agent को local edits तक restrict करता है। तीसरा tests generate करता है लेकिन implementation नहीं। चौथा agent को automatically commands run करने देता है। बिना shared convention के, team की real process fragments हो जाती है। [ALLOY]: CLAUDE dot md-style या AGENTS dot md-style file टीम को expectations encode करने की जगह देती है। यह agent को बता सकती है कि editing से पहले repo को explore कैसे करें, कौन से commands safe हैं, कौन से directories generated हैं, कौन से tests meaningful हैं, changes को कैसे summarize करें, और कब confirmation के लिए रुकें। यह human को भी बता सकती है कि agent को क्या evidence produce करना चाहिए जब तक काम done माना जाए। [NOVA]: key distinction guidelines के बीच prompt flavor और engineering control है। Prompt flavor कहता है, "be concise" या "act like a senior engineer." Engineering control कहता है, "parser change करने से पहले, grammar fixtures inspect करें; generated clients edit न करें; broader checks से पहले narrow parser test run करें; अगर public API बदलती है, तो migration notes update करें; semantic change explain किए बिना कभी snapshot update न करें।" [ALLOY]: viral reaction बताता है कि कई developers जानते हैं कि उनकी conventions under-specified हैं। उनके पास agents के साथ काफी अनुभव है यह जानने के लिए कि "बस model से पूछो" काफी नहीं है, लेकिन team में behavior standardize करने के लिए पर्याप्त shared language नहीं है। Stanford का document उन्हें एक concrete reference देता है, भले ही priorities एक course से आए हों। [NOVA]: एक evaluation angle भी है। अगर दो groups कहते हैं कि agent coding tasks पर अच्छा या बुरा perform करता है, लेकिन एक group detailed context और operating rules provide करता है जबकि दूसरा bare prompt इस्तेमाल करता है, तो वे same system evaluate नहीं कर रहे हैं। मॉडल सिर्फ एक component है। Instructions, tools, permissions, और environment agent का हिस्सा हैं। Formal guidelines उस composite system की तुलना करना आसान बनाती हैं। [ALLOY]: builders के लिए, सबसे अच्छा adaptation document को starting point मानना है, sacred text नहीं। Academic guidelines learning, explanation, और independent reasoning पर emphasis दे सकती हैं। Production team incident safety, code ownership, review boundaries, generated-file rules, deployment limits, और secret handling पर emphasis दे सकती है। Research team provenance, experiment logs, और reproducibility पर emphasis दे सकती है। Priorities बदलने पर भी structure transfer होती है। [NOVA]: सीमाएं हैं। गाइडलाइंस फ़ाइल परफेक्ट व्यवहार नहीं ला सकती। यह सैंडबॉक्सिंग, परमीशन, रिव्यू, या टेस्ट की जगह नहीं ले सकती। यह पुरानी हो सकती है। यह विपरीत सलाह में बदल सकती है। यह एक मॉडल की आदतों पर ओवरफिट हो सकती है और जब टीम रनटाइम बदलती है तो अटपटी हो सकती है। लेकिन ये मेंटेनेंस की समस्याएं हैं, पैटर्न से बचने के कारण नहीं। [ALLOY]: सबसे अच्छा वर्शन इतना संक्षिप्त होता है कि एजेंट इसे वास्तव में उपयोग करे और इतना ठोस होता है कि यह व्यवहार बदल दे। सामान्य वैल्यूज से भरी फ़ाइल कुछ नहीं करती। एक फ़ाइल जो रेपो के ट्रैप्स, जेनरेटेड पाथ्स, मतलबपूर्ण वेरिफिकेशन कमांड्स, रिव्यू अपेक्षाएं, और अनसर्टेंटी रूल्स समझाती है, एजेंट को एक बेहतर स्टार्टिंग पॉइंट देती है। [NOVA]: रिलीज़ इसलिए लैंड होती है क्योंकि एजेंट का काम व्यक्तिगत प्रयोग से साझा प्रैक्टिस की ओर बढ़ रहा है। एक बार जब कई लोग और कई एजेंट एक ही कोडबेस को छूते हैं, तो कन्वेंशन ऑप्शनल नहीं रहते। वे टीम के क्वालिटी को प्रिज़र्व करने और ऑटोमेशन बढ़ाते हुए काम करने का हिस्सा बन जाते हैं। ... [ALLOY]: OpenAI ने GPT-4.5, o-series मॉडल्स, और Codex को AWS Bedrock के ज़रिए उपलब्ध कराया, जो एक प्रमुख एंटरप्राइज़ डिस्ट्रीब्यूशन पैटर्न पूरा करता है। Anthropic का Claude पहले से ही Bedrock पर उपलब्ध था। अब दोनों प्रमुख लैब फैमिली एक ही AWS मॉडल-एक्सेस सरफेस के पीछे बैठ सकती हैं। [NOVA]: Bedrock इसलिए मायने रखता है क्योंकि यह सिर्फ एक और एंडपॉइंट नहीं है। एंटरप्राइज़ टीमों के लिए, यह मॉडल एक्सेस को AWS आइडेंटिटी, नेटवर्किंग, गवर्नेंस, लॉगिंग, प्रोक्योरमेंट, कोटा, और बिलिंग से जोड़ता है। एक टीम जो पहले से AWS में वर्कलोड चला रही है, वह परिचित प्रिमिटिव्स का उपयोग कर सकती है: IAM पॉलिसीज़, VPC कॉन्फ़िगरेशंस, प्राइवेट कनेक्टिविटी पैटर्न, CloudWatch लॉग्स, रीज़नल कंट्रोल्स, और केंद्रीकृत कॉस्ट मैनेजमेंट। [ALLOY]: यह एजेंट-स्टैक डिज़ाइन बदलता है। साझा क्लाउड सरफेस के बिना, मल्टी-लैब रूटिंग का मतलब अक्सर अलग-अलग क्रेडेंशियल्स, अलग SDKs, अलग लॉगिंग पाथ्स, अलग कंप्लायंस रिव्यूज़, अलग नेटवर्क एक्सेप्शंस, और अलग फेल्योर मोड्स होते हैं। OpenAI और Anthropic के Bedrock के ज़रिए उपलब्ध होने से, मॉडल सेलेक्शन एक मौजूदा क्लाउड बाउंड्री के अंदर कॉन्फ़िगरेशन जैसा हो जाता है। [NOVA]: OpenClaw, Hermes, Codex, और Claude Code ऑपरेटर्स के लिए, प्रोवाइडर डायवर्सिटी का मतलब अब इंटीग्रेशन स्प्रॉल नहीं होना चाहिए। एक टीम लंबी प्लानिंग या ध्यानपूर्ण रिव्यू के लिए Claude पसंद कर सकती है, रीज़निंग-हेवी टास्क्स के लिए OpenAI का o-series, ब्रॉड लैंग्वेज वर्क के लिए GPT-4.5, और कोड-ओरिएंटेड फ्लोज़ के लिए Codex। Bedrock उन चॉइसिज़ को एक सामान्य ऑपरेशनल डोरवे देता है। [ALLOY]: आइडेंटिटी एजेंट्स के लिए खासतौर पर ज़रूरी है क्योंकि टूल कॉल्स असली सिस्टम्स को छू सकते हैं। जब एक एजेंट रेपो पढ़ता है, इंटरनल डॉक्स क्वेरी करता है, लॉग्स इंस्पेक्ट करता है, कमांड्स रन करता है, या डिप्लॉयमेंट बदलाव तैयार करता है, तो मॉडल कॉल एक ऑडिटेबल वर्कफ़्लो का हिस्सा होता है। टीमें जानना चाहती हैं कि किसने, किस एनवायरनमेंट से, किस पॉलिसी के तहत, किस टाइमिंग और कॉस्ट के साथ मॉडल इनवोक किया। [NOVA]: IAM गार्डरेल हर एजेंट सेफ़्टी प्रॉब्लम को सॉल्व नहीं करते, लेकिन वे एक परिचित कंट्रोल लेयर देते हैं। एक ऑर्गनाइज़ेशन स्कोप कर सकता है कि कौन से रोल्स कौन से मॉडल फैमिलीज़ को इनवोक कर सकते हैं, कौन से एनवायरनमेंट्स कौन से एंडपॉइंट्स एक्सेस कर सकते हैं, और लॉग्स और कॉस्ट एलोकेशन में यूज़ेज़ कैसा दिखता है। यह लैपटॉप्स, स्क्रिप्ट्स, और लोकल एनवायरनमेंट फ़ाइल्स में बिखरे हुए डेवलपर-ओन्ड API कीज़ से गवर्न करना आसान है। [ALLOY]: VPC-बाउंड एक्सेस एक और प्रमुख अंतर है। कुछ टीमें एजेंट ट्रैफ़िक को मनमाने पब्लिक रूट्स से गुज़रने में कंफर्टेबल नहीं हैं, खासकर जब प्रॉम्प्ट्स में कोड, लॉग्स, कस्टमर-एडजेसेंट डेटा, इन्फ्रास्ट्रक्चर नेम्स, या आर्किटेक्चर डीटेल्स शामिल हो सकते हैं। क्लाउड-नेटिव रूट उन्हें ट्रैफ़िक को अप्रूव्ड नेटवर्क पैटर्न के अंदर रखने और मॉडल एक्सेस को मौजूदा सेक्योरिटी पोस्चर से जोड़ने देता है। [NOVA]: क्लाउडवॉच लॉगिंग तब भी मायने रखती है जब कुछ गलत हो जाता है। अगर कोई एजेंट रन बुरी सिफारिश करता है, बहुत आक्रामकता से दोबारा कोशिश करता है, या अप्रत्याशित टोकन जलाता है, तो ऑपरेटर को एक निशान चाहिए। जरूरी नहीं कि हर वातावरण में पूरा ट्रांसक्रिप्ट हो, क्योंकि गोपनीयता और प्रतिधारण नियम अलग-अलग होते हैं, लेकिन मॉडल चयन, समय, त्रुटि दरों, पुनः प्रयास, थ्रूपुट और लागत को समझने के लिए पर्याप्त मेटाडेटा। [ALLOY]: Claude Code ऑपरेटरों के लिए, Bedrock का पहलू मैनेज्ड-क्लाउड ऑटो मोड से जुड़ता है। जब CLI प्रोवाइडर-बैक्ड मैनेज्ड वातावरण के माध्यम से काम कर सकता है, तो मॉडल रूटिंग अनुमतियों और एक्जीक्यूशन बाउंड्रीज जैसे उसी ट्रस्ट कन्वर्सेशन का हिस्सा बन जाती है। Bedrock में OpenAI मॉडल जोड़ने का मतलब है कि मल्टी-लैब रूटिंग उस मैनेज्ड-क्लाउड पोस्चर के भीतर हो सकती है, अलग OpenAI इंटीग्रेशन पाथ के बजाय। [NOVA]: यहां एक क्लाउड-मार्केट सिग्नल भी है। प्रमुख लैब्स हाइपरस्केलर डिस्ट्रिब्यूशन चुनते हैं क्योंकि एंटरप्राइज AI खरीदारी केवल बेंचमार्क पोजीशन के बारे में नहीं है। यह प्रोक्योरमेंट है, कंप्लायंस है, आइडेंटिटी है, रीजनल उपलब्धता है, ऑडिटेबिलिटी है, सपोर्ट है, और मौजूदा स्पेंड कमिटमेंट्स हैं। एक मॉडल जिसे खरीदना और गवर्न करना आसान है, वह वर्कलोड जीत सकता है भले ही दूसरा मॉडल संकीर्ण बेंचमार्क में मजबूत दिखे। [ALLOY]: यह मॉडल चॉइस को अप्रासंगिक नहीं बनाता। लेटेंसी, थ्रूपुट, रेट लिमिट्स, कॉन्टेक्स्ट बिहेवियर, टूल-यूज क्वालिटी, स्ट्रक्चर्ड-आउटपुट रिलायबिलिटी, और लागत मॉडलों और रूट्स में काफी अलग हो सकती है। Bedrock-होस्टेड मॉडल हर ऑपरेशनल डिटेल में सीधे एक्सेस जैसा व्यवहार नहीं कर सकता। फीचर्स, स्ट्रीमिंग बिहेवियर, वर्जन उपलब्धता, रीजनल सपोर्ट, और कोटा हैंडलिंग अलग हो सकती हैं। [NOVA]: तो घोषणा एक क्षमता खोलना है, अंतिम आर्किटेक्चर निर्णय नहीं। उपयोगी दावा यह है कि रास्ता मौजूद है। अनसुलझे विवरण यह हैं कि प्रत्येक मॉडल वास्तविक एजेंट वर्कलोड के तहत कैसा प्रदर्शन करता है: कोडबेस साइज, टूल-कॉल फ्रीक्वेंसी, कॉन्टेक्स्ट लेंथ, रिट्राय बिहेवियर, कॉन्करेंसी, आउटपुट कंस्ट्रेंट्स, और अप्रूवल पैटर्न। [ALLOY]: बड़ा बदलाव यह है कि एंटरप्राइज एजेंट स्टैक्स बनासे बिना वास्तव में मल्टी-लैब बन सकते हैं। एक टीम सारांश के लिए एक मॉडल को, प्लानिंग के लिए दूसरे को, कोड जेनरेशन के लिए तीसरे को, और रिव्यू कमेंट्री के लिए चौथे को भेज सकती है जबकि आसपास के इन्फ्रास्ट्रक्चर को अधिक स्थिर रखती है। इससे स्विचिंग कॉस्ट कम होते हैं और एक्सपेरिमेंटेशन कम जोखिमभरा होता है। [NOVA]: सावधानी यह है कि रूटिंग जटिलता थिएटर बन सकती है अगर यह एविडेंस-बेस्ड नहीं है। अगर हर टास्क के लिए अस्पष्ट कारणों से अलग मॉडल है, तो डिबगिंग कठिन हो जाती है। परिपक्व पैटर्न है कि अवलोकनीय अंतरों पर रूट करें: लेटेंसी, लागत, सफलता दर, टूल-कॉल करेक्टनेस, रिव्यू क्वालिटी, कॉन्टेक्स्ट रिटेंशन, और फेलियर बिहेवियर। Bedrock उन तुलनाओं को आसान बनाती है क्योंकि आइडेंटिटी, लॉगिंग, और नेटवर्क पोस्चर अधिक सुसंगत रह सकते हैं। [ALLOY]: ड्यूल-लैब पैटर्न इसलिए क्लाउड पॉलिटिक्स के बारे में कम और ऑपरेशनल लीवरेज के बारे में अधिक है। एजेंट रनटाइम को अब प्रोवाइडर डाइवर्सिटी का पूरा बोझ नहीं उठाना पड़ता। क्लाउड कंट्रोल प्लेन अधिक आइडेंटिटी, लॉगिंग, और एक्सेस-मैनेजमेंट का काम सोख सकती है, जिससे हार्नेस सत्रों, टूल्स, अनुमतियों, कॉन्टेक्स्ट, और यूजर एक्सपीरियंस पर ध्यान केंद्रित कर सके। [NOVA]: Expanse दिलचस्प है क्योंकि यह एक आम धारणा को चुनौती देता है: सबसे आम तौर पर सक्षम मॉडल हमेशा संकीर्ण ऑपरेशनल प्रेडिक्शन टास्क के लिए सबसे अच्छा मॉडल नहीं होता। Expanse HPC और क्लाउड क्लस्टर्स के लिए GPU रिसोर्स प्रेडिक्शन पर केंद्रित है, और इसका दावा है कि क्लस्टर-विशिष्ट फाइन-ट्यून्ड मॉडल उस जॉब पर फ्रंटियर LLMs से 8x बेहतर प्रदर्शन कर सकते हैं। [ALLOY]: समस्या सादी है लेकिन महंगी। GPU जॉब्स अक्सर उन संसाधनों से अधिक का अनुरोध करते हैं जिनकी उन्हें जरूरत है क्योंकि सबमिटर को पहले से असली रनटाइम प्रोफाइल का पता नहीं होता। वे आउट-ऑफ-मेमोरी फेलियर से बचने के लिए VRAM का �_OVER_REQUEST करते हैं। वे कैंसलेशन से बचने के लिए अधिक समय रिजर्व करते हैं। वे अधिक मेमोरी या यूटिलाइजेशन हेडरूम मांगते हैं क्योंकि कम आंकना अधिक क्षमता बर्बाद करने से बदतर लगता है। [NOVA]: क्लस्टर स्केल पर, वे रक्षात्मक विकल्प एक बड़ी दक्षता समस्या बन जाते हैं। Expanse राष्ट्रीय HPC क्लस्टरों पर 59 प्रतिशत कम्प्यूट बर्बादी का हवाला देता है, एक क्लस्टर हर महीने बर्बाद कम्प्यूट पर लगभग 85 लाख डॉलर खो रहा है। इन आंकड़ों की पुष्टि हर वातावरण में होनी चाहिए, लेकिन त्वरक ऑपरेटरों के लिए यह घटना परिचित है: कतारें लंबी हैं, उपयोग असमान है, और अनुरोधित संसाधन अक्सर वास्तविक उपयोग से भिन्न होते हैं। [ALLOY]: Expanse SLURM और Kubernetes नोड्स पर एक हल्के डेमॉन के रूप में इंस्टॉल होता है। यह महत्वपूर्ण है क्योंकि ये दो प्रमुख शेड्यूलिंग दुनिया हैं। SLURM HPC, विश्वविद्यालयों, राष्ट्रीय प्रयोगशालाओं, अनुसंधान क्लस्टरों और बड़े प्रशिक्षण सेटअप में आम है। Kubernetes क्लाउड-नेटिव ML इन्फ्रास्ट्रक्चर, इन्फरेंस प्लेटफॉर्म और टीमों में आम है जो वर्कलोड को कंटेनर के रूप में पैक करती हैं। [NOVA]: टेलीमेट्री DCGM और CUPTI के माध्यम से आती है। DCGM, NVIDIA का डेटा सेंटर GPU मैनेजर, हार्डवेयर-स्तर के स्वास्थ्य और उपयोग सिग्नल एक्सपोज करता है: GPU उपयोग, मेमोरी उपयोग, तापमान, पावर, एरर कंडीशन और संबंधित ऑपरेशनल मेट्रिक्स। CUPTI, CUDA प्रोफाइलिंग टूल्स इंटरफेस, CUDA एक्टिविटी में निचले स्तर की दृश्यता देता है। साथ में, वे दिखाते हैं कि जॉब्स वास्तव में हार्डवेयर के साथ क्या करते हैं, न कि केवल यह कि उपयोगकर्ता क्या अनुरोध करते हैं। [ALLOY]: यह अंतर उत्पाद का मूल है। एक फ्रंटियर LLM जो जॉब डिस्क्रिप्शन या कोड स्निपेट पढ़ता है, वह व्यापक रूप से तर्क कर सकता है कि जॉब को क्या चाहिए। Expanse अ actual क्लस्टर व्यवहार देखता है। यह हार्डवेयर टेलीमेट्री, सबमिशन हिस्ट्री, वर्कलोड पैटर्न और स्थानीय वातावरण विवरणों से सीखता है। मॉडल क्लस्टर-विशिष्ट है न कि जेनेरिक। [NOVA]: क्लस्टर विशिष्टता मायने रखती है क्योंकि दो क्लस्टर अलग तरह से व्यवहार कर सकते हैं भले ही वे समान श्रेणी के काम चलाते हों। हार्डवेयर जनरेशन अलग होती हैं। ड्राइवर वर्जन अलग होते हैं। कंटेनर इमेज अलग होती हैं। उपयोगकर्ता स्थानीय आदतें विकसित करते हैं। एक समूह छोटे इन्फरेंस जॉब्स चलाता है, दूसरा डिस्ट्रिब्यूटेड ट्रेनिंग चलाता है, तीसरा सिमुलेशन, रेंडरिंग, जीनोमिक्स या मात्रात्मक वर्कलोड चलाता है। शेड्यूलर पॉलिसी और फेलियर हिस्ट्री यह तय करती हैं कि "सामान्य" का मतलब क्या है। [ALLOY]: एक जेनेरिक मॉडल जान सकता है कि बैच साइज VRAM को प्रभावित करता है, सीक्वेंस लेंथ मेमोरी प्रेशर बदलती है, और मिक्स्ड प्रिसिजन थ्रूपुट बदल सकता है। यह नहीं जानता कि इस क्लस्टर के उपयोगकर्ता नियमित रूप से एक विशेष GPU क्लास के लिए अधिक अनुरोध करते हैं, कि एक वर्कफ़्लो के जॉब लगातार घोषित से कम मेमोरी का उपयोग करते हैं, या कि एक कतार में अवरुद्ध रिजर्वेशन की इतिहास रही है। [NOVA]: Expanse का बेंचमार्क दावा है कि उसका दृष्टिकोण GPU रिसोर्स प्रेडिक्शन सटीकता में GPT-4.5, Claude Opus 4.8, Gemini 3.5 Pro और Codex 5.3 को 8x से हराता है। आकर्षक विवरण यह है कि मॉडल साइज सटीकता के साथ साफ तरह से सहसंबद्ध नहीं है। Claude Haiku के बारे में रिपोर्ट है कि वह कुछ वर्कलोड पर Opus को हराती है। यह बिल्कुल वही है जो आप उम्मीद करेंगे अगर टास्क लोकल टेलीमेट्री और कैलिब्रेशन पर जेनेरिक रीजनिंग डेप्थ से अधिक निर्भर करता है। [ALLOY]: एजेंट-स्टैक बिल्डरों के लिए यह एक महत्वपूर्ण पाठ है। एक जेनेरिक मॉडल प्लानिंग, कोड सिंथेसिस, एक्सप्लनेशन और व्यापक रीजनिंग में उत्कृष्ट हो सकता है जबकि फिर भी डोमेन-स्पेसिफिक प्रेडिक्शन के लिए गलत टूल हो सकता है। अगर सिग्नल हार्डवेयर मेट्रिक्स, कतार हिस्ट्री, जॉब ट्रेस और स्थानीय पैटर्न में रहता है, तो मॉडल जो उन सिग्नल्स को देखता है एक बड़े मॉडल को हरा सकता है जो केवल एक प्रॉम्प्ट देखता है। [NOVA]: रिसोर्स प्रेडिक्शन के कई ठोस आउटपुट हैं। VRAM प्रेडिक्शन यह तय करने में मदद करता है कि कोई जॉब दिए गए GPU पर फिट है या नहीं बिना बड़े डिवाइस बर्बाद किए। उपयोग प्रेडिक्शन उन जॉब्स की पहचान करता है जो महंगे त्वरक रिजर्व करते हैं लेकिन उन्हें प्रभावी ढंग से उपयोग नहीं करते। मेमोरी प्रेडिक्शन क्रैश और ओवर-एलोकेशन को कम करता है। रनटाइम प्रेडिक्शन कतार प्लेसमेंट और शेड्यूलिंग फेरनेस में सुधार कर सकती है। साथ में, ये हार्डवेयर खरीदे बिना प्रभावी क्षमता बढ़ा सकते हैं। [ALLOY]: लाइन-लेवल ऑप्टिमाइजेशन एंगल भी उल्लेखनीय है। Expanse कहता है कि यह वास्तविक रिसोर्स उपयोग के विरुद्ध कोड-लेवल बदलाव सुझा सकता है। इसका मतलब है कि यह केवल यह नहीं कह रहा है, "कम मेमोरी का अनुरोध करें।" यह उन पैटर्न्स की पहचान कर सकता है जो प्रेशर या बर्बादी पैदा कर रहे हैं: अक्षम बैच साइज, अनावश्यक टेंसर रिटेंशन, परिहार्य डेटा मूवमेंट, खराब प्रिसिजन चॉइस, या कोड जो मेमोरी को आवश्यकता से अधिक समय तक जीवित रखता है। [NOVA]: यह क्लस्टर ऑपरेशंस और डेवलपर वर्कफ़्लो के बीच का सेतु है। एक क्लस्टर एडमिन जान सकता है कि किसी यूज़र के जॉब बर्बाद हैं, लेकिन उसे कोड लेवल पर समझाने का कोई साफ़ तरीका नहीं हो सकता। एक डेवलपर कोड समझ सकता है लेकिन हार्डवेयर टेलीमेट्री नहीं देख सकता। टेलीमेट्री को ऑप्टिमाइज़ेशन सुझावों से जोड़ने वाला टूल उस बातचीत को कहीं ज़्यादा उत्पादक बना सकता है। [ALLOY]: एहतियातें सही हैं। बेंचमार्क क्लेम को स्वतंत्र रेप्लिकेशन की ज़रूरत है। 8x का आंकड़ा टास्क डेफिनिशन, डेटा डिस्ट्रीब्यूशन, बेसलाइन प्रॉम्प्टिंग, इवैलुएशन मेट्रिक्स, और सही प्रेडिक्शन को क्या माना जाए, इस पर निर्भर करता है। एक नैशनल HPC क्लस्टर स्टार्टअप इन्फरेंस फ्लीट जैसा नहीं है। Kubernetes प्लेटफ़ॉर्म जिसकी सर्विसेज़ प्रेडिक्टेबल हैं, उसका वेस्ट प्रोफ़ाइल एक-ऑफ़ एक्सपेरिमेंट चलाने वाले रिसर्च क्लस्टर से अलग हो सकता है। [NOVA]: नॉन-इनवेसिव इंटीग्रेशन पोस्चर अभी भी मायने रखता है। एक डेमन जो ऑब्ज़र्व और प्रेडिक्ट करता है, वह फुल कंट्रोल فوراً मांगने वाले शेड्यूलर रिप्लेसमेंट से ज़्यादा अपनाने में आसान है। क्लस्टर ऑपरेटर्स सतर्क रहते हैं क्योंकि शेड्यूलर क्रिटिकल इन्फ्रास्ट्रक्चर है। अगर कोई टूल मापना, प्रेडिक्ट करना, और रिकमेंड करना शुरू करता है, फिर एनफ़ोर्स करने से पहले, तो यह धीरे-धीरे ट्रस्ट बना सकता है। [ALLOY]: Expanse एक ब्रॉडर एफ़िशिएंसी फ़्यूचर की ओर भी इशारा करता है। अगली सेविंग्स की लहर सिर्फ़ बेहतर GPU, बेहतर कर्नेल, क्वांटाइज़ेशन, या सस्ते इन्फरेंस API से नहीं आएगी। यह इससे भी आएगी कि कोई जॉब चलने से पहले उसके लिए असल में क्या रिसोर्सेज़ चाहिए, यह प्रेडिक्ट करना। वेस्ट पहले से खरीदी गई क्षमता है जो प्रभावी तरीके से इस्तेमाल नहीं की गई। [NOVA]: जैसे-जैसे एजेंट ज़्यादा एक्सपेरिमेंट, फ़ाइन-ट्यूनिंग जॉब, इवैलुएशन रन, बैच इन्फरेंस, और GPU-हेवी कोड पाथ जनरेट करते हैं, यह और भी महत्वपूर्ण हो जाता है। अगर एजेंट वर्क सबमिट करना आसान बनाते हैं, तो वे हार्डवेयर बर्बाद करना भी आसान बना सकते हैं। रिसोर्स-प्रेडिक्शन लेयर ज़िम्मेदार ऑटोमेशन का हिस्सा बन जाता है। [ALLOY]: फ़ीडबैक लूप को सावधानी की ज़रूरत होगी। अगर प्रेडिक्शन यूज़र रिक्वेस्ट को प्रभावित करती हैं, और वे रिक्वेस्ट फ़्यूचर शेड्यूलिंग और टेलीमेट्री को आकार देती हैं, तो मॉडल को बुरी धारणाओं को मज़बूत करने से बचना होगा। क्लस्टर-स्पेसिफ़िक सिस्टम को नए वर्कलोड, नए हार्डवेयर, बदलते यूज़र व्यवहार, और दुर्लभ हाई-रिसोर्स जॉब के आसपास सावधानीपूर्वक हैंडलिंग की ज़रूरत है जो सच में उनकी ज़रूरतों के मुताबिक माँग करते हैं। [NOVA]: फिर भी, कोर क्लेम ठोस है क्योंकि यह एक असली बॉटलनेक पर आधारित है। AI इंडस्ट्री लगातार मॉडल इंटेलिजेंस के बारे में बात करती है, लेकिन मॉडल वर्क के आसपास की प्लंबिंग में बहुत पैसा गायब होता है: आइडल GPU, ओवर-रिज़र्व्ड जॉब, क्यू इनइफ़िशिएंसी, रीट्राई स्टॉर्म, फ़ेल्ड रन, और मिसमैच्ड हार्डवेयर। सही टेलीमेट्री पर ट्रेंड स्पेशलाइज़्ड मॉडल ज़्यादा वैल्यू क्रिएट कर सकता है जितना कि फ्रंटियर मॉडल का जेनेरिकली इस्तेमाल करने से। [ALLOY]: प्रोजेक्ट रडार के तीन लेयर हैं: हार्डवेयर एजेंट ऑपरेटिंग सिस्टम, लाइटवेट टर्मिनल कॉन्टेक्स्ट, और AI-ऑपरेटेड फ़िज़िकल मशीनों के लिए शेड्यूलिंग। ये शुरुआती प्रोजेक्ट हैं, लेकिन हर एक किसी सच्ची गैप की ओर इशारा करता है। [NOVA]: Fullive-AI का Anima हार्डवेयर इंटेलिजेंस के लिए एक ओपन-सोर्स Agent OS है, जो IoT डिवाइसेज़, रोबोटिक्स, और एज एजेंट को टारगेट करता है। यह महत्वपूर्ण है क्योंकि अधिकतर एजेंट डिस्कशन अभी भी क्लाउड VM या डेवलपर वर्कस्टेशन मानती है। एजेंट फ़ाइलें पढ़ता है, API कॉल करता है, शेल कमांड चलाता है, कोड एडिट करता है, और शायद ब्राउज़र चलाता है। हार्डवेयर एजेंट एक अलग ऑपरेटिंग एनवायरनमेंट का सामना करते हैं। [ALLOY]: हार्डवेयर एजेंट को फ़िज़िकल स्टेट के बारे में रीज़न करना होता है। सेंसर शोरिल होते हैं। एक्चुएटर फ़ेल हो सकते हैं। टाइमिंग मायने रखती है। एक कमांड के अपरिवर्तनीय फ़िज़िकल कंसीक्वेंस हो सकते हैं। दुनिया बदलती रहती है जब मॉडल सोच रहा होता है। लेटेंसी, पावर, थर्मल लिमिट, कनेक्टिविटी, और सेफ़्टी बाउंड्रीज़ मायने रखती हैं ऐसे तरीकों से जो क्लाउड-ओनली एजेंट में कम दिखती हैं। [NOVA]: हार्डवेयर एजेंट्स के लिए एक ऑपरेटिंग-सिस्टम लेयर, एम्बेडेड Linux पर LLM लगाने और raw टूल्स एक्सपोज करने की तुलना में ज़्यादा संरचित दृष्टिकोण का सुझाव देती है। OS डिवाइस, सेंसर स्ट्रीम, हार्डवेयर परमिशन, लोकल स्टेट, एज कंस्ट्रेंट्स, और परसेप्शन और एक्शन के बीच समन्वय को रिप्रेजेंट कर सकती है। यह एजेंट को फिजिकल वर्ल्ड के लिए एक कंट्रोल्ड इंटरफेस दे सकती है। [ALLOY]: Anima शुरुआती चरण में है, मॉडरेट विजिबल एडॉप्शन और बहुत हाल की एक्टिविटी के साथ, तो पोस्चर कुरियोसिटी है न कि असम्प्शन। कैटेगरी महत्वपूर्ण स्टैक एंगल है। जैसे-जैसे एजेंट्स रोबोटिक्स, स्मार्ट होम्स, इंडस्ट्रियल टूल्स, लैब ऑटोमेशन, और फील्ड डिवाइसेस में जाते हैं, रनटाइम सिर्फ एक चैट लूप with shell access नहीं हो सकता। उन्हें हार्डवेयर-अवेयर एब्स्ट्रैक्शन्स की ज़रूरत है। [NOVA]: ctx from smarthomeo कॉम्प्लेक्सिटी स्पेक्ट्रम के विपरीत छोर पर बैठती है। यह एक टर्मिनल कॉन्टेक्स्ट मैनेजर है जो कोडिंग एजेंट्स के लिए .ctx.md फाइल्स जेनरेट करती है। पैटर्न इंटेंशनली सिम्पल है: रेपो में एक मार्कडाउन फाइल सेशन्स में पर्सिस्टेंट वर्किंग कॉन्टेक्स्ट ले जाती है। [ALLOY]: कोडिंग एजेंट्स तब suffer करते हैं जब हर नया सेशन एम्नीशिया के साथ शुरू होता है। ट्रांसक्रिप्ट-ओनली कॉन्टेक्स्ट फ्रैजाइल है। अगर पिछले रन में रिलेवेंट डिसीजन हुए, तो एजेंट उन्हें देख नहीं सकता। अगर हर बार human को प्रोजेक्ट कन्वेंशन्स फिर से समझाने पड़ें, तो एजेंट धीमा और कम कंसिस्टेंट बन जाता है। फुल मेमोरी सिस्टम्स मदद कर सकते हैं, लेकिन वे setup, indexing, retrieval, governance, और maintenance overhead जोड़ते हैं। [NOVA]: एक .ctx.md फाइल हल्के वज़न का मिडल पाथ है। यह करंट टास्क स्टेट, repo कन्वेंशन्स, ओपन क्वेश्चन्स, नॉन पिटफॉल्स, ब्रांच कॉन्टेक्स्ट, टेस्टिंग नोट्स, जेनरेटेड-फाइल वार्निंग्स, या डिज़ाइन डिसीजन को प्रिज़र्व कर सकती है। एजेंट शुरू में इसे पढ़ता है और कोड छूने से पहले एक बेहतर मैप रखता है। [ALLOY]: ट्रेडऑफ यह है कि एक कॉन्टेक्स्ट फाइल खुद में इंटेलिजेंट मेमोरी नहीं है। यह automatically जानती नहीं कि क्या मायने रखता है। यह stale हो सकती है। यह बहुत लंबी हो सकती है। इसमें पुराने असम्प्शन्स शामिल हो सकते हैं। यह semantic search, code graphs, लोकल MCP सर्वर्स, या knowledge-graph memory की जगह नहीं लेती। लेकिन उसकी सिम्पलिसिटी पॉइंट है। रेपो में एक फाइल transparent, reviewable, editable, और एजेंट्स में पोर्टेबल है। [NOVA]: टीम्स के लिए, यह एक सोशल ऑब्जेक्ट बन जाती है। एक human इसे edit कर सकता है। एक एजेंट updates propose कर सकता है। एक reviewer देख सकता है कि कॉन्टेक्स्ट बदला या नहीं। अगर फाइल कहती है, "generated API clients मत edit करो," और एक एजेंट फिर भी एक को edit करता है, तो failure का diagnosis आसान है। अगर यह कहती है, "migration स्कीमा review पर ब्लॉक है," तो एक नया सेशन आगे बढ़ने से बच सकता है जैसे कि रास्ता साफ हो। [ALLOY]: agentgrid from hanfeihu AI-ऑपरेटेड फिजिकल मशीनों, टूल्स, और डेस्कटॉप्स के लिए एक ओपन शेड्यूलिंग लेयर है। यह एजेंट रनटाइम के नीचे बैठती है और तय करती है कि फिजिकल एक्शन्स कब और कैसे dispatch होते हैं। यह तय करने से अलग है कि एजेंट क्या हासिल करना चाहता है। [NOVA]: डिजिटल टूल कॉल्स को अक्सर तुरंत या reverting के लिए काफी माना जाता है। फिजिकल एक्शन्स ऐसे नहीं होते। एक रोबोट आर्म एक साथ दो पोजीशन नहीं ले सकता। एक लैब इंस्ट्रूमेंट को warm-up time चाहिए। एक डेस्कटॉप ऑटोमेशन टास्क को exclusive स्क्रीन कंट्रोल चाहिए। एक मशीन टूल में safety interlocks हो सकते हैं। एक स्मार्ट-होम एक्शन समय, occupancy, या सेंसर स्टेट पर निर्भर कर सकता है। [ALLOY]: एक शेड्यूलिंग लेयर उन कंस्ट्रेंट्स को explicit बनाती है। LLM द्वारा सीधे हर एक्शन को sequence करने के बजाय, एजेंट एक्शन्स request कर सकता है और scheduler timing, exclusivity, dependencies, और फिजिकल कंस्ट्रेंट्स को coordinate कर सकता है। मॉडल goals और plans के बारे में reasoning कर सकता है, जबकि scheduler execution reality enforce करता है। [NOVA]: जब कई एजेंट या यूज़र फिजिकल संसाधनों को शेयर करते हैं, तो यह और भी ज़रूरी हो जाता है। अगर दो एजेंट एक ही मशीन चाहते हैं, तो सिस्टम को arbitration की ज़रूरत है। अगर एक एक्शन दूसरे से पहले पूरा होना चाहिए, तो उसे dependency tracking चाहिए। अगर किसी फिजिकल एक्शन का एक सुरक्षित समय-विंडो है, तो उसे timing awareness चाहिए। प्रॉम्प्ट टेक्स्ट यह सब एन्कोड करने के लिए कमज़ोर जगह है। [ALLOY]: प्रोजेक्ट बहुत शुरुआती दौर में है, दिखने वाला adoption बहुत कम है, तो यह एक मैच्योर प्लैटफॉर्म की जगह एक रडार सिग्नल है। लेकिन शुरुआती प्रोजेक्ट्स अक्सर यह दिखाते हैं कि दर्द कहां जा रहा है। जब AI एजेंट ब्राउज़र और टर्मिनल छोड़कर डिवाइसों को टच करना शुरू करते हैं, तो scheduling एक कोर लेयर बन जाता है। [NOVA]: ये प्रोजेक्ट्स context management से भी जुड़ते हैं। Anima को hardware context चाहिए: sensors, device state, physical constraints. ctx को repo context चाहिए: task state, conventions, और open questions. agentgrid को action context चाहिए: availability, timing, exclusivity, और dispatch state. अलग-अलग एजेंट लेयर्स को अलग-अलग memory और scheduling primitives चाहिए। [ALLOY]: .ctx.md पैटर्न वह अतिरिक्त ध्यान देने योग्य है क्योंकि यह दो सामान्य अंतर्निहित स्थितियों के बीच बैठता है। Transcript-only context आसान है लेकिन भंगुर है; एक बार session खत्म होने पर, memory खो जाती है या दब जाती है। Full semantic memory richer questions का जवाब दे सकती है और बड़ी codebases में scale कर सकती है, लेकिन इसके लिए infrastructure चाहिए और stale indexes या retrieval errors आ सकती हैं। [NOVA]: Lightweight context files वे few facts जो मायने रखती हैं उन्हें preserve करती हैं बिना context को एक hidden system में बदले। वे active branches, migrations, छोटी टीमों, repo-specific rules, और उन प्रोजेक्ट्स के लिए अच्छी तरह काम करती हैं जहां humans चाहते हैं कि उन्हें agent क्या मानता है उसकी visibility मिले। वे knowledge graphs से कम powerful हैं, लेकिन inspect और correct करना आसान है। [ALLOY]: subtle failure mode है stale authority। अगर एक memory layer कुछ confidently कहती है और repo बदल गया है, तो agent पुराने guidance को follow कर सकता है। एक visible context file उस risk को कम कर सकती है क्योंकि humans उसे directly पढ़ सकते हैं, लेकिन यह फिर भी stale हो सकती है। Knowledge graphs more retrieval automate कर सकती हैं, लेकिन वे polished answer के पीछे mistakes छिपा सकती हैं। Transcript-only context persistent staleness से बचती है लेकिन continuity खो देती है। [NOVA]: सिद्धांत है freshness और authority, सिर्फ ज़्यादा information नहीं। एक current convention को एक hypothesis से अलग तरीके से treat करना चाहिए। एक completed task को एक open question से अलग तरीके से treat करना चाहिए। एक generated note को एक human-approved policy से अलग तरीके से treat करना चाहिए। ctx interesting है क्योंकि यह that working context visible बनाता है। [ALLOY]: Hardware agent systems को same discipline चाहिए। Anima-like OS layers और agentgrid-like schedulers physical context को structured तरीकों से expose कर सकते हैं: device state, sensor readings, constraints, action queues, और safety boundaries। बिना उसके, model को brittle tool descriptions और delayed feedback के through physical world infer करनी पड़ती है। [NOVA]: Radar items दिखाते हैं कि agent stack चौड़ा हो रहा है। यह अब सिर्फ model, prompt, और tool नहीं है। यह है runtime, context file, memory layer, hardware OS, scheduler, cloud model surface, telemetry model, और permission boundary। हर लेयर इसलिए है क्योंकि raw model capability अकेले operational coordination solve नहीं करती। [ALLOY]: Codex .136 immediate runtime release है समझने के लिए। इसकी value है readable doctor output, बेहतर error location और cause, more stable TUI rendering, cleaner app-server startup और shutdown, more reliable model selection, faster transport recovery, named hooks, permission scopes, SDK improvements, और more dependable non-interactive installation। साथ में, वे local और remote agent operation को less ambiguous बनाते हैं। ... [NOVA]: OpenClaw 5.28 और Hermes .15.2 state और coordination के आसपास एक ही trend को frame करते हैं। OpenClaw recovery, session boundaries, subagent isolation, browser safety, और stricter automation inputs पर focus करता है। Hermes multi-agent work surfaces पर focus करता है: kanban, decomposition, swarm topology, worktree isolation, scheduled tasks, model overrides, promptware defense, और secrets handling। Common theme managed workers है, loose conversations नहीं। [ALLOY]: Claude Code two point one latest operational picture में इसलिए belongs क्योंकि package channels matter करते हैं। Engineering workflows के अंदर इस्तेमाल होने वाला एक CLI runtime supply chain का part है। Stable pin करना और latest track करना different risk decisions हैं, खासकर जब tool developer machines, managed workspaces, या CI-adjacent environments पर run करता है। [NOVA]: Stanford की CS336 guidelines सबसे clear sign हैं कि agent behavior conventions formal infrastructure बन रहे हैं। एक guidelines file humans और agents को shared contract देती है: tasks कैसे decompose करने हैं, कौन से tools use करने हैं, context कैसे manage करना है, क्या evidence expect किया जाता है, और uncertainty कैसे handle करनी चाहिए। Viral reaction से पता चलता है कि developers एक concrete reference का इंतज़ार कर रहे थे। [ALLOY]: AWS Bedrock पर OpenAI enterprise agents के लिए model distribution बदल देता है। GPT-4.5, o-series models, और Codex को Claude के साथ available रखने पर, teams एक cloud control plane से major labs के बीच route कर सकते हैं। IAM, VPC patterns, logging, quotas, billing, और compliance reviews model surface के ज़्यादा हिस्से cover कर सकते हैं। Multi-lab routing custom integration project से कम हो जाता है। [NOVA]: Caveat यह है कि Bedrock availability हर route पर identical behavior नहीं है। Teams को अभी भी latency, throughput, cost, feature parity, regional support, streaming behavior, quota limits, और हर model की tool-heavy workloads में performance समझनी होगी। Value यह है कि वो comparisons एक ज़्यादा consistent operational environment में हो सकते हैं। [ALLOY]: Expanse याद दिलाता है कि specialized infrastructure models तब general frontier models को beat कर सकते हैं जब signal local और measurable हो। GPU resource prediction cluster telemetry, user behavior, scheduler patterns, hardware generation, और workload history पर depend करता है। एक cluster-specific model जो उन signals देखता है, एक बड़े general model से बेहतर perform कर सकता है जो सिर्फ text से reason करता है। [NOVA]: Economic implication direct है। Wasted GPU allocation कम करने से बिना नया hardware खरीदे capacity unlock हो सकती है। यह research clusters, training platforms, inference fleets, और हर उस organization के लिए matter करता है जहाँ accelerator access bottleneck है। जैसे-जैसे agents compute-heavy work generate और submit करना आसान बनाते हैं, resource prediction और भी important हो जाता है। [ALLOY]: Project radar edges fill in करता है। Anima hardware-aware agent operating systems की तरफ इशारा करता है IoT, robotics, और edge devices के लिए। ctx lightweight persistent context की तरफ .ctx.md files के ज़रिए। agentgrid physical machine actions के लिए scheduling layers की तरफ। ये interchangeable tools नहीं हैं; ये signs हैं कि stack physical state, working memory, और coordinated action dispatch में फैल रहा है। [NOVA]: Context-management takeaway simple है: हर team को full memory system की ज़रूरत नहीं है। Transcript-only context अक्सर बहुत weak होता है, full knowledge graphs बहुत heavy हो सकते हैं, और एक visible context file right intermediate layer हो सकता है। Best memory layer facts preserve करता है जो agent को चाहिए बिना stale notes को hidden authority बनाए। [ALLOY]: Operational takeaway यह है कि infrastructure visible हो रही है। Diagnostics failures को explainable बनाते हैं। Guidelines expectations को legible बनाते हैं। Bedrock model routing को governable बनाता है। Telemetry models compute waste को measurable बनाते हैं। Hardware OS और scheduling projects physical action constraints को explicit बनाते हैं। Context files agent assumptions को inspect करना आसान बनाते हैं। [NOVA]: यही एक परिपक्व एजेंट स्टैक दिखता है: कम रहस्य, अधिक सीमाएं, अधिक साक्ष्य, और अधिक विशेषज्ञ परतें जो वे काम करती हैं जो कच्चे मॉडल बुद्धिमत्ता अपने आप अच्छी तरह नहीं कर पाती। [ALLOY]: AgentStack Daily सुनने के लिए धन्यवाद। लिंक और स्रोत विवरण के लिए Toby On Fitness Tech dot com पर शो नोट्स देखें। हम जल्द ही वापस आएंगे।