Codex रिमोट कंट्रोल, एजेंट RCE हार्डनिंग, Copilot सेशन हुक, और Microsoft एजेंट फ्रेमवर्क 1.5

[00:00] Codex 0.130.0 coding-agent ऑपरेटरों को एक साफ़ नियंत्रण विमान प्रदान करता है। मुख्य फ़ीचर codex remote-control है, जो एक headless app-server शुरू करने के लिए एक सरल प्रवेश बिंदु है जिसे दूर से नियंत्रित किया जा सकता है। यह मायने रखता है क्योंकि coding agents अब केवल terminal tools नहीं हैं। वे app-server sessions हैं जिनमें threads, configuration snapshots, plugin surfaces, review events, file views, और remote clients शामिल हैं जिन्हें मूल terminal के अंदर बैठे बिना काम का निरीक्षण करना या जारी रखना पड़ सकता है। इस रिलीज में paged thread views, plugin hook metadata, बेहतर live config refresh, partial patch failures के बाद अधिक सटीक turn diffs, multi-environment image resolution, और review paths को debug करने के लिए समृद्ध telemetry भी शामिल है।

[02:00] STORY 1 — OpenAI Codex 0.130.0 Adds Remote-Control App Servers, Paged Thread Views, Plugin Hook Visibility, and Better State Repair remote-control entrypoint से शुरू करें। एक headless app-server एक one-shot CLI run से अलग परिचालन वस्तु है। Server sessions, threads, configuration, environment selection, tool execution, और client connections का स्वामित्व रखता है। एक शीर्ष-स्तरीय codex remote-control कमांड जोड़ने से उस नियंत्रण विमान को सीधे शुरू करने का घर्षण कम हो जाता है। Dashboard, IDE, browser clients, या remote development machines में coding agents को embed करने वाले builders के लिए, वह सतह एक स्थानीय सहायक को service endpoint में बदल देती है।

महत्वपूर्ण तंत्र नियंत्रण और कार्य का पृथक्करण है। App-server एक coding session को जीवित रख सकता है जबकि एक client पुनः कनेक्ट होता है, एक बड़े thread के माध्यम से पेज करता है, एक summary view खोलता है, या केवल आवश्यकता पड़ने पर एक पूर्ण आइटम view का अनुरोध करता है। Codex 0.130.0 में large-thread paging जोड़ता है जहाँ clients unloaded, summary, या full turn item views का अनुरोध कर सकते हैं। यह सिर्फ़ UI की चमक नहीं है। Agent threads बड़े हो सकते हैं क्योंकि इनमें user turns, model turns, tool calls, diffs, file references, approvals, images, और compacted summaries शामिल होते हैं। हर client में सब कुछ लोड करना मेमोरी बर्बाद करता है, latency बढ़ाता है, और remote clients को भंगुर बनाता है।

एक paged thread API app-server को thread materialization को एक contract के रूप में व्यवहार करने का स्थान देता है। एक unloaded आइटम payload को स्थानांतरित किए बिना क्रम और पहचान बनाए रख सकता है। एक summary आइटम navigation के लिए पर्याप्त संदर्भ दे सकता है। एक full turn आइटम तब लाया जा सकता है जब उपयोगकर्ता विवरण खोलता है। यह पैटर्न logs, traces, और issue timelines से परिचित है, और coding agents को अब इसकी जरूरत है क्योंकि उनके transcripts संचालन रिकॉर्ड हैं, सिर्फ़ चैट टेक्स्ट नहीं।

Plugin details अब bundled hooks दिखाते हैं, और plugin sharing link metadata के साथ-साथ discoverability controls को उजागर करता है। Hooks एक plugin के वास्तविक runtime behavior का हिस्सा हैं। यदि एक plugin startup को संशोधित कर सकता है, एक tool call का निरीक्षण कर सकता है, एक कमांड प्रदान कर सकता है, या review में भाग ले सकता है, तो ऑपरेटरों को इसे install या share करने से पहले देखना होगा। एक package के अंदर hooks छिपाना plugin review को guesswork में बदल देता है। Plugin details में उन्हें दिखाना execution surface को auditable बनाता है।

