Orkestra: बड़े पैमाने पर AI एजेंट को ऑर्केस्ट्रेट करना

इस पोस्ट में दिए गए आंकड़े प्रकाशन के समय (जनवरी 2026) की सिस्टम स्थिति दर्शाते हैं। मौजूदा आंकड़ों के लिए हमारा टीम पेज देखें।

जब हमने Claude Code के साथ बनाना शुरू किया, तो हम एक ऐसी समस्या में फंस गए जिसका सामना AI कोडिंग असिस्टेंट का उपयोग करने वाली हर टीम को आख़िरकार करना पड़ता है: एक अकेला एजेंट हर चीज़ अच्छी तरह नहीं कर सकता।

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

तो हमने Orkestra बनाया।

Orkestra क्या है?

Orkestra, Claude Code और इसी तरह के AI कोडिंग टूल के लिए एक एजेंट ऑर्केस्ट्रेशन सिस्टम है। यह कई विशेषज्ञ एजेंट को समन्वित करता है, हर एक की अपनी अलग विशेषज्ञता होती है, एक ही ऑर्केस्ट्रेटर के अंतर्गत जो काम को सही स्पेशलिस्ट तक भेजता है।

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

आंकड़े ख़ुद कहानी बताते हैं:

कॉम्पोनेंट	संख्या
स्पेशलिस्ट एजेंट	46
पुनः उपयोग योग्य स्किल	466
आइडेंटिटी आर्किटाइप	27
माइंडसेट	11
कम्युनिकेशन स्टाइल	10
नॉलेज डोमेन	21

कैरेक्टर सिस्टम: एजेंट के लिए D&D

Orkestra के पीछे मुख्य इनसाइट यह है कि एजेंट का व्यवहार तीन कम्पोज़ेबल प्रिमिटिव से उभरता है:

Identity परिभाषित करती है कि एजेंट क्या है। एक आर्किटेक्ट सिस्टम संरचनाएं डिज़ाइन करता है। एक डीबगर विफलताओं को उनके मूल कारणों तक ट्रेस करता है। एक गार्डियन अनुपालन और सुरक्षा सीमाओं को लागू करता है। हमारे पास 27 आइडेंटिटी आर्किटाइप हैं जिन्हें मिलाया जा सकता है।

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

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

एक एजेंट इन प्रिमिटिव को मिलाता है:

# architecture-advisor.yaml
identity:
  - knowledge-architect
  - architect
  - strategist
mindset: analytical
style: concise

यह कम्पोज़िशन एक ऐसा एजेंट बनाता है जो सिस्टम डिज़ाइन करता है (architect), डोमेन में ज्ञान जोड़ता है (knowledge-architect), रणनीतिक दिशा तय करता है (strategist), साक्ष्य और डेटा में सोचता है (analytical), और बिना फ़ालतू बात के संवाद करता है (concise)।

ताक़त कॉम्बिनेटोरियल विस्फोट में है। 27 आइडेंटिटी गुणा 11 माइंडसेट गुणा 10 स्टाइल लगभग 3,000 संभावित एजेंट व्यक्तित्व पैदा करता है। लेकिन आप सिर्फ़ वही कॉम्बिनेशन परिभाषित करते हैं जो आपके काम के लिए मायने रखते हैं।

स्किल: पुनः उपयोग योग्य क्षमता मॉड्यूल

स्किल वह ज्ञान और वर्कफ़्लो हैं जिन्हें एजेंट इनवोक कर सकते हैं। ये स्कोप के आधार पर एक स्तरीय सिस्टम का पालन करते हैं:

स्तर	नाम	स्कोप	उदाहरण
K0	Foundations	सार्वभौमिक कार्यप्रणाली	Test-first discipline, साक्ष्य-आधारित पूर्णता
K1	Identities	भूमिका-आधारित वर्कफ़्लो	CLI इंटरफ़ेस मानक, परफ़ॉर्मेंस प्लेबुक
K2	Domains	डोमेन-विशिष्ट ज्ञान	डेटाबेस माइग्रेशन पैटर्न, ऑथेंटिकेशन वैलिडेशन
K3	Stacks	टेक्नोलॉजी-विशिष्ट	Cloudflare डिप्लॉयमेंट, Supabase ऑपरेशन
K4	Project	सिर्फ़ यह कोडबेस	प्रोजेक्ट-विशिष्ट वर्कफ़्लो और परंपराएं

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

हर स्किल में शामिल है:

• स्पष्ट ट्रिगर शर्तें (“डेटाबेस स्कीमा माइग्रेट करते समय उपयोग करें”)
• चरण-दर-चरण मार्गदर्शन
• वर्कफ़्लो के लिए अनुमत टूल
• सफलता मानदंड और विफलता रिकवरी पथ

हमारी रजिस्ट्री में मौजूद 466 स्किल git worktree पृथक्करण से लेकर वेब रिसर्च वर्कफ़्लो से लेकर डिप्लॉयमेंट हेल्थ वैलिडेशन तक सब कुछ कवर करती हैं।

