वर्चुअल कंपनी का भ्रम: इंजीनियरिंग में रोल-आधारित मल्टी-एजेंट आर्किटेक्चर क्यों विफल होते हैं

**

AI समुदाय में व्यापक रूप से प्रचलित एक आर्किटेक्चरल विचार कई टीमों को गलत दिशा में ले जा रहा है।

पहले निष्कर्ष

यदि आप कई AI एजेंटों को "प्रोडक्ट मैनेजर", "आर्किटेक्ट" और "टेस्ट इंजीनियर" जैसे नाम देने और उन्हें कंपनी के विभागों की तरह दस्तावेज़ पास करके सहयोग करने पर विचार कर रहे हैं—कृपया रुक जाएँ।

यह मॉडल सहज और तार्किक लगता है, लेकिन इंजीनियरिंग में इसकी मूलभूत कमियाँ हैं। इससे भी महत्वपूर्ण बात यह है कि तीनों प्रमुख प्रदाता—Anthropic, OpenAI और Google—अपने स्वयं के Agent सिस्टम बनाते समय इस मॉडल का उपयोग नहीं करते हैं।

यह कोई संयोग नहीं है।

"तीन विभाग और छह मंत्रालय" आर्किटेक्चर क्या है?

यह रूपक समुदाय में व्यापक रूप से लोकप्रिय मल्टी-एजेंट डिज़ाइन विचारों के एक वर्ग को संदर्भित करता है, जिसे विभिन्न फ्रेमवर्क और लेखों में अलग-अलग नामों से जाना जाता है: भूमिका-आधारित एजेंट, वर्चुअल टीमें, CrewAI-शैली का श्रम विभाजन, या MetaGPT-शैली का संगठन। यह लेख सामूहिक रूप से उन्हें "विभागीकृत" मॉडल कहता है।

मुख्य पैटर्न है: एक जटिल कार्य को कई कार्यों में विघटित करना, प्रत्येक Agent एक भूमिका निभाता है—PM आवश्यकताओं के लिए, Tech Lead आर्किटेक्चर के लिए, Dev कार्यान्वयन के लिए, और QA परीक्षण के लिए। कार्य एजेंटों के बीच एक असेंबली लाइन की तरह प्रवाहित होते हैं।

यह मॉडल आरेख पर बहुत अच्छा दिखता है। यह "श्रम विभाजन" के लिए मानवीय अंतर्ज्ञान को संतुष्ट करता है और "AI टीम" की अवधारणा को ठोस और समझाने योग्य बनाता है। CrewAI जैसे फ्रेमवर्क ने इसी कारण से कई उपयोगकर्ता जमा किए हैं।

समस्या यह है कि यह मानवीय बाधाओं को हल करता है, AI बाधाओं को नहीं।

यह उपमा मौलिक रूप से गलत क्यों है?

मनुष्यों को श्रम विभाजन की आवश्यकता है क्योंकि:

• एक व्यक्ति का ध्यान सीमित होता है और वह सभी जानकारी को एक साथ संसाधित नहीं कर सकता।
• मनुष्यों में पेशेवर बाधाएँ और उच्च सीखने/स्विचिंग लागत होती है।
• मनुष्यों को एक दूसरे के साथ समन्वय करने के लिए इंटरफेस की आवश्यकता होती है।

लेकिन LLM विशेषताएँ पूरी तरह से अलग हैं:

• एक ही मॉडल PRD और कोड दोनों लिख सकता है; कोई "पेशेवर सीमाएँ" नहीं हैं।
• मॉडलों के लिए बाधा ध्यान अवधि नहीं है, बल्कि तर्क गहराई और सूचना अखंडता है।
• मॉडलों में सूचना हानि की भरपाई करने के लिए "संस्कृति" और "मौन समझ" का अभाव है।

एक Agent को "प्रोडक्ट मैनेजर" का लेबल लगाने से वह अधिक पेशेवर नहीं बनता—यह उसे सीमाएँ पार करने से मना करने पर मजबूर करता है। "टेस्ट इंजीनियर" की भूमिका में बंधा एक Agent किसी आर्किटेक्चरल मुद्दे को इसलिए छोड़ सकता है क्योंकि "यह मेरे दायरे में नहीं है।" सबसे मूल्यवान तर्क अक्सर सीमाओं पर होता है, और विभागीकृत मॉडल सिस्टम स्तर पर इस संभावना को बंद कर देता है।

भूमिका-निर्वाह नकली सीमाएँ बनाता है। यह पहली समस्या है।