रिलीज में live app-server configuration behavior की मरम्मत भी शामिल है। Live app-server threads अब बिना restart की आवश्यकता के config changes उठाते हैं। एक agent runtime में, configuration में model choices, approval policies, provider settings, tool availability, plugin state, environment selection, और telemetry options शामिल हो सकते हैं। यदि एक लंबे समय से चल रहा thread stale config का उपयोग करता रहता है, तो ऑपरेटर यह मान सकते हैं कि उन्होंने नीति बदल दी जबकि एक सक्रिय agent पुरानी सेटिंग्स के साथ जारी रहता है। नवीनतम config snapshot से live threads को refresh करना नीति परिवर्तनों को वहाँ प्रभावी बनाता है जहाँ काम हो रहा है।

Turn diffs को एक विशेष रूप से व्यावहारिक fix मिलता है। Codex अब apply_patch operations के दौरान diffs को सटीक रखता है, जिसमें partial failures शामिल हैं जो फ़ाइलों को फिर भी mutate करते हैं। यह failure mode मायने रखती है। एक patch बीच में fail हो सकती है लेकिन फिर भी फ़ाइल का कुछ हिस्सा बदल सकती है। यदि runtime बाद में गलत diff रिपोर्ट करता है, तो उपयोगकर्ता review view, rollback logic, या audit trail पर भरोसा नहीं कर सकता। Operation-backed diff tracking सही दिशा है: यह रिकॉर्ड करें कि operation ने वास्तव में क्या बदला, न कि ideal patch क्या बदलने वाला था।

ThreadStore fixes summaries, renames, resume, और fork paths को बेहतर बनाते हैं, जिसमें local rollout paths के बिना threads शामिल हैं। इसका मतलब है कि thread storage layer अधिक lifecycle operations के लिए truth का स्रोत बन रहा है। Resume और fork coding agents के लिए विशेष रूप से महत्वपूर्ण हैं क्योंकि एक उपयोगकर्ता एक investigation को branch करना चाह सकता है, एक failed run जारी रखना चाह सकता है, या एक remote client से एक thread खोलना चाह सकता है जिसमें मूल local rollout path नहीं है। यदि thread identity स्थानीय filesystem state पर बहुत निर्भर करती है, तो remote और headless workflows टूट जाते हैं।

Remote compaction को भी stream-contract fixes मिलते हैं। Codex अब v2 streams के लिए response.processed emit करता है और API-key compact requests पर service_tier भेजने से बचता है। Compaction वह तरीका है जिससे लंबे sessions उपयोगी रहते हैं, लेकिन remote compaction को app-server के बाकी हिस्से जैसी ही event language बोलनी चाहिए। एक गुम processed event clients को terminal state की प्रतीक्षा में छोड़ सकती है। compact request पर unsupported fields भेजना केवल compaction path को तोड़ सकता है जबकि सामान्य turns अभी भी काम करते हैं, जिसका निदान करना कठिन है।

Multi-environment support view_image में दिखाई देता है, जो अब चयनित environment के माध्यम से फ़ाइलों को resolve कर सकता है। Coding agents अक्सर host, container, sandbox, remote workspace, या mounted project में संचालित होती हैं। एक image path तब तक सार्थक नहीं है जब तक runtime नहीं जानता कि कौन सा environment उसका मालिक है। चयनित environment के माध्यम से resolve करना एक client को गलती से गलत filesystem देखने या एक artifact प्रदर्शित करने में विफल होने से रोकता है जो सक्रिय sandbox के अंदर मौजूद है।

