आपके पाँच AI coding agents एक feature epic पर काम कर रहे हैं। Agent 1 API layer build कर रहा है। Agent 2 को frontend wire up करने के लिए वह API चाहिए। Agent 3 integration tests लिख रहा है जो दोनों पर depend करते हैं। Agents 4 और 5 migrations और docs handle कर रहे हैं, हर एक अलग pieces पर blocked।
यह करीब बीस मिनट काम करता है। फिर Agent 2 stall हो जाता है क्योंकि Agent 1 को unexpected schema problem मिली। Agent 3 अब Agent 2 पर blocked है, जो Agent 1 पर blocked है। Agents 4 और 5 काम करते रहते हैं, पर उनका काम chain resolve होने तक merge नहीं हो सकता। आपको तब पता चलता है जब सोचते हैं कि एक घंटे में कुछ ship क्यों नहीं हुआ और हर issue पर bd blocked run करना शुरू करते हैं।
Dependency information exist करती है। आपके issue tracker में रहती है। पर जब CLI से manage करते हैं, flat text output से दिमाग में graph reconstruct कर रहे होते हैं। वह reconstruction ठीक उस moment fail होता है जब सबसे ज़्यादा matter करता है: जब graph complex हो और चीज़ें टूट रही हों।
beads dependencies कैसे track करता है
beads एक git-backed issue tracker है जो AI agent coordination के लिए बना है। सब कुछ आपके repo की .beads/ directory में local Dolt database में store करता है। कोई cloud service नहीं, accounts नहीं, sync conflicts नहीं।
Agents एक command से dependencies declare करते हैं:
bd dep add ISSUE-42 ISSUE-37
यह record करता है कि ISSUE-42 ISSUE-37 पर depend करता है। ISSUE-42 तब तक आगे नहीं बढ़ सकता जब तक ISSUE-37 close न हो। Inverse query उतना ही simple है:
bd blocked
यह workspace में हर issue return करता है जो unresolved dependency से blocked है। किसी specific issue के लिए:
bd dep list ISSUE-42
यह दिखाता है ISSUE-42 किस पर depend करता है और क्या ISSUE-42 पर depend करता है।
Data model clean है। Problem dependencies record करने में नहीं। Problem उन्हें देखने में है। जब पाँच agents पर 30 active issues हैं, bd blocked एक list देता है। List नहीं दिखाती कि ISSUE-12 bottleneck है जो तीन agents की सात downstream tasks block कर रहा। List नहीं दिखाती कि Agent 3 ने ISSUE-18 और ISSUE-22 के बीच circular dependency बनाई। आपको graph का spatial view चाहिए, sequential नहीं।
Beadbox क्या दिखाता है
Beadbox एक native desktop app है जो beads CLI को visual interface से wrap करता है। वही .beads/ database read करता है जिसमें agents write करते हैं, और real time में update होता है जैसे वे काम करते हैं।
Epic tree view में, हर issue जिसकी unresolved dependencies हैं, inline blocked badge दिखाता है। Epic का पूरा tree structure दिखता है, blocked issues एक नज़र में marked। कोई command run करने की या output parse करने की ज़रूरत नहीं।
Dependency chain spatially visible है। अगर ISSUE-42 ISSUE-37 पर depend करता है, ISSUE-37 ISSUE-15 पर, और ISSUE-15 Agent 1 को assigned है जो stuck है, tree scan करके यह chain trace कर सकते हैं। Bottleneck का shape अलग-अलग CLI queries से reconstruct किए बिना दिखता है।
Real-time piece matter करता है। जब Agent 1 finally ISSUE-15 close करता है, Beadbox UI एक second में reflect करता है। ISSUE-37 पर blocked badge drop होता है। अगर ISSUE-37 ही अकेला ISSUE-42 block कर रहा था, वह badge भी drop होता है। काम complete होने पर dependency chain collapse होते हुए देखते हैं, बिना refresh या re-query किए।
Under the hood, straightforward pipeline काम करती है: WebSocket server .beads/ directory को fs.watch() से watch करता है। जब कोई agent database में write करता है (issue close करना, dependency add करना, status update करना), filesystem event सभी connected clients को broadcast trigger करता है। React UI fresh data से re-render होता है। Agent action से visual update तक sub-second latency।
एक concrete scenario: bottleneck ढूँढना
पाँच agents 24 issues वाले feature epic पर काम कर रहे हैं। Beadbox खोलकर epic tree देखते हैं। बारह issues in progress। छह blocked badges दिखा रहे।
यह पहले से वह information है जो आपके पास नहीं थी। bd list 12 in-progress issues दिखाता, पर separately bd blocked run करके cross-reference करना पड़ता कि कौन से in-progress issues actually stalled हैं।
Blocked badges scan करते हैं और notice करते हैं: छह blocked issues में से चार सब ISSUE-19 पर depend करते हैं, Agent 4 को assigned database schema migration। Agent 4 अभी काम कर रहा, पर ISSUE-19 single-point bottleneck बन गया। चार agents effectively idle हैं, एक task का wait कर रहे।
Visual view के बिना, शायद एक और घंटे तक पता नहीं चलता। इसके साथ, immediately intervene कर सकते हैं। शायद ISSUE-19 तेज़ agent को reassign करें। शायद छोटे pieces में split करें जो कुछ dependents को जल्दी unblock करें। शायद realize करें कि चार में से दो dependencies over-declared थीं और bd dep remove से remove हो सकती हैं।
Point यह नहीं कि information पहले unavailable थी। हमेशा database में थी। Point यह है कि visual representation patterns surface करता है जो flat text छुपाता है।
Common dependency anti-patterns
एक repo पर multiple AI agents चलाने से कुछ recurring dependency problems होती हैं। सभी visually CLI queries से ज़्यादा आसानी से पकड़ी जाती हैं।
Over-declaration। Agents conservative होते हैं। Doubt होने पर dependency declare करते हैं। Result ज़रूरत से dense dependency graph, issues ऐसे काम पर blocked जिसकी actually ज़रूरत नहीं। Beadbox में, यह तब दिखता है जब issue blocked badge दिखाता है पर blocking issue codebase के बिल्कुल unrelated part में है। Quick bd dep remove साफ़ कर देता है।
Circular chains। Agent A Agent B के काम पर dependency declare करता है। Agent B, independently काम करते हुए, Agent A के काम पर dependency declare करता है। अब दोनों एक दूसरे पर blocked हैं और कोई आगे नहीं बढ़ सकता। beads CLI creation time पर obvious circular dependencies पकड़ता है, पर तीन या ज़्यादा issues से indirect cycles detect करना harder है। Epic tree में, ये blocked badges के clusters के रूप में दिखते हैं जो कभी resolve नहीं होते, भले ही आसपास का काम complete हो रहा हो।
Single-point bottlenecks। एक issue पाँच, छह, सात downstream dependents accumulate करता है। यह naturally होता है जब parallel काम करने वाले agents सबको same foundational piece चाहिए। ऊपर का scenario यह pattern illustrate करता है। List view में, सात blocked issues दिखते हैं। Tree view में, सात arrows एक ही node पर point करते दिखते हैं। Bottleneck obvious है।
शुरू करें
Beadbox macOS, Linux, और Windows पर चलता है। Homebrew से install करें:
brew tap beadbox/cask && brew install --cask beadbox
.beads/ directory वाले किसी भी repository पर point करें। अगर पहले से agent fleet के साथ beads चला रहे हैं, Beadbox existing database pick करता है और immediately render करना शुरू करता है। कोई import step नहीं, configuration नहीं, account creation नहीं।
Agents CLI use करते रहते हैं। bd dep add, bd update, bd close हमेशा की तरह run करते हैं। Beadbox database watch करता है और हर change real time में reflect करता है। Agent workflows बदले बिना visual layer मिल जाता है।
Beadbox beta में free है।
अगर एक codebase पर multiple AI agents coordinate कर रहे हैं, dependency graph वह चीज़ है जो सबसे पहले workflow तोड़ेगी। CLI से blindly manage कर सकते हैं, या देख सकते हैं। देखना तेज़ है।