Zurück zum Blog

Blockierte Aufgaben in paralleler Entwicklung sichten

Sie koennen jetzt 10 KI-Coding-Agenten parallel ausfuehren. Geben Sie jedem ein Issue, richten Sie sie auf eine gemeinsame beads-Datenbank und lassen Sie sie arbeiten. Agenten erstellen Teilaufgaben, melden entdeckte Bugs, aktualisieren Status und schliessen Issues, wenn sie fertig sind. Es ist wirklich produktiv.

Bis etwas blockiert.

Wenn ein Mensch blockiert ist, sagt er etwas. Er postet in Slack, er meldet es im Standup, er geht zum Schreibtisch von jemandem. Agenten tun nichts davon. Ein Agent stoesst auf eine Abhaengigkeit, die er nicht aufloesen kann, und stagniert entweder stillschweigend oder beginnt, das Problem zu umgehen, auf eine Weise, die weitere Probleme schafft. Drei Agenten koennen am selben ungeloesten Upstream-Task feststecken und Sie erfahren es erst, wenn Sie sich fragen, warum seit vier Stunden nichts ausgeliefert wurde.

Das ist das Triage-Problem fuer agentenbasierte Entwicklung. Nicht "wie fuehren wir bessere Standups durch", sondern "wie sehen wir, was in einer Flotte autonomer Arbeiter, die sich nicht beschweren, feststeckt." Hier ist, was wir beim Bau von Beadbox gelernt haben, einem Echtzeit-Dashboard fuer beads, das Ihnen genau zeigt, was Ihre Agenten tun, worauf sie blockiert sind und was gerade verfuegbar wurde.

Direkt zum relevanten Thema:

Wie Agenten Blockierungsketten erzeugen

Agenten erzeugen Abhaengigkeitsprobleme anders als menschliche Teams. Das Verstaendnis der Fehlermodi ist wichtig, weil die Triage-Reaktionen unterschiedlich sind.

Agenten modellieren Abhaengigkeiten nicht im Voraus. Ein menschlicher Architekt zerlegt ein Feature in Aufgaben und denkt ueber die Reihenfolge nach. Ein Coding-Agent erhaelt eine Aufgabe, beginnt mit der Arbeit und entdeckt mitten in der Implementierung, dass er etwas braucht, das noch nicht existiert. Er erstellt moeglicherweise ein neues Issue fuer diese Abhaengigkeit. Er versucht moeglicherweise, sie inline zu bauen und ein Chaos zu verursachen. Oder er stoppt einfach. Keines dieser Ergebnisse ist sichtbar, es sei denn, Sie beobachten die Issue-Datenbank.

Agenten arbeiten schneller als sich Abhaengigkeitsgraphen aktualisieren. Agent-3 schliesst eine Aufgabe, auf die Agent-7 gewartet hat, aber Agent-7 weiss es nicht, weil er vor 10 Minuten nach Blockern geschaut hat. In der Zwischenzeit ist Agent-7 immer noch untaetig oder arbeitet an etwas mit niedrigerer Prioritaet. Die Freigabe ist passiert, aber die Information hat sich nicht verbreitet.

Zirkulaere Abhaengigkeiten entstehen durch parallele Zerlegung. Wenn mehrere Agenten gleichzeitig Arbeit zerlegen, koennen sie Zyklen erzeugen, die kein einzelner Agent sieht. Agent-1 erstellt Aufgabe A, die von Aufgabe B abhaengt. Agent-2 erstellt Aufgabe B, die von Aufgabe C abhaengt. Agent-3 erstellt Aufgabe C, die von Aufgabe A abhaengt. Jede Abhaengigkeit war lokal sinnvoll. Der Zyklus ist nur von oben sichtbar.

Ressourcenkonflikte sind unsichtbar. Zwei Agenten muessen beide dieselbe Datei aendern, oder beide brauchen die Staging-Umgebung, oder beide brauchen dieselbe gemeinsame Bibliothek in einem stabilen Zustand. Es wird keine Abhaengigkeit gemeldet, weil keiner der Agenten vom anderen weiss. Beide werden einfach langsamer und keiner berichtet warum.

Der rote Faden: Agenten erzeugen Blockierungssituationen schneller, als sie diese melden. Der Supervisor (Sie) braucht Werkzeuge, die Blockaden automatisch sichtbar machen, nicht Werkzeuge, die darauf warten, dass jemand ein Signal gibt.

Automatische Abhaengigkeitserkennung

Die Loesung sind explizite, abfragbare Abhaengigkeitsdaten, die zum Zeitpunkt der Aufgabenerstellung erfasst und kontinuierlich ueberprueft werden. So sieht das mit beads aus, dem Git-nativen Issue-Tracker, mit dem wir unsere Agent-Flotte betreiben.