Bedrock authentication support अब aws login profiles से AWS console-login credentials स्वीकार करता है। यह operator convenience है जिसका real deployment impact है। कई teams पहले से profile-based flows के माध्यम से AWS access manage करते हैं। Codex को उन profiles का उपयोग करने देना duplicate credential paths को reduce करता है और model-provider auth को existing cloud access controls के साथ align करता है।

Telemetry changes production debugging के लिए useful हैं। Codex configurable OpenTelemetry trace metadata और richer review तथा feedback analytics जोड़ता है। Review events coding-agent safety का core part हैं। यदि कोई command approve, denied, retry, या escalate की गई थी, तो operators को यह समझने के लिए पर्याप्त trace context चाहिए। Good telemetry एक session, turn, tool call, approval decision, model request, और user-visible result को secrets leak किए बिना connect करनी चाहिए।

Practical recommendation यह है कि Codex app-server deployments को service deployments की तरह treat करें। Version pin करें, remote-control को deliberately start करें, document करें कि कौन से clients connect कर सकते हैं, sharing से पहले plugin hooks audit करें, configuration refresh behavior को mind में रखें, और patch failure cases test करें। Release केवल new commands के बारे में नहीं है; यह coding agent को controllable, inspectable, और recoverable बनाने के बारे में है जब sessions बड़ी हो जाती हैं और remotely run होती हैं।

[16:00] STORY 2 — Microsoft's Semantic Kernel RCE Research Turns Prompt Injection into a Tool-Execution Boundary Lesson

Microsoft का security post एक direct reminder है कि prompt injection तब और खतरनाक हो जाती है जब language tools से wired होती है। Case study में model vulnerable component नहीं है। Model text receive करता है, tool call करने का निर्णय लेता है, और tool arguments fill करता है। Vulnerable boundary वह framework और plugin code है जो those arguments पर trust करता है और उन्हें executable host behavior में बदलता है।

First disclosed issue Semantic Kernel के In-Memory Vector Store search path पर केंद्रित है। Example agent एक hotel search function expose करता है। User एक city में hotels के लिए पूछता है। Model एक city argument के साथ search plugin call करता है। Plugin vector similarity से पहले dataset narrow करने के लिए एक deterministic filter build करता है। Risky step यह है कि एक model-controlled argument एक Python lambda expression में interpolated होता है और फिर eval() के साथ execute होता है।

यही execution boundary है। एक normal city value एक filter expression बन जाती है। एक malicious value quote close कर सकती है और Python logic append कर सकती है। Prompt injection को browser exploit, malicious attachment, या memory corruption की जरूरत नहीं है। उसे agent framework की जरूरत है जो एक language-derived parameter ले और उसे executable expression में रख दे। एक बार ऐसा होने पर, prompt injection code injection बन गया है।

Attempted mitigation ने AST validation और एक restricted builtins environment का उपयोग किया। High level पर, validator lambda expressions allow करता था, names और attributes को dangerous identifiers के लिए scan करता था, और __builtins__ remove करके execute करता था। यह reasonable लगता है, लेकिन dynamic languages blocklists को fragile बनाते हैं। Microsoft's researchers ने obvious blocked names directly use किए बिना filter bypass किया। Payload ने Python object structures traverse किया import machinery locate करने के लिए और alternate attributes के माध्यम से system command execution तक पहुँचने के लिए।

Lesson simply "eval का उपयोग न करें" नहीं है। Broader lesson यह है कि tool-call arguments untrusted input हैं भले ही वे model से आए हों, भले ही user ने directly code type न किया हो, और भले ही schema कहता हो कि field एक city name है। Model को attacker-controlled strings किसी भी argument में place करने के लिए induce किया जा सकता है जिसे वह fill करने की अनुमति रखता है। यदि tool फिर उस string को code, query language, shell command, file path, या template के रूप में interpret करता है, तो framework ने एक injection sink create कर दिया है।

