Mehrere Copilot-Agenten parallel: Was Ihr Dev-Team jetzt im Blick behalten sollte

Stellen Sie sich vor, ein Entwickler in Ihrem Unternehmen gibt morgens drei Aufgaben an drei Coding-Agenten: einen Fehler in der Rechnungsschnittstelle beheben, eine Exportfunktion für den Steuerberater ergänzen und die Tests für das Kundenportal aufräumen. Jede Aufgabe läuft in einer eigenen Sitzung. Nach einer Stunde fragt er sich: Welche Sitzung war noch gleich fertig? Welche wartet auf eine Rückfrage? Und warum meldet der Laptop plötzlich, dass die Festplatte voll ist?

Genau an dieser Stelle setzt eine Meldung an, die GitHub am 9. Oktober 2026 veröffentlicht hat. Im wöchentlichen Release-Überblick für GitHub Copilot, datiert auf den 5. Oktober, beschreibt GitHub unter anderem zwei Neuerungen in VS Code 1.141: Agenten-Sitzungen lassen sich nebeneinander anzeigen, und ein neuer Aufräum-Dialog zeigt, wie viel Speicherplatz die Arbeitskopien inaktiver Sitzungen belegen. Das klingt nach Kleinkram. Für Unternehmen, die Coding-Agenten bereits einsetzen, ist es ein guter Anlass, über Überblick, Verantwortung und Grenzen zu sprechen.

In diesem Artikel ordnen wir ein, was die Quelle belegt, was sie nicht belegt, welcher Aufgabe im Team von Amazing Agents diese Neuerung zugeordnet ist und welche drei Schritte Sie als Geschäftsführer oder Inhaber diese Woche gehen können. Wir bleiben bei dem, was in der Primärquelle steht, und kennzeichnen Beispielrechnungen ausdrücklich als solche.

Was GitHub am 9. Oktober 2026 veröffentlicht hat

Die Quelle ist der GitHub Changelog mit dem Titel „GitHub Copilot weekly releases – October 5“. Veröffentlicht wurde der Beitrag am 9. Oktober 2026. Er bündelt mehrere Neuerungen der Woche. Für diesen Artikel sind drei Punkte relevant, die wir wörtlich beziehungsweise sinngemäß aus der Quelle übernehmen.

• Sitzungen nebeneinander: In GitHub Copilot in VS Code (Version 1.141) können Sie laut Changelog „agent sessions side by side in the Agents window“ ansehen. Die Sitzungen lassen sich in einem Raster anordnen, um Ergebnisse zu vergleichen oder mehrere Aufgaben gleichzeitig zu verfolgen.
• Worktree-Aufräumen: Im Chat gibt es die Option „Open worktree cleanup“. Sie zeigt, wie viel Speicherplatz die Worktrees inaktiver Sitzungen belegen, und Sie können auswählen, welche davon entfernt werden.
• Weitere Punkte derselben Ausgabe: Claude Haiku 5.5 steht laut Changelog Nutzern der Tarife Copilot Pro, Pro+, Max, Business und Enterprise zur Verfügung. In der GitHub Copilot App lassen sich getrennte GitHub-Konten für die Copilot-Lizenz und für den Zugriff auf Repositories verwenden. Und die Copilot CLI findet über den Befehl /model auch Modelle einer lokal laufenden Ollama-Instanz.

Ein kurzer Begriff vorab, weil er im Alltag selten erklärt wird: Ein Worktree ist eine zusätzliche Arbeitskopie desselben Code-Projekts auf der Festplatte. Wenn ein Agent eine Aufgabe bearbeitet, arbeitet er häufig in einer eigenen Kopie, damit er die Arbeit des Entwicklers oder anderer Agenten nicht stört. Drei Agenten bedeuten drei Kopien. Bleiben die Kopien nach Abschluss liegen, belegen sie Platz. Das ist das Problem, das der neue Aufräum-Dialog adressiert.

„View agent sessions side by side in the Agents window.“ – GitHub Changelog, 9. Oktober 2026

Verfügbarkeit: Was sich über den Status sagen lässt

Wir halten uns bei jeder Neuigkeit an dieselbe Reihenfolge: zuerst die Verfügbarkeit, dann die Bewertung. Die Neuerungen stammen aus dem regulären wöchentlichen Release von VS Code und GitHub Copilot. In unserer Quellenprüfung haben wir keinen Hinweis auf eine Beta- oder Vorschau-Kennzeichnung für die beiden Funktionen gefunden, und die Quelle nennt keine Einschränkung auf bestimmte Regionen. Wir führen die Funktionen deshalb als allgemein verfügbar im regulären Release.

