Hat man einmal Copilot Cowork in Aktion erlebt, könnte man sich fragen, warum es überhaupt mehrere Copiloten gibt. Wenn ein autonomer Agent mehrstufige Aufgaben selbstständig plant und ausführt, warum dann noch Copilot Chat, GitHub Copilot oder eigens gebaute Copilot-Studio-Agents daneben betreiben?
Mit zwei sehr unterschiedlichen Beispielen zeige ich Ihnen, warum die Antwort komplizierter ist, als „nimm einfach den stärksten Agenten“: Beide Beispiele stammen aus erlebter Praxis als Trainer und Consultant.
Fall 1 ist das Erstellen von Bicep/-ARM- oder Terraform-Template für ein Azure-Deployment.
Fall 2 betrifft das Erstellen oder zumindest Optimieren von PowerPoint Foliensätzen, z. B. in Form einer Font-Ersetzung oder der Austausch eines Hintergrundbildesüber einen ganzen PowerPoint-Foliensatz mit mehreren hundert Slides.
Gleiche Modelle, unterschiedliche Umgebung
Der eigentliche Unterschied zwischen den im Einführungs-Artikel genannten Copilot-Produkten liegt seltener im zugrunde liegenden Sprachmodell, als in der Umgebung, in die der jeweilige Agent eingebettet ist. Genau diese Umgebung entscheidet, ob eine Aufgabe überhaupt zuverlässig lösbar ist, nicht nur plausibel aussehend.
Copilot Chat ist konversationell und (im Tenant-Kontext) auf Microsoft-Graph-Daten geerdet. Das ist gut für schnelle Fragen und für Agents, die primär Wissen abrufen oder zusammenfassen, aber schwächer, wenn eine Aufgabe mehrere Ausführungsschritte mit echten Seiteneffekten braucht.
GitHub Copilot lebt im Entwicklungs-Circle, also Repository, Terminal, Compiler beziehungsweise Linter, CLI-Werkzeuge, Versionskontrolle. Der Agent-Modus kann heute direkt im Editor mehrere Dateien anpassen, Terminalbefehle ausführen und das Ergebnis iterativ prüfen. Für ein Bicep-Template heißt das konkret: GitHub Copilot kann
az deployment group what-if
laufen lassen, auf Validierungsfehler reagieren, sich an bestehende Module und Parameter-Dateien im Repo halten und am Ende sogar einen Pull Request öffnen.
Copilot Studio ist kein Werkzeug für die eigene Ad-hoc-Nutzung, sondern eine Fabrik für einen wiederverwendbaren, governance-fähigen Agenten, den andere Kollegen, Kursteilnehmer, Kunden usw. über eine definierte Oberfläche mit festgelegten Connectors, Leitplanken und eigener Abrechnung aufrufen. Das Ergebnis ist ein „Produkt“, keine einmalige Aufgabenerledigung.
Copilot Cowork wiederum ist auf die Office-/SharePoint-Dateiwelt zugeschnitten, also mehrstufige, selbstständig geplante Aufgaben, die direkt auf Word-, Excel-, PowerPoint- oder SharePoint-Inhalten operieren.
Der Bizep/ARM-Fall im Detail
Rein technisch könnte man ein Template von jedem der vier erzeugen lassen. Text, der aussieht wie ein gültiges Bicep-File, produzieren alle. Der Unterschied zeigt sich erst danach. Nur GitHub Copilot im Agent-Modus kann das Ergebnis tatsächlich gegen Azure validieren, auf Deployment-Fehler reagieren und iterieren, weil nur dort der Ausführungs-Loop aus Repo, Terminal und Azure-CLI vorhanden ist.
Copilot Chat oder Cowork liefern bestenfalls einen plausiblen ersten Entwurf, den man anschließend manuell testen muss.
Copilot Studio könnte das nachbilden, aber nur, wenn man explizit die passenden Actions/Connectors dafür baut, was im Kern bedeutet, dass man sich dort seinen eigenen kleinen Coding-Agenten nachbaut.
Darum ist Cowork nicht einfach „der eine Agent für alles“
Beim PowerPoint-Beispiel liegt der Fall anders, weil Cowork hier tatsächlich in seinem ureigenen Terrain agiert, also Dateien in der Office-/SharePoint-Welt. Die Grenze verläuft hier nicht entlang der Umgebung, sondern entlang der Aufgabenart selbst: Ein globaler Font-Wechsel ist strukturell und regelbasiert, also der klassische Fall für ein deterministisches Skript und das bleibt so, unabhängig davon, ob man ihn Cowork, Chat oder sonst wem gibt.
Ein autonomer Agent würde die Aufgabe zwar lösen können, aber dafür Planungs- und Werkzeugaufrufe verbrauchen, die eine fünfzeilige Automatisierung nicht braucht.
Die grundsätzliche Intuition – „wäre nicht ein hinreichend fähiger Agent im Prinzip universell einsetzbar?“ – ist technisch nicht falsch. Architektonisch ist Cowork tatsächlich der allgemeinste der vier Agenten. Dass Microsoft trotzdem separate Produkte anbietet, hat vor allem vier Gründe:
- unterschiedlicher Werkzeug- und Ausführungszugriff (Entwicklungsumgebung vs. Office-Dateien vs. reines Chat-Wissen),
- unterschiedliche Zielgruppe (eigene Ad-hoc-Nutzung vs. für andere gebautes Produkt),
- ein auf die jeweilige Aufgabenklasse zugeschnittenes Kostenmodell,
- und schlicht die Frage, wo der Nutzer ohnehin schon arbeitet – IDE, Office-App oder Chat-Fenster.
Ein einzelner Agent mit Zugriff auf sämtliche Werkzeuge gleichzeitig wäre nicht nur technisch aufwendiger zu integrieren, sondern hätte für einfache Aufgaben auch einen unnötig großen Wirkradius und damit unnötig hohe Kosten pro Aktion.
Ein oft übersehener Unterschied: Anthropic-Modelle und Datenverarbeitung
Neben Umgebung, Zielgruppe und Kostenmodell gibt es noch eine vierte, häufig übersehene Achse: Cowork ist technisch eng an Anthropics Claude-Modelle gekoppelt. Microsoft selbst beschreibt Cowork als direkte Integration der Technologie hinter „Claude Cowork“ in Microsoft 365 Copilot. Das unterscheidet sich von den übrigen Copilot-Erlebnissen (Copilot Chat, Copilot in Word/Excel/PowerPoint), bei denen standardmäßig Azure-OpenAI-Modelle laufen und Anthropic nur optional als zusätzlicher Modell-Anbieter zugeschaltet werden kann.
Microsoft weist in der eigenen Dokumentation ausdrücklich darauf hin, dass Anthropic-Modelle von der EU Data Boundary und etwaigen In-Country-Processing-Zusagen ausgenommen sind: Die Verarbeitung läuft nicht auf Azure, sondern überwiegend auf Anthropic-eigener Infrastruktur (AWS/GCP), vorwiegend in den USA.
Für Mandanten in der EU/EFTA/UK ist Anthropic bei den regulären Copilot-Erlebnissen zwar standardmäßig deaktiviert und muss aktiv per Admin-Opt-in freigeschaltet werden, anders als bei Copilot Studio, das bei deaktiviertem Anthropic automatisch auf ein OpenAI-Modell zurückgefällt, ist für Cowork selbst kein solcher Anthropic-freier Betriebsmodus dokumentiert.
Für die Werkzeugwahl bedeutet das: Wer Cowork für seinen Mandanten aktiviert, akzeptiert damit auch eine Datenverarbeitung außerhalb der EU-Data-Boundary, ein Punkt, der bei Mandanten mit erhöhten Datenschutzanforderungen mindestens so schwer wiegen sollte wie die eigentliche fachliche Eignung der Aufgabe für Cowork.
Eine praktische Entscheidungshilfe
Hier eine kleine Entscheidungshilfe mit typischen Use Cases und den von mir empfohlenen Werkzeugen.
- Aufgabe ist code-/infrastruktur-gebunden und muss kompiliert, validiert oder deployed werden → GitHub Copilot (Agent-Modus)
- Schnelle Frage, geerdet auf eigene Tenant-/Graph-Daten → Copilot Chat
- Mehrstufige Aufgabe, die vollständig in Office-Dateien/SharePoint lebt: → Copilot Cowork
- Eine wiederverwendbare Fähigkeit, die andere über eine definierte, geführte Oberfläche aufrufen sollen → Copilot-Studio-Agent
- Sicherheitsspezifischer Untersuchungs-Workflow im SOC → Security Copilot
Fazit
Die vier bis fünf Copilots sind kein Zeichen von Produktwildwuchs, sondern spiegeln vier unterschiedliche Einsatzkontexte wider, in denen dieselbe zugrunde liegende KI-Fähigkeit jeweils unterschiedlich viel wert ist. Die richtige Frage ist nie „welcher Copilot ist am fähigsten“, sondern „wo lebt die Aufgabe, wer soll sie später aufrufen könne, und ist es überhaupt eine Aufgabe für einen Agenten oder für ein Skript“.