Vector search इसे underestimate आसान बनाती है क्योंकि यह retrieval infrastructure की तरह feel होती है code execution की तरह नहीं। लेकिन vector stores अक्सर metadata filters, expression languages, custom predicates, embedding prefilters, rerankers, और connector-specific query strings support करते हैं। इनमें से हर एक एक injection boundary बन सकता है यदि user या model-controlled values interpreted expression में concatenated हों। Safe design आमतौर पर parameterized filters, typed DSLs, allowlisted operators, और validation शामिल करती है जो execution से पहले unexpected structure को reject करती है।

A robust fix को default path से string-code construction remove करना चाहिए। Lambda string generate करने के बजाय, एक framework typed fields और operators से predicate build कर सकती है। उदाहरण के लिए, field equals value data होनी चाहिए, source code नहीं। यदि filter language अनavoidable है, तो runtime को एक constrained AST में parse करना चाहिए और एक interpreter के साथ evaluate करना चाहिए जो केवल allowed operations को समझती है। इसे host language evaluator call नहीं करना चाहिए और फिर dangerous behavior block करने की कोशिश नहीं करनी चाहिए।

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

डिटेक्शन व्यावहारिक है। एजेंट फ्रेमवर्क का उपयोग करने वाली टीमों को उन टूल्स का इन्वेंट्री बनाना चाहिए जो टेम्पलेट, फ़िल्टर, शेल कमांड, नोटबुक सेल, Python स्निपेट, JavaScript स्निपेट, SQL, या फ़ाइल ऑपरेशंस निष्पादित करते हैं। उन्हें उन इंटरप्रेटर्स में पास किए गए मॉडल-नियंत्रित वैल्यूज की तलाश करनी चाहिए। उन्हें Semantic Kernel और संबंधित पैकेज को पैच करना चाहिए, लेकिन कस्टम प्लगइन की भी समीक्षा करनी चाहिए क्योंकि वही पैटर्न एप्लिकेशन कोड में भी दिखाई देता है। प्रॉम्प्ट-इंजेक्शन सिक्योरिटी केवल मॉडल-इवैल्यूएशन की समस्या नहीं है; यह टूल रनटाइम के लिए इनपुट वैलिडेशन और निष्पादन आइसोलेशन है।

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

[28:00] कहानी 3 — GitHub Copilot SDK में प्लान-अप्रूवल और रेट-लिमिट मोड हुक्स के साथ-साथ क्रॉस-SDK डायग्नोस्टिक्स जोड़ता है

Copilot SDK 8 मई प्री-रिलीज एजेंट सेशन को अधिक स्पष्ट रनटाइम कंट्रोल के साथ प्रोडक्ट्स में एम्बेड करने के बारे में है। एप्लिकेशन अब exitPlanMode.request और autoModeSwitch.request के लिए कॉलबैक्स रजिस्टर कर सकते हैं। वे इवेंट्स मायने रखती हैं क्योंकि प्लान मोड और स्वचालित मॉडल स्विचिंग प्रोडक्ट निर्णय हैं, न कि केवल मॉडल निर्णय।

प्लान मोड काम का प्रस्ताव रखने और करने के बीच की सीमा है। एम्बेडेड कोडिंग एजेंट में, एप्लिकेशन किसी मानव को प्लान अप्रूव करने, पॉलिसी इंजन से जांचने, या किसी प्रोजेक्ट-विशिष्ट नियम को कुछ बदलावों को ब्लॉक करने के लिए चाह सकती है। नए हैंडलर्स एप्लिकेशन को यह तय करने देते हैं कि exit-plan-mode रिक्वेस्ट अप्रूव है या नहीं। यह होस्ट प्रोडक्ट को रनटाइम को प्लानिंग से निष्पादन में ले जाने से पहले एक स्पष्ट इंटरसेप्शन पॉइंट देता है।

