मल्टी-एजेंट आर्किटेक्चर: बिना सोचे-समझे बाँटोगे तो उल्टा पड़ेगा

“क्या मेरे एजेंट को कई एजेंट्स में बाँट दूँ तो वो ज़्यादा स्मार्ट हो जाएगा?” - यह सवाल हर दूसरे developer community में उठता है। जवाब, हमेशा की तरह, “निर्भर करता है।”

Anthropic की रिसर्च बताती है कि multi-agent architecture सही conditions में 90% तक बेहतर results दे सकता है। लेकिन यहाँ पकड़ यह है - “सही conditions में।” ग़लत architecture चुन लिया तो performance बेहतर होने के बजाय और गिर जाएगी, tokens ज़्यादा ख़र्च होंगे, और debugging का दर्द कई गुना बढ़ जाएगा।

आइए चार प्रमुख multi-agent patterns को समझें, देखें कि कौन सा कब काम आता है, और एक practical guide बनाएँ जिससे आप अपने अगले project में सही फ़ैसला ले सकें।

चार मल्टी-एजेंट पैटर्न

Subagents: मुख्य एजेंट जो विशेषज्ञों को बुलाता है

इस pattern में एक main agent होता है जो पूरे workflow का conductor है। जब भी किसी specialized काम की ज़रूरत पड़ती है - code review, security analysis, database query - main agent एक dedicated subagent को tool की तरह invoke करता है।

सबसे बड़ी ताक़त यह है कि subagents parallel में चल सकते हैं। तीन अलग-अलग files का analysis चाहिए? तीनों subagents एक साथ काम करें, results main agent के पास वापस आएँ। Routing हमेशा main agent से होती है, जिससे overall flow पर control बना रहता है।

कमज़ोरी: हर subagent invocation एक अलग context spawn करती है। अगर task छोटा है तो यह overhead बेवजह भारी पड़ता है।

Skills: एक एजेंट, कई विशेषज्ञताएँ

Skills pattern में एजेंट एक ही रहता है, लेकिन task के हिसाब से expert prompt load कर लेता है। मान लीजिए आपको code review करनी है - एजेंट code-review skill activate करता है, जिसमें relevant instructions, rules, और evaluation criteria पहले से defined होते हैं।

यह approach lightweight है क्योंकि नया agent spawn नहीं होता। एजेंट का पूरा context बरक़रार रहता है - पिछली बातचीत, लिए गए decisions, project की state - सब accumulated रहता है। इसीलिए repeated tasks में यह pattern चमकता है।

कमज़ोरी: जैसे-जैसे skills load होती जाती हैं, context window भरता जाता है। अगर एक ही session में बहुत सारे domains handle करने हों, तो context pollution की वही पुरानी समस्या लौट आती है।

Handoffs: एक स्टेज पूरा, अगला एजेंट सँभाले

Handoffs में active agent बदलता रहता है। Planning agent काम करता है, फिर control coding agent को सौंपता है, फिर testing agent को। हर stage पर एक ही agent active होता है, और transition के वक़्त relevant context अगले agent को pass हो जाता है।

यह pattern sequential workflows के लिए बना है - ऐसे काम जहाँ steps का क्रम तय है और हर step पिछले के output पर निर्भर है। Pipeline जैसी processing के लिए यह सबसे natural fit है।

कमज़ोरी: parallel execution यहाँ संभव नहीं है। अगर दो independent tasks एक साथ चलाने हों, तो Handoffs में आप एक के बाद एक ही कर सकते हैं। इसके अलावा, handoff के दौरान context transfer सही से न हो तो information loss हो सकता है।

Router: वर्गीकरण करो, बाँटो, नतीजे जोड़ो

Router pattern में एक stateless classifier होता है जो incoming request को analyse करता है, तय करता है कि यह किस domain में आती है, और उसे सही specialized agent को dispatch कर देता है। काम होने पर results aggregate होकर वापस आते हैं।

इसकी ख़ूबसूरती statelessness में है। Router को पिछली history याद रखने की ज़रूरत नहीं - वो बस classify करता है और भेज देता है। Subagents की तरह parallel dispatch कर सकता है, लेकिन main agent जैसा orchestration overhead नहीं होता।

कमज़ोरी: stateless होने का मतलब है कि context-dependent decisions लेना मुश्किल है। अगर request का जवाब पिछली बातचीत पर निर्भर करता है, तो router को वो context separately feed करना पड़ेगा।

परिदृश्य विश्लेषण: कौन कब जीतता है?

बस patterns जानना काफ़ी नहीं - यह समझना ज़रूरी है कि किस situation में कौन सा pattern सबसे efficient है। तीन real-world scenarios देखते हैं।

परिदृश्य 1: One-Shot Task (एक बार का काम)

मान लीजिए एक bug fix करनी है - file ढूँढो, problem identify करो, fix लिखो, test चलाओ।

