GitHub Copilot /fleet: Mehrere KI-Agents parallel – was d...
TL;DR: GitHub Copilot CLI bekommt mit /fleet einen Orchestrator, der komplexe Aufgaben in parallele Sub-Agents aufteilt – Refactoring, Tests und Docs laufen gleichzeitig statt nacheinander. Für Teams bedeutet das: weniger Wartezeit, strukturierteres KI-gestütztes Arbeiten und ein klarer Schritt in Richtung agentic Development.
GitHub Copilot CLI wurde am 25. Februar 2026 offiziell als General Availability (GA) veröffentlicht und brachte den /fleet-Befehl mit, der Multi-Agent-Workflows ermöglicht. Was klingt wie ein weiteres KI-Feature, ist tatsächlich ein fundamentaler Shift in der Art, wie KI-Assistenten in der Softwareentwicklung eingesetzt werden können – weg vom einzelnen Assistenten, hin zu einem koordinierten Team aus Agents.
Die wichtigsten Punkte
- 📅 Verfügbarkeit: GitHub Copilot CLI ist seit 25. Februar 2026 General Availability (GA)
- 🎯 Zielgruppe: Dev-Teams, Tech Leads, CTOs – alle, die mit Copilot CLI arbeiten
- 💡 Kernfeature: Ein Orchestrator zerlegt Aufgaben automatisch in parallele Sub-Agents
-
🔧 Tech-Stack: GitHub Copilot CLI,
.github/agents/-Verzeichnis, Custom Agent Definitions
Was bedeutet das für Teams?
Bisher war KI-gestützte Entwicklung mit Copilot CLI ein sequenzieller Prozess: Eine Aufgabe, ein Agent, eine Datei nach der anderen. Mit /fleet ändert sich das grundlegend.
Der Befehl führt einen Hintergrund-Orchestrator ein, der eine einzige Prompt-Eingabe in unabhängige Arbeitseinheiten aufteilt und diese gleichzeitig an mehrere Sub-Agents dispatcht. Jeder Sub-Agent bekommt ein eigenes Context-Window, arbeitet aber auf demselben Filesystem. Die Koordination liegt beim Orchestrator – ähnlich wie ein Projektleiter, der Aufgaben verteilt, den Fortschritt überwacht und das Ergebnis zusammenführt.
Konkret läuft das so ab:
- Aufgabe wird in diskrete Arbeitseinheiten zerlegt (mit Dependency-Tracking)
- Unabhängige Tasks starten parallel als Background-Sub-Agents
- Abhängige Tasks warten auf ihre Vorgänger
- Der Orchestrator überprüft Outputs und synthetisiert ein finales Ergebnis
Technische Details
Der Einstieg ist denkbar einfach. Ein Prompt wie dieser:
/fleet Refactor the auth module, update tests, and fix the related docs in the folder docs/auth/…reicht, um den Orchestrator loszuschicken. Er entscheidet selbst, was parallel laufen kann und was warten muss. Für strukturiertere Aufgaben empfiehlt GitHub, explizite Deliverables zu definieren:
/fleet Create docs for the API module:
- docs/authentication.md covering token flow and examples
- docs/endpoints.md with request/response schemas for all REST endpoints
- docs/errors.md with error codes and troubleshooting steps
- docs/index.md linking to all three pages (depends on the others finishing first)
Drei Tasks laufen parallel, einer wartet auf die anderen – die Dependency-Logik wird direkt im Prompt deklariert.
Custom Agents sind ebenfalls möglich: In .github/agents/ können spezialisierte Agents mit eigenem Modell, eigenen Tools und eigenen Instruktionen definiert werden. So lässt sich z. B. ein technical-writer-Agent für Dokumentationsaufgaben verwenden, während ein anderer Agent für komplexe Codeänderungen zuständig ist.
Laufende Sub-Agents lassen sich mit /tasks im Terminal einsehen, überwachen und bei Bedarf stoppen.
Was Teams konkret gewinnen
Für Lernende und Weiterbildungs-Verantwortliche ist das Konzept hinter /fleet mindestens so relevant wie das Feature selbst: Es zeigt, in welche Richtung sich KI-gestützte Entwicklung entwickelt.
Parallel statt sequenziell: Tasks, die früher nacheinander abgearbeitet wurden, laufen jetzt gleichzeitig. Ein Refactoring über mehrere Dateien, kombiniert mit Test-Updates und Docs-Pflege, ist kein mehrstündiges Silo mehr.
Strukturiertes Prompting wird zur Kernkompetenz: /fleet funktioniert am besten mit klaren Deliverables, expliziten Datei-Boundaries und deklarierten Abhängigkeiten. Das erfordert ein neues Denken darüber, wie Aufgaben beschrieben werden – eine Fähigkeit, die Teams aktiv aufbauen müssen.
Wichtige Einschränkung: Sub-Agents teilen sich ein Filesystem ohne File-Locking. Wenn zwei Agents in dieselbe Datei schreiben, gewinnt der letzte. Das macht klare Scope-Trennung im Prompt zur Pflicht, nicht zur Option.
Strategische Einordnung für CTOs und Tech Leads
/fleet ist nicht der erste parallele Agent-Ansatz – Anthropic’s Claude Code, Devin und andere Tools experimentieren ähnlich mit Multi-Agent-Setups. Was GitHub hier anders macht: Die native Integration in den Terminal-Workflow, direkte Verbindung zu GitHub-Issues und Pull Requests, und die Möglichkeit, bestehende Copilot-Lizenzen zu nutzen ohne neues Tooling einzuführen.
Für Teams, die bereits auf GitHub Copilot setzen, senkt das die Adoptionshürde erheblich. Für CTOs, die gerade evaluieren, wie viel “Agentic AI” in ihre Entwicklungsprozesse einfließen soll, ist /fleet ein konkretes Experiment-Feld: klein anfangen, klare Aufgaben testen, Feedback sammeln.
Die Lernkurve ist real – aber sie liegt nicht bei der Technik, sondern beim Prompting. Teams, die lernen, Aufgaben in parallele, unabhängige Deliverables zu zerlegen, werden den größten Benefit ziehen.
Praktische nächste Schritte
- Ausprobieren mit kleiner Aufgabe: Starte mit einem Task mit 2-3 unabhängigen Dateien – z. B. gleichzeitiges Updaten von Tests und Docs für ein Modul
- Prompting üben: Die offizielle GitHub-Dokumentation enthält konkrete Beispiel-Prompts für verschiedene Szenarien (Dependency-Migration, Feature-Flags, Dokumentation)
-
Team-Konventionen definieren: Klärt, welche Aufgabentypen sich für
/fleeteignen und welche besser sequenziell bleiben – besonders bei geteilten Dateien -
Custom Agents erkunden: Das
.github/agents/-Verzeichnis erlaubt spezialisierte Agents – ein Einstieg in teamweites Prompting-Wissen