रेट लिमिट्स के बाद स्वचालित मॉडल स्विचिंग एक अलग प्रकार की सीमा है। रनटाइम दूसरे मॉडल या मोड पर जाकर रेट-लिमिट इवेंट्स से रिकवर करना चाह सकता है। यह निरंतरता बनाए रख सकता है, लेकिन यह व्यवहार, लागत, विलंबता या क्षमता को भी बदल सकता है। autoModeSwitch.request हैंडलर एप्लिकेशन को यह तय करने देता है कि उस स्विच को स्वीकार किया जाए या नहीं। एंटरप्राइज प्रोडक्ट्स के लिए, यह महत्वपूर्ण है क्योंकि मॉडल चॉइस डेटा पॉलिसी, कंप्लायंस, इवैल्यूएशन बेसलाइन या बजट कंट्रोल से जुड़ा हो सकता है।

रिलीज में .NET, Python और Rust में स्ट्रक्चर्ड डायग्नोस्टिक्स भी जोड़ता है। लॉग्स CLI स्टार्टअप, TCP कनेक्शन, JSON-RPC रिक्वेस्ट टाइमिंग, सेशन लाइफसाइकल और एरर पाथ को कवर करते हैं। यह एम्बेडेड एजेंट SDK के लिए यही विजिबिलिटी है। जब कोई सेशन फेल होता है, तो कारण प्रोसेस स्टार्टअप, ट्रांसपोर्ट, ऑथ, JSON-RPC फ्रेमिंग, रनटाइम इवेंट हैंडलिंग, मॉडल रिस्पॉन्स, टूल निष्पादन या होस्ट कॉलबैक व्यवहार हो सकता है। स्ट्रक्चर्ड टाइमिंग और लाइफसाइकल लॉग्स के बिना, हर फेलियर "एजेंट हंग गया" जैसा दिखता है।

JSON-RPC विवरण पर प्रकाश डालने योग्य है। कई कोडिंग-एजेंट SDK एक लोकल रनटाइम प्रोसेस रैप करते हैं और JSON-RPC पर संवाद करते हैं। इसका मतलब है कि एप्लिकेशन में एक क्लाइंट ऑब्जेक्ट है, एक रनटाइम प्रोसेस है, एक ट्रांसपोर्ट कनेक्शन है, रिक्वेस्ट ID हैं, इवेंट स्ट्रीम्स हैं और लॉन्ग-रनिंग ऑपरेशंस हैं। डायग्नोस्टिक्स को दिखाना चाहिए कि रनटाइम कब स्टार्ट हुआ, TCP कनेक्शन कब खुला, कौन से JSON-RPC रिक्वेस्ट भेजे गए, उन्हें कितना समय लगा, और एरर्स कहाँ सतह पर आए। अन्यथा एप्लिकेशन डेवलपर्स SDK के दुरुपयोग और रनटाइम फेलियर में अंतर नहीं कर पाएंगे।

enableSessionTelemetry विकल्प टेलीमेट्री को एक स्पष्ट सेशन चॉइस बनाता है। यह प्राइवेसी और ऑपरेशंस के लिए सही आकार है। कुछ डिप्लॉयमेंट्स इंसू बग करने और प्रोडक्ट क्वालिटी में सुधार के लिए आंतरिक सेशन टेलीमेट्री चाहते हैं। दूसरों को पॉलिसी द्वारा इसे डिसेबल करने की आवश्यकता है। सेशन कॉन्फ़िगरेशन और रीज्यूम कॉन्फ़िगरेशन पर नॉब रखने से निर्णय ऑडिटेबल और दोहराने योग्य हो जाता है छिपी डिफ़ॉल्ट्स पर भरोसा करने के बजाय।