दूसरी समस्या: सूचना संचरण में मर जाती है

विभागीकृत मॉडल में, Agent A एक दस्तावेज़ तैयार करता है और उसे Agent B को देता है।

यह प्रक्रिया निष्कर्ष पास करती है, तर्क प्रक्रिया नहीं।

B दस्तावेज़ प्राप्त करता है, उसे पुनः समझता है, और संदर्भ का पुनर्निर्माण करता है। मूल आशय क्षीण हो जाता है, छिपी हुई मान्यताएँ खो जाती हैं, और प्रत्येक हैंडऑफ त्रुटि जमा करता है। वर्कफ़्लो जितना लंबा होगा, अंतिम आउटपुट उतना ही अधिक "स्थानीय रूप से सही लेकिन वैश्विक रूप से विचलित" हो जाता है—प्रत्येक नोड उचित दिखता है, लेकिन समग्र मूल लक्ष्य से भटक गया है।

मानव संगठन इस सूचना हानि की भरपाई के लिए बैठकों, संस्कृति और अनौपचारिक संचार पर निर्भर करते हैं। एजेंटों के पास ये तंत्र नहीं हैं।

एक सामान्य प्रतिवाद है: क्या तीनों प्रमुख प्रदाताओं (progress.txt, spec फ़ाइलें, runbooks) के समाधानों में भी "फ़ाइलें पास करना" शामिल नहीं है? क्या अंतर है?

अंतर इस बात में है कि कौन लिखता है, यह किसके लिए है, और इसे कैसे अपडेट किया जाता है।

विभागीकृत सूचना प्रवाह भूमिकाओं के बीच एकतरफा हैंडऑफ है: A समाप्त करता है और B को देता है; B पीछे मुड़कर नहीं देखता, और A को नहीं पता कि B ने दस्तावेज़ का उपयोग कैसे किया। सूचना निष्कर्षों में संपीड़ित हो जाती है, तर्क प्रक्रिया खो जाती है, और हैंडऑफ एक ब्रेकपॉइंट है।

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

यह अंतर यह निर्धारित करता है कि तर्क श्रृंखला सत्रों में निरंतर रह सकती है या नहीं।

एजेंटों के बीच "हैंडऑफ फ़ाइलों" पर भारी मात्रा में टोकन बर्बाद होते हैं, वास्तविक तर्क पर नहीं। आपको एक सिस्टम मिलता है जो कंपनी के व्यवहार का अनुकरण करता है, न कि एक सिस्टम जो समस्याओं को हल करता है।

तीनों प्रमुख प्रदाता वास्तव में यह कैसे करते हैं?

यह उल्लेखनीय है कि जब Anthropic, OpenAI और Google अपने प्रोडक्शन-ग्रेड Agent सिस्टम बनाते हैं, तो उनके इंजीनियरिंग दस्तावेज़ लगभग कभी भी "भूमिका-निर्वाह" या "विभागीय विभाजन" का उल्लेख नहीं करते हैं।

Anthropic: कॉन्टेक्स्ट इंजीनियरिंग + स्पष्ट स्थिति फ़ाइलें

Anthropic ने "प्रॉम्प्ट इंजीनियरिंग" को "कॉन्टेक्स्ट इंजीनियरिंग" में अपग्रेड किया है: सवाल यह नहीं है कि एक अच्छा प्रॉम्प्ट कैसे लिखा जाए, बल्कि कौन सा टोकन कॉन्फ़िगरेशन वांछित व्यवहार उत्पन्न करने के लिए सबसे अच्छा है?

Claude Code और Research सिस्टम बनाते समय, उनकी मुख्य चुनौती थी: एजेंटों को अलग-अलग सत्रों में काम करना होता है, और प्रत्येक नए सत्र को पिछले सत्र की कोई याद नहीं होती। उनका रूपक "शिफ्ट इंजीनियर" है—इंजीनियरों की प्रत्येक नई शिफ्ट को पिछली शिफ्ट के काम के बारे में कुछ नहीं पता।

समाधान एजेंटों को अलग-अलग भूमिकाएँ देना नहीं है, बल्कि:

• claude-progress.txt: एक क्रॉस-सेशन वर्क लॉग जिसे Agent प्रत्येक सत्र के अंत में अपडेट करता है और अगले सत्र की शुरुआत में पढ़ता है।
• Git हिस्ट्री: स्थिति एंकर के रूप में कार्य करना, प्रत्येक वृद्धिशील परिवर्तन को रिकॉर्ड करना।
• इनिशियलाइज़र Agent: केवल पहले सत्र में चलता है ताकि वातावरण सेट कर सके, फीचर सूची का विस्तार कर सके, और सभी बाद के सत्रों के लिए रनबुक लिख सके।

