Abhängigkeiten zwischen KI-Agenten in Echtzeit visualisieren

Du hast fünf 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 abhängen. Agenten 4 und 5 kümmern 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 gestoßen 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 aufgelöst ist. Du erfährst das erst, als du dich wunderst, warum seit einer Stunde nichts ausgeliefert wurde, und anfängst, bd blocked für jedes Issue durchzugehen.

Die Abhängigkeitsinformation existiert. Sie lebt in deinem Issue-Tracker. Aber wenn du sie über eine CLI verwaltest, rekonstruierst du den Graphen im 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 Abhängigkeiten trackt

beads ist ein Git-gestützter Issue-Tracker für die Koordination von KI-Agenten. Er speichert alles in einer lokalen Dolt-Datenbank im .beads/-Verzeichnis deines Repos. Kein Cloud-Service, keine Accounts, keine Sync-Konflikte.

Agenten deklarieren Abhängigkeiten mit einem einzigen Befehl:

bd dep add ISSUE-42 ISSUE-37

Das zeichnet auf, dass ISSUE-42 von ISSUE-37 abhängt. ISSUE-42 kann nicht weiter, bis ISSUE-37 geschlossen ist. Die umgekehrte Abfrage ist genauso einfach:

bd blocked

Das gibt jedes Issue im Workspace zurück, das derzeit durch eine ungelöste Abhängigkeit blockiert ist. Und für ein bestimmtes Issue:

bd dep list ISSUE-42

Das zeigt, wovon ISSUE-42 abhängt und was von ISSUE-42 abhängt.

Das Datenmodell ist sauber. Das Problem ist nicht das Aufzeichnen von Abhängigkeiten. Das Problem ist, sie zu sehen. Wenn du 30 aktive Issues über fünf Agenten hast, gibt dir bd blocked eine Liste. Eine Liste zeigt dir nicht, dass ISSUE-12 ein Engpass ist, der sieben Downstream-Tasks über drei Agenten blockiert. Eine Liste zeigt dir nicht, dass Agent 3 eine zirkuläre Abhängigkeitskette zwischen ISSUE-18 und ISSUE-22 erstellt hat. Du brauchst eine räumliche Ansicht des Graphen, keine sequentielle.

Was Beadbox dir zeigt

Beadbox ist eine native Desktop-App, die die beads CLI mit einer visuellen Oberfläche umhüllt. Sie liest aus derselben .beads/-Datenbank, in die deine Agenten schreiben, und aktualisiert sich in Echtzeit, während sie arbeiten.

In der Epic-Baum-Ansicht zeigt jedes Issue mit ungelösten Abhängigkeiten ein Blocked-Badge inline. Du siehst die vollständige Baumstruktur deines Epics, mit blockierten Issues auf einen Blick markiert. Kein Befehl auszuführen, keine Ausgabe zu parsen.

Die Abhängigkeitskette ist räumlich sichtbar. Wenn ISSUE-42 von ISSUE-37 abhängt und ISSUE-37 von ISSUE-15, und ISSUE-15 Agent 1 zugewiesen ist, der feststeckt, kannst du diese Kette durch Scannen des Baums nachverfolgen. Du siehst die Form des Engpasses, ohne ihn aus separaten CLI-Abfragen rekonstruieren zu müssen.

Der Echtzeit-Aspekt ist entscheidend. Wenn Agent 1 schließlich ISSUE-15 schließt, 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. Du beobachtest, wie die Abhängigkeitskette zusammenfällt, während Arbeit abgeschlossen wird, ohne zu refreshen oder erneut abzufragen.

Unter der Haube funktioniert das über eine einfache Pipeline: Ein WebSocket-Server überwacht das .beads/-Verzeichnis mit fs.watch(). Wenn ein Agent in die Datenbank schreibt (ein Issue schließen, eine Abhängigkeit hinzufügen, einen Status aktualisieren), löst das Dateisystem-Event 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

Fünf Agenten arbeiten an einem Feature-Epic mit 24 Issues. Du öffnest Beadbox und schaust auf den Epic-Baum. Zwölf Issues sind in Arbeit. Sechs zeigen Blocked-Badges.

