Parallel Coding Agents mit Git Worktrees, Conductor und Antigravity 2.0

Von Terminal-Management zu einer visuellen Steuerung

Wenn 2025 das Jahr der KI-Agenten war, scheint 2026 das Jahr zu sein, in dem viele Agenten gemeinsam arbeiten – ein Google-Engineer prophezeite bereits früh, dass dies das Jahr der Agent-Orchestrierung werden würde. Für alle, die ausschließlich in Terminals arbeiten, zeigt sich das Problem schnell: Der Versuch, ein Team paralleler Subagenten bei der Entwicklung eines kleinen Zeitspiel-Programms zu koordinieren – mit tmux-Fenstern, Repository-Downloads sowie Zettel auf dem Monitor, um zu vermerken, welche Aufgabe gerade ausgeführt wird – verwandelte sich in ein kognitives Chaos.

Das Foto zeigt mehrere macOS-Desktops, die voller agy-Terminals mit Haftnotizen sind – ein gutes Beispiel dafür, wie das Verwalten paralleler Agent-Arbeitsräume ohne geeignete Tools aussieht.

Die Idee, Apps mit einem Multi-Agent-System zu entwickeln, stammt von einem Beitrag aus Juni 2026, in dem gezeigt wurde, wie eine einzige Anweisung vier parallele Entwicklungsagenten erzeugte und innerhalb von weniger als zwei Minuten eine funktionierende Anwendung erstellte. Starre CLI-Hilfsprogramme eignen sich hervorragend für einthreadige Aufgaben, doch mehrere gleichzeitige Agentenströme, jeder mit seiner eigenen Abteilung, Checkout- und Koordinationsfeedbackschleife, passen nicht in einen flachen Scrollback-Puffer. Deshalb war der nächste Schritt der Umstieg auf die Antigravity 2.0-Desktop-Anwendung.

Die App gruppiert alles nach Projekt – im Grunde wie ein Ordner – und listet die Threads darunter auf, neueste zuerst. Ein persönliches Projekt könnte einen Thread zur Hinzufügung einer blauen Anmeldetaste mit einem versteckten Passwort sowie einen weiteren Thread zur Hinzufügung einer /checkout/-Backend-Route enthalten, während ein Arbeitsprojekt Threads für das Schreiben von doc/PRD.md und das Hinzufügen von Sicherheitstests beherbergt. Threads können archiviert werden, sodass sie auch nach einem Neustart erhalten bleiben, und niemand braucht dann noch physische Notizzettel.

Sobald eine visuelle Entwicklungsumgebung funktioniert, stellt sich die nächste Frage nach Skalierbarkeit. Eine einzelne Sandbox und ein Spielzeug-Programm sind einfach. Diese Konfiguration erweitert die Desktop-App auf eine 12-Track-SRE-Simulation unter Verwendung von Git-Worktrees, einem mit Rails inspirierten Orchestrierer namens Conductor++ sowie einem Concierge-Agenten namens Agostina.

Die Abbildung zeigt einen Entwickler, der versucht, mit einem Panettone in der Hand eine Ansammlung von Worktree-Subagenten unter Kontrolle zu halten.

Die Anregung, die alles in Gang setzte

Die Inspiration war eine kompakte Anweisung zur Entwicklung einer App zur Buchung von Hotelzimmern mit einem kleinen Team von Mitarbeitern.

Let's build a hotel room booking app [..].

First, launch the Engineering Manager agent to ... into an artifact called 'architecture.md'.

Once the design is ready, launch three agents in parallel:
1. Test Manager: Write <SPECS> to 'architecture.md'.
2. Backend Engineer: Build an API based on <SPECS> .
3. Frontend Engineer: Build a web UI based on <SPECS>  to interact with the API <details>.

[..] How to sync the 3 sub-agents [..]

Finally, spin up both components and a browser so I can test the live app.

Ein genaues Lesen zeigt, was darin enthalten ist:

1. eine Beschreibung des gewünschten Produkts, hier eine Hotelbuchungs-App
2. eine Gruppe von drei Unteragenten
3. die Reihenfolge und das Timing ihrer Interaktion
4. was am Ende geschieht, wenn das System für eine Person, die nicht eng in den Prozess eingebunden ist, zur Überprüfung gestartet wird
5. das Wichtigste überhaupt: ein gemeinsamer Dateizustand – das gemeinsame Dokument architecture.md