Agenten erfassen Abhaengigkeiten beim Erstellen von Aufgaben:

# Agent erstellt eine Aufgabe und entdeckt, dass eine noch nicht existierende API noetig ist
API_TASK=$(bd create \
  --title "Implement /api/v2/orders endpoint" \
  --type task --priority 2 --json | jq -r '.id')

# Agent erstellt seine eigene Aufgabe und deklariert die Abhaengigkeit
UI_TASK=$(bd create \
  --title "Build order history page" \
  --type task --priority 2 --json | jq -r '.id')

bd dep add "$UI_TASK" "$API_TASK"

Dieses bd dep add ist ein einzelner CLI-Aufruf. Jeder KI-Coding-Agent (Claude Code, Cursor, Copilot Workspace) kann ihn ausfuehren. Keine API-Client-Bibliothek, kein Authentifizierungstanz. Die Abhaengigkeit ist jetzt strukturierte Daten, abfragbar von jedem anderen Agenten oder Skript.

Zykluserkennung laeuft automatisch:

# beads prueft den gesamten Abhaengigkeitsgraphen auf Zyklen
bd dep cycles

# Ausgabe bei vorhandenen Zyklen:
# CYCLE DETECTED: beads-a1b -> beads-c3d -> beads-e5f -> beads-a1b

Bei einem 5.000-Abhaengigkeiten-Graphen dauert das ~70ms. Fuehren Sie es als Post-Commit-Hook oder per 5-Minuten-Cron aus. Wenn drei Agenten unabhaengig voneinander einen Abhaengigkeitszyklus erstellen, erkennen Sie ihn in Minuten statt Stunden spaeter, wenn alle drei stagnieren.

Alle blockierten Aufgaben mit einem Befehl anzeigen:

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

Ausgabe:

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

Jetzt wissen Sie, dass Agent-3 und Agent-7 feststecken, woran sie feststecken und was passieren muss, um sie freizugeben. Die gesamte Abfrage hat 30ms auf einer 10K-Issue-Datenbank gedauert.

Blockierte PRs ueber Branch-Namenskonventionen erkennen:

#!/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

Zwanzig Zeilen Shell. Laeuft lokal, liest lokale Daten, sagt Ihnen, welche PRs von Ihren Agenten noch nicht gemergt werden koennen und warum.

Ein CLI-First-Triage-Workflow

Triage in einem agentenbasierten Workflow ist kein Meeting. Es ist ein Skript, das in einer Schleife laeuft. Der Supervisor (Mensch oder Agent) schaut, was feststeckt, und trifft eine Entscheidung fuer jeden Punkt.

Hier ist das Triage-Skript, das wir tatsaechlich ausfuehren:

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

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