Zwei Einschränkungen gehören dazu. Erstens setzt die Nutzung eine bestehende GitHub-Copilot-Nutzung in VS Code voraus. Zweitens nennt die Quelle für diese beiden Funktionen keine gesonderte Preisangabe. Ob und welche Kosten in Ihrem Tarif entstehen, richtet sich nach Ihrer Lizenz. Prüfen Sie das bei Ihrem Dienstleister oder in Ihrem GitHub-Vertrag, statt es anzunehmen.

Für DACH gibt es keine ausdrückliche Sperre in der Quelle. Das ist nicht dasselbe wie eine ausdrückliche Zusage, aber für den Alltag eines deutschen Dev-Teams ein unkritischer Befund. Die Datenschutzfragen rund um den Einsatz von Coding-Agenten bleiben davon unberührt und gehören in jedem Fall in Ihre eigene Prüfung.

Was hier tatsächlich neu ist, und was nicht

Wer die Meldung nüchtern liest, erkennt: GitHub verkündet keinen neuen, klügeren Agenten. Es verbessert die Bedienung rund um Agenten. Das ist keine Abwertung, im Gegenteil. In vielen Unternehmen scheitert der produktive Einsatz von KI nicht an der Intelligenz des Modells, sondern an Alltagsfragen: Wer hat den Überblick? Wer weiß, was gerade läuft? Wer räumt auf?

Die Neuerung löst deshalb ein Organisationsproblem mit einem Werkzeug. Was sie nicht löst, ist die Frage, welche Aufgaben ein Agent überhaupt übernehmen darf und wer das Ergebnis prüft. Die Quelle sagt dazu nichts, und das ist auch nicht ihre Aufgabe. Diese Entscheidung bleibt bei Ihnen.

Ebenso wichtig: Die Quelle belegt keine Zeitersparnis, keine Fehlerquote und keine Produktivitätssteigerung durch die beiden Funktionen. Wenn Ihnen jemand eine konkrete Zahl dazu nennt, fragen Sie nach der Quelle. Wir nennen in diesem Artikel deshalb keine solche Zahl.

Warum mehrere parallele Agenten ein Führungsthema sind

Sobald ein einzelner Entwickler mehrere Agenten gleichzeitig arbeiten lässt, ändert sich seine Rolle. Er schreibt weniger Code selbst und prüft mehr Ergebnisse. Das hat drei Folgen, die Sie als Entscheider kennen sollten.

Erstens wächst der Prüfaufwand, nicht der Schreibaufwand. Ein Agent kann in kurzer Zeit viel Code erzeugen. Jede dieser Änderungen muss aber jemand lesen, verstehen und freigeben. Wer drei Agenten parallel laufen lässt, hat drei Prüfaufgaben gleichzeitig offen. Eine Ansicht, die Sitzungen nebeneinander zeigt, erleichtert den Vergleich. Sie ersetzt die Prüfung nicht.

Zweitens entsteht ein Überblicksproblem. Sitzungen, die irgendwo im Hintergrund laufen oder auf eine Antwort warten, werden leicht vergessen. Vergessene Sitzungen sind nicht nur ein Komfortthema. Sie können Arbeitskopien mit unveröffentlichten Änderungen enthalten, die niemand mehr auf dem Schirm hat.

Drittens braucht es Hygiene. Der Aufräum-Dialog zeigt, dass GitHub das Thema „liegengebliebene Agentenarbeit“ ernst nimmt. Für Sie heißt das: Legen Sie fest, wann eine Agenten-Sitzung als abgeschlossen gilt und wer entscheidet, dass ihre Arbeitskopie gelöscht werden darf. Genau diese Entscheidung nimmt Ihnen das Werkzeug bewusst nicht ab, denn es lässt Sie auswählen, welche Worktrees entfernt werden.

Beispielrechnung: Was Überblick im Alltag kosten kann

Die folgende Rechnung ist ein Beispiel und keine Messung. Sie dient nur dazu, die Größenordnung eines Überblicksproblems greifbar zu machen. Setzen Sie Ihre eigenen Zahlen ein.

Angenommen, ein Entwickler sucht im Schnitt zweimal pro Tag fünf Minuten nach einer bestimmten Agenten-Sitzung oder deren Ergebnis. Das wären zehn Minuten pro Tag, bei fünf Arbeitstagen knapp 50 Minuten pro Woche und pro Person. Bei einem Team mit vier Entwicklern wären es rund dreieinhalb Stunden pro Woche. Ob diese Annahme auf Ihr Team zutrifft, wissen nur Sie. Wenn die Zahl in der Praxis halb so hoch ist, bleibt es immer noch ein Posten, den man nicht ignorieren muss, aber auch nicht überschätzen sollte.