Das ist bereits eine Information, die du nicht hattest. bd list würde dir 12 In-Progress-Issues zeigen, aber du müsstest bd blocked separat ausführen und abgleichen, um zu verstehen, welche In-Progress-Issues tatsächlich stagnieren.

Du scannst die Blocked-Badges und bemerkst etwas: Vier der sechs blockierten Issues hängen 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 würdest du das vielleicht erst in einer weiteren Stunde bemerken. Damit kannst du sofort eingreifen. Vielleicht weist du ISSUE-19 einem schnelleren Agenten zu. Vielleicht teilst du es in kleinere Stücke auf, die einige Abhängige frühzeitig freigeben. Vielleicht erkennst du, dass zwei der vier Abhängigkeiten überdeklariert waren und mit bd dep remove entfernt werden können.

Der Punkt ist nicht, dass die Information vorher nicht verfügbar war. Sie war immer in der Datenbank. Der Punkt ist, dass die visuelle Darstellung Muster sichtbar macht, die flacher Text verbirgt.

Häufige Abhängigkeits-Antimuster

Mehrere KI-Agenten auf einem Repository zu betreiben erzeugt einige wiederkehrende Abhängigkeitsprobleme. Alle sind visuell leichter zu erkennen als durch CLI-Abfragen.

Überdeklaration. Agenten neigen zur Vorsicht. Im Zweifel deklarieren sie eine Abhängigkeit. Das Ergebnis ist ein Abhängigkeitsgraph, der dichter ist als nötig, mit Issues die auf Arbeit blockiert sind, die sie gar nicht brauchen. In Beadbox erkennst du das, wenn ein Issue ein Blocked-Badge zeigt, aber das blockierende Issue in einem völlig unverwandten Teil der Codebasis liegt. Ein schnelles bd dep remove räumt das auf.

Zirkuläre Ketten. Agent A deklariert eine Abhängigkeit von Agent Bs Arbeit. Agent B, der unabhängig arbeitet, deklariert eine Abhängigkeit von Agent As Arbeit. Jetzt sind beide aufeinander blockiert und keiner kann weiter. Die beads CLI erkennt offensichtliche zirkuläre Abhängigkeiten bei der Erstellung, aber indirekte Zyklen über drei oder mehr Issues sind schwerer zu entdecken. Im Epic-Baum fallen diese als Cluster von Blocked-Badges auf, die sich nie auflösen, während andere Arbeit drumherum abgeschlossen wird.

Single-Point-Engpässe. Ein Issue sammelt fünf, sechs, sieben Downstream-Abhängige an. Das passiert natürlich, wenn Agenten, die parallel arbeiten, alle dasselbe Fundament brauchen. Das obige Szenario illustriert das Muster. In einer Listenansicht siehst du sieben blockierte Issues. In einer Baumansicht siehst du sieben Pfeile, die auf denselben Knoten zeigen. Der Engpass ist offensichtlich.

Loslegen

Beadbox läuft auf macOS, Linux und Windows. Installation mit Homebrew:

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

Richte es auf ein beliebiges Repository mit einem .beads/-Verzeichnis. Wenn du beads bereits mit deiner Agent-Flotte nutzt, erkennt Beadbox die vorhandene Datenbank und rendert sofort. Kein Import-Schritt, keine Konfiguration, keine Kontoerstellung.

Deine Agenten nutzen weiterhin die CLI. Sie führen bd dep add, bd update, bd close wie gewohnt aus. Beadbox überwacht die Datenbank und spiegelt jede Änderung in Echtzeit wider. Du bekommst die visuelle Schicht, ohne Agent-Workflows ändern zu müssen.

Beadbox ist während der Beta kostenlos.

Wenn du mehrere KI-Agenten auf einer einzigen Codebasis koordinierst, ist der Abhängigkeitsgraph das, was deinen Workflow zuerst zum Kippen bringt. Du kannst ihn blind über die CLI verwalten, oder du kannst ihn sehen. Sehen ist schneller.