ऑर्केस्ट्रेशन क्यों मायने रखता है

सिंगल-एजेंट आर्किटेक्चर जल्दी दीवारों से टकरा जाते हैं:

कॉन्टेक्स्ट डायल्यूशन। 200k टोकन का कॉन्टेक्स्ट विंडो तब तक बड़ा लगता है जब तक आप डेटाबेस स्कीमा, API डॉक्स, टेस्ट फ़िक्स्चर, और डोमेन ज्ञान लोड नहीं करते। स्पेशलिस्ट टार्गेटेड कॉन्टेक्स्ट के साथ काम कर सकते हैं।

निर्देश टकराव। किसी एजेंट को “पूरी तरह से पर तेज़ बनो” और “सब कुछ वेरिफ़ाई करो लेकिन ओवर-इंजीनियर मत करो” कहना तनाव पैदा करता है। स्पेशलिस्ट स्पष्ट स्कोप रखकर इन्हें सुलझाते हैं।

विशेषज्ञता की गहराई। एक जनरलिस्ट एजेंट हर चीज़ के बारे में थोड़ा-थोड़ा जानता है। सही identity और skills के साथ बना एक स्पेशलिस्ट एजेंट अपने डोमेन को गहराई से जानता है।

Orkestra फ़्लैट ऑर्केस्ट्रेशन लागू करता है: एक ऑर्केस्ट्रेटर कई स्पेशलिस्ट को समन्वित करता है। स्पेशलिस्ट सब-स्पेशलिस्ट स्पॉन नहीं कर सकते। यह समानांतर काम को सक्षम करते हुए जटिलता के विस्फोट को रोकता है।

ऑर्केस्ट्रेटर के पास प्रभावी क्षमता के 2.2 मिलियन टोकन तक पहुंच है: इसकी अपनी 200k विंडो, साथ ही 10 समवर्ती सबएजेंट, हर एक के पास 200k। जो काम एक अकेले एजेंट को थका देता, वह पूरे फ़्लीट में आराम से चल जाता है।

रेंडरिंग पाइपलाइन

एजेंट परिभाषाएं YAML में रहती हैं। Claude Code मार्कडाउन पढ़ता है। Orkestra एक डिटरमिनिस्टिक रेंडरिंग पाइपलाइन के साथ इस अंतर को पाटता है:

