यह अभी मेरा terminal है।

13 agent tmux session

13 Claude Code agents, हर एक अपने tmux pane में, एक ही codebase पर काम कर रहे हैं। experiment के तौर पर नहीं। दिखावे के लिए नहीं। मैं हर दिन ऐसे ही software ship करता हूँ।

Project है Beadbox, AI coding agents की real-time monitoring के लिए एक dashboard। इसे उसी agent fleet ने बनाया है जिसे यह monitor करता है। Agents code लिखते हैं, test करते हैं, review करते हैं, package करते हैं, और ship करते हैं। मैं coordinate करता हूँ।

अगर आप दो-तीन से ज़्यादा agents चला रहे हैं और सोच रहे हैं कि सबका track कैसे रखें, तो महीनों की iteration के बाद मैं यहाँ पहुँचा हूँ। सुबह 9 बजे एक bug report हुआ और दोपहर 3 बजे तक fix ship हो गया, जबकि चार अन्य workstreams parallel में चल रहे थे। हमेशा सब ठीक नहीं होता, लेकिन throughput असली है।

टीम की संरचना

हर agent के पास एक CLAUDE.md file है जो उसकी identity, responsibilities, सीमाएँ और दूसरे agents के साथ communication का तरीका define करती है। ये generic "कुछ भी कर दो" वाले assistants नहीं हैं। हर एक का काम संकीर्ण है और boundaries स्पष्ट हैं।

समूह	Agents	ज़िम्मेदारी
Coordination	super, pm, owner	काम का वितरण, product specs, business priorities
Engineering	eng1, eng2, arch	Implementation, system design, test suites
Quality	qa1, qa2	स्वतंत्र validation, release gates
Operations	ops, shipper	Platform testing, builds, release execution
Growth	growth, pmm, pmm2	Analytics, positioning, public content

मुख्य शब्द है boundaries। eng2 issues close नहीं कर सकता। qa1 code नहीं लिखता। pmm कभी app source को नहीं छूता। Super काम assign करता है पर implement नहीं करता। Boundaries इसलिए हैं क्योंकि बिना इनके agents भटक जाते हैं। वे "मदद" करते हैं ऐसे code refactor करके जिसे refactoring की ज़रूरत नहीं थी, या unverified issues close करके, या ऐसे architectural decisions लेकर जो उनके दायरे में नहीं हैं।

हर CLAUDE.md एक identity paragraph और boundary section से शुरू होता है। यहाँ eng2 का संक्षिप्त रूप है:

## Identity
Engineer for Beadbox. You implement features, fix bugs, and write tests. You own implementation quality: the code you write is correct, tested, and matches the spec.

## Boundary with QA
QA validates your work independently. You provide QA with executable verification steps. If your DONE comment doesn't let QA verify without reading source code, it's incomplete.

यह pattern scale करता है। जब मैंने 3 agents से शुरू किया, एक ही loose prompt काम करता था। 13 पर, explicit roles और protocols coordination और अराजकता के बीच का फ़र्क हैं।

Coordination Layer

तीन tools पूरे fleet को जोड़ कर रखते हैं।

beads एक open-source, Git-native issue tracker है जो ठीक इसी workflow के लिए बना है। हर task एक "bead" है जिसमें status, priority, dependencies और comment thread होता है। Agents एक ही local database को bd नाम की CLI के ज़रिए read और write करते हैं।

bd update bb-viet --claim --actor eng2   # eng2 एक bug claim करता है
bd show bb-viet                           # पूरी spec + comments
bd comments add bb-viet --author eng2 "PLAN: ..."  # eng2 अपना plan post करता है

gn / gp / ga tmux messaging tools हैं। gn दूसरे agent के pane में message भेजता है। gp दूसरे agent का recent output देखता है (बिना disturb किए)। ga एक non-urgent message queue करता है।

gn -c -w eng2 "[from super] You have work: bb-viet. P2."  # dispatch
gp eng2 -n 40                                               # progress check
ga -w super "[from eng2] bb-viet complete. Pushed abc123."  # report back

CLAUDE.md protocols escalation paths, communication format और completion criteria define करते हैं। हर agent जानता है: bead claim करो, coding से पहले plan comment करो, push से पहले tests चलाओ, verification steps के साथ DONE comment करो, ready for QA mark करो, super को report करो।

व्यवहार में यह ऐसा दिखता है। यह आज का एक असली bead है: super टास्क असाइन करता है, eng2 एक नंबर वाला प्लान कमेंट करता है, eng2 QA वेरिफिकेशन स्टेप्स और चेक किए गए acceptance criteria के साथ DONE कमेंट करता है, super QA को भेजता है।

