LLM Agents बस Distributed Systems हैं

AI समुदाय multi-agent systems बना रहा है — LLM की ऐसी टीमें जो काम बाँटती हैं, आपस में संवाद करती हैं और मिलकर उन समस्याओं को सुलझाती हैं जिन्हें कोई एक model अकेले नहीं संभाल सकता। एक 'researcher' agent जानकारी जुटाता है, एक 'coder' agent implementation लिखता है, एक 'reviewer' agent quality जाँचता है, और एक 'coordinator' agent workflow संभालता है। सुनने में बात बहुत आकर्षक लगती है: एक अच्छी तरह चलने वाली engineering team की तरह मिलकर काम करते specialized agents।

यह सुना-सुना लग रहा है, और लगना भी चाहिए। Distributed systems के researchers 40 साल से स्वतंत्र processes के बीच coordination का अध्ययन कर रहे हैं। Multi-agent LLM systems उन समस्याओं को शून्य से दोबारा खोज रहे हैं जिन्हें distributed systems community दशकों पहले सुलझा चुकी है (या यह साबित कर चुकी है कि वे सुलझ नहीं सकतीं)। इन समानताओं को समझने से आप वही solutions दोबारा बनाने से बचते हैं, और ऐसे systems भी नहीं बनाते जो पहले से ज्ञात तरीकों से, अनुमानित ढंग से fail होते हैं।

Coordination का टैक्स

Distributed systems का पहला सबक: coordination का overhead होता है। दो processes अलग-अलग कामों पर स्वतंत्र रूप से काम करें तो एक से दोगुनी रफ्तार होती है। लेकिन दो processes एक ही काम पर साथ मिलकर काम करें और उन्हें coordinate करना पड़े, तो अक्सर वे अकेले process से धीमे होते हैं, क्योंकि communication और synchronization का खर्च parallelism के फायदे से ज़्यादा हो जाता है।

Multi-agent LLM systems में यह समस्या तुरंत दिखती है। 'researcher' agent एक रिपोर्ट बनाता है। 'coder' agent को कोड लिखने के लिए उस रिपोर्ट को समझना होता है। 'reviewer' agent को उपयोगी feedback देने के लिए रिपोर्ट और कोड दोनों समझने होते हैं। हर handoff पर context को prompt में serialize करना पड़ता है, और उसे प्राप्त करने वाले agent को उसे parse करके समझना पड़ता है। यह ठीक वही shared state वाली distributed systems समस्या है, और agents जोड़ने के साथ यह और बिगड़ती जाती है।

Single agent vs. multi-agent for a coding task:
Single agent:
1. Understand the problem         (1 LLM call)
2. Research relevant APIs          (2 LLM calls)
3. Write implementation            (1 LLM call)
4. Review and fix                  (1 LLM call)
Total: 5 LLM calls, full context throughout
Multi-agent (researcher + coder + reviewer):
1. Coordinator describes task      (1 LLM call)
2. Researcher reads and plans      (1 LLM call)
3. Researcher does research        (3 LLM calls)
4. Researcher summarizes findings  (1 LLM call)
5. Coder reads summary             (1 LLM call)  ← context lost here
6. Coder writes implementation     (1 LLM call)
7. Reviewer reads code + summary   (1 LLM call)  ← context lost here
8. Reviewer provides feedback      (1 LLM call)
9. Coordinator synthesizes         (1 LLM call)
Total: 11 LLM calls, context degraded at each handoff
More agents = more communication = more cost = worse context.

Distributed systems में इसे communication पर लागू Amdahl's Law कहा जा सकता है: parallelism से मिलने वाली speedup उस sequential communication से सीमित हो जाती है जिसे parallel नहीं किया जा सकता। जिस काम में कसकर coordination चाहिए, उसमें और agents जोड़ने से system तेज़ होने के बजाय धीमा हो जाता है।

Consensus की समस्या