छोटे कम्पैटिबिलिटी फिक्सेस हैं जो लॉन्ग-लिव्ड SDK यूजर्स के लिए मायने रखते हैं। C# सेशन-इवेंट एनम्स अब स्ट्रिंग-बैक्ड readonly स्ट्रक्ट्स हैं ताकि डिसिरियलाइज़ेशन तब न फेल हो जब रनटाइम नए एनम वैल्यू जोड़ता है। यह इवेंट स्ट्रीम्स के लिए फॉरवर्ड कम्पैटिबिलिटी है। Rust बाइनरी टूल रिज़ल्ट रिसोर्स ब्लॉब्स अब mimeType के अनुपस्थित होने पर application/octet-stream पर डिफ़ॉल्ट करते हैं। यह वायर-फॉर्मेट रेज़िलिएंस फिक्स है। दोनों बदलाव रनटाइम और SDK के अलग-अलग गति से विकसित होने पर ब्रेकेज को कम करते हैं।

व्यावहारिक बिल्डर निहितार्थ यह है कि Copilot SDK सत्र होस्ट-नियंत्रित रनटाइम ऑब्जेक्ट बन रहे हैं। यदि आप उन्हें एम्बेड करते हैं, तो प्लान-मोड और मोड-स्विच कॉलबैक को सोच-समझकर इम्प्लीमेंट करें। तय करें कि कौन से स्विच स्वचालित हो सकते हैं और किनकी समीक्षा की जरूरत है। डेवलपमेंट और स्टेजिंग में डायग्नोस्टिक्स चालू करें। धीमे या फ्लैकी सत्रों के आसपास JSON-RPC टाइमिंग कैप्चर करें। टेलीमेट्री को पॉलिसी निर्णय के रूप में मानें। और पुराने क्लाइंट्स को नए रनटाइम इवेंट्स के विरुद्ध टेस्ट करें ताकि enum और इवेंट फॉरवर्ड कम्पैटिबिलिटी आपको चौंकाए नहीं।

[38:00] स्टोरी 4 — Microsoft Agent Framework 1.5 ऑर्केस्ट्रेशन, ऑब्जर्वेबिलिटी, ब्राउज़र-टूल पॉलिसी और वायर सिमेंटिक्स को आगे बढ़ाता है Microsoft Agent Framework का 8 मई का रिलीज व्यापक है, लेकिन कई बदलाव प्रोडक्शन एजेंट बिल्डर के लिए सीधे प्रासंगिक हैं। .NET लाइन में Magentic Orchestration, WebBrowsingTool allowlisting, hosted-agent observability सैम्पल, AGUI में reasoning इवेंट्स, todo मल्टीथ्रेडिंग सुधार, और Foundry per-call क्लाइंट हेडर जोड़ता है। Python लाइन आसपास class-based स्किल्स और experimental harness कॉन्टेक्स्ट प्रोवाइडर जोड़ता है। रिलीज tool-output वायर फॉर्मेट, वर्कफ़्लो लूप्स, YAML पार्सिंग, मल्टीपार्टी सीरियलाइज़ेशन और सीक्वेंस नंबरिंग को भी फिक्स करता है।

Magentic Orchestration हेडलाइन है क्योंकि मल्टी-एजेंट सिस्टम को एजेंट्स की सूची से ज्यादा की जरूरत है। उन्हें शेड्यूलिंग, डेलिगेशन, टर्न ओनरशिप, शेयर्ड स्टेट, टर्मिनेशन कंडीशन्स और यह तय करने का तरीका चाहिए कि किस एजेंट को अगला काम करना चाहिए। एक ऑर्केस्ट्रेशन लेयर उन मैकेनिक्स को औपचारिक बनाता है। इसे experimental के रूप में मार्क करना उचित है क्योंकि ऑर्केस्ट्रेशन सिमेंटिक्स एप्लिकेशन आर्किटेक्चर बन जाते हैं: एक बुरा शेड्यूलर लूप कर सकता है, काम की डुप्लिकेट कर सकता है, फेलियर्स छिपा सकता है, या एक एजेंट को बातचीत पर हावी होने दे सकता है।