A real bead comment thread showing the full PLAN/DONE workflow

Super हर 5-10 मिनट में patrol loop चलाता है: हर active agent का output देखो, bead status check करो, verify करो कि pipeline रुका तो नहीं। यह production on-call rotation जैसा है, बस services AI agents हैं और incidents हैं "eng2 20 मिनट से संदिग्ध रूप से शांत है।"

एक असली दिन

यहाँ बताता हूँ फरवरी 2026 के आखिर में एक बुधवार को क्या हुआ।

सुबह 9:14 -- GitHub user ericinfins Issue #2 खोलता है: Beadbox को remote Dolt server से connect नहीं कर पा रहा। App सिर्फ local connections support करता है। Owner देखता है और super को flag करता है।

सुबह 9:30 -- Super काम distribute करता है। Arch connection auth flow design करता है (TLS toggle, username/password fields, environment variable passing)। PM acceptance criteria के साथ spec लिखता है। Eng उठाता है और implement करना शुरू करता है।

इसी बीच, parallel में:

PM release testing में मिले दो bugs file करता है। एक cosmetic: header badge final builds में "v0.10.0" की जगह "v0.10.0-rc.7" दिखाता है। दूसरा platform-specific: screenshot automation tool ARM64 Macs पर blank strip return करता है क्योंकि Apple Silicon Tauri के WebView को Metal compositing से render करता है, और backing store खाली है।

Ops screenshot bug की root cause ढूँढता है। Fix elegant है: capture के बाद check करो कि image height suspiciously छोटी तो नहीं (800px window के लिए 50px से कम), और अगर है तो coordinate-based screen capture पर fall back करो।

Growth PostHog data pull करता है और IP correlation analysis चलाता है। निष्कर्ष: Reddit ads ने 96 clicks दिए और zero attributable retained users। GitHub README traffic 15.8% पर convert होता है। यह article उसी analysis की वजह से लिखा गया है।

Eng1, arch के Activity Dashboard design से unblock होकर, cross-filter state management और utility functions बनाना शुरू करता है। 687 tests pass।

QA1 header badge fix validate करता है: test server start करता है, browser automation से badge render verify करता है, 665 unit tests pass confirm करता है, PASS mark करता है।

दोपहर 2:45 -- Shipper release candidate PR merge करता है, v0.10.0 tag push करता है, promote workflow trigger करता है। CI सभी 5 platforms के लिए artifacts build करता है (macOS ARM, macOS Intel, Linux AppImage, Linux .deb, Windows .exe)। Shipper हर artifact verify करता है, दोनों repos पर release notes update करता है, website redeploy करता है, और Homebrew cask update करता है।

दोपहर 3:12 -- Owner GitHub Issue #2 पर reply करता है:

Good news: v0.10.0 just shipped with full Dolt server auth support. Update and you should be unblocked.

Bug सुबह report हुआ। Fix दोपहर तक ship हो गया। और जब यह हो रहा था, अगला feature पहले से design हो रहा था, एक और bug root-cause हो रहा था, analytics analyze हो रही थी, और QA independently एक अलग fix verify कर रहा था।

यह इसलिए नहीं कि 13 agents तेज़ हैं। बल्कि इसलिए कि 13 agents parallel में काम करते हैं।

क्या गलत होता है

यह वह हिस्सा है जो ज़्यादातर "मेरा AI setup देखो" posts छोड़ देते हैं।

High concurrency पर rate limits लगते हैं। जब 13 agents एक ही API account पर चलते हैं, tokens तेज़ी से खत्म होते हैं। इस particular दिन super, eng1 और eng2 तीनों एक साथ rate limit ceiling पर पहुँच गए। सब रुक जाते हैं। आप इंतज़ार करते हैं। यह ऐसा है जैसे office में सब एक साथ printer use करना चाहें, बस printer per page charge करता है और per-minute page cap है।

QA काम वापस भेजता है। यह design के हिसाब से है, पर cycles बढ़ाता है। QA ने एक build reject किया क्योंकि engineer के "DONE" comment में verification steps नहीं थे। Fix काम करता था, पर QA source code पढ़े बिना confirm नहीं कर सकता था। वापस eng को, completion comment rewrite करो, फिर QA को, दोबारा verify करो। पाँच मिनट का काम बीस मिनट लगा। Protocol friction create करता है, पर यह friction load-bearing है। जब भी मैंने QA skip किया, production में कुछ टूटा।