जब कई agents एक ही काम पर साथ काम करते हैं, तो उन्हें कई बातों पर सहमत होना पड़ता है। Requirements क्या हैं? किस approach से चलें? यह implementation सही है या नहीं? Distributed systems में इसे consensus problem कहते हैं, और यह साबित रूप से कठिन है। FLP impossibility result दिखाता है कि asynchronous system में, जिसमें एक भी process faulty हो, deterministic consensus संभव ही नहीं है।

LLM agents consensus के मामले में पारंपरिक distributed processes से भी ज़्यादा मुश्किल हैं, क्योंकि वे non-deterministic होते हैं। एक ही सवाल एक ही agent से दो बार पूछिए, तो शायद दो अलग जवाब मिलें। एक ही कोड की समीक्षा करने वाले दो agents इस बात पर असहमत हो सकते हैं कि कोड सही है या नहीं। असहमति सुलझाने के लिए कहा गया 'coordinator' agent शायद सिक्का उछाल दे।

Multi-agent frameworks आम तौर पर इसे दो तरह से संभालते हैं: एक coordinator agent को अंतिम अधिकार देकर (centralized consensus model, सरल, पर एक single point of failure बनता है), या majority voting से (महँगा, क्योंकि हर फैसले के लिए कम से कम तीन agents चाहिए)। दोनों तरीके काम करते हैं, लेकिन वे उस समस्या को सुलझा रहे हैं जो सिर्फ इसलिए पैदा होती है क्योंकि आपने काम पहले ही कई agents में बाँट दिया था।

ऐसी Failure Modes जो परिचित लगेंगी

Multi-agent systems ऐसे तरीकों से fail होते हैं जिन्हें distributed systems के engineers तुरंत पहचान लेंगे।

• Cascading failures. Agent A गलत output देता है। Agent B, A के output पर आधारित होकर और खराब output देता है। Agent C, B के काम की समीक्षा करता है, पर मूल गलती नहीं पकड़ पाता क्योंकि उसने गलत मान्यताएँ विरासत में ले ली हैं। यह distributed systems की error propagation का ही रूप है: गलत input, जो हर चरण पर और बढ़ता जाता है।
• Deadlocks. Agent A आगे बढ़ने के लिए Agent B के output का इंतज़ार करता है। Agent B आगे बढ़ने के लिए Agent A के feedback का। दोनों में से कोई भी आगे नहीं बढ़ पाता। व्यवहार में यह अंतहीन loops के रूप में दिखता है, जहाँ agents काम को आगे-पीछे भेजते रहते हैं और कभी किसी नतीजे पर नहीं पहुँचते।
• Split brain. एक-दूसरे से जुड़े कामों पर काम कर रहे दो agents समस्या की असंगत तस्वीर बना लेते हैं। एक मानता है कि API JSON लौटाता है; दूसरा मानता है कि XML। उनके output अलग-अलग तौर पर सही हैं, पर आपस में मेल नहीं खाते।
• Thundering herd. एक coordinator agent कई agents को एक साथ काम सौंपता है। वे सब एक ही API को हिट करते हैं, एक ही rate limit खत्म कर देते हैं, या एक ही फ़ाइल बदलने की कोशिश करते हैं। यह resource contention ऐसी चीज़ है जो एक अकेला agent कभी सामना नहीं करता।

Multi-Agent कब सच में मदद करता है

Distributed systems के साथ यह समानता दोनों तरफ लागू होती है। कुछ खास समस्याओं के लिए distributed systems के असली फायदे हैं। Multi-agent systems के भी हैं, जब उन्हें ऐसी समस्याओं पर लगाया जाए जो सच में decomposition से लाभ उठाती हैं।

Embarrassingly parallel tasks. अगर आपको 50 codebases में एक ही pattern खोजना है, तो 50 स्वतंत्र agents सच में 50 गुना तेज़ होंगे। कोई coordination नहीं चाहिए, क्योंकि हर agent अलग input पर काम करता है और अपना स्वतंत्र output देता है। यह MapReduce pattern है, और जितना यह distributed data processing में काम करता है, उतना ही LLM agents के लिए भी।