Das Diagramm zeigt, wie die Agenten in diesem Beispiel miteinander interagieren. Es handelt sich dabei um reines Metaprogrammieren. Die Anweisung beschreibt nicht den Code, sondern das Team, das den Code schreiben wird. Zudem kommunizieren die Agenten miteinander über ein Markdown-Dokument, was bedeutet, dass die Spezifikationen selbst der Kommunikationskanal sind.

Die Wunschliste für eine parallele Einrichtung ging noch weiter: Die Umsetzung soll durch GitHub Issues (GHI) ausgelöst werden, sodass jeder Subagent ein echtes Ticket erhält.

Bestandteile des Workflows

Mehrere Komponenten bilden die gesamte Einrichtung.

• Integration von Issues. Jeder Subagent sollte an einem Issue arbeiten, sobald eines vorhanden ist.
• Rails für KI. Die Conductor-Erweiterung gibt der Agentenarbeit klare Grenzen vor. Ein einzelnes Issue reicht manchmal nicht aus, damit ein Agent handeln kann, und manchmal muss ein Mensch im Prozess (HITL) die schwierigen Fragen beantworten – dadurch werden Umsetzungen nicht nachlässig, wie zum Beispiel mit der Bemerkung „Natürlich meinte ich nur authentifizierte Benutzer.“

git worktree. Worktrees verhindern, dass zwei oder mehr Agenten denselben Repository beschädigen. Wenn N Agenten Pull Requests auf entfernten Branches öffnen, macht es ebenfalls Sinn, einen Git-Concierge zu haben, der den Code in den main-Branch integriert. Diese Rolle sollte zurückhaltend agieren. Während Agent X versucht, Funktion X zu veröffentlichen, bleibt der Concierge unerschütterlich und stellt die letzte Verteidigungslinie für Konsistenz dar – schließlich kann Code zwar in Ordnung sein, aber ohne ausgeführte Tests oder aktualisierten Changelog veröffentlicht werden, und ein neues Kontextfenster hilft dabei, das zu erkennen.

Um diese gesamte Struktur in verschiedenen Codebasen wiederverwenden zu können, wurden die Regeln und Automatisierungen in eine Open-Source-Agent-Fähigkeit namens conductor-worktree-hitl gepackt, die auch als condutree bezeichnet wird. Ihre Kernkomponenten sind:

• git worktree für die asynchrone Umsetzung, wobei pro Worktree ein Subagent und pro Conductor eine Spur vorhanden sind

GitHub Issues zusammen mit Conductor für klare Implementierungsgrenzen

Antigravity 2.0 als visuelles Steuerungswerkzeug

Der Zustand wird auf der Festplatte gespeichert, sodass der Agentkontext über mehrere Ausführungen hinweg erhalten bleibt; kompatibel mit Conductor, doch es wird ein auf Dateien basierender Zustand für das Verknüpfen von Issues sowie ein experimentelles Frage-und-Antwort-Framework für Subagenten hinzugefügt

Optional ein Plugin, das die Fähigkeit using-git-worktrees bereitstellt, um die Isolierung von Worktrees zu automatisieren

Diese Fähigkeit als externe Fähigkeit zu betrachten und keine git-Befehle in das Prompt des Koordinators einzufügen, hat drei Gründe. Erstens werden alle Aufgaben der niedrigen Ebene wie die Einrichtung des Arbeitsbereichs, das Erstellen von Symbolverknüpfungen sowie die Ausnahme-Einstellungen in einem wartbaren Skript zusammengefasst. Zweitens bleibt das Prompt des Koordinators kurz und konzentriert sich darauf, Aufgaben an Unteragenten zu delegieren und Fragen zu klären, sodass der Agent sich nicht mit der git-Syntax herumschlagen muss. Drittens können andere Entwickler diese Fähigkeit in ihre eigenen Repositorien einbinden und konfliktfreie parallele Ausführungen ohne Neuverfassen von Integrationsskripten erreichen.

