अब आप 10 AI coding agents parallel में चला सकते हैं। हर एक को issue दें, shared beads database पर point करें, और काम करने दें। Agents subtasks बनाते हैं, bugs file करते हैं, statuses update करते हैं, और काम पूरा होने पर issues close करते हैं। यह सच में productive है।

जब तक कुछ block न हो जाए।

जब इंसान block होता है, बोलता है। Slack में post करता है, standup में flag करता है, किसी की desk पर जाता है। Agents ऐसा कुछ नहीं करते। Agent एक dependency से टकराता है जिसे resolve नहीं कर सकता, और या तो चुपचाप रुक जाता है या problem को ऐसे तरीकों से bypass करने लगता है जो और problems create करते हैं। तीन agents एक ही unresolved upstream task पर अटके हो सकते हैं और आपको तब तक पता नहीं चलता जब तक आप सोचें कि चार घंटे में कुछ ship क्यों नहीं हुआ।

यह agentic development की triage problem है। "बेहतर standups कैसे करें" नहीं बल्कि "autonomous workers के fleet में जो शिकायत नहीं करते, क्या अटका है कैसे देखें।" यहाँ बताता हूँ क्या सीखा Beadbox बनाते हुए, beads के लिए real-time dashboard जो दिखाता है कि आपके agents क्या कर रहे हैं, किस पर blocked हैं, और क्या अभी available हुआ।

जो section चाहिए उस पर जाएँ:

Agents blocking chains कैसे बनाते हैं -- agentic काम के unique patterns
Automated dependency detection -- blocks बनते ही पकड़ें
CLI-first triage workflow -- scriptable, agent-runnable
Real-time visibility -- blocks होते ही देखें
Triage tools का evaluation -- क्या देखें
Supervisor loop -- रोज़ाना 10+ agents कैसे manage करते हैं

Agents blocking chains कैसे बनाते हैं

Agents human teams से अलग तरीके से dependency problems create करते हैं। Failure modes समझना ज़रूरी है क्योंकि triage responses अलग हैं।

Agents dependencies upfront model नहीं करते। Human architect feature को tasks में decompose करता है और ordering सोचता है। Coding agent task receive करता है, काम शुरू करता है, और mid-implementation discover करता है कि उसे कुछ चाहिए जो exist नहीं करता। वह उस dependency के लिए new issue file कर सकता है। Inline build करने की कोशिश करके mess बना सकता है। बस रुक सकता है। इनमें से कोई भी outcome तब तक visible नहीं जब तक आप issue database watch नहीं कर रहे।

Agents dependency graphs update होने से तेज़ काम करते हैं। Agent-3 एक task close करता है जिसका Agent-7 wait कर रहा था, पर Agent-7 को पता नहीं क्योंकि उसने 10 मिनट पहले blockers check किए थे। इस बीच Agent-7 अभी भी idle है या lower priority काम कर रहा है। Unblock हो गया, पर information propagate नहीं हुई।

Circular dependencies parallel decomposition से उभरती हैं। जब multiple agents एक साथ काम decompose करते हैं, ऐसे cycles बना सकते हैं जो कोई single agent नहीं देखता। Agent-1 Task A बनाता है जो Task B पर depend करता है। Agent-2 Task B बनाता है जो Task C पर depend करता है। Agent-3 Task C बनाता है जो Task A पर depend करता है। हर dependency locally sense बनाती थी। Cycle सिर्फ ऊपर से दिखता है।

Resource contention invisible है। दो agents दोनों को same file modify करना है, या दोनों को staging environment चाहिए, या दोनों को same shared library stable state में चाहिए। Dependency file नहीं है क्योंकि कोई agent दूसरे के existence को नहीं जानता। दोनों बस slow हो जाते हैं और कोई report नहीं करता क्यों।

Common thread: agents blocking situations report करने से तेज़ create करते हैं। Supervisor (आप) को ऐसे tooling चाहिए जो blocks automatically surface करे, ऐसे tooling नहीं जो किसी के flag raise करने का wait करे।

Automated dependency detection

Solution है explicit, queryable dependency data जो task creation time पर बनाया जाए और continuously check हो। यह beads के साथ कैसा दिखता है, Git-native issue tracker जिस पर हम अपना agent fleet चलाते हैं।

Agents tasks बनाते समय dependencies record करते हैं:

# Agent task create करता है और discover करता है कि एक API चाहिए जो exist नहीं करता
API_TASK=$(bd create \
  --title "Implement /api/v2/orders endpoint" \
  --type task --priority 2 --json | jq -r '.id')