YAML Registries → Jinja Templates → .claude/agents/*.md

ऑपरेटर YAML सोर्स एडिट करते हैं। orkestra sync चलाएं। रेंडर्ड मार्कडाउन .claude/agents/ में दिखाई देता है। Claude Code बदलाव उठा लेता है।

यह अलगाव अलग-अलग ऑडियंस के काम आता है:

• YAML सोर्स में टूलिंग के लिए लाइफ़साइकल मेटाडेटा, टैग, वैलिडेशन नियम, और डेप्रीकेशन नोट शामिल होते हैं
• रेंडर्ड मार्कडाउन में सिर्फ़ वही शामिल होता है जिसकी मॉडल को ज़रूरत है: विवरण, टूल, स्किल, और व्यवहार संबंधी मार्गदर्शन

पाइपलाइन identity, mindset, style, और skills को एक ही सुसंगत प्रॉम्प्ट में मिला देती है। एक architect-analytical-concise एजेंट को एक debugger-skeptical-technical एजेंट से बिल्कुल अलग सिस्टम प्रॉम्प्ट मिलता है, भले ही वे कुछ अंतर्निहित स्किल साझा करते हों।

डोमेन नॉलेज: चार-फ़ाइल पैटर्न

हर नॉलेज डोमेन एक सुसंगत संरचना का पालन करता है:

domain-name/
  decisions.md      # Key choices, rationale, consequences
  patterns.md       # Step-by-step guidance and examples
  anti-patterns.md  # Failure modes and remediation
  evolution.md      # Dated log of changes

यह संरचना एजेंट कॉन्टेक्स्ट लोडिंग के काम आती है। ऑथेंटिकेशन पर काम करने वाला कोई एजेंट मार्गदर्शन के लिए authentication/patterns.md और जाने-पहचाने ख़तरों से बचने के लिए authentication/anti-patterns.md लोड करता है। फ़ाइलें कुशल कॉन्टेक्स्ट लोडिंग के लिए आकार में रखी गई हैं: उपयोगी होने लायक़ फ़ोकस्ड, आधिकारिक होने लायक़ व्यापक।

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

Values: ऑपरेटिंग सिस्टम

सभी एजेंट वैल्यू की एक बेस लेयर साझा करते हैं जो तय करती है कि वे कैसे ऑपरेट करते हैं:

सादगी पहले। ऐसा सबसे सरल समाधान उपयोग करें जो काम करे। जटिलता तभी जोड़ें जब वह जायज़ हो।

मूल कारण ठीक करें। विफलताओं के इर्द-गिर्द कभी पैच न लगाएं। अगर कोई पाइपलाइन फ़ेल होती है, तो पाइपलाइन डीबग करें। अगर कोई टेस्ट फ़ेल होता है, तो कोड या टेस्ट ठीक करें।

साक्ष्य-आधारित। दावों को “verified” (बेंचमार्क के साथ) या “अनुमानित” (धारणाओं के साथ) लेबल करें। पैटर्न मिलना समस्या की पुष्टि होने के बराबर नहीं है।

कॉन्टेक्स्ट इकोनॉमिक्स। MCP टूल कॉन्टेक्स्ट का 0.1% ख़र्च करते हैं। फ़ाइल रीड हर एक 2% ख़र्च करती हैं। कोड एक्सप्लोर करने से पहले डोमेन विशेषज्ञता लागू करें।

ये वैल्यू रेंडरिंग पाइपलाइन के ज़रिए हर स्पेशलिस्ट तक फैलती हैं। कोई एजेंट कम्पोज़िशन के ज़रिए इन्हें बायपास नहीं कर सकता।

CLI: कंट्रोल प्लेन

Orkestra एजेंट इकोसिस्टम को मैनेज करने के लिए एक CLI के साथ आता है:

# Discovery
orkestra agents search "database"
orkestra agents info database-architect

# Validation
orkestra validate --show-warnings

# Rendering
orkestra sync --dry-run
orkestra sync

# Skills
orkestra skills list
orkestra skills info schema-migration-workflow

# Decisions
orkestra decisions search "authentication"

CLI इस बात का सच्चाई का स्रोत है कि कौन-से एजेंट मौजूद हैं, उनके पास कौन-सी स्किल हैं, और सिस्टम स्वस्थ है या नहीं। यह समस्याओं को जल्दी पकड़ने के लिए सिंक से पहले वैलिडेशन चलाता है।

ओपन सोर्स पर विचार

हमने Orkestra अपनी ही समस्या हल करने के लिए बनाया: एक जटिल कोडबेस के लिए बड़े पैमाने पर AI एजेंट को समन्वित करना। जो पैटर्न हमने खोजे, वे हमारे डोमेन तक सीमित नहीं हैं।

कैरेक्टर कम्पोज़िशन सिस्टम (identity + mindset + style) किसी भी टीम पर लागू होता है जो एजेंट व्यक्तित्व परिभाषित करती है।

स्किल टियर सिस्टम (K0-K4) स्कोप के हिसाब से पुनः उपयोग योग्य क्षमताओं को व्यवस्थित करने के लिए एक मानसिक मॉडल देता है।

रेंडरिंग पाइपलाइन पैटर्न (YAML सोर्स + टेम्पलेट + जनरेट किए गए आर्टिफ़ैक्ट) टूलिंग और मॉडल कंज़म्पशन के बीच सरोकार अलग करता है।

फ़्लैट ऑर्केस्ट्रेशन मॉडल (एक कोऑर्डिनेटर, कई स्पेशलिस्ट) समानांतरता को सक्षम करते हुए जटिलता से बचता है।

क्या Orkestra ओपन सोर्स बनता है, यह इस पर निर्भर करता है कि क्या इन पैटर्न का Claude Code के साथ बना रहे दूसरों के लिए कोई मूल्य है। अगर आप उन्हीं दीवारों से टकरा रहे हैं जिनका हमने वर्णन किया, तो यह आर्किटेक्चर मदद कर सकता है।

हमने क्या सीखा

Orkestra बनाने ने हमें सिखाया कि ऑर्केस्ट्रेशन एजेंट को ज़्यादा समझदार बनाने के बारे में नहीं है। यह उन्हें ज़्यादा केंद्रित बनाने के बारे में है।

परफ़ेक्ट निर्देशों वाला एक अकेला एजेंट भी कॉन्टेक्स्ट ख़त्म कर बैठता है। सारी स्किल वाला एक अकेला एजेंट भी उलझ जाता है कि कौन-सी लागू करे। हर चीज़ बनने की कोशिश करने वाला एक अकेला एजेंट हर जगह औसत दर्जे के नतीजे देता है।

चालीस स्पेशलिस्ट, हर एक अपने डोमेन में उत्कृष्ट, एक ऐसे ऑर्केस्ट्रेटर से समन्वित जो जानता है कि कब डेलिगेट करना है: यही वह तरीक़ा है जिससे हम शिप करते हैं।

आर्किटेक्चर से कम मायने आंकड़े रखते हैं। आपको पांच एजेंट चाहिए हो सकते हैं, या पचास। सिद्धांत वही रहता है: क्षमता के बजाय कम्पोज़िशन, सामान्यीकरण के बजाय विशेषज्ञता, व्यक्तिगत वीरता के बजाय समन्वय।

---

Orkestra हमारे कोड इंटेलिजेंस प्लेटफ़ॉर्म, Maguyva के पीछे मौजूद एजेंट इकोसिस्टम को चलाता है। और जानना चाहते हैं? टीम से संपर्क करें।