WebBrowsingTool allowlisting एक महत्वपूर्ण ब्राउज़र/कंप्यूटर-यूज़ कंट्रोल है। ब्राउज़िंग टूल्स एक एजेंट को बाहरी कंटेंट से जोड़ते हैं जो मैलिशियस, अनट्रस्टेड, या बस डिस्ट्रैक्टिंग हो सकता है। एक allowlist होस्ट एप्लिकेशन को एक पॉलिसी सरफेस देता है कि कौन से ब्राउज़िंग डेस्टिनेशन्स या ब्राउज़र बिहेवियर्स की अनुमति है। एजेंट सिस्टम में, ब्राउज़िंग सिर्फ पढ़ना नहीं है। ब्राउज़र प्रॉम्प्ट-इंजेक्शन कंटेंट फेच कर सकता है, फॉर्म सबमिट कर सकता है, रीडायरेक्ट फॉलो कर सकता है, कुकीज़ एक्सपोज़ कर सकता है, और फाइल्स रिट्रीव कर सकता है। पॉलिसी टूल चलने से पहले मौजूद होनी चाहिए।

Hosted-agent observability सैम्पल भी मूल्यवान हैं क्योंकि डिप्लॉयमेंट वह जगह है जहां फ्रेमवर्क एब्स्ट्रैक्शन प्रोडक्शन रियलिटी से मिलते हैं। एक hosted agent को लॉग, ट्रेस, रिक्वेस्ट करिलेशन, मॉडल-कॉल विजिबिलिटी, टूल-कॉल टाइमिंग और फेलियर स्टेट की जरूरत है। Observability सैम्पल उन टीमों के लिए रेफरेंस पैटर्न बन सकते हैं जो वरना एजेंट्स को सिर्फ कंसोल लॉग के साथ शिप करेंगी। किसी भी hosted agent के लिए उपयोगी सवाल यह है: क्या हम एक विफल रन को एक्सटर्नल रिक्वेस्ट से ऑर्केस्ट्रेशन डिसीजन, मॉडल कॉल, टूल कॉल और फाइनल रिस्पॉन्स तक रीकंस्ट्रक्ट कर सकते हैं?

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

Todo मल्टीथ्रेडिंग और मैसेज लिस्ट में todo इंजेक्शन दिखाते हैं कि स्टेट मैनेजमेंट रनटाइम फीचर कैसे बनता है। एजेंट्स प्लान करने, प्रोग्रेस ट्रैक करने और इंटरप्शन के बाद रिकवर करने के लिए todo लिस्ट्स का उपयोग करते हैं। यदि todo स्टेट थ्रेड-सेफ नहीं है, तो कंकरेंेंट अपडेट्स प्लान को करप्ट कर सकते हैं। यदि todo स्टेट मैसेज कॉन्टेक्स्ट में विजिबल नहीं है, तो मॉडल कमिटमेंट्स का ट्रैक खो सकता है। मैसेज लिस्ट में todos इंजेक्ट करना task स्टेट को मॉडल कॉन्टेक्स्ट का हिस्सा बनाता है, जबकि मल्टीथ्रेडिंग सुधार अपडेट्स के आसपास race conditions को कम करते हैं।

function_call_output.output वायर-फॉर्मेट फिक्स छोटा लेकिन क्रिटिकल है। रिलीज इसे वायर पर एक JSON स्ट्रिंग होने के लिए फिक्स करता है। टूल आउटपुट फॉर्मेट रनटाइम, SDKs, मॉडल्स और क्लाइंट्स के बीच कॉन्ट्रैक्ट्स हैं। यदि एक तरफ स्ट्रिंग की उम्मीद है और दूसरी तरफ स्ट्रक्चर्ड JSON सीधे भेजता है, तो डीसिरियलाइज़ेशन या रीप्ले फेल हो सकता है। एजेंट फ्रेमवर्क्स को इन वायर कॉन्ट्रैक्ट्स के बारे में सख्त होना चाहिए क्योंकि टूल आउटपुट्स अक्सर स्टोर, स्ट्रीम, कॉम्पैक्ट और बाद में रीज्यूम किए जाते हैं।