# Agent अपना task create करता है और dependency declare करता है
UI_TASK=$(bd create \
  --title "Build order history page" \
  --type task --priority 2 --json | jq -r '.id')

bd dep add "$UI_TASK" "$API_TASK"

यह bd dep add एक single CLI call है। कोई भी AI coding agent (Claude Code, Cursor, Copilot Workspace) इसे run कर सकता है। कोई API client library नहीं, कोई authentication dance नहीं। Dependency अब structured data है, किसी भी दूसरे agent या script से queryable।

Cycle detection automatically चलता है:

# beads पूरे dependency graph को cycles के लिए check करता है
bd dep cycles

# Cycles होने पर output:
# CYCLE DETECTED: beads-a1b -> beads-c3d -> beads-e5f -> beads-a1b

5,000-dependency graph पर ~70ms लगते हैं। Post-commit hook या 5-minute cron पर चलाएँ। जब तीन agents independently dependency cycle create करें, आप minutes में पकड़ लेते हैं, hours बाद नहीं जब तीनों stall हो चुके हों।

एक command में सभी blocked tasks:

bd blocked --json | jq -r '.[] |
  "BLOCKED: \(.id) \(.title)\n  waiting on: \(.blocked_by | join(", "))\n  assignee: \(.owner // "unassigned")\n"'

Output:

BLOCKED: beads-x7q Build order history page
  waiting on: beads-m2k Implement /api/v2/orders endpoint
  assignee: agent-3

BLOCKED: beads-r4p Deploy staging environment
  waiting on: beads-j9w Fix Docker build, beads-n1c Update TLS certificates
  assignee: agent-7

अब आप जानते हैं कि Agent-3 और Agent-7 stuck हैं, किस पर stuck हैं, और unblock करने के लिए क्या करना है। पूरी query 10K-issue database पर 30ms लगी।

Branch naming conventions से blocked PRs detect करें:

#!/bin/bash
# blocked-prs.sh: find PRs whose dependencies haven't merged

for pr in $(gh pr list --json number,headRefName --jq '.[].headRefName'); do
  ISSUE_ID=$(echo "$pr" | grep -oE 'beads-[a-z0-9]+')
  [ -z "$ISSUE_ID" ] && continue

  BLOCKERS=$(bd show "$ISSUE_ID" --json | jq -r '.blocked_by[]' 2>/dev/null)
  for blocker in $BLOCKERS; do
    BLOCKER_STATUS=$(bd show "$blocker" --json | jq -r '.status')
    if [ "$BLOCKER_STATUS" != "closed" ]; then
      echo "PR ($pr) blocked: $ISSUE_ID waiting on $blocker ($BLOCKER_STATUS)"
    fi
  done
done

बीस lines shell। Locally run होता है, local data read करता है, बताता है कि आपके agents के कौन से PRs अभी merge नहीं हो सकते और क्यों।

CLI-first triage workflow

Agentic workflow में triage meeting नहीं है। यह loop में चलने वाला script है। Supervisor (human या agent) देखता है क्या stuck है और हर item के लिए decision लेता है।

यह triage script हम actually run करते हैं:

#!/bin/bash
# triage.sh: agentic fleet blocker triage

echo "========================================="
echo "TRIAGE REPORT: $(date +%Y-%m-%d %H:%M)"
echo "========================================="