Die eigentliche Lehre der Rechnung: Der Nutzen einer solchen Funktion liegt nicht in einer spektakulären Zahl, sondern darin, eine kleine, wiederkehrende Reibung zu entfernen. Und er entsteht nur, wenn Ihr Team Coding-Agenten überhaupt schon parallel nutzt. Wer erst am Anfang steht, braucht diese Funktion noch nicht dringend.

Welcher Agent von Amazing Agents dazugehört: der Code-Operator

Auf amazing-agents.com beschreiben wir den Agenten „Code-Operator“ so: Er erfasst Bugs, schreibt Fixes und erstellt Pull-Requests, vom Ticket bis zum Deploy, nachvollziehbar und mit Freigabe an den kritischen Stellen. Die Neuerung von GitHub betrifft genau das Umfeld, in dem eine solche Aufgabe stattfindet: mehrere Aufgaben laufen nebeneinander, mehrere Ergebnisse müssen geprüft werden, und der Arbeitsplatz muss aufgeräumt bleiben.

Wichtig für die Einordnung: Der Code-Operator ist ein Agent aus unserem Angebot, nicht GitHub Copilot. Wir behaupten nicht, dass die Copilot-Funktion Teil unseres Agenten ist. Wir verwenden die Meldung als Anlass, an einem konkreten Beispiel zu zeigen, welche Fragen Sie für jeden Coding-Agenten klären sollten, egal von welchem Anbieter er stammt.

Drei dieser Fragen eignen sich als Prüfliste:

1. Auftrag: Welche Aufgaben darf der Agent bearbeiten (zum Beispiel Fehlerbehebung in einem klar umrissenen Modul), und welche nicht (zum Beispiel Änderungen an Zahlungs- oder Berechtigungslogik)?
2. Sichtbarkeit: Kann ein Mensch jederzeit sehen, welche Sitzungen laufen, was sie getan haben und in welchem Zustand sie sind?
3. Abschluss: Wer prüft das Ergebnis, wer gibt es frei, und wer räumt danach auf?

Die neue Ansicht in VS Code unterstützt die zweite Frage. Die erste und die dritte Frage beantwortet keine Funktion, sondern Ihre Organisation.

Mit und ohne Freigabe-Schritt: ein konkreter Vergleich

Der Kern unserer Arbeit ist der Unterschied zwischen einem Agenten ohne Rahmen und einem Agenten mit Grenzen und Freigabe-Schritt. Am Beispiel mehrerer paralleler Coding-Sitzungen sieht das so aus.

Ohne Freigabe-Schritt gilt: Die Sitzungen laufen, die Ergebnisse landen irgendwann im Projekt, und niemand weiß genau, was von wem geprüft wurde. Liegengebliebene Arbeitskopien füllen die Festplatte. Wenn ein Fehler auffällt, ist unklar, welche Sitzung ihn erzeugt hat. Das ist nicht automatisch ein Drama, aber es ist ein Zustand, den man in einem Unternehmen mit Verantwortung für Kundendaten nicht haben möchte.

Mit Freigabe-Schritt gilt: Jede Sitzung hat einen klaren Auftrag. Ergebnisse gehen erst nach Durchsicht durch einen Menschen in den gemeinsamen Code. Aufräumen ist eine bewusste Entscheidung: Im Dialog „Open worktree cleanup“ wählt eine Person aus, welche Arbeitskopien gelöscht werden. Das ist ein kleiner, aber echter Freigabe-Schritt, den GitHub hier eingebaut hat, weil das Löschen nicht rückgängig zu machen sein kann.

Beachten Sie die Wortwahl in der Quelle: Das Werkzeug zeigt Platzbedarf und lässt Sie auswählen. Es löscht nicht von selbst. Diese Trennung zwischen Anzeigen und Entscheiden ist ein gutes Muster, das Sie auch bei eigenen Abläufen anwenden können: Der Agent bereitet vor und zeigt, der Mensch entscheidet.

Das können Sie diese Woche tun

Weil die Funktionen nach unserer Prüfung im regulären Release enthalten sind, können Sie sie direkt prüfen, sofern Ihr Team Copilot in VS Code nutzt. Drei Schritte reichen für den Anfang.