सीक्वेंस नंबर जेनरेशन को डुप्लिकेट या आउट-ऑफ-ऑर्डर IDs के लिए फिक्स मिलता है। इवेंट ऑर्डरिंग एजेंट UIs और लॉग्स के लिए फाउंडेशनल है। यदि दो इवेंट्स एक सीक्वेंस नंबर शेयर करते हैं या असंगत ऑर्डरिंग के साथ आते हैं, तो क्लाइंट्स स्टेल स्टेट रेंडर कर सकते हैं, अपडेट्स ड्रॉप कर सकते हैं, या टूल रिज़ल्ट्स को गलत तरीके से एसोसिएट कर सकते हैं। मल्टी-एजेंट या मल्टीपार्टी बातचीत में, ऑर्डरिंग बग्स विशेष रूप से दर्दनाक हैं क्योंकि यूजर बता नहीं सकता कि किस एजेंट ने पहले क्या कहा या किया।

वर्कफ़्लो री-एंट्री और YAML पार्सिंग फिक्सेस डिक्लेरटिव-एजेंट रिलायबिलिटी की बात करते हैं। GotoAction री-एंट्री के बाद QuestionExecutor लूप वह तरह का बग है जो डिक्लेरटिव वर्कफ़्लो सुविधा को आउट-ऑफ-कंट्रोल बिहेवियर में बदल देता है। फाइल स्किल्स के लिए YAML ब्लॉक स्केलर पार्सिंग मायने रखती है क्योंकि फाइल-बेस्ड स्किल डेफिनिशन्स में अक्सर प्रॉम्प्ट्स, इंस्ट्रक्शन्स, उदाहरण या स्क्रिप्ट्स होते हैं। यदि ब्लॉक स्केलर्स गलत तरीके से पार्स होते हैं, तो एजेंट जो स्किल देखता है वह वह स्किल नहीं है जो डेवलपर ने लिखी।

व्यावहारिक सिफारिश है कि इस रिलीज़ को प्रोडक्शन सतहों के माध्यम से मूल्यांकन करें। यदि आप Microsoft Agent Framework का उपयोग करते हैं, तो जांचें कि ऑर्केस्ट्रेशन अगले एक्टर को कैसे चुनता है, बाहरी साइटों से कनेक्ट करने से पहले ब्राउज़र-टूल allowlists परिभाषित करें, rollout से पहले observability को जोड़ें, reasoning इवेंट्स को एक शासित UI चैनल के रूप में मानें, concurrency के तहत todo state का परीक्षण करें, और टूल आउटपुट के लिए wire compatibility को मान्य करें। फ्रेमवर्क रिलीज़ केवल नए abstractions नहीं हैं; वे runtime contracts में बदलाव हैं जिन पर आपका एप्लिकेशन निर्भर करता है।

[50:00] समापन EP048 से व्यावहारिक takeaway operational है। Codex 0.130.0 coding-agent सत्रों को remote-control app servers, paged thread views, plugin hook visibility, config refresh, और patches और compaction के आसपास बेहतर recovery के साथ अधिक service-like बनाता है। Microsoft's Semantic Kernel research दिखाता है कि model-controlled tool arguments code execution कैसे बन सकते हैं यदि frameworks उन्हें interpreted host-language expressions में बदलते हैं। GitHub Copilot SDK embedded products को approval और recovery hooks plus diagnostics देता है। Microsoft Agent Framework 1.5 orchestration, browser policy, observability, event transport, todo state, और wire-format correctness को आगे बढ़ाता है। builders के लिए, काम हर agent runtime boundary को explicit बनाना है: control plane, tool input, approval event, browser policy, telemetry, और stored thread state।