आपने स्क्रीनशॉट देखे होंगे। पांच, दस, पंद्रह Claude Code एजेंट tmux में चल रहे हैं, हर एक एक ही कोडबेस के अलग हिस्से पर काम कर रहा है। प्रोडक्टिव दिखता है। एक्साइटिंग दिखता है। और अगर आपने इसे रिप्लिकेट करने की कोशिश की है, तो आप जानते हैं कि यह दिखता उतना आसान नहीं है जितना लगता है।
एक Claude Code एजेंट चलाना सीधा-साधा है। आप उसे टास्क देते हैं, वो कोड लिखता है, आप रिव्यू करते हैं। दो मैनेज करने लायक हैं लेकिन एक नई समस्या लाते हैं: वे एक-दूसरे के बदलावों पर कदम रख सकते हैं। पांच के लिए एक सिस्टम चाहिए। बिना सिस्टम के दस चलाना, मंथली बिल वाला अराजकता है।
यह गाइड उसी सिस्टम के बारे में है। मल्टी-एजेंट आर्किटेक्चर की थ्योरी नहीं। एक रियल कोडबेस पर कई Claude Code एजेंट चलाने का असल, प्रैक्टिकल वर्कफ्लो, बिना सब कुछ बिखरे।
एक एजेंट काफी क्यों नहीं है
एक अकेला Claude Code एजेंट हैरानी भरा काम कर सकता है। लेकिन वो सीक्वेंशियल है। जब वो बैकएंड एंडपॉइंट इम्प्लीमेंट कर रहा है, आपका फ्रंटएंड रुका हुआ है। जब वो टेस्ट लिख रहा है, डॉक्यूमेंटेशन पीछे पड़ रहा है। जब वो बिल्ड फेलियर डीबग कर रहा है, तीन नए फीचर्स कतार में इंतजार कर रहे हैं।
गणित बदल जाता है जब आप समझते हैं कि ज्यादातर सॉफ्टवेयर काम पैरेलाइज़ेबल है। एक फ्रंटएंड कम्पोनेंट और एक बैकएंड API एंडपॉइंट फाइलें शेयर नहीं करते। एक टेस्ट सूट और एक डॉक्यूमेंटेशन अपडेट अलग-अलग डायरेक्टरीज़ को छूते हैं। एक आर्किटेक्चर रिव्यू और एक बगफिक्स बिल्कुल अलग टाइमस्केल पर काम करते हैं।
सिंगल-एजेंट डेवलपमेंट का बॉटलनेक एजेंट की स्पीड नहीं है। पाइपलाइन की गहराई है। एक एजेंट मतलब एक बार में एक चीज़ प्रोग्रेस में। कई एजेंट मतलब कई चीज़ें एक साथ प्रोग्रेस में, और यह बदल देता है कि एक अकेला डेवलपर एक दिन में क्या शिप कर सकता है।
काम बांटने की रणनीतियां
दूसरा tmux पेन खोलने से पहले, आपको तय करना होगा कि काम कैसे बांटना है। प्रैक्टिस में तीन पैटर्न काम करते हैं।
कम्पोनेंट के आधार पर बंटवारा
सबसे सिंपल अप्रोच। एजेंट A components/ का मालिक है, एजेंट B server/ का, एजेंट C lib/ का। हर एजेंट अपने इलाके में काम करता है और बाहर की फाइलों को कभी नहीं छूता।
यह तब अच्छा काम करता है जब आपकी कोडबेस में साफ आर्किटेक्चरल बाउंड्रीज़ हों। अलग-अलग फ्रंटएंड कम्पोनेंट्स, बैकएंड एक्शन्स और शेयर्ड लाइब्रेरीज़ वाली Next.js ऐप नैचुरली इन लाइनों पर डिवाइड होती है।
सीमा: क्रॉस-कटिंग काम। एक फीचर जिसे UI, API और डेटा लेयर सभी में बदलाव चाहिए, एक एजेंट की टेरिटरी में साफ नहीं बैठता। इसे फीचर को कम्पोनेंट-स्कोप्ड सबटास्क में तोड़कर और सीक्वेंस करके हैंडल करते हैं।
रोल के आधार पर बंटवारा
कोड लोकेशन की जगह, फंक्शन से बांटें। एक एजेंट कोड लिखता है। दूसरा टेस्ट लिखता है। तीसरा डॉक्यूमेंटेशन संभालता है। चौथा कोड रिव्यू करता है।
यह ह्यूमन टीम्स के काम करने के तरीके को मिरर करता है और बेहतर क्वालिटी प्रोड्यूस करता है क्योंकि टेस्ट एजेंट को पता नहीं (और परवाह नहीं) कि कोड लिखना कितना आसान था। वो स्पेक के खिलाफ टेस्ट करता है, ऑथर की assumptions के खिलाफ नहीं।
ट्रेडऑफ ज्यादा कोऑर्डिनेशन ओवरहेड है। टेस्ट एजेंट को इम्प्लीमेंटेशन एजेंट का पहले खत्म होना चाहिए। डॉक्यूमेंटेशन एजेंट को दोनों चाहिए। आप पैरेलल वर्कर्स नहीं, एक पाइपलाइन मैनेज कर रहे हैं।
लाइफसाइकल फेज़ के आधार पर बंटवारा
रोल स्प्लिटिंग का एक ज्यादा sophisticated वर्शन। एक एजेंट ब्रेनस्टॉर्म और प्लान करता है। दूसरा इम्प्लीमेंट करता है। तीसरा वेरिफाई करता है। काम फेज़ों से गुज़रता है, और हर एजेंट अपनी फेज़ के लिए स्पेशलाइज़्ड है।
यह वो पैटर्न है जो हम Beadbox में यूज़ करते हैं। हमारा आर्किटेक्ट एजेंट डिज़ाइन करता है, हमारे इंजीनियरिंग एजेंट इम्प्लीमेंट करते हैं, हमारे QA एजेंट इंडिपेंडेंटली वेरिफाई करते हैं। वही टास्क कई स्पेशलिस्ट्स से गुज़रता है, और हर एक एक क्वालिटी लेयर जोड़ता है जो जनरलिस्ट एजेंट मिस कर देते हैं। पूरे सेटअप के बारे में मैंने मैं 13 AI एजेंट्स के साथ सॉफ्टवेयर शिप करता हूं में लिखा है।
सही स्ट्रैटेजी आपके प्रोजेक्ट पर निर्भर करती है। साफ फाइल बाउंड्रीज़ वाले छोटे प्रोजेक्ट्स कम्पोनेंट स्प्लिटिंग से अच्छा करते हैं। बड़े प्रोजेक्ट्स जहां क्वालिटी मायने रखती है, रोल या लाइफसाइकल स्प्लिटिंग से फायदा उठाते हैं। ज्यादातर टीमें हाइब्रिड पर आती हैं।
CLAUDE.md आइडेंटिटी पैटर्न
यहां थ्योरी इम्प्लीमेंटेशन से मिलती है। हर Claude Code एजेंट को अपनी CLAUDE.md फाइल मिलती है, और यह फाइल पूरे मल्टी-एजेंट सिस्टम का सबसे ज़रूरी हिस्सा है।
एक CLAUDE.md चार चीज़ें डिफाइन करता है:
- एजेंट क्या है। उसका रोल, स्पेशलिटी और डोमेन।
- वो क्या ओन करता है। जो फाइलें, डायरेक्टरीज़ या ज़िम्मेदारियां वो कंट्रोल करता है।
- उसे क्या नहीं छूना चाहिए। एक्सप्लिसिट बाउंड्रीज़ जो कॉन्फ्लिक्ट्स रोकती हैं।
- वो कैसे कम्यूनिकेट करता है। काम रिपोर्ट करने और दूसरे एजेंट्स के साथ कोऑर्डिनेट करने के प्रोटोकॉल।
यहां एक रियल उदाहरण है। दो Claude Code एजेंट कॉम्प्लिमेंटरी स्कोप्स के साथ:
# CLAUDE.md for Agent: frontend-eng
## Identity
Frontend engineer. You implement UI components, pages, and client-side
logic. You own everything under components/, app/, and hooks/.
## File Ownership
- components/** (you own these)
- app/** (you own these)
- hooks/** (you own these)
- lib/utils.ts (shared, read-only for you)
- server/** (DO NOT MODIFY — owned by backend-eng)
## Communication
When you need a backend change, create a task describing what API
you need. Do not implement it yourself.
When done with a task, comment: "DONE: <summary>. Commit: <hash>"
# CLAUDE.md for Agent: backend-eng
## Identity
Backend engineer. You implement server actions, API routes, and
data layer logic. You own everything under server/, actions/, and lib/.
## File Ownership
- server/** (you own these)
- actions/** (you own these)
- lib/** (you own these, except utils.ts is shared)
- components/** (DO NOT MODIFY — owned by frontend-eng)
- app/** (DO NOT MODIFY — owned by frontend-eng)
## Communication
When you change a data type in lib/types.ts, notify frontend-eng
by commenting on the relevant task.
When done with a task, comment: "DONE: <summary>. Commit: <hash>"
एक्सप्लिसिट "DO NOT MODIFY" लाइनों पर ध्यान दें। इनके बिना, एजेंट भटकते हैं। वे किसी ऐसी फाइल में टाइपो ठीक करके "मदद" करने का मौका देखते हैं जो उनकी नहीं है, और अचानक आपके पास मर्ज कॉन्फ्लिक्ट्स हैं। या बदतर, वे चुपचाप उस कोड को रीफैक्टर कर देते हैं जिस पर दूसरा एजेंट डिपेंड कर रहा था।
आइडेंटिटी सेक्शन डेकोरेशन नहीं है। Claude Code हर सेशन की शुरुआत में CLAUDE.md पढ़ता है और इसे अपने बिहेवियर का स्कोप तय करने में यूज़ करता है। जिस एजेंट को बताया गया कि वो "फ्रंटएंड इंजीनियर" है, वो नैचुरली बैकएंड चेंजेज़ से बचेगा। जिस एजेंट को बताया गया कि वो स्पेसिफिक डायरेक्टरीज़ ओन करता है, वो उनके बाहर की फाइलें मॉडिफाई करने से पहले पूछेगा।
मर्ज कॉन्फ्लिक्ट्स से बचना
फाइल-लेवल ओनरशिप, जैसा कि ऊपर CLAUDE.md उदाहरणों में दिखाया गया, पहली डिफेंस लाइन है। लेकिन अकेली नहीं।
बार-बार कमिट और पुश करें। 45 मिनट बिना कमिट किए काम करने वाला एजेंट मर्ज कॉन्फ्लिक्ट का टाइम बम बना रहा है। एजेंट्स को (उनकी CLAUDE.md में) हर लॉजिकल यूनिट ऑफ वर्क पूरी करने के बाद कमिट करने का निर्देश दें।
नया काम शुरू करने से पहले पुल करें। हर एजेंट को नया टास्क शुरू करने से पहले git pull --rebase रन करना चाहिए। CLAUDE.md में एजेंट के स्टार्टअप प्रोटोकॉल में जोड़कर इसे लागू करना बहुत आसान है।
क्रॉस-कटिंग काम के लिए फीचर फ्लैग्स यूज़ करें। जब दो एजेंट्स को एक ही फाइल मॉडिफाई करनी हो, सेफर अप्रोच अक्सर यह है कि एक एजेंट इंटरफेस या फ्लैग बनाए, कमिट और पुश करे, फिर दूसरा एजेंट पुल करे और उसके ऊपर बिल्ड करे। जब विकल्प मर्ज नाइटमेयर हो तो सीक्वेंशियल, पैरेलल को हराता है।
रिस्की काम के लिए अलग ब्रांचेज़। अगर एजेंट कुछ एक्सपेरिमेंटल कर रहा है, उसे अपनी ब्रांच दें। आर्किटेक्चर स्पाइक्स या रीफैक्टरिंग काम के लिए खासतौर पर उपयोगी जो लैंड न हो।
प्रैक्टिस में, फाइल ओनरशिप रूल्स और फ्रीक्वेंट कमिट्स का कॉम्बिनेशन 90% मर्ज कॉन्फ्लिक्ट्स खत्म कर देता है। बाकी 10% शेयर्ड फाइलों जैसे types.ts या package.json में होते हैं, और आमतौर पर रिज़ॉल्व करना आसान होता है।
एजेंट-टू-एजेंट कम्यूनिकेशन
Claude Code एजेंट सीधे एक-दूसरे से बात नहीं कर सकते। कोई शेयर्ड मेमोरी नहीं, कोई मैसेज बस नहीं, उनके बीच कोई रियल-टाइम चैनल नहीं। यह असल में अच्छी बात है। एजेंट्स के बीच डायरेक्ट कम्यूनिकेशन कपलिंग, रेस कंडीशन्स और डीबगिंग नाइटमेयर्स बनाता है।
इसके बजाय, कम्यूनिकेशन आर्टिफैक्ट्स से होता है। तीन पैटर्न काम करते हैं:
टास्क कमेंट्स
सबसे भरोसेमंद पैटर्न। एजेंट A काम पूरा करता है और शेयर्ड टास्क पर कमेंट करता है: "DONE: /api/users एंडपॉइंट इम्प्लीमेंट किया। JSON रिटर्न करता है। स्कीमा lib/types.ts में है।" एजेंट B टास्क कमेंट पढ़ता है और जानता है कि क्या अवेलेबल है।
स्टेटस अपडेट्स
हर टास्क का एक स्टेटस होता है: open, in_progress, done, blocked। जब एजेंट A प्रीरिक्विज़िट टास्क को done मार्क करता है, एजेंट B (या आप, या कोऑर्डिनेटर) जानता है कि डिपेंडेंट काम शुरू हो सकता है।
फाइल चेंजेज़
सबसे सिंपल फॉर्म। एजेंट A एक TypeScript इंटरफेस lib/types.ts में लिखता है और कमिट करता है। एजेंट B पुल करता है और नए टाइप्स देखता है। कोई एक्सप्लिसिट कम्यूनिकेशन ज़रूरी नहीं क्योंकि कोड ही मैसेज है।
क्या काम नहीं करता: एजेंट्स के बीच रियल-टाइम मैसेज-पासिंग सिस्टम बनाने की कोशिश। अगर आपको एजेंट A को एजेंट B के आउटपुट का इंतज़ार करना है, तो इसे सिंक्रोनस कॉल की जगह टास्क्स के बीच डिपेंडेंसी के रूप में मॉडल करें।
डिस्पैच लूप
किसी को शो चलाना होगा। मल्टी-एजेंट Claude Code सेटअप में दो ऑप्शन हैं: आप मैन्युअली करें, या कोऑर्डिनेटर एजेंट डेज़िग्नेट करें।
मैन्युअल डिस्पैच
आप टास्क लिस्ट मेंटेन करते हैं। एजेंट्स को टास्क असाइन करते हैं। प्रोग्रेस चेक करते हैं। ब्लॉकर्स हैंडल करते हैं। यह लगभग पांच एजेंट्स तक काम करता है, उसके बाद कोऑर्डिनेशन ओवरहेड प्रोडक्टिविटी गेन्स खाना शुरू कर देता है।
एक टिपिकल मैन्युअल डिस्पैच साइकल ऐसा दिखता है:
- सुबह: प्रोग्रेस में क्या है, ब्लॉक्ड क्या है, काम के लिए रेडी क्या है, रिव्यू करें
- असाइन करें: हर एजेंट को कॉन्टेक्स्ट के साथ अगला टास्क भेजें
- मॉनिटर करें: हर 10-15 मिनट में एजेंट आउटपुट चेक करें, स्टक होने के संकेत देखें
- अनब्लॉक करें: जब एजेंट प्रॉब्लम हिट करे, इंटरवीन करें या रीअसाइन करें
- क्लोज़ आउट: दिन के अंत में रिव्यू करें क्या शिप हुआ और कल प्लान करें
tmux में, यह पेन्स स्विच करना, रीसेंट आउटपुट पढ़ना और हर एजेंट को आगे क्या चाहिए तय करना जैसा दिखता है। gp (एजेंट के रीसेंट आउटपुट को बिना इंटरप्ट किए देखना) जैसे टूल्स मदद करते हैं, लेकिन आप बॉटलनेक बने रहते हैं।
कोऑर्डिनेटर एजेंट
एक Claude Code एजेंट को दूसरों को काम डिस्पैच करने के लिए डेडिकेट करें। यह एजेंट कोड नहीं लिखता। यह टास्क बैकलॉग पढ़ता है, अवेलेबल एजेंट्स को काम असाइन करता है, प्रोग्रेस चेक करता है और डिस्पैच लूप प्रोग्रामेटिकली हैंडल करता है।
यही वो पैटर्न है जो हम यूज़ करते हैं। हमारा "super" एजेंट एक पैट्रोल लूप चलाता है: हर कुछ मिनट में हर एक्टिव एजेंट को चेक करता है, टास्क स्टेटस वेरिफाई करता है, ब्लॉकर्स आइडेंटिफाई करता है और जब कोई एजेंट आइडल होता है तो नया काम डिस्पैच करता है। इंसान (मैं) प्रायोरिटी डिसीज़न्स लेता है और एम्बिगुअस सिचुएशन्स रिज़ॉल्व करता है। Super लॉजिस्टिक्स हैंडल करता है।
कोऑर्डिनेटर एजेंट को अपना CLAUDE.md चाहिए:
# CLAUDE.md for Agent: super
## Identity
Dispatch coordinator. You assign work to agents, monitor progress,
and ensure the pipeline keeps moving. You do NOT write code.
## Responsibilities
- Maintain awareness of all active tasks and their statuses
- Assign ready tasks to idle agents
- Monitor agent progress every 5-10 minutes
- Escalate blockers to the human when agents can't self-resolve
- Verify agents follow the protocol: plan before code, test before done
## Communication
- To assign work: message the agent with task ID and priority
- To check progress: peek at agent's recent output
- To escalate: message the human with context and options
कोऑर्डिनेटर पैटर्न मैन्युअल डिस्पैच से बहुत बेहतर स्केल करता है। 10+ एजेंट्स पर, मैन्युअल कोऑर्डिनेशन फुल-टाइम जॉब है। कोऑर्डिनेटर एजेंट रूटीन लॉजिस्टिक्स हैंडल करता है और सिर्फ वो डिसीज़न्स एस्कलेट करता है जिनमें ह्यूमन जज्मेंट ज़रूरी है।
मल्टी-एजेंट काम के लिए tmux लेआउट
फिज़िकल लेआउट आप जितना सोचते हैं उससे ज़्यादा मायने रखता है। कई Claude Code एजेंट चलाने के लिए एक tmux कॉन्फिगरेशन:
# Create a new tmux session
tmux new-session -s agents -n super
# Split into panes for each agent
tmux split-window -h -t agents:super
tmux split-window -v -t agents:super.1
# Or create named windows (easier to manage at scale)
tmux new-window -t agents -n eng1
tmux new-window -t agents -n eng2
tmux new-window -t agents -n qa1
tmux new-window -t agents -n frontend
tmux new-window -t agents -n backend
नेम्ड विंडोज़ चार एजेंट्स के बाद स्प्लिट पेन्स को हरा देती हैं। एक स्क्रीन पर पांच पेन्स नहीं पढ़ सकते, लेकिन नेम्ड विंडोज़ के बीच तेज़ी से स्विच कर सकते हैं। नेमिंग कन्वेंशन भी मायने रखता है। eng1, eng2, qa1 तुरंत स्कैन करने लायक हैं। agent-1, agent-2, agent-3 कुछ नहीं बताते।
हर एजेंट को अपनी वर्किंग डायरेक्टरी और अपने CLAUDE.md से स्टार्ट करें:
# In the eng1 window
cd ~/project
claude --claude-md ./agents/eng1/CLAUDE.md
# In the qa1 window
cd ~/project
claude --claude-md ./agents/qa1/CLAUDE.md
एक प्रैक्टिकल टिप: एक "dashboard" विंडो रखें जो बस एक शेल हो। इसे git log --oneline -10 चलाने, टास्क स्टेटस चेक करने या एजेंट्स के काम को इंटरप्ट किए बिना देखने के लिए यूज़ करें। यह आपका कमांड सेंटर बन जाता है।
जब चीज़ें गलत होती हैं
मल्टी-एजेंट वर्कफ्लो प्रिडिक्टेबल तरीकों से फेल होते हैं। फेलियर मोड्स जानना आपको हार्ड वे से सीखने से बचाता है।
दो एजेंट एक ही फाइल एडिट करते हैं। आमतौर पर इसलिए कि CLAUDE.md में फाइल ओनरशिप काफी स्पेसिफिक नहीं थी। lib/utils.ts क्लासिक कॉन्फ्लिक्ट मैग्नेट है। सॉल्यूशन: या तो शेयर्ड यूटिलिटी फाइलें एक स्पेसिफिक एजेंट को असाइन करें, या सबके लिए रीड-ओनली बनाएं और चेंजेज़ सिंगल ओनर से रूट करें।
एजेंट साइलेंट हो जाता है। रेट लिमिट, एरर लूप, या डीप रीज़निंग चेन में फंस गया। आउटपुट चेक करें। अगर वही फेलिंग कमांड रीट्राई कर रहा है, सेशन किल करें और क्लियर इंस्ट्रक्शन्स से रीस्टार्ट करें। पीरियोडिक हेल्थ चेक्स (हर 10-15 मिनट) इसे एक घंटा बर्बाद होने से पहले पकड़ लेते हैं।
कॉन्टेक्स्ट विंडोज़ भर जाते हैं। लॉन्ग-रनिंग एजेंट कॉन्टेक्स्ट एक्यूमुलेट करते हैं और खराब परफॉर्म करने लगते हैं। हर एजेंट की CLAUDE.md में इसके लिए प्रोटोकॉल होना चाहिए: "90 मिनट से ज़्यादा काम कर रहे हो तो अपना स्टेट सेव करो और नया सेशन रिक्वेस्ट करो।" प्रैक्टिस में, एजेंट अपना काम कमिट करता है, कहां छोड़ा नोट करता है, और नया Claude Code सेशन उस कमिट से पिक अप करता है।
काम स्पेक से भटक जाता है। एजेंट कुछ बनाता है जो टेक्निकली काम करता है लेकिन जो मांगा गया था उससे मैच नहीं करता। सॉल्यूशन प्लान-बिफोर-कोड पैटर्न है: कोड लिखने से पहले, एजेंट अपना इम्प्लीमेंटेशन प्लान कमेंट करता है। 60 सेकंड में प्लान रिव्यू करें और 500-लाइन diff बनने से पहले मिसअंडरस्टैंडिंग्स पकड़ें।
पाइपलाइन स्टॉल हो जाती है। एजेंट B एजेंट A का इंतज़ार कर रहा है, लेकिन एजेंट A आपके डिसीज़न का इंतज़ार कर रहा है। इस बीच एजेंट C ने 30 मिनट पहले काम खत्म कर दिया और आइडल बैठा है। यह कोऑर्डिनेशन फेलियर है, टेक्निकल नहीं। कोऑर्डिनेटर एजेंट (या आप) को ब्लॉकर्स मॉनिटर करके और आइडल एजेंट्स को रीअसाइन करके पाइपलाइन चलाते रहना होगा।
हमने Beads से इसे कैसे सॉल्व किया
ऊपर का सब कुछ स्टिकी नोट्स और अच्छी नीयत से काम करता है। लेकिन लगभग पांच एजेंट्स पर, इनफॉर्मल अप्रोच में दरारें आने लगती हैं। आप भूल जाते हैं कि एजेंट C किस पर काम कर रहा था। ट्रैक खो देते हैं कि कौन से टास्क ब्लॉक्ड हैं। याद नहीं रहता कि एजेंट B को जो API एंडपॉइंट चाहिए वो कम्पलीट हुआ था या बस शुरू।
यही प्रॉब्लम है जो beads सॉल्व करता है। Beads एक ओपन-सोर्स, लोकल-फर्स्ट इश्यू ट्रैकर है। हर टास्क एक "bead" है जिसमें यूनीक ID, स्टेटस, डिस्क्रिप्शन, एक्सेप्टेंस क्राइटेरिया, डिपेंडेंसीज़ और कमेंट थ्रेड होता है। सब bd नाम के CLI से एक्सेसिबल है, जिसका मतलब है कि आपके Claude Code एजेंट टर्मिनल छोड़े बिना रीड और राइट कर सकते हैं।
beads के साथ डिस्पैच लूप ऐसा दिखता है:
# See what's ready for work
bd list --status open
# Assign a task to an agent
bd update bb-a1b2 --claim --actor eng1
# Agent reads its assignment
bd show bb-a1b2
# Agent comments its plan before coding
bd comments add bb-a1b2 --author eng1 "PLAN:
1. Add endpoint at /api/users
2. Define UserResponse type in lib/types.ts
3. Write integration test
Files: server/api/users.ts (new), lib/types.ts (modify)
Test: curl localhost:3000/api/users returns 200 with JSON array"
# Agent finishes and comments what it did
bd comments add bb-a1b2 --author eng1 "DONE: /api/users endpoint live.
Returns paginated JSON. Added UserResponse type.
Verification:
1. curl http://localhost:3000/api/users → 200, JSON array
2. curl http://localhost:3000/api/users?page=2 → 200, second page
3. pnpm test → all passing
Commit: 8f3c2a1"
# Agent marks the task done
bd update bb-a1b2 --status closed
हर एजेंट इस प्रोटोकॉल को फॉलो करता है: क्लेम, प्लान, इम्प्लीमेंट, DONE कमेंट, स्टेटस अपडेट। हर bead का कमेंट थ्रेड एक कम्पलीट ऑडिट ट्रेल बन जाता है: क्या हुआ, क्यों, और कैसे वेरिफाई करें।
डिपेंडेंसीज़ कॉन्फ्लिक्टिंग काम रोकती हैं:
# Create a task that depends on another
bd create --title "Build user list component" \
--deps bb-a1b2 \
--description "Frontend component that calls /api/users. Blocked until API is live."
डिपेंडेंट टास्क bb-a1b2 पूरा होने तक ब्लॉक्ड रहता है। कोई एजेंट इसे पहले नहीं उठाएगा। कोई अभी तक मौजूद न होने वाले API का फ्रंटएंड बनाकर टाइम वेस्ट नहीं करेगा।
bd list कमांड पूरी पाइपलाइन का स्नैपशॉट देता है:
bd list --status in_progress
# Shows what every agent is actively working on
bd blocked
# अधूरी डिपेंडेंसीज़ पर प्रतीक्षा कर रहे टास्क दिखाता है
bd list --status open --priority p1
# Shows the highest-priority work that's ready to start
यह उस मेंटल मॉडल को रिप्लेस करता है जो आप दिमाग में रखे हुए थे। हर टास्क का स्टेटस, हर एजेंट का करंट काम, हर डिपेंडेंसी चेन, सब कमांड लाइन से क्वेरी करने लायक।
विज़िबिलिटी को स्केल करना
CLI काम करता है। लेकिन स्केल पर, टर्मिनल में bd list चलाकर आप कितना अब्ज़ॉर्ब कर सकते हैं इसकी एक लिमिट है। जब आठ एजेंट तीन एपिक्स पर सत्रह ओपन टास्क और दर्जन डिपेंडेंसीज़ के साथ काम कर रहे हैं, आपको काम की लिस्ट नहीं, काम का शेप देखना होगा।
यही गैप है जो Beadbox भरने के लिए बनाया गया। Beadbox एक रियल-टाइम डैशबोर्ड है जो beads के ऊपर बैठता है और आपको दिखाता है:
- एपिक ट्रीज़ प्रोग्रेस बार्स के साथ, ताकि आप देखें हर फीचर अपने सब-टास्क्स में कैसे प्रोग्रेस कर रहा है
- डिपेंडेंसी ग्राफ्स जो ब्लॉक्ड काम पाइपलाइन स्टॉल करने से पहले सरफेस करते हैं
- एजेंट एक्टिविटी दिखाती है कौन सा एजेंट किस पर काम कर रहा है, उनके प्लान और done कमेंट्स कॉन्टेक्स्ट में विज़िबल
- रियल-टाइम अपडेट्स क्योंकि डैशबोर्ड आपके beads डेटाबेस को वॉच करता है और एजेंट्स के टास्क स्टेटस अपडेट करने पर रिफ्रेश होता है
Beadbox CLI को रिप्लेस नहीं करता। आपके एजेंट bd से beads में रीड और राइट करते रहते हैं। Beadbox आपको बिग पिक्चर देता है ताकि आप जज्मेंट कॉल्स ले सकें: कौन सा एपिक पीछे पड़ रहा है, किस एजेंट को हेल्प चाहिए, बॉटलनेक कहां बन रहा है।
बीटा के दौरान फ्री है। अगर आप इस तरह के वर्कफ्लो बना रहे हैं, तो GitHub पर Beadbox को स्टार दें।
शुरू कैसे करें
इसका फायदा उठाने के लिए तेरह एजेंट की ज़रूरत नहीं। मिनिमम वायबल सेटअप:
- दो Claude Code एजेंट अलग tmux विंडोज़ में, हर एक अपनी CLAUDE.md के साथ जो फाइल ओनरशिप बाउंड्रीज़ डिफाइन करे।
- एक टास्क लिस्ट (इस स्केल पर टेक्स्ट फाइल भी काम करती है) ताकि दोनों एजेंट जानें किस पर काम कर रहे हैं और आगे क्या है।
- कमिट प्रोटोकॉल: दोनों एजेंट बार-बार कमिट करें और नया काम शुरू करने से पहले पुल करें।
जब यह नैचुरल लगने लगे, टेस्टिंग या डॉक्यूमेंटेशन के लिए तीसरा एजेंट जोड़ें। फिर कोऑर्डिनेटर एजेंट पर विचार करें। फिर beads अडॉप्ट करें स्ट्रक्चर्ड टास्क ट्रैकिंग के लिए। सिस्टम को तब स्केल करें जब कोऑर्डिनेशन का दर्द बढ़े, उससे पहले नहीं।
मुश्किल टूलिंग नहीं है। सोच बदलना है: "मैं AI असिस्टेंट यूज़ कर रहा हूं" से "मैं एक टीम चला रहा हूं।" CLAUDE.md फाइलें, डिस्पैच प्रोटोकॉल, ओनरशिप बाउंड्रीज़: ये कॉन्फिगरेशन फाइलें नहीं, मैनेजमेंट प्रैक्टिसेज़ हैं। आप एक ऑर्गनाइज़ेशन बना रहे हैं, भले ही टीम मेंबर्स API कॉल्स पर चलते हों।
दो एजेंट और क्लियर बाउंड्रीज़ से शुरू करें। बाकी सब वहां से फॉलो करता है।