1. Bestandsaufnahme (15 Minuten Gespräch mit Ihrem Dev-Team): Fragen Sie, ob und wie Coding-Agenten genutzt werden, mit welchem Werkzeug und wie viele Sitzungen typischerweise gleichzeitig laufen. Wenn niemand die Frage beantworten kann, ist das der eigentliche Befund.
2. Aufräum-Regel festlegen: Vereinbaren Sie, wann eine Agenten-Sitzung als beendet gilt, wer ihre Arbeitskopie löschen darf und wie oft aufgeräumt wird. Ein Satz im Teamhandbuch genügt.
3. Prüf-Regel festhalten: Schreiben Sie auf, dass kein Agentenergebnis ohne Durchsicht durch eine zweite Person in das Hauptprojekt gelangt. Der Vergleich der Sitzungen nebeneinander kann diese Durchsicht erleichtern.

Falls Ihr Team bisher keine Coding-Agenten nutzt, ist das kein Versäumnis. Nutzen Sie die Zeit, um die drei Fragen aus dem vorigen Abschnitt zu beantworten, bevor der erste Agent startet. Dann beginnen Sie mit Regeln statt mit Aufräumarbeiten.

Was die Quelle nicht hergibt: Grenzen dieser Einordnung

Der Vollständigkeit halber nennen wir, was wir nicht belegen können.

• Die Quelle nennt keine Messwerte zu Zeitersparnis oder Qualität. Alle Rechnungen in diesem Artikel sind Beispiele.
• Die beiden Funktionen stehen im Kontext von VS Code 1.141. Ob und wie ähnliche Funktionen in anderen Entwicklungsumgebungen oder bei anderen Anbietern existieren, haben wir nicht geprüft.
• Die übrigen Punkte der Ausgabe (Claude Haiku 5.5, getrennte Konten, Ollama-Anbindung) haben wir nur der Vollständigkeit halber genannt. Eine Empfehlung leiten wir daraus nicht ab. Wer lokale Modelle über Ollama anbindet, sollte zuvor Datenschutz und Zugriffsrechte klären.
• Die Ankündigung ersetzt nicht die offizielle Dokumentation. Prüfen Sie die Details dort, bevor Sie Regeln für Ihr Team ableiten.

Einordnung für Geschäftsführer ohne technischen Hintergrund

Sie müssen die Details von Worktrees und Agenten-Fenstern nicht verstehen. Sie sollten aber drei Fragen stellen können und die Antworten einordnen.

Wer in unserem Haus lässt Agenten arbeiten, und womit? In vielen Unternehmen nutzen einzelne Entwickler oder externe Dienstleister bereits Coding-Agenten, ohne dass es eine zentrale Übersicht gibt. Das ist verbreitet und nicht per se ein Problem. Es ist aber ein Zustand, den Sie kennen sollten.

Was passiert mit dem, was Agenten erzeugen? Code, der von einem Agenten stammt, ist Ihr Code. Sie tragen dafür dieselbe Verantwortung wie für Code, den ein Mitarbeiter geschrieben hat. Wer ihn prüft und freigibt, sollte feststehen.

Wie viel Kontrolle ist genug? Das hängt davon ab, was der Code tut. Für ein internes Hilfsskript genügt eine leichte Durchsicht. Für alles, was Kundendaten, Zahlungen oder Berechtigungen berührt, gehört mehr Prüfung dazu. Dieses Prinzip gilt unabhängig davon, ob der Code von einer Person oder einem Agenten stammt.

Fazit: Überblick ist die Voraussetzung für Vertrauen

Die Meldung von GitHub ist eine kleine, nützliche Verbesserung. Sie zeigt, wohin sich der Alltag mit Coding-Agenten entwickelt: weg vom einzelnen Chatfenster, hin zu mehreren parallelen Arbeitssträngen, die ein Mensch im Blick behalten muss. Wer mehrere Agenten einsetzt, braucht Überblick, klare Zuständigkeiten und Hygiene beim Aufräumen.

Der Unterschied, auf den es am Ende ankommt, ist der zwischen einem Agenten ohne Rahmen und einem Agenten mit Grenzen und Freigabe-Schritt. Der erste arbeitet schnell, bis etwas Unerwartetes passiert. Der zweite arbeitet planbarer, weil vorab geklärt ist, was er tun darf, was ein Mensch prüft und wer am Ende aufräumt. Mit Werkzeugen wie dem Agenten-Fenster in VS Code wird dieser zweite Weg ein Stück einfacher. Er bleibt aber eine Entscheidung Ihres Unternehmens.

Quelle: GitHub Changelog, „GitHub Copilot weekly releases – October 5“, veröffentlicht am 9. Oktober 2026 (github.blog/changelog/2026-10-05-github-copilot-weekly-releases-october-5/).