# 1. Was ist blockiert?
echo -e "\n--- BLOCKED TASKS ---"
bd blocked --json | jq -r '.[] |
  "[\(.priority)] \(.id) \(.title)
    blocked by: \(.blocked_by | join(", "))
    assignee: \(.owner // "unassigned")\n"'

# 2. Was ist fuer Agenten verfuegbar?
echo -e "\n--- READY (unblocked, open) ---"
bd ready --json | jq -r '.[] |
  "[\(.priority)] \(.id) \(.title) (\(.owner // "unassigned"))"'

# 3. Welche Agenten sind verstummt?
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. Zustand der Abhaengigkeiten
echo -e "\n--- DEPENDENCY CYCLES ---"
bd dep cycles 2>&1 || echo "No cycles detected."

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

Fuer menschliche Teams bedeutet "veraltet" 48 Stunden ohne Update. Fuer Agenten ist 2 Stunden Stille bei einer In-Progress-Aufgabe ein Warnsignal. Entweder steckt der Agent fest und meldet es nicht, oder er ist abgestuerzt. So oder so muessen Sie nachschauen.

Der Entscheidungsbaum fuer jeden blockierten Punkt:

  1. Kann ein anderer Agent die Blockade loesen? Die blockierende Aufgabe hoeher priorisieren, einen verfuegbaren Agenten zuweisen.
  2. Ist die Abhaengigkeit falsch? Agenten erstellen manchmal waehrend der Planung uebervorsichtige Abhaengigkeiten. Wenn die Blockade nicht real ist, entfernen: bd dep remove beads-x7q beads-m2k (entfernt die Abhaengigkeit von x7q auf m2k, gibt x7q sofort frei).
  3. Kann die Arbeit aufgeteilt werden? Den blockierten Agenten die Teile machen lassen, die die Abhaengigkeit nicht brauchen. Eine Folgeaufgabe fuer den Rest erstellen.
  4. Ist es eine externe Blockade? Etwas, das nur ein Mensch loesen kann (API-Key, Design-Entscheidung, Zugriffsberechtigung). Taggen, erwartete Loesung notieren und den Agenten auf andere verfuegbare Arbeit umleiten.

Option 2 passiert staendig mit Agenten. Sie modellieren Abhaengigkeiten basierend auf ihrem Verstaendnis der Codebasis zum Planungszeitpunkt. Sobald die Implementierung beginnt, zeigt die tatsaechliche Form der Arbeit, dass die Haelfte dieser Abhaengigkeiten unnoetig war.

Echtzeit-Sichtbarkeit der Agenten-Arbeit

Ein Triage-Skript alle 30 Minuten laesst Luecken. Wenn Agenten schnell arbeiten, passiert viel zwischen den Pruefungen. Die Frage wird: Koennen Sie sehen, wie sich Blockaden in Echtzeit bilden?

Wie Beadbox es macht:

Die beads-Datenbank lebt in einem .beads/-Verzeichnis auf Ihrem Dateisystem. Jedes bd update, bd create oder bd close, das ein Agent ausfuehrt, schreibt in dieses Verzeichnis. Beadbox ueberwacht es mit fs.watch() und pusht Aenderungen innerhalb von Millisekunden ueber WebSocket an die UI.

Der praktische Effekt: Agent-5 fuehrt bd update beads-x7q --status=closed in einem Terminal aus. Das Beadbox-Dashboard zeigt die Aufgabe sofort als geschlossen, und jede Aufgabe, die darauf blockiert war, leuchtet als neu verfuegbar auf. Sie sehen die Kaskade, ohne einen Befehl auszufuehren.

Das ist wichtig, weil agentenbasierte Arbeit in Schueben stattfindet. Ein Agent koennte drei Aufgaben in 90 Sekunden schliessen, die jeweils unterschiedliche nachgelagerte Arbeit freigeben. Ein Polling-basiertes Dashboard mit 30-Sekunden-Aktualisierungsintervall wuerde Ihnen einen verwirrenden Zwischenzustand zeigen. Propagierung unter einer Sekunde zeigt Ihnen das vollstaendige Bild, waehrend es passiert.

Wenn Sie Beadbox nicht verwenden, funktionieren Dateisystem-Watches trotzdem:

# 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

Den Kreislauf mit CI schliessen:

# 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

Wenn CI dieses Issue schliesst, wird alles, was es blockierte, freigegeben. Wenn ein Agent bd ready auf neue Arbeit ueberwacht, nimmt er die freigegebene Aufgabe automatisch auf. Kein Mensch in der Schleife fuer Routine-Freigaben.

Das ist der Unterschied zwischen Tools, die Status tracken, und Tools, die ihn propagieren. Die meisten Projektmanagement-Programme tun Ersteres: Sie aktualisieren eine Karte, die Karte aendert die Farbe. Propagierung bedeutet, dass nachgelagerte Effekte (Abhaengige freigeben, verfuegbare Arbeit anzeigen, Fortschrittszusammenfassungen aktualisieren) ohne jeden Klick passieren.

Triage-Tools fuer agentenbasierte Workflows bewerten

Wenn Sie nach Werkzeugen suchen, um eine Agent-Flotte zu verwalten, sind die Anforderungen anders als bei einem menschlichen Team.

Muss: CLI, die Agenten aufrufen koennen. Wenn Ihr Issue-Tracker nur eine Web-UI hat, koennen Agenten ihn nicht nutzen. Sie muessen Shell-Befehle ausfuehren koennen. bd create, bd update, bd blocked sind Einzeiler, die jeder Coding-Agent bereits ausfuehren kann. REST-APIs funktionieren auch, erfordern aber Auth-Tokens, HTTP-Clients und Fehlerbehandlung. Unix-Pipes sind einfacher.

Muss: abfragbarer Abhaengigkeitsgraph. "Blockiert" als Status-Label ist fuer Automatisierung nutzlos. Sie brauchen A haengt von B ab als strukturierte Daten, damit Skripte den Graphen traversieren, Zyklen erkennen und berechnen koennen, was bereit ist.

Muss: Lokale Lesevorgaenge unter einer Sekunde. Wenn Agenten nach verfuegbarer Arbeit fragen, zaehlt die Antwortzeit. Ein 2-Sekunden-API-Roundtrip pro Abfrage, multipliziert mit 10 Agenten, die jede Minute pollen, erzeugt messbaren Overhead. beads liefert bd ready-Ergebnisse in 30ms auf einer 10K-Issue-Datenbank, weil alles lokal ist.

Nett: Echtzeit-Aenderungspropagierung. Wenn Agenten 50 Issues pro Stunde erstellen und loesen, muessen Sie den Zustand sehen, waehrend er sich aendert, nicht in einem Aktualisierungsintervall.

Warnsignal: "KI-gestuetzte Blocker-Erkennung." Tools, die behaupten, Blockaden durch Analyse von Issue-Beschreibungen zu erkennen, erzeugen False Positives und verpassen echte Blockaden, die nie aufgeschrieben wurden. Explizite bd dep add-Deklarationen schlagen Inferenz.

Warnsignal: Tools, die einen Browser fuer Triage erfordern. Das Freigeben einer Aufgabe ueber eine Web-UI dauert 5-15 Sekunden Klicken. Ueber die CLI dauert bd dep remove 18ms. Bei 50 blockierten Aufgaben sind das 1 Minute vs. 12 Minuten. Wenn Sie Agenten beaufsichtigen, die sich schnell bewegen, ist die Triage-Geschwindigkeit Ihr Engpass.

Wie gaengige Tools mit Blockierungen umgehen

Faehigkeit Jira Linear GitHub Issues beads + Beadbox
Abhaengigkeits-Tracking Plugin (Advanced Roadmaps) Relations (teilweise) Tasklist-Referenzen First-Class bd dep add
Blockiert-Status automatisch Manuell Manuell Manuell Automatisch aus Deps
Zykluserkennung Nein Nein Nein Eingebaut (bd dep cycles)
CLI fuer Agenten Jira CLI (Drittanbieter) Linear CLI (eingeschraenkt) gh (keine Deps) Vollstaendig (bd blocked, bd ready)
Echtzeit-Propagierung Webhook (serverseitig) Webhook (serverseitig) Webhook (serverseitig) fs.watch (unter 1 Sekunde, lokal)
Offline / lokal Nein Nein Nein Ja (Embedded-Modus)
Agent-skriptfaehig API + Auth-Tokens API + Auth-Tokens gh CLI bd CLI (Unix-Pipes)

Die Supervisor-Schleife

Hier ist der Workflow, den wir taeglich ausfuehren, mit 10+ KI-Agenten auf einem einzelnen Projekt:

  1. Agenten deklarieren Abhaengigkeiten bei der Aufgabenerstellung. Jedes bd create, das eine Voraussetzung hat, bekommt sofort ein bd dep add. Das ist ein einziger zusaetzlicher CLI-Aufruf pro Aufgabe.

  2. Ein Supervisor-Agent fuehrt alle 30 Minuten bd blocked aus. Wenn etwas neu blockiert ist, loest er den Blocker entweder selbst (umpriorisieren, neu zuweisen) oder meldet es dem Menschen.

  3. Beadbox laeuft auf dem Bildschirm des Menschen. Das Dashboard zeigt den vollstaendigen Abhaengigkeitsgraphen mit blockierten Aufgaben in Echtzeit hervorgehoben. Meistens kuemmert sich die Automatisierung um Routine-Freigaben. Wenn sie es nicht kann (externe Abhaengigkeit, Architekturentscheidung, Zugriffsberechtigung), sieht der Mensch das Problem sofort und greift ein.

  4. Veraltete Aufgaben werden aggressiv gemeldet. Ein Agent, der seine In-Progress-Aufgabe seit 2 Stunden nicht aktualisiert hat, steckt entweder fest oder ist abgestuerzt. Der Supervisor prueft und stupst entweder den Agenten an, weist die Arbeit neu zu oder untersucht.

  5. Falsche Abhaengigkeiten werden kontinuierlich bereinigt. Agenten ueberdeklarieren Abhaengigkeiten waehrend der Planung. Wenn die Implementierung die tatsaechliche Form der Arbeit zeigt, entfernt der Supervisor (oder die Agenten selbst) Abhaengigkeiten, die sich als unnoetig herausgestellt haben. Ein sauberer Graph ist ein nuetzlicher Graph.

Das zugrunde liegende Prinzip: Agenten sind schnell, aber nicht selbstbewusst. Sie wissen nicht, was andere Agenten tun, sie bemerken nicht, wenn Blockaden sich aufloesen, und sie beschweren sich nicht, wenn sie feststecken. Die Aufgabe des Supervisors ist es, das Nervensystem zu sein, das all das verbindet. Strukturierte Abhaengigkeitsdaten, automatisch abgefragt und visuell dargestellt, machen das moeglich.


Beadbox ist waehrend der Beta kostenlos. Es zeigt Ihnen, was Ihre Agenten tun, was blockiert ist und was gerade verfuegbar wurde, in Echtzeit.

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

Wenn Sie bereits beads verwenden, liest Beadbox Ihr bestehendes .beads/-Verzeichnis ohne Import-Schritt. Probieren Sie es aus.