Diverse perspectives. तीन अलग-अलग system prompts वाले agents से एक ही कोड की समीक्षा करवाने पर वे ऐसी समस्याएँ पकड़ सकते हैं जो एक अकेली समीक्षा से छूट जातीं। यह redundancy pattern है, जैसे किसी PR पर कई reviewers हों। लागत तीन गुना compute की है, पर कवरेज ज़्यादा व्यापक होता है।

Specialization with clean interfaces. एक translation agent जो text लेकर translated text लौटाए, उसका interface साफ है। एक summarization agent जो document लेकर summary लौटाए, उसका भी interface साफ है। इन्हें जोड़ना, जैसे पहले अनुवाद करना फिर summary बनाना, अच्छा चलता है क्योंकि उनके बीच का interface सरल है। Distributed systems में इसका समतुल्य है: well-defined APIs वाले microservices, उन microservices से बेहतर चलते हैं जिनके interfaces बातूनी और जटिल हों।

Distributed Systems से सीखे सबक

अगर आप multi-agent LLM systems बना रहे हैं, तो distributed systems की दशकों पुरानी समझ सीधे लागू होती है।

1. कम, पर ज़्यादा सक्षम agents चुनें। जैसे एक अच्छी तरह डिज़ाइन किया गया monolith, खराब डिज़ाइन की microservice architecture से बेहतर प्रदर्शन करता है, वैसे ही अच्छे prompting वाला एक सक्षम agent ज़्यादातर कामों में संकीर्ण agents की टीम से बेहतर होता है। Agents तभी जोड़ें जब साबित हो जाए कि एक agent उस workload को नहीं संभाल सकता।
2. Agents के बीच साफ interfaces तय करें। हर agent का input और output सुनिश्चित होना चाहिए। अस्पष्ट handoffs ('researcher ने जो पाया है उसे समझकर लागू कर दो') context खोने और गलत समझ का कारण बनते हैं। Agents के बीच structured data contracts, freeform text से बेहतर काम करते हैं।
3. Agents को idempotent बनाएँ। अगर कोई agent बीच में fail हो जाए, तो आपको उसे उसी input के साथ दोबारा चलाकर सही नतीजा मिलना चाहिए। इसके लिए ऐसे agents चाहिए जिनमें कोई छिपी हुई state न हो, और जो तब तक कोई side effect न करें जब तक उनके output के सही होने की पुष्टि न हो जाए।
4. Observability जोड़ें। हर inter-agent message, हर फैसला और हर failure log करें। जब कोई multi-agent system गलत output दे, तो आपको यह पता लगाना होगा कि गलती किस agent ने, किस कारण से की। Observability के बिना debugging अंदाज़े का खेल बन जाती है।
5. Partial failure के लिए डिज़ाइन करें। कोई भी agent fail हो सकता है, गलत output दे सकता है, या timeout हो सकता है। System को इसे सहजता से संभालना चाहिए: retry करे, किसी सरल तरीके पर fallback करे, या इंसान से पूछे। यह मानकर कभी न चलें कि सारे agents सफल होंगे।

वह असहज सच

ज़्यादातर multi-agent LLM systems एक अच्छे prompt वाले single agent के रूप में बेहतर चलते। जिन कामों को एक model अकेले संभाल सकता है, उनमें multi-agent architectures का coordination overhead, context loss और failure modes लगभग हमेशा फायदों से भारी पड़ते हैं। जैसे-जैसे AI tooling विकसित हो रही है, जटिल multi-agent systems बनाने का लालच बढ़ रहा है, पर distributed systems का सबक साफ है: जिसे distribute करने की ज़रूरत नहीं, उसे distribute मत करो।

अपवाद असली हैं: embarrassingly parallel tasks, साफ interfaces वाली सच्ची specialization, और ऐसी समस्याएँ जो एक model की context window से बड़ी हों। बाकी सब के लिए, एक अच्छी तरह संरचित prompt, अच्छे tools और सोच-समझकर बनाई गई retry strategy वाला एक agent, agents की टीम से बेहतर प्रदर्शन करेगा। यह architecturally कम रोमांचक है, पर बेहतर काम करता है। सबसे अच्छा distributed system वह है जिसे आपको बनाना ही न पड़े।