# 1. क्या blocked है?
echo -e "\n--- BLOCKED TASKS ---"
bd blocked --json | jq -r '.[] |
  "[\(.priority)] \(.id) \(.title)
    blocked by: \(.blocked_by | join(", "))
    assignee: \(.owner // "unassigned")\n"'

# 2. Agents pick up करने के लिए क्या available है?
echo -e "\n--- READY (unblocked, open) ---"
bd ready --json | jq -r '.[] |
  "[\(.priority)] \(.id) \(.title) (\(.owner // "unassigned"))"'

# 3. कौन से agents शांत हो गए?
echo -e "\n--- STALE IN-PROGRESS (no update in 2h) ---"
CUTOFF=$(date -v-2H +%Y-%m-%dT%H:%M:%S 2>/dev/null || date -d '2 hours ago' --iso-8601=seconds)
bd list --status=in_progress --json | jq -r --arg cutoff "$CUTOFF" '.[] |
  select(.updated_at < $cutoff) |
  "STALE: \(.id) \(.title) (last update: \(.updated_at), assignee: \(.owner // "unknown"))"'

# 4. Dependency health
echo -e "\n--- DEPENDENCY CYCLES ---"
bd dep cycles 2>&1 || echo "No cycles detected."

echo -e "\n--- FLEET STATS ---"
bd stats

Human teams के लिए "stale" का मतलब 48 घंटे बिना update। Agents के लिए in-progress task पर 2 घंटे की खामोशी red flag है। या तो agent stuck है और report नहीं कर रहा, या crash हो गया। दोनों cases में देखना ज़रूरी है।

हर blocked item के लिए decision tree:

क्या दूसरा agent unblock कर सकता है? Blocking task को reprioritize करें, available agent assign करें।
क्या dependency false है? Agents कभी-कभी planning के दौरान overly conservative dependencies file करते हैं। अगर block real नहीं है, हटाएँ: bd dep remove beads-x7q beads-m2k (x7q की m2k पर dependency हटाता है, x7q को instantly unblock करता है)।
क्या काम split हो सकता है? Blocked agent को वे parts करने दें जिन्हें dependency की ज़रूरत नहीं। बाकी के लिए follow-up task बनाएँ।
External block है? कुछ जो सिर्फ human resolve कर सकता है (API key, design decision, access grant)। Tag करें, expected resolution note करें, agent को दूसरे ready काम पर reassign करें।

Option 2 agents के साथ लगातार होता है। वे planning time पर codebase की अपनी समझ के आधार पर dependencies model करते हैं। Implementation शुरू होते ही, काम का असली shape दिखाता है कि आधी dependencies unnecessary थीं।

Agent work में real-time visibility

Triage script हर 30 मिनट चलाने में gaps रहते हैं। जब agents तेज़ काम करते हैं, checks के बीच बहुत कुछ होता है। सवाल: क्या blocks बनते हुए real time में देख सकते हैं?

Beadbox कैसे करता है:

beads database आपकी filesystem पर .beads/ directory में रहती है। Agent का हर bd update, bd create, या bd close इस directory में write करता है। Beadbox fs.watch() से इसे watch करता है और milliseconds में WebSocket से UI में changes push करता है।

Practical effect: Agent-5 terminal में bd update beads-x7q --status=closed run करता है। Beadbox dashboard तुरंत वह task closed दिखाता है, और जो task उस पर blocked था वह newly available दिखता है। कोई command run किए बिना cascade दिखता है।

यह important है क्योंकि agentic काम bursts में होता है। एक agent 90 seconds में तीन tasks close कर सकता है, हर एक different downstream work unblock करता है। 30-second refresh interval वाला polling-based dashboard confusing intermediate state दिखाता। Sub-second propagation पूरी picture बनते हुए दिखाता है।

अगर Beadbox use नहीं करते, filesystem watches फिर भी काम करती हैं:

# Watch the beads database for changes, alert on new blocks
# Note: fswatch fires on every write. In production you'd debounce this
# (e.g., sleep 2 after each trigger) to avoid noise during burst writes.
fswatch -o .beads/ | while read; do
  BLOCKED_COUNT=$(bd blocked --json | jq length)
  if [ "$BLOCKED_COUNT" -gt 0 ]; then
    echo "$(date): $BLOCKED_COUNT tasks currently blocked"
    # Pipe to ntfy, Slack webhook, or any notification system
  fi
done

CI से loop close करें:

# In your CI post-build step: auto-close the issue when the build passes
if [ "$BUILD_STATUS" = "success" ]; then
  ISSUE_ID=$(echo "$BRANCH_NAME" | grep -oE 'beads-[a-z0-9]+')
  if [ -n "$ISSUE_ID" ]; then
    bd update "$ISSUE_ID" --status=closed
    bd comments add "$ISSUE_ID" --author ci \
      "Build passed. Commit: $COMMIT_SHA. Closing automatically."
  fi
fi

जब CI वह issue close करता है, जो कुछ वह block कर रहा था unblock हो जाता है। अगर कोई agent bd ready watch कर रहा है नए काम के लिए, वह unblocked task automatically pick कर लेता है। Routine unblocks में कोई human loop में नहीं।

यह उन tools में फ़र्क है जो status track करते हैं और जो propagate करते हैं। ज़्यादातर project management software पहला करता है: card update करो, card color बदले। Propagation का मतलब है कि downstream effects (dependents unblock करना, available work surface करना, progress rolls update करना) बिना किसी click के होते हैं।

Agentic workflows के लिए triage tools का evaluation

अगर agent fleet manage करने के लिए tooling choose कर रहे हैं, requirements human team की ज़रूरतों से अलग हैं।

ज़रूरी: CLI जो agents call कर सकें। अगर issue tracker में सिर्फ web UI है, agents use नहीं कर सकते। उन्हें shell commands चाहिए। bd create, bd update, bd blocked सब one-liners हैं जो कोई भी coding agent पहले से जानता है कैसे execute करना है। REST APIs भी काम करते हैं, पर auth tokens, HTTP clients, और error handling चाहिए। Unix pipes simpler हैं।

ज़रूरी: queryable dependency graph। "Blocked" एक status label के रूप में automation के लिए useless है। आपको A depends on B structured data के रूप में चाहिए ताकि scripts graph traverse कर सकें, cycles detect करें, और compute करें क्या ready है।

ज़रूरी: sub-second local reads। जब agents available work query करते हैं, response time matter करता है। 2-second API round-trip per query, 10 agents हर minute poll कर रहे, measurable overhead create करता है। beads 10K-issue database पर bd ready results 30ms में return करता है क्योंकि सब local है।

अच्छा हो: real-time change propagation। अगर agents per hour 50 issues file और resolve करते हैं, state बदलते हुए देखना चाहिए, refresh interval पर नहीं।

Red flag: "AI-powered blocker detection।" जो tools claim करते हैं कि issue descriptions analyze करके blockers detect करते हैं, false positives देते हैं और real blockers miss करते हैं जो कभी लिखे ही नहीं गए। Explicit bd dep add declarations inference से better हैं।

Red flag: tools जो triage के लिए browser माँगते हैं। Web UI से एक task unblock करने में 5-15 seconds clicking लगती है। CLI से bd dep remove 18ms लगता है। 50 blocked tasks पर, 1 minute vs 12 minutes। जब fast-moving agents supervise कर रहे हैं, triage speed आपकी bottleneck है।

Common tools blocking कैसे handle करते हैं

Capability	Jira	Linear	GitHub Issues	beads + Beadbox
Dependency tracking	Plugin (Advanced Roadmaps)	Relations (partial)	Tasklist references	First-class `bd dep add`
Blocked status auto-set	Manual	Manual	Manual	Automatic from deps
Cycle detection	No	No	No	Built-in (`bd dep cycles`)
Agents के लिए CLI	Jira CLI (third-party)	Linear CLI (limited)	`gh` (no deps)	Full (`bd blocked`, `bd ready`)
Real-time propagation	Webhook (server-side)	Webhook (server-side)	Webhook (server-side)	fs.watch (sub-second, local)
Offline / local काम	No	No	No	Yes (embedded mode)
Agent-scriptable	API + auth tokens	API + auth tokens	`gh` CLI	`bd` CLI (Unix pipes)

Supervisor loop

यह workflow है जो हम daily run करते हैं, एक project पर 10+ AI agents manage करते हुए:

Agents task creation time पर dependencies declare करते हैं। हर bd create जिसकी prerequisite है, तुरंत bd dep add मिलता है। Per task एक extra CLI call।
Supervisor agent हर 30 मिनट bd blocked run करता है। अगर कुछ newly blocked है, वह blocker खुद resolve करता है (reprioritize, reassign) या human को flag करता है।
Human की screen पर Beadbox चलता है। Dashboard full dependency graph दिखाता है blocked tasks real time में highlighted। ज़्यादातर समय automation routine unblocks handle करती है। जब नहीं कर पाती (external dependency, architectural decision, access grant), human immediately problem देखता है और intervene करता है।
Stale tasks aggressively flag होती हैं। जिस agent ने 2 घंटे से अपनी in-progress task update नहीं की, वह या stuck है या crash हो गया। Supervisor check करता है और agent को nudge करता है, काम reassign करता है, या investigate करता है।
False dependencies continuously prune होती हैं। Agents planning के दौरान ज़रूरत से ज़्यादा dependencies declare करते हैं। जैसे-जैसे implementation काम का असली shape reveal करता है, supervisor (या agents खुद) unnecessary dependencies remove करते हैं। Clean graph useful graph है।

Underlying principle: agents fast हैं पर self-aware नहीं। वे नहीं जानते दूसरे agents क्या कर रहे हैं, notice नहीं करते जब blockers resolve होते हैं, और stuck होने पर complain नहीं करते। Supervisor का काम वह nervous system होना है जो यह सब connect करे। Structured dependency data, automatically queried और visually rendered, यही possible बनाता है।

Beadbox beta में free है। यह दिखाता है कि आपके agents क्या कर रहे हैं, क्या blocked है, और क्या अभी available हुआ, real time में।

brew tap beadbox/cask && brew install --cask beadbox

अगर आप पहले से beads use करते हैं, Beadbox आपकी existing .beads/ directory बिना import step के read करता है। Try करें।