Ein Agent, der über diese Fähigkeit verfügt, lernt vier Dinge:

1. wie man unabhängige Worktrees für parallele Aufgaben erstellt
2. Grundlagen der git-Hygiene, insbesondere das Erstellen von Symbolverknüpfungen zu den gemeinsamen Conductor-Metadatenordnern sowie deren lokale Ausnahme-Einstellungen, damit git status sauber bleibt
3. Ein duales, reentrantes HITL-Protokoll zum Verfassen von Kommentaren zu Problemen, zum Lesen lokaler Register sowie zum Abfragen von Antworten, ohne die API-Quoten aufzubrauchen
4. Wie man lokal Commit vornimmt und Zustimmungen als Git Notes speichert, ohne direkte Remote-Pushes durchzuführen

Version 1.0 bildet eine solide Grundlage, und für Version 2.0 sind automatische Konfigurationsverknüpfungen sowie umfangreichere Hilfsskripte geplant.

Diese von KI generierte Illustration spielt auf den Ausdruck „zu viele Köche im Kochtopf“ an: Eine Menge codender Subagenten verursacht Chaos in einem Branch, da es keine Isolierung der Arbeitsbäume gibt.

Stresstest: Ein SRE-Incident-Simulator

Um herauszufinden, wie weit die parallele Ausführung getrieben werden kann, wurde das Modell auf einen realistischen SRE-Automatisierungs- und Incidents-Command-Simulator angewendet. Es ging nicht um Spiel-Apps, sondern um ein Mehr-Agenten-System, das Cloud-Umgebungen prüft und gleichzeitig die Bearbeitung von Vorfällen in mehreren isolierten Arbeitsräumen koordiniert. Damit dies ohne Konflikte funktioniert, mussten zunächst einige Aspekte der Git-Struktur und Namensgebung geklärt werden.

• Verunreinigung durch Symlinks. In der Conductor++-Konfiguration erhält jedes parallele Agenten-System seinen eigenen Arbeitsbaum, beispielsweise .worktrees/telegram_incident_creation/. Da die Unteragenten Metadaten an den Koordinator zurückmelden, wird der Wurzelordner conductor/ mit ln -s ../../conductor conductor in jeden Arbeitsbaum als Symlink eingefügt. Alles außer diesem Ordner unterscheidet sich je nach Arbeitsbaum, und da jede Spur in ihrem eigenen Unterordner von conductor liegt, sind Probleme bei der Zusammenführung äußerst unwahrscheinlich.
• Die Koordinatorin. Die leitende Git-Concierge heißt Agostina – eine ruhige, organisierte Italienerin, die auf Espresso läuft und Subagenten wie Mario und Luigi synchron hält, ohne dass sie sich in die Quere kommen. Sie ist absichtlich Italienerin, und der Name klingt ein wenig wie Antigravity.
• Der Schreiber. Ein engagierter Agent namens Amanuense, benannt nach dem lateinischen Wort für Schreiber, protokolliert die Erstellung von Verzeichnissen, Codeänderungen sowie Interaktionen der Agenten mit genauen Zeitstempeln in einer zentralen Prüfungsdatei, sodass man sehen kann, wer was, wann und in welchem Arbeitstreeb getan hat. Sie wurde erstellt, um zu überprüfen, wie gut die Synchronisierung der Subagenten funktioniert, sowie um faktische Zeitstempel und Protokolle für die Dokumentation bereitzustellen.

Der Betrieb mehrerer KI-Agenten in einem Repository erfordert strenge Isolation sowie eine kommunikative Methode ohne Konflikte.

Hier löst Agostina die Merges von Mario und Luigi auf, während ein dritter, gelber Subagent weiterhin in seinem eigenen Arbeitstree arbeitet.

Regeln, die das Repository intakt halten

Mehrere Gestaltungsentscheidungen hatten den größten Einfluss.

