Sie haben fuenf KI-Coding-Agenten, die an einem Feature-Epic arbeiten. Agent 1 baut die API-Schicht. Agent 2 braucht diese API, um das Frontend zu verdrahten. Agent 3 schreibt Integrationstests, die von beidem abhaengen. Agenten 4 und 5 kuemmern sich um Migrationen und Dokumentation, jeweils blockiert durch verschiedene Teile.
Das funktioniert etwa zwanzig Minuten lang. Dann stagniert Agent 2, weil Agent 1 auf ein unerwartetes Schema-Problem gestossen ist. Agent 3 ist jetzt blockiert durch Agent 2, der durch Agent 1 blockiert ist. Agenten 4 und 5 arbeiten weiter, aber ihre Arbeit kann nicht gemergt werden, bis die Kette aufgeloest ist. Sie erfahren das erst, als Sie sich wundern, warum seit einer Stunde nichts ausgeliefert wurde, und beginnen, bd blocked fuer jedes Issue durchzugehen.
Die Abhaengigkeitsinformation existiert. Sie lebt in Ihrem Issue-Tracker. Aber wenn Sie sie ueber eine CLI verwalten, rekonstruieren Sie den Graphen in Ihrem Kopf aus flacher Textausgabe. Diese Rekonstruktion versagt genau in dem Moment, wo sie am wichtigsten ist: wenn der Graph komplex ist und Dinge kaputtgehen.
Wie beads Abhaengigkeiten trackt
beads ist ein Git-gestuetzter Issue-Tracker, der fuer die Koordination von KI-Agenten gebaut wurde. Er speichert alles in einer lokalen Dolt-Datenbank im .beads/-Verzeichnis Ihres Repos. Kein Cloud-Service, keine Konten, keine Sync-Konflikte.
Agenten deklarieren Abhaengigkeiten mit einem einzigen Befehl:
bd dep add ISSUE-42 ISSUE-37
Dies zeichnet auf, dass ISSUE-42 von ISSUE-37 abhaengt. ISSUE-42 kann nicht fortschreiten, bis ISSUE-37 geschlossen ist. Die umgekehrte Abfrage ist genauso einfach:
bd blocked
Das gibt jedes Issue im Workspace zurueck, das derzeit durch eine ungeloeste Abhaengigkeit blockiert ist. Und fuer ein bestimmtes Issue:
bd dep list ISSUE-42
Das zeigt, wovon ISSUE-42 abhaengt und was von ISSUE-42 abhaengt.
Das Datenmodell ist sauber. Das Problem ist nicht das Aufzeichnen von Abhaengigkeiten. Das Problem ist, sie zu sehen. Wenn Sie 30 aktive Issues ueber fuenf Agenten haben, gibt Ihnen bd blocked eine Liste. Eine Liste zeigt Ihnen nicht, dass ISSUE-12 ein Engpass ist, der sieben nachgelagerte Aufgaben ueber drei Agenten blockiert. Eine Liste zeigt Ihnen nicht, dass Agent 3 eine zirkulaere Abhaengigkeitskette zwischen ISSUE-18 und ISSUE-22 erstellt hat. Sie brauchen eine raeumliche Ansicht des Graphen, keine sequenzielle.
Was Beadbox Ihnen zeigt
Beadbox ist eine native Desktop-App, die die beads CLI mit einer visuellen Oberflaeche umgibt. Sie liest aus derselben .beads/-Datenbank, in die Ihre Agenten schreiben, und aktualisiert sich in Echtzeit, waehrend sie arbeiten.
In der Epic-Baum-Ansicht zeigt jedes Issue mit ungeloesten Abhaengigkeiten ein Blocked-Badge inline. Sie sehen die vollstaendige Baumstruktur Ihres Epics, mit blockierten Issues auf einen Blick markiert. Kein Befehl auszufuehren, keine Ausgabe zu parsen.
Die Abhaengigkeitskette ist raeumlich sichtbar. Wenn ISSUE-42 von ISSUE-37 abhaengt und ISSUE-37 von ISSUE-15, und ISSUE-15 Agent 1 zugewiesen ist, der feststeckt, koennen Sie diese Kette durch Scannen des Baums nachverfolgen. Sie sehen die Form des Engpasses, ohne ihn aus separaten CLI-Abfragen rekonstruieren zu muessen.
Der Echtzeit-Aspekt ist entscheidend. Wenn Agent 1 schliesslich ISSUE-15 schliesst, spiegelt die Beadbox-UI das innerhalb einer Sekunde wider. Das Blocked-Badge von ISSUE-37 verschwindet. Wenn ISSUE-37 das Einzige war, das ISSUE-42 blockierte, verschwindet auch dieses Badge. Sie beobachten, wie die Abhaengigkeitskette zusammenfaellt, waehrend Arbeit abgeschlossen wird, ohne zu aktualisieren oder erneut abzufragen.
Unter der Haube funktioniert das ueber eine einfache Pipeline: Ein WebSocket-Server ueberwacht das .beads/-Verzeichnis mit fs.watch(). Wenn ein Agent in die Datenbank schreibt (ein Issue schliessen, eine Abhaengigkeit hinzufuegen, einen Status aktualisieren), loest das Dateisystem-Ereignis einen Broadcast an alle verbundenen Clients aus. Die React-UI rendert mit frischen Daten neu. Latenz unter einer Sekunde von der Agent-Aktion zum visuellen Update.
Ein konkretes Szenario: Einen Engpass erkennen
Fuenf Agenten arbeiten an einem Feature-Epic mit 24 Issues. Sie oeffnen Beadbox und schauen auf den Epic-Baum. Zwoelf Issues sind in Arbeit. Sechs zeigen Blocked-Badges.
Das ist bereits eine Information, die Sie nicht hatten. bd list wuerde Ihnen 12 In-Progress-Issues zeigen, aber Sie muessten bd blocked separat ausfuehren und abgleichen, um zu verstehen, welche In-Progress-Issues tatsaechlich stagnieren.
Sie scannen die Blocked-Badges und bemerken etwas: Vier der sechs blockierten Issues haengen alle von ISSUE-19 ab, einer Datenbank-Schema-Migration, die Agent 4 zugewiesen ist. Agent 4 arbeitet noch daran, aber ISSUE-19 ist zu einem Single-Point-Engpass geworden. Vier Agenten stehen praktisch still und warten auf eine Aufgabe.
Ohne die visuelle Ansicht wuerden Sie das vielleicht erst in einer weiteren Stunde bemerken. Damit koennen Sie sofort eingreifen. Vielleicht weisen Sie ISSUE-19 einem schnelleren Agenten zu. Vielleicht teilen Sie es in kleinere Stuecke auf, die einige Abhaengige fruehzeitig freigeben koennen. Vielleicht erkennen Sie, dass zwei der vier Abhaengigkeiten ueberdeklariert waren und mit bd dep remove entfernt werden koennen.
Der Punkt ist nicht, dass die Information vorher nicht verfuegbar war. Sie war immer in der Datenbank. Der Punkt ist, dass die visuelle Darstellung Muster sichtbar macht, die flacher Text verbirgt.
Haeufige Abhaengigkeits-Antimuster
Das Ausfuehren mehrerer KI-Agenten auf einem Repository erzeugt einige wiederkehrende Abhaengigkeitsprobleme. Alle sind visuell leichter zu erkennen als durch CLI-Abfragen.
Ueberdeklaration. Agenten neigen zur Vorsicht. Im Zweifel deklarieren sie eine Abhaengigkeit. Das Ergebnis ist ein Abhaengigkeitsgraph, der dichter ist als noetig, mit Issues die auf Arbeit blockiert sind, die sie nicht tatsaechlich brauchen. In Beadbox erkennen Sie das, wenn ein Issue ein Blocked-Badge zeigt, aber das blockierende Issue in einem voellig unverwandten Teil der Codebasis liegt. Ein schnelles bd dep remove raeumt das auf.
Zirkulaere Ketten. Agent A deklariert eine Abhaengigkeit von Agent Bs Arbeit. Agent B, der unabhaengig arbeitet, deklariert eine Abhaengigkeit von Agent As Arbeit. Jetzt sind beide aufeinander blockiert und keiner kann fortfahren. Die beads CLI erkennt offensichtliche zirkulaere Abhaengigkeiten bei der Erstellung, aber indirekte Zyklen ueber drei oder mehr Issues sind schwerer zu entdecken. Im Epic-Baum fallen diese als Cluster von Blocked-Badges auf, die sich nie aufloesen, waehrend andere Arbeit drumherum abgeschlossen wird.
Single-Point-Engpaesse. Ein Issue sammelt fuenf, sechs, sieben nachgelagerte Abhaengige an. Das passiert natuerlich, wenn Agenten, die parallel arbeiten, alle dasselbe Fundament brauchen. Das obige Szenario illustriert das Muster. In einer Listenansicht sehen Sie sieben blockierte Issues. In einer Baumansicht sehen Sie sieben Pfeile, die auf denselben Knoten zeigen. Der Engpass ist offensichtlich.
Erste Schritte
Beadbox laeuft auf macOS, Linux und Windows. Installation mit Homebrew:
brew tap beadbox/cask && brew install --cask beadbox
Richten Sie es auf ein beliebiges Repository mit einem .beads/-Verzeichnis. Wenn Sie beads bereits mit Ihrer Agent-Flotte ausfuehren, erkennt Beadbox die vorhandene Datenbank und beginnt sofort mit dem Rendering. Kein Import-Schritt, keine Konfiguration, keine Kontoerstellung.
Ihre Agenten verwenden weiterhin die CLI. Sie fuehren bd dep add, bd update, bd close wie gewohnt aus. Beadbox ueberwacht die Datenbank und spiegelt jede Aenderung in Echtzeit wider. Sie erhalten die visuelle Schicht, ohne Agent-Workflows aendern zu muessen.
Beadbox ist waehrend der Beta kostenlos.
Wenn Sie mehrere KI-Agenten auf einer einzigen Codebasis koordinieren, ist der Abhaengigkeitsgraph das, was Ihren Workflow zuerst zum Scheitern bringt. Sie koennen ihn blind ueber die CLI verwalten, oder Sie koennen ihn sehen. Sehen ist schneller.