- लंबे समय तक चलने वाले एजेंटों के लिए होस्टेड सेवा Managed Agents ने इंटरफ़ेस-आधारित आर्किटेक्चर अपनाया है, जो harness मॉडल के विकास के साथ बदलने पर भी स्थिर रहता है
- harness उन कामों के बारे में धारणाओं को encode करता है जिन्हें Claude अकेले नहीं कर सकता, लेकिन मॉडल बेहतर होने पर ये धारणाएँ पुरानी (stale) हो जाती हैं और अनावश्यक overhead पैदा करती हैं
- जैसे operating system हार्डवेयर को process और file जैसी abstractions के रूप में virtualize करता है, वैसे ही Managed Agents एजेंट के घटकों (session, harness, sandbox) को virtualize करता है ताकि उन्हें स्वतंत्र रूप से बदला जा सके
- दिमाग (harness) और हाथ (sandbox) को अलग करके p50 TTFT लगभग 60% कम हुआ, जबकि p95 में 90% से अधिक की कमी आई
- यह डिज़ाइन भविष्य में किसी भी harness या sandbox के आने पर उन्हें समायोजित कर सकने वाले meta-harness की भूमिका निभाता है
harness की धारणाएँ मॉडल के विकास के साथ पुरानी हो जाती हैं
- harness एक ऐसी संरचना है जो उन कामों के बारे में धारणाएँ encode करती है जिन्हें Claude अपने आप नहीं कर सकता, लेकिन मॉडल बेहतर होने पर वही धारणाएँ अनावश्यक हो जाती हैं
- Claude Sonnet 4.5 में context limit नज़दीक आने पर काम को जल्दी समाप्त कर देने वाली "context anxiety" की प्रवृत्ति थी, इसलिए harness में context reset जोड़ा गया
- Claude Opus 4.5 में यह व्यवहार गायब हो गया, इसलिए reset logic अनावश्यक code बन गया
- क्योंकि harness के लगातार बदलते रहने की उम्मीद थी, इसलिए एक ऐसे Managed Agents service का निर्माण किया गया जो किसी विशेष implementation पर निर्भर न हो और generic interface पर आधारित हो
operating system से प्रेरित डिज़ाइन दर्शन
- operating system हार्डवेयर को process, file जैसी abstractions के रूप में virtualize करता है, ताकि ऐसे programs भी चल सकें जो अभी मौजूद नहीं हैं
- जैसे
read() command 1970 के दशक के disk pack पर भी और आधुनिक SSD पर भी एक जैसा काम करती है, वैसे ही abstraction हार्डवेयर से अधिक समय तक टिकती है
- Managed Agents भी इसी पैटर्न का पालन करते हुए एजेंट के घटकों को virtualize करता है
- session: अब तक हुई सभी events का append-only log
- harness: Claude को call करने और tool calls को route करने वाला loop
- sandbox: वह execution environment जहाँ Claude code चलाता है और files edit करता है
शुरुआती डिज़ाइन: एकल container की सीमाएँ ("Pet" समस्या)
- शुरुआत में session, harness और sandbox को एक ही container में रखा गया था
- इसका फायदा यह था कि file editing सीधे syscall से हो सकती थी और service boundary डिज़ाइन करने की ज़रूरत नहीं थी
- लेकिन इससे container के "pet" (ऐसा अलग instance जिसे बदला नहीं जा सकता) बन जाने की समस्या पैदा हुई
- container fail होने पर session खो जाता था
- response न आने पर container को manually recover करना पड़ता था
- debugging के नज़रिए से केवल WebSocket event stream के आधार on यह पता लगाना संभव नहीं था कि failure कहाँ हुआ, और container में shell access करने पर उसमें user data शामिल होने के कारण debugging खुद मुश्किल हो जाती थी
- harness यह मानकर चलता था कि सभी work targets container के अंदर हैं, इसलिए ग्राहक की VPC connectivity की मांग आने पर network peering या उनके अपने environment में harness चलाने की ज़रूरत पड़ती थी
दिमाग और हाथों का अलगाव (मुख्य आर्किटेक्चर)
- "दिमाग" (Claude और harness), "हाथ" (sandbox और tools), और "session" (event log) को अलग-अलग स्वतंत्र interfaces में विभाजित किया गया
- हर घटक स्वतंत्र रूप से fail हो सकता है या बदला जा सकता है
harness का container से बाहर निकलना
- harness को container के बाहर ले जाया गया, और वह container को दूसरे tools की तरह
execute(name, input) → string के माध्यम से call करने लगा
- इससे container "cattle" (आसानी से बदले जा सकने वाले instances) में बदल गया
- container fail होने पर harness इसे tool call error की तरह संभालता है, और अगर Claude retry का फैसला करता है तो
provision({resources}) के ज़रिए नया container initialize करता है
harness failure recovery
- क्योंकि session log harness के बाहर मौजूद है, इसलिए harness के अंदर ऐसा कोई state नहीं है जिसे ज़िंदा रहना ज़रूरी हो
- failure होने पर
wake(sessionId) → getSession(id) से event log लाया जाता है और आखिरी event से फिर शुरू किया जाता है
- harness agent loop के दौरान
emitEvent(id, event) के माध्यम से durable event records बनाए रखता है
security boundary
- coupled design में Claude द्वारा बनाया गया untrusted code credentials वाले उसी container में चलता था, जिससे prompt injection के माध्यम से environment variables की चोरी संभव थी
- अगर हमलावर token हासिल कर ले, तो वह बिना किसी सीमा के नए sessions बना सकता है और काम delegate कर सकता है
- इसका structural solution यह था कि sandbox को इस तरह अलग किया जाए कि उसे token तक कभी पहुँच ही न हो
- Git: repository access token के साथ sandbox initialize करते समय clone किया जाता है और local git remote से जोड़ा जाता है, ताकि एजेंट token को सीधे संभाले बिना
push/pull कर सके
- MCP custom tools: OAuth token को secure vault में रखा जाता है, और एक dedicated proxy के माध्यम से MCP tool call करते समय session से जुड़े token के आधार पर vault से credentials निकालकर external service call की जाती है
session, Claude की context window नहीं है
- लंबे चलने वाले काम अक्सर Claude की context window length से आगे निकल जाते हैं, इसलिए क्या बनाए रखना है इस पर irreversible decisions लेने पड़ते हैं
- compaction: Claude context window का summary सहेजता है
- memory tool: Claude context को files में लिखता है ताकि sessions के बीच सीखना संभव हो
- context trimming: पुराने tool results या thinking blocks जैसे चुने हुए tokens को हटाना
- irreversible context discard विफलता का कारण बन सकता है, क्योंकि यह अनुमान लगाना कठिन है कि भविष्य के turn में कौन से tokens चाहिए होंगे
- पहले के शोध में context को context window के बाहर मौजूद object की तरह store करने और LLM से code लिखवाकर उसे programmatically access करने के तरीकों का अध्ययन किया गया
Managed Agents में session log का उपयोग
- session, context window के बाहर मौजूद context object की भूमिका निभाता है
- इसे sandbox या REPL में नहीं, बल्कि session log में durable रूप से store किया जाता है
getEvents() interface के ज़रिए event stream के position-based slices चुने जा सकते हैं
- आखिरी read point से आगे पढ़ना
- किसी खास समय से पहले के कुछ events को rewind करके देखना
- किसी विशेष action से पहले का context दोबारा पढ़ना
- लाए गए events को harness में transform करने के बाद Claude की context window में भेजा जा सकता है
- इस transformation में बेहतर prompt cache hit rate के लिए context cleanup और context engineering शामिल हैं
- session केवल durable storage और retrieval की गारंटी देता है, जबकि concrete context management harness को सौंपा जाता है ताकि भविष्य के models की बदलती ज़रूरतों के अनुसार काम किया जा सके
कई दिमाग, कई हाथ
कई दिमाग (Many Brains)
- दिमाग और हाथों को अलग करने से शुरुआती ग्राहकों की शिकायत दूर हुई: VPC के भीतर resources पर काम करने के लिए अब network peering की ज़रूरत नहीं रही
- शुरुआती डिज़ाइन में हर दिमाग के लिए container चाहिए होता था, इसलिए container provisioning पूरा होने तक inference शुरू नहीं हो सकता था
- जिन sessions को sandbox की ज़रूरत नहीं थी, वे भी repository clone, process boot, pending events fetch जैसी पूरी container setup cost उठाते थे
- अलगाव के बाद container केवल जरूरत पड़ने पर tool call के रूप में provision किया जाता है, जिससे अनावश्यक latency हट गई
- orchestration layer session log से pending events लाते ही inference शुरू कर सकती है
- p50 TTFT लगभग 60% कम, p95 TTFT 90% से अधिक कम
- कई दिमागों तक scale करना बस कई stateless harnesses शुरू करना है, जो जरूरत पड़ने पर ही हाथों से जुड़ते हैं
कई हाथ (Many Hands)
- हर दिमाग को कई execution environments से जोड़ने की क्षमता चाहिए
- Claude को कई execution environments के बारे में reasoning करनी होती है और काम का बँटवारा तय करना होता है, इसलिए यह एक single shell से ज़्यादा cognitive रूप से कठिन काम है
- शुरुआत में मॉडल की सीमित क्षमता के कारण दिमाग को single container में रखा गया था, लेकिन intelligence बढ़ने पर वही single container उल्टा बाधा बन गया
- अलग किए गए डिज़ाइन में हर हाथ को
execute(name, input) → string tool की तरह माना जाता है
- custom tools, MCP servers, और in-house tools सभी समर्थित हैं
- harness को यह जानने की ज़रूरत नहीं कि sandbox container है, phone है, या Pokémon emulator
- क्योंकि दिमाग और हाथ आपस में जुड़े नहीं हैं, इसलिए एक दिमाग से दूसरे दिमाग को हाथ सौंपना भी संभव है
निष्कर्ष: meta-harness के रूप में Managed Agents
- यह वही दृष्टिकोण है जिसमें operating system हार्डवेयर को virtualize करके ऐसे programs को भी समायोजित करता है जो अभी मौजूद नहीं हैं
- Managed Agents किसी खास harness पर निर्भर नहीं रहने वाला meta-harness है, जो अलग-अलग harnesses को समायोजित करने के लिए generic interface देता है
- Claude Code को भी एक harness की तरह इस्तेमाल किया जा सकता है, और task-specific agent harnesses भी समायोजित किए जा सकते हैं
- interfaces को लेकर इसका रुख स्पष्ट है: Claude को state manipulate करने (session) और computation करने (sandbox) की क्षमता चाहिए
- कई दिमाग और कई हाथों तक विस्तार, और लंबी अवधि तक स्थिर व सुरक्षित संचालन के लिए interface डिज़ाइन किया गया है
- यह दिमाग और हाथों की संख्या या स्थान के बारे में कोई धारणा नहीं बनाता
अभी कोई टिप्पणी नहीं है.