• Subagents: 4 calls (main orchestration + 3 subagent invocations)। हर subagent के लिए नया context setup - इतने छोटे काम के लिए ज़रूरत से ज़्यादा।
• Skills / Handoffs / Router: 3 calls। कम overhead, direct execution।
• Single agent: बस 1 context, 1 flow। सबसे efficient।

नतीजा: One-shot tasks के लिए single agent काफ़ी है। Multi-agent architecture लगाना यहाँ overkill है - जैसे एक कील ठोकने के लिए JCB बुलाना।

परिदृश्य 2: बार-बार दोहराए जाने वाले Tasks

फ़्रंटएंड feature development - design review, component build, styling, testing - एक ही session में कई बार similar patterns दोहराने पड़ते हैं।

• Subagents: कुल 8 invocations। हर बार नया context, accumulated learning का कोई फ़ायदा नहीं।
• Skills / Handoffs: कुल 5 invocations - 40% कम। पिछले iterations की learning context में बनी रहती है। पहली बार जो pattern सीखा, दूसरी बार उसे repeat नहीं करना पड़ता।

नतीजा: Stateful patterns (Skills और Handoffs) repeated tasks में साफ़ जीतते हैं। Context accumulation यहाँ asset है, liability नहीं।

परिदृश्य 3: Multi-Domain Task (कई क्षेत्रों में फैला काम)

एक बड़ा feature जिसमें frontend, backend API, database schema, और deployment config - सब एक साथ छूने पड़ें।

• Subagents / Router: कुल ~9K tokens। हर domain का काम parallel में isolated context में होता है। कोई cross-contamination नहीं।
• Skills (single agent): कुल ~15K tokens। एक ही context में सारे domains की information - React components, SQL queries, Docker configs - सब एक साथ। Context window तेज़ी से भरता है।

नतीजा: Parallel-capable patterns (Subagents और Router) multi-domain tasks में 67% कम tokens इस्तेमाल करते हैं। जब domains अलग-अलग हों, तो context isolation ज़रूरी है।

Decision Guide: कौन सा Pattern कब चुनें

यह सारा analysis एक simple decision framework में सिमटता है:

आपकी स्थिति	सही Pattern	क्यों
एक बार का छोटा काम	Single Agent	Overhead zero, सबसे तेज़
बार-बार दोहराने वाले tasks	Skills / Handoffs	Accumulated context का फ़ायदा
कई domains एक साथ	Subagents / Router	Parallel execution, isolated contexts
तय क्रम वाला pipeline	Handoffs	Sequential flow, clean transitions
Stateless classification ज़रूरी	Router	Classify, dispatch, aggregate
Maximum parallel throughput	Subagents	Tool-like invocation, concurrent execution

सबसे ज़रूरी सलाह: Single Agent से शुरू करें

यह पूरे blog post की सबसे अहम बात है - हमेशा single agent से शुरू करें।

बहुत सारे developers पहले दिन से ही multi-agent architecture बना लेते हैं क्योंकि “future-proof” लगता है। लेकिन प्रैक्टिस में ऐसा होता है:

1. Debugging तीन गुना मुश्किल हो जाती है - कौन से agent ने ग़लत output दिया, यह trace करना अकेले agent से कहीं ज़्यादा पेचीदा है
2. Latency बढ़ती है - हर agent invocation का अपना round-trip time है
3. Token cost बढ़ता है - context duplication और orchestration overhead
4. Complexity बिना किसी फ़ायदे के बढ़ जाती है - अगर single agent काम कर सकता था, तो multi-agent ने सिर्फ़ maintenance burden जोड़ा

सही approach यह है: single agent से शुरू करें। जब specific bottleneck दिखे - context window भर रही है, parallel execution चाहिए, domains इतने अलग हैं कि एक agent handle नहीं कर पा रहा - तब ऊपर दी गई guide के हिसाब से सही pattern चुनें।

Anthropic की रिसर्च में जो 90% improvement दिखी, वो multi-agent blindly लगाने से नहीं आई। वो सही architecture सही problem पर लगाने से आई। ग़लत problem पर multi-agent लगाओगे तो improvement तो दूर, regression मिलेगा।

अंतिम बात

Multi-agent architecture एक powerful tool है - लेकिन tool ही है, जादू की छड़ी नहीं। हर tool की तरह, इसकी value इस बात पर निर्भर करती है कि आपने सही जगह पर इस्तेमाल किया या नहीं।

चार patterns याद रखें: Subagents parallel specialization के लिए, Skills lightweight context accumulation के लिए, Handoffs sequential pipelines के लिए, और Router stateless classification और dispatch के लिए। अपने task की प्रकृति पहचानें, guide देखें, और फिर फ़ैसला लें।

और अगर confusion हो, तो default हमेशा single agent है। Split तभी करें जब data बताए कि ज़रूरत है।