मुख्य अंतर्दृष्टि: तर्क श्रृंखला की निरंतरता मॉडल के "याद रखने" पर निर्भर नहीं करती; यह इसे एंकर करने के लिए स्पष्ट बाहरी स्थिति पर निर्भर करती है।

उन्होंने यह भी पाया कि हार्नेस में "मॉडल क्षमता धारणाओं" को हार्ड-कोड करना खतरनाक है। Sonnet 4.5 में "कॉन्टेक्स्ट चिंता" थी—यह कॉन्टेक्स्ट सीमा के करीब पहुँचने पर जल्दी समाप्त हो जाता था, इसलिए उन्होंने हार्नेस में एक कॉन्टेक्स्ट रीसेट जोड़ा। लेकिन Opus 4.5 में, यह व्यवहार गायब हो गया, और रीसेट बेकार हो गया। यह दर्शाता है कि हार्नेस को मॉडल के साथ विकसित होने की आवश्यकता है; कोई भी "स्थायी समाधान" वर्तमान चरण के लिए सिर्फ एक इंजीनियरिंग समझौता है।

मल्टी-एजेंट Research सिस्टम में, Anthropic का आर्किटेक्चर ऑर्केस्ट्रेटर-वर्कर है: एक लीड एजेंट कार्यों को विघटित करता है और सबएजेंटों का समन्वय करता है, जो समानांतर में विभिन्न दिशाओं का पता लगाते हैं, परिणाम संश्लेषण के लिए लीड एजेंट को वापस प्रवाहित होते हैं। उन्होंने पाया कि अकेले टोकन खपत ने 80% प्रदर्शन अंतरों की व्याख्या की—मल्टी-एजेंट का मूल्य "श्रम विभाजन" नहीं है, बल्कि एक बड़े खोज स्थान को कवर करने के लिए अधिक टोकन का उपयोग करना है।

यहाँ एक भ्रम का बिंदु है: Anthropic के सबएजेंट "श्रम विभाजन" की तरह लग सकते हैं, लेकिन सार अलग है। विभागीकरण कार्यात्मक विभाजन है—विभिन्न भूमिकाएँ विभिन्न प्रकार के काम को संभालती हैं (PM से Dev से QA)। Anthropic के सबएजेंट कार्यात्मक समानता हैं—कई समान एजेंट एक साथ विभिन्न दिशाओं की खोज करते हैं, कोई "अगला हैंडऑफ" नहीं है, और सभी परिणाम एक ही ऑर्केस्ट्रेटर में वापस आते हैं। पहला एक रिले रेस है; दूसरा एक विस्तृत जाल बिछाना है।

OpenAI: कॉम्पैक्शन + स्किल्स + स्ट्रक्चर्ड स्पेक फ़ाइलें

लंबी अवधि के कार्यों के लिए OpenAI के सिद्धांत और भी सीधे हैं: कार्य की शुरुआत में निरंतरता की योजना बनाएं।

अपने Codex प्रयोगों में, इंजीनियरों ने एजेंट को एक स्पेक फ़ाइल दी (लक्ष्य को फ्रीज करना ताकि एजेंट को "प्रभावशाली लेकिन गलत दिशा में" कुछ बनाने से रोका जा सके), इसे एक माइलस्टोन-आधारित योजना उत्पन्न करने के लिए कहा, और फिर एजेंट को बताने के लिए एक रनबुक फ़ाइल का उपयोग किया कि कैसे काम करना है। यह रनबुक एक साझा मेमोरी और ऑडिट लॉग भी है।

परिणाम: GPT-5.3-Codex लगभग 25 घंटे तक लगातार चला, एक पूर्ण डिज़ाइन टूल पूरा किया, जबकि पूरे समय सुसंगतता बनाए रखी।

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

उन्होंने स्किल्स की अवधारणा भी पेश की—कंटेनरों में माउंट किए गए पुन: प्रयोज्य, संस्करणित निर्देश सेट, जो एजेंटों को विशिष्ट कार्यों के लिए स्थिर संचालन मानक प्रदान करते हैं। ये "भूमिकाएँ" नहीं हैं; ये उपकरण और संचालन प्रक्रियाएँ हैं, जो मौलिक रूप से भिन्न हैं।

Google: 1M कॉन्टेक्स्ट + कॉन्टेक्स्ट-संचालित विकास

Google की दिशा विंडो को बलपूर्वक बढ़ाना है: Gemini का 1M टोकन कॉन्टेक्स्ट एक स्पष्ट विभेदीकरण रणनीति है। उनका तर्क है कि पहले से मजबूर तकनीकें जैसे RAG स्लाइसिंग और पुराने संदेशों को हटाना, पर्याप्त बड़ी विंडो दिए जाने पर "सब कुछ एक साथ रखने" से बदला जा सकता है।

लेकिन वे स्वीकार करते हैं कि यह भी पर्याप्त नहीं है। Google ने Gemini CLI के लिए Conductor एक्सटेंशन लॉन्च किया, जिसका मुख्य विचार Anthropic के समान है: प्रोजेक्ट के इरादे को चैट विंडो से बाहर और कोडबेस में स्थायी Markdown फ़ाइलों में ले जाएँ। दर्शन: "अस्थिर चैट इतिहास पर भरोसा न करें; औपचारिक स्पेक और प्लान फ़ाइलों पर भरोसा करें।"

Gemini 3 ने थॉट सिग्नेचर भी पेश किए: लंबे सत्रों में तर्क श्रृंखला के प्रमुख नोड्स को सहेजना ताकि "तर्क बहाव"—लंबे संदर्भों में तार्किक असंगति की समस्या—को रोका जा सके।

वास्तविक आर्किटेक्चरल सिद्धांत क्या हैं?

इन तीनों कंपनियों की इंजीनियरिंग प्रथाओं से, कई सामान्य सिद्धांत निकाले जा सकते हैं:

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

स्पष्ट बाहरी स्थिति, मॉडल मेमोरी पर भरोसा न करें। चाहे वह progress.txt हो, git हिस्ट्री, spec फ़ाइलें, या डेटाबेस—रूप मायने नहीं रखता। सिद्धांत है: तर्क श्रृंखला के प्रमुख नोड्स को स्थायी भंडारण में बाहरीकृत किया जाना चाहिए।

मल्टी-एजेंट का मूल्य समानांतर कवरेज है, श्रम विभाजन नहीं। Anthropic के Research सिस्टम का निष्कर्ष स्पष्ट है: प्रदर्शन लाभ "अधिक टोकन खर्च करने" से आता है, न कि "बेहतर श्रम विभाजन" से। मल्टी-एजेंट चौड़ाई-प्रथम कार्यों के लिए उपयुक्त हैं—ऐसे परिदृश्य जिनमें स्वतंत्र दिशाओं की एक साथ खोज की आवश्यकता होती है। वे निरंतर तर्क और गहरी संदर्भ निर्भरता की आवश्यकता वाले परिदृश्यों के लिए उपयुक्त नहीं हैं।

वेरिफायर Agent एक इनकार करने वाला है, रिले धावक नहीं। यदि गुणवत्ता नियंत्रण के लिए मल्टी-एजेंट का उपयोग कर रहे हैं, तो सही डिज़ाइन यह है कि एक Agent विशेष रूप से दूसरे के काम में समस्याएँ खोजे, न कि "काम का परिणाम पास करे।" प्रतिकूल परीक्षण, असेंबली लाइन स्थानांतरण नहीं।

उपकरण उपकरण हैं, भूमिकाएँ नहीं। आप एक Agent को किन उपकरणों (bash, फ़ाइल I/O, खोज, कोड निष्पादन) से सुसज्जित करते हैं, यह उस पर लगाए गए लेबल से कहीं अधिक महत्वपूर्ण है। उपकरण यह निर्धारित करते हैं कि एक Agent क्या कर सकता है; भूमिका लेबल केवल यह सीमित करते हैं कि वह क्या करने को तैयार है।

"विभागीकृत" मॉडल लोकप्रिय क्यों है?

क्योंकि इसे समझाना आसान है।

"यह Agent PM है, वह QA है"—कोई भी इसे समझ सकता है। यह AI सिस्टम की व्याख्यात्मकता के लिए मानवीय इच्छा और प्रबंधन की "AI के एक टीम की तरह काम करने" की कल्पना को संतुष्ट करता है।

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

लेकिन समझाना और प्रदर्शित करना आसान होना इंजीनियरिंग रूप से सही होने से अलग है।