Context windows भर जाती हैं। Agents एक session में context accumulate करते हैं। Super के पास 65% context usage पर "save your work" directive भेजने का protocol है। अगर यह window miss हो गया, agent भूल जाता है कि वह क्या कर रहा था।

Agents अटक जाते हैं। कभी-कभी agent error loop में फँस जाता है और वही failing command बार-बार retry करता रहता है। Super का patrol loop इसे पकड़ता है, पर तभी जब आप enough frequently check कर रहे हों। मैंने 30 मिनट एक ऐसे agent पर खोए जो शांति से fail हो रहा था।

Coordination overhead असली है। CLAUDE.md files, dispatch protocols, patrol loops, bead comments, completion reports। दो agents के setup के लिए यह overkill है। 13 agents के लिए यह minimum viable structure है। करीब 5 agents पर एक crossover point आता है जहाँ informal coordination काम करना बंद कर देता है और आपको explicit protocols चाहिए, वरना आप track खो देते हैं।

मैंने क्या सीखा

Specialization generalization को हराती है। 13 focused agents 3 "full-stack" agents से better perform करते हैं। जब qa1 सिर्फ validate करता है और कभी code नहीं लिखता, वह हर बार वो चीज़ पकड़ता है जो eng से छूट गई। जब arch सिर्फ design करता है और कभी implement नहीं करता, designs cleaner होते हैं क्योंकि implementation आसान करने के लिए spec में shortcut लेने का temptation नहीं होता।

Independent QA non-negotiable है। QA का अपना repo clone है। वह pushed code test करता है, working tree नहीं। Engineer की self-report पर trust नहीं करता। यह slow लगता है। पर हर release में bugs पकड़ता है।

आपको visibility चाहिए वरना fleet भटक जाता है। 5+ agents पर, tmux panes switch करके और दिमाग में bd list चलाकर state track नहीं हो सकता। आपको एक dashboard चाहिए जो dependency tree दिखाए, कौन agent क्या कर रहा है, और कौन से beads blocked हैं। यही problem solve करने के लिए मैंने Beadbox बनाया।

Recursive loop मायने रखता है। Agents Beadbox बनाते हैं। Beadbox agents को monitor करता है। जब agents Beadbox में bug create करते हैं, fleet उसी QA process से उसे पकड़ता है। Tool improve होता है क्योंकि जो team इसे सबसे ज़्यादा use करती है वही इसे बनाती है। मुझे पता है यह या तो brilliant है या अब तक बनी सबसे elaborate Rube Goldberg machine। Shipped features पहले वाले की तरफ इशारा करते हैं। मेरा token bill दूसरे की तरफ।

Tech Stack

अगर खुद try करना चाहते हैं, यह चाहिए:

beads: Open-source Git-native issue tracker। यह coordination backbone है। हर agent इसे read और write करता है।
Claude Code: Agent runtime। हर agent एक tmux pane में Claude Code session है जिसका अपना CLAUDE.md identity file है।
tmux + gn/gp/ga: Agents को side by side चलाने के लिए terminal multiplexer। Messaging tools agents को बिना shared memory के communicate करने देते हैं।
Beadbox: Real-time visual dashboard जो दिखाता है कि fleet क्या कर रहा है। यही वह है जिसके बारे में आप पढ़ रहे हैं।

शुरू करने के लिए 13 agents की ज़रूरत नहीं। दो engineers और एक QA agent, beads से coordinated, आपकी सोच बदल देंगे कि एक developer कितना ship कर सकता है।

आगे क्या है

मौजूदा setup में सबसे बड़ा gap तीन सवालों का एक नज़र में जवाब मिलना है: कौन से agents active हैं, idle हैं, या stuck हैं? Pipeline में काम कहाँ जमा हो रहा है? और अभी क्या हुआ, उस agent या pipeline stage से filter करके जो मुझे देखना है?

अभी इसके लिए patrol loop और बहुत सारे gp commands चाहिए। इसलिए हम Beadbox में सीधे एक coordination dashboard बना रहे हैं: ऊपर एक agent status strip, एक pipeline flow जो दिखाता है कि beads कहाँ accumulate हो रहे हैं, और एक cross-filtered event feed जहाँ किसी agent या pipeline stage पर click करने से बाकी सब उसी के अनुसार filter हो जाता है। तीनों layers एक ही real-time data source share करती हैं। तीनों live update होती हैं।

Activity Dashboard preview

13 agents इसे अभी बना रहे हैं। जब ship होगा तब इसके बारे में लिखूँगा।

मैं 13 AI Agents के साथ Software Ship करता हूँ। असल में यह कैसा दिखता है