• Keine direkten Remote-Pushes. Wenn viele Subagenten gleichzeitig git push ausführen, verursachen sie Lock-Konflikte bei den Remote-Referenzen und können ungetesteten Code in die Produktion einschleusen. Subagenten committen nur in lokale feature/-Branches und schreiben zusammenfassende Git-Nachrichten. Nur der Koordinator darf pushen, die Validierungsbranche auschecken und Feature-Branches zusammenführen.
• Duales reentrantes Frageprotokoll. Ein einziges globales questions.json würde bei gleichzeitigen Fragen der Subagenten zu Schreibkonflikten führen. Stattdessen schreibt ein Subagent seine Frage in seine private Track-Datei (conductor/tracks//metadata.json), wodurch völlig konfliktfrei gearbeitet werden kann. Zudem wird die Frage als Kommentar zu einem GitHub-Issue mit einer eindeutigen Tracking-Signatur veröffentlicht. Agostinas Abfrageskript prüft zunächst, ob eine lokale Track-Datei den Status awaiting_human hat. Falls nicht, wird der GitHub-API-Aufruf ganz weggelassen, wodurch mehr als 95 Prozent der Quoten eingespart werden. Wenn auf GitHub eine passende Antwort erscheint, ändert sich der lokale Metadatenstatus auf answered, wodurch der Subagent aktiviert wird.
• Eine gemeinsame Wiki-ähnliche Speicherlösung. Anstatt den Kontext jedes Unteragenten mit der gesamten Projektgeschichte zu füllen, dient der gemeinsame conductor/-Ordner als persistenter Speicher – ein strukturierter lokaler Ordner, den die Agenten wie eine Wiki-Seite lesen und schreiben können. Dies spiegelt eine bekannte Aussage von Andrej Karpathy zur Speicherkapazität von LLMs wider und bezieht sich auf die häufige Sorge, dass schlecht verwalteter Agentenspeicher Assistenten zu „Goldfischen“ macht.
• Kaskadielle Konfliktlösung. Wenn fertige Funktionszweige nacheinander zusammengeführt werden, kann es zu einer Kaskade kommen. Marios Zweig fügt sich reibungslos in den Validierungs-Zweig ein, doch bei Luigi entstehen Konflikte. Wenn ein Mensch Luigis Konflikt im Validierungs-Zweig behebt, bleibt Luigis ursprünglicher Funktionszweig in seinem Arbeitsbaum weiterhin konfliktbehaftet und veraltet. Um diesen Abweichungen vorzubeugen, wählt Agostina gezielt Lösungen aus oder führt sie zurück in Luigis Zweig ein, wodurch der isolierte Arbeitsbaum mit dem validierten Code in Einklang bleibt.
• Pull-Anfragen statt des Pushens in den Hauptbranch. Ein direktes Pushen des zusammengeführten Validierungsbranches in main würde die Überprüfungsmechanismen umgehen, weshalb die Integration über eine PR abgewickelt wird. Die Unteragenten führen lokale Commit-Vorgänge durch, Agostina zieht den Code heran, prüft und fügt ihn lokal zusammen. Sobald die Integrationstests bestanden sind, pusht sie den vereinigten Branch und führt gh pr create --title „feat: ...“ --body „...“ aus. Ein menschlicher Prüfer kann anschließend die Diff-Unterschiede sowie die CI-Prüfungen in GitHubs eigenem Benutzeroberfläche überprüfen. Agostina speichert die URL der PR in metadata.json des Registriersystems und zeigt den aktuellen Status über gh pr list sowie gh pr status an.
• Abschaltung aufgrund konzeptioneller Konflikte. Zwei Arbeitswege können logisch inkompatibel sein, zum Beispiel wenn einer eine Funktion implementiert, die der andere auf eine inkompatible Weise umstrukturiert. Wenn Agostina dies feststellt, kann sie sofort einen der konfliktschaffenden Unteragenten abschalten. Die Abschaltung muss im Ticket dieses Agenten dokumentiert werden, und das Ticket muss entweder gesperrt oder mit dem Ticket des anderen Agenten verknüpft werden, um einen klaren Entscheidungsverlauf zu gewährleisten. Dies ist bisher genau einmal geschehen.

Der Lebenszyklus der Orchestrierung

Der menschliche Operator spricht niemals direkt mit den Unteragenten. Sie laufen vollständig isoliert in ihren Arbeitsbäumen, und der Operator spricht nur zu dem Koordinator an zwei Stellen: beim Starten des Vorgangs und bei der Beantwortung von Fragen, die vom HITL-Watcher übermittelt werden.

Das Flussdiagramm zeigt den Lebenszyklus von Agenten und Unteragenten in sechs Schritten:

1. Start. Der Operator beginnt den Vorgang.
2. Status prüfen. Agostina überprüft aktive GitHub-Issues sowie die Zustände der Conductor-Tracks.
3. Vorbereitung. Sie erstellt isolierte Arbeitsbäume und startet die parallelen Entwickler-Subagenten.
4. Beobachter für HITL. Blockierte Anfragen der Subagenten werden an den Menschen weitergeleitet, und die Antworten werden zurückgesendet, wodurch der Feedbackkreislauf sicher und asynchron bleibt.
5. Aufräumen. Wenn die Subagenten fertig sind und ihre PRs öffnen, löscht Agostina die temporären Arbeitsbaumverzeichnisse.
6. Integration in den Hauptcode. Sie integriert die Änderungen und öffnet oder verschmilzt die endgültige PR, um anschließend wieder zum Aufräumen zurückzukehren, falls noch Aufgaben übrig sind. Es kann zu einem Chaos kommen, aber Agenten bewältigen Git-Verbindungen besser als Menschen.

Die Beantwortung von Fragen ist noch sehr experimentell, und es wurden drei Ansätze ausprobiert. Einer davon ist eine Telegram Sidecar-Brücke, die als Hintergrunddienst läuft, Fragen oder Genehmigungen für Datenbankänderungen über einen Telegram-Bot zum Handy des Entwicklers sendet und anschließend nach Antworten fragt.

Das Diagramm zeigt den asynchronen Telegram-Fluss. Zu den Vorteilen gehören eine antizipierte Beantwortung und Genehmigungsabläufe auf mobilen Geräten, parallele Abarbeitung ohne Konflikte, da die Fragen in track-spezifischen Verzeichnissen liegen und so Dateilock-Konflikte vermieden werden, sowie ein Audit-Trail, da jede Entscheidung als JSON im Repository gespeichert wird. Der einfachste Ansatz, über questions.json mit dem Hauptagenten zu kommunizieren, wurde verworfen, weil er sich nicht automatisch freischaltete und manuell ausgelöst werden musste, obwohl Hooks oder zukünftige Versionen das ändern könnten.

Fallstudie: Zwölf SRE-Tracks in fünf Stunden

Die Testumgebung war eine Webanwendung, die um eine SRE-Erweiterung aufgebaut war. Viele ihrer Aufgaben konnten parallel ausgeführt werden: Benutzeroberflächen, Backend-Endpunkte, ein durch ein LLM unterstützter Chat-Assistent, ein Telegram-Bot, OpenTelemetry-Instrumentierung sowie die Erkennung von GCP-Ressourcen.

Dabei wurden zwölf komplexe SRE-Fähigkeiten genutzt und in mehr als zwanzig konkrete GitHub-Issues aufgeteilt. Anschließend wurde der Prozess automatisiert gestartet. Innerhalb von etwa fünf Stunden, größtenteils ohne menschliche Überwachung, baute der Conductor++-Pipeline all diese Elemente, führte Tests durch und integrierte sie in die Hauptbranche. Der Umfang reichte von der Einrichtung der OpenTelemetry-Trace-Logik in Cloud Run bis hin zur Erstellung interaktiver Telegram-Incident-Assistenten sowie Registrierungen zur Freigabe ausstehender Änderungen.

Integration und Ergebnisse der Fusion

Unter der Orchestrierung des parallelen Arbeitsbaums wurde jeder Funktionspfad entwickelt, getestet und in main integriert.

Das Tabellenbild zeigt die endgültige Statusprüfung der Hauptspuren. Zudem wurden acht weitere betriebliche Spuren integriert, die die Taxonomie des Incident-Status, die Löschung und Archivierung von Incidents, das Kreuzverlinken von Wiki-Projekten, die Zustandsverwaltung in mehreren Umgebungen, den Übergang des Zustands in die Cloud, eine responsives Wiki-UI, Live-Verbindungen zu GCP sowie ausstehende Änderungen abdecken.

Zwei Wochen nach der Ausführung kann der Conductor-Status mit einem einzigen task-runner-Befehl überprüft werden, der den Inspektor über das Repository startet und eine Zusammenfassung des Arbeitsbereichs ausgibt.

$ just conductor-status
python3 conductor/bin/conductor-inspector . --open --short

🔍 Inspecting Conductor Workspace: /usr/local/google/home/ricc/git/adk-sre-benjamin
📦 Product: Initial Concept
STATUS      |  PROGRESS  | RATIO |  GHI  |   AGENT    |   CHANGED   | TRACK ID                                           |  🌳
==============================================================================================================================
NEW         | ░░░░░░░░░░ |  0/25 |  #23  |            |  💻 15days   | managed_agents_sandbox_20260616                    |
NOT_READY   | ░░░░░░░░░░ |  0/17 |  #22  |            |  💻 15days   | mcp_streamline_abilities_20260616                  |
NOT_READY   | ░░░░░░░░░░ |  0/11 |  #15  |            |  💻 15days   | migrate_tf_cb_logic_20260616                       |
NOT_READY   | ░░░░░░░░░░ |   0/9 |  #21  |            |  💻 15days   | ai_engineering_practices_20260616                  |
NOT_READY   | ░░░░░░░░░░ |   0/9 |  #19  |            |  💻 15days   | workspace_agent_installation_20260616              |
NEW         | ░░░░░░░░░░ |  0/15 |  #31  | antigravity|  🐙 16days   | disable_mock_fallback_dev_20260616                 |
==============================================================================================================================
TOTAL       |            |  0/86 |       |            |              | 0 completed, 6 open (6 total)                      | 0 🌳

Der Zeitplan des Workflows

Ein schrittweiser Überblick über den Ablauf zeigt, wie Koordinator, Schreiber sowie die parallelen Unteragenten verhinderten, sich gegenseitig zu behindern.

Schritt 1: Initialisierung der Spuren und Arbeitsbäume

Auf dem Host-Computer bereitete der übergeordnete Koordinator die Arbeitsräume vor. Anschließend listete die Conductor-Inspektor-CLI die aktiven Spuren auf und übergab sie benannten Unteragenten – einer kümmerte sich um die Discord-Kriegsräume, der andere um die ausstehenden Mutationen. Ein Flag, das alle Spuren enthält, ermöglicht es derselben Tool, für jeden parallelen Arbeitsraum die Zweige sowie den Status der Agenten anzuzeigen.

./scripts/conductor-inspector /Users/ricc/git/adk-sre-benjamin --all

Die bei der Initialisierung erfasste Terminalausgabe ist wie folgt.

================================================================================
  CONDUCTOR++ ACTIVE WORKTREES & TRACKS INSPECTION
================================================================================
[Track: telegram_incident_creation_20260603]
  Worktree: .worktrees/issue-29-telegram-wizard
  Branch:   feature/issue-29
  Agent:    pinocchio
  Status:   AWAITING_HUMAN (Question: "Verify Telegram Token config?")
  GHI URL:  https://github.com/palladius/adk-sre-benjamin/issues/29

[Track: unified_incident_lifecycle_observability_20260607]
  Worktree: .worktrees/issue-18-discord-warrooms
  Branch:   feature/issue-18
  Agent:    grazia
  Status:   RUNNING
  GHI URL:  https://github.com/palladius/adk-sre-benjamin/issues/18
================================================================================

In dieser Auflistung ist der Subagent, der mit ausstehenden Mutationen befasst ist, blockiert und wartet auf eine Antwort von HITL.

Eine natürliche Frage ist, ob GitHub Issues und Conductor Tracks dasselbe sind. Es handelt sich um zwei Systeme, die auseinanderdriften können. Ein Agent wurde beauftragt, solche Abweichungen zwischen den beiden zu erkennen.

Das Screenshot zeigt einen Überblick über aktive Worktrees, Branches sowie Zuweisungen von Subagents. Die Abstimmung der beiden Systeme erfordert lediglich einen Befehl in eine Richtung. Dabei kann man Conductor bitten, für jedes Issue einen neuen Track zu erstellen und nacheinander alle notwendigen Fragen zu stellen. Alternativ wird sichergestellt, dass für jeden Conductor Track ein entsprechendes Issue existiert.

Die detaillierte Ansicht zeigt eine ausstehende HITL-Frage, die auf Eingaben zu GitHub Issues wartet.

Schritt 2: parallele Isolierung der Worktrees

Jeder Agent arbeitete an seiner eigenen Branch, und der Scribe protokollierte die genauen Dateiänderungen sowie Arbeitsplatzereignisse ohne Konflikte.

Dieses Screenshot zeigt den Dateimonitor im Worktree während der gleichzeitigen Entwicklung.

Der Antigravity-Thread-Tracker zeigt laufende Aufgaben an – eine Ansicht, die die ursprüngliche Demo mit einer einzigen Aufforderung und vier Unteragenten beeindruckt hätte.

Schritt 3: Abfragen und menschliche Steuerung

Wenn die Agenten Klarheit brauchten, stellten sie Probleme online, die von einem Abfrageskript namens poll_ghi_questions.py verarbeitet wurden. Um die menschliche Steuerung mobilfreundlich zu gestalten, wurden die Fragen über die Telegram-Sidecar-Brücke übertragen. Der Operator musste nicht am Computer sitzen und GitHub aktualisieren, da die Brücke jede Frage auf das Handy schickte, damit sie unterwegs schnell genehmigt werden konnte.

Der Screenshot zeigt den Feedbackkreislauf aus Genehmigungen und Diagnosen in Aktion.

Schritt 4: Der endgültige grüne Zustand

Nachdem jede Funktionsfortentwicklung die Überprüfung bestanden hatte und nacheinander eingemergt wurde, öffnete Agostina den Pull Request, und die abschließende Prüfung bestätigte, dass alle zwölf SRE-Tracks in den Produktionszweig eingemergt worden waren. Wurden sie alle vollständig getestet, einschließlich ihrer Wechselwirkungen? Nicht ganz – das ist ein Thema für weitere Arbeiten. Ein Visualisierungswerkzeug namens Conductor At Scale wandelt außerdem eine allgemeine Git-Geschichte in eine Arcade-Animation um, wobei die Conductor-Tracks in JavaScript über den Bildschirm „explodieren“.

Lektionen aus dem Testlauf

Die erste Lektion besteht darin, möglichst den Austausch mit einem einzigen Agenten beizubehalten und Sub-Agenten nur einfache, im Voraus festgelegte Aufgaben zu übertragen, die keine Interaktion erfordern. Zwei Praktiken unterstützen das.

• Minimieren Sie die Wartezeit zwischen Agent und Mensch. Ein /roastme-Befehl ist eine gute Möglichkeit, schwierige Fragen bereits im Voraus zur Sprache zu bringen, damit der Agent ununterbrochen arbeiten kann, und Conductor eignet sich hervorragend zum Sammeln von Fragen offline. Anstatt alle fünf Minuten eine 30-sekündige Frage zu beantworten, beantworten Sie alles in einem 30-minütigen Block, fahren anschließend mit dem Fahrrad und kehren zu einer fertigen Anwendung zurück.

Das Screenshot zeigt /roastme in Conductor im Betrieb, einschließlich Tippfehlern.

• Halten Sie die Beziehung zwischen Agent und Unteragent schlank. In der Branche wird oft von komplexen Mehr-Agent-Hierarchien gesprochen, doch im Jahr 2026 ist die sicherere Wahl einfache, wiederholbare Aufgaben, die stark auf der Implementierung beruhen und nur geringe Unklarheiten aufweisen, wodurch unnötige Orchestrierungskosten vermieden werden.

Es gibt auch eine Orchestrierungssteuerung. Code zu schreiben ist billig, die Spezifikation ist entscheidend, und das Testen sowie die Akzeptanz der Ergebnisse sind das neue Engpassproblem. Andere im Bereich scheinen dem zuzustimmen. Teams können diesem Trend voraus sein oder von ihm überwältigt werden.

Für diejenigen, die diesen Ansatz ausprobieren möchten, ist der Ausgangspunkt die Antigravity 2.0-Desktop-App, die bereits aus der Box heraus eine visuelle Mehrspur-Orchestrierung bietet.