एक गहरा कारण यह है कि इस मॉडल को अपनाने वाली अधिकांश टीमों ने वास्तव में "मल्टी-एजेंट स्थानांतरण के दौरान संदर्भ हानि" की समस्या का सामना नहीं किया है। उनके कार्य पर्याप्त जटिल नहीं हो सकते हैं, या समस्या अन्य कारकों द्वारा छिपी हुई है। एक बार जब कार्य जटिलता बढ़ जाती है और सिस्टम "स्थानीय रूप से सही लेकिन वैश्विक रूप से गलत" त्रुटियाँ दिखाना शुरू कर देता है, तो समस्या उजागर हो जाती है।

व्यावहारिक सलाह

सबसे अच्छा मल्टी-एजेंट सिस्टम किसी कंपनी की तरह नहीं दिखता। यह एक विचारक के कई ड्राफ्ट की तरह अधिक दिखता है—एक ही मस्तिष्क विभिन्न आयामों में तर्क का विस्तार करता है और अंततः उन्हें एक सुसंगत निष्कर्ष में विलय करता है।

इस सिद्धांत के आधार पर:

यह न पूछें "मुझे कितने Agents चाहिए?"; पूछें "इस कार्य की सूचना निर्भरता संरचना क्या है?"

यदि किसी कार्य में निरंतर तर्क और उच्च संदर्भ निर्भरता की आवश्यकता है (जैसे, एक जटिल सुविधा के लिए डिज़ाइन दस्तावेज़ लिखना), तो एक एकल Agent + अच्छी कॉन्टेक्स्ट इंजीनियरिंग आमतौर पर मल्टी-एजेंट से बेहतर होती है।

यदि किसी कार्य में स्वतंत्र दिशाओं की एक साथ खोज की आवश्यकता है (जैसे, एक साथ 10 प्रतिस्पर्धियों पर शोध करना), तो मल्टी-एजेंट समानता उचित है—प्रत्येक सबएजेंट का कार्य स्वतंत्र है, और सूचना हानि की लागत कम हो जाती है।

यदि कोई कार्य कई सत्रों में फैला है, तो बाहरी स्थिति फ़ाइलें अनिवार्य हैं। एक प्रभावी स्थिति फ़ाइल में चार प्रकार की जानकारी होनी चाहिए:

• कार्य लक्ष्य (अपरिवर्तनीय, बहाव को रोकने के लिए सत्र की शुरुआत में पढ़ा जाता है)
• पूर्ण किए गए चरण (जोड़े गए, अधिलेखित नहीं, पूरा इतिहास रखने के लिए)
• वर्तमान स्थिति (नवीनतम प्रगति को दर्शाने के लिए अधिलेखित)
• ज्ञात नुकसान (अगले सत्र में गलतियों को दोहराने से बचने के लिए जोड़े गए)

ये चार प्रकार की जानकारी, अलग-अलग बनाए रखी और संयुक्त, "अगले स्व" को आवश्यक पूर्ण संदर्भ प्रदान करती हैं।

यदि सत्यापन चरण जोड़ रहे हैं, तो वेरिफायर Agent का एकमात्र कार्य समस्याएँ खोजना बनाएँ, न कि "बैटन लेकर आगे बढ़ना।" प्रतिकूल परीक्षण, असेंबली लाइन स्थानांतरण नहीं।

अंत में: मॉडल क्षमताएँ तेजी से सुधर रही हैं। आज हार्नेस में आवश्यक वर्कअराउंड छह महीने में बेकार हो सकते हैं। Anthropic ने पहले ही यह साबित कर दिया है—Sonnet 4.5 की कॉन्टेक्स्ट चिंता Opus 4.5 में गायब हो गई। आर्किटेक्चरल विकास-क्षमता बनाए रखना "सही आर्किटेक्चर" चुनने से अधिक महत्वपूर्ण है।

विभागीकरण एक अच्छा-लगने वाला लेकिन इंजीनियरिंग रूप से महँगा भ्रम है। इसकी वास्तविक लागत प्रत्यक्ष विफलता नहीं है, बल्कि आपके सिस्टम को जटिलता बढ़ने पर कठिन-से-निदान तरीकों से खराब करना है—जहाँ प्रत्येक नोड "काम करता हुआ दिखता है," लेकिन समग्र बहाव कर रहा है।

जब तक आप समस्या पाते हैं, असेंबली लाइन पहले से ही बहुत लंबी होती है।

संदर्भ: Anthropic Engineering Blog (Building Effective Agents, Effective Context Engineering, Multi-Agent Research System, Effective Harnesses for Long-Running Agents, Managed Agents); OpenAI Developers Blog (Run Long Horizon Tasks with Codex, Shell + Skills + Compaction); Google Developers Blog (Architecting Efficient Context-Aware Multi-Agent Framework, Conductor: Context-Driven Development for Gemini CLI)