CONSULTING BRIEFING · 17.07.2026 · boddenberg.de

Share agents to Teams in Copilot Studio now available

Executive Summary

Seit dem 1. Juli 2026 ist „Share agents to Teams“ in Copilot Studio allgemein verfügbar — Roadmap-ID 557947, zunächst in der Web-Oberfläche. Was die Funktion tut, ist in einem Satz erzählt: Im Freigabe-Dialog deines Agents suchst du jetzt direkt nach einem Microsoft-Teams-Team, wählst es aus und schickst dem Team eine Benachrichtigung in den Haupt-Kanal — inklusive Installationslink. Vorher musstest du die Leute außerhalb von Teams informieren. Also per Mail. Die niemand gelesen hat.

Das klingt nach einem Feature, für das man keine Folie braucht, und genau darin liegt der Reiz. Die meisten intern gebauten Agents sterben nicht an schlechtem Prompt-Design, an halluzinierten Antworten oder an fehlender Rechenleistung. Sie sterben an dem Schritt, der in keinem Architekturdiagramm auftaucht: „und jetzt sag den Leuten Bescheid“. Microsoft hat diesen Schritt jetzt in das Werkzeug eingebaut, in dem der Agent ohnehin entsteht. Reibung raus, Adoption rauf.

Für dich als Verantwortlichen ist die Nachricht zweigeteilt. Die gute: Die Verteilung deiner Agents wird spürbar einfacher, und die Kollegen erfahren davon an der Stelle, an der sie ohnehin den halben Tag verbringen. Die schlechte: Genau dieselbe Reibung, die bisher deine Adoption gebremst hat, war auch deine faktische Governance. Wenn Verteilung drei Mails und einen Termin gekostet hat, hat sich das niemand aus Versehen angetan. Ab jetzt kostet es zwei Klicks.

Worum geht es im Detail?

Technisch passiert Folgendes: Der Freigabe-Dialog eines Agents kannte bisher Einzelnutzer, Sicherheitsgruppen und „alle in der Organisation“. Dazu kommt jetzt das Teams-Team als Ziel. Du tippst den Teamnamen, wählst aus, und optional setzt Copilot Studio eine Nachricht in den Haupt-Kanal des Teams, die den Agent vorstellt und einen Installationslink mitliefert. Microsoft begründet das in den Release Notes genau so, wie man es begründen würde: weniger Kommunikationsreibung, schnellere Verbreitung, höhere Sichtbarkeit im Team.

Wichtig ist, was dabei nicht passiert. Die Freigabe an ein Team ist kein Zauberstab, der Berechtigungen erfindet. Der Agent muss vorher mindestens einmal publiziert sein, sonst gibt es weder Kanal noch Link. Der Kanal „Teams und Microsoft 365 Copilot“ muss verbunden sein. Und die Empfänger brauchen eine Copilot-Studio-Lizenz pro Nutzer — ohne die läuft gar nichts, egal wie schön der Link im Kanal aussieht. Dazu kommt die Empfehlung, die faktisch eine Voraussetzung ist: Benutzerauthentifizierung auf „Manuell authentifizieren“ mit Microsoft Entra ID, und „Anmeldung erforderlich“ eingeschaltet. Sonst hast du keine Kontrolle darüber, wer in deiner Organisation mit dem Agent redet.

Der komplette Weg vom Agent zum installierten Team-Mitglied. Orange markiert ist exakt das, was seit dem 1. Juli 2026 neu ist — der Rest stand vorher schon im Weg und steht es weiterhin.

Der eigentlich interessante Teil steckt eine Ebene tiefer, und den zeigt dir die Oberfläche nicht. Um mit einem Agent überhaupt chatten zu dürfen, braucht ein Nutzer in der Dataverse-Umgebung die Berechtigung ChatBotReaders. Hat er sie nicht, weist Copilot Studio ihm beim Teilen die Rolle Environment Maker zu — die diese Berechtigung enthält. Lies den Satz ruhig zweimal. Du wolltest jemandem erlauben, einen Chatbot zu benutzen, und hast ihn zum Maker in einer Power-Platform-Umgebung gemacht. Das funktioniert übrigens nur, wenn du selbst System Administrator bist, und es kann bis zu zehn Minuten dauern, bis der Betroffene etwas davon sieht. Wer sauber arbeiten will, baut sich vorher eine benutzerdefinierte Sicherheitsrolle, die ausschließlich ChatBotReaders enthält, und weist die zu.

Ein Klick, vier Konsequenzen. Keine davon wird dir im Dialog angezeigt, alle vier stehen in der Dokumentation — dort, wo erfahrungsgemäß niemand nachsieht.

Zwei weitere Details entscheiden darüber, ob dein Agent beim ersten echten Nutzer funktioniert oder eine Fehlermeldung wirft. Erstens: Verbindungen zu externen Diensten hängen an der Identität des jeweiligen Nutzers. Der Agent läuft bei dir wunderbar, weil deine Verbindung existiert — beim Kollegen läuft er nicht. Gegenmittel sind ein Service Principal oder Verbindungen auf Umgebungsebene, die unter einer gemeinsamen, nicht personengebundenen Identität laufen. Zweitens: Die Power-Automate-Flows hinter den Aktionen deines Agents werden beim Teilen nicht mitfreigegeben. Nie. Und weil sie im Test-Panel trotzdem sauber durchlaufen, merkst du es garantiert erst in der Produktion.

Was sind Chancen? Was sind Risiken?

Die Chance ist real und sie ist größer, als das Feature aussieht. Agent-Projekte scheitern in der Praxis fast nie an der Technik. Sie scheitern daran, dass der Agent nach dem Bauen in einer Umgebung liegt, die niemand kennt, mit einem Link, den niemand hat. Ich habe bei einem Kunden einen wirklich guten Onboarding-Agent gesehen — Urlaubsantrag, Reisekosten, Zugriffsrechte, alles sauber verdrahtet. Nutzung nach vier Monaten: neun Unterhaltungen. Sieben davon vom Erbauer. Der Link stand in einer Willkommensmail auf Seite zwei, unter dem Parkplatzkonzept. Genau dieses Muster adressiert Microsoft hier — der Agent taucht dort auf, wo das Team ohnehin arbeitet.

Dazu kommt ein zweiter, unterschätzter Effekt: Die Team-Auswahl zwingt dich, über den Empfängerkreis nachzudenken. Ein Team ist ein fachlicher Zuschnitt, keine willkürliche Nutzerliste. Wer Agents team-weise verteilt, baut fast automatisch passendere Agents als jemand, der reflexartig „alle in der Organisation“ anklickt.

Drei Verteilwege, drei Preisschilder. Der neue Team-Share verbessert Weg 1 — er ersetzt weder den App-Store-Weg noch die Admin-Freigabe.

Das Risiko heißt Wildwuchs, und es ist die direkte Kehrseite der Chance. Wenn Verteilung mühsam war, hat die Mühe gefiltert. Fällt die Mühe weg, fällt der Filter weg. Rechne mit Agents, die in Teams auftauchen, in denen sie fachlich nichts verloren haben. Rechne mit fünf Varianten desselben Urlaubs-Agents, gebaut von fünf Abteilungen, die voneinander nichts wissen. Und rechne damit, dass die Benachrichtigung im Haupt-Kanal als das gelesen wird, was sie optisch ist: eine offizielle Empfehlung der IT. Ist sie nicht. Sie ist ein Post von Kollege Meyer aus dem Controlling, der ein produktives Wochenende hatte.

Der zweite Risikoblock ist Compliance. Wenn du einen Agent nach Teams bringst, fließen Agent-Inhalte und Chat-Inhalte nach Teams — und laut Dokumentation unter Umständen über die Compliance- und Geo-Grenzen deiner Organisation hinaus. Das galt vorher auch schon. Der Unterschied ist, dass es vorher zehn Leute pro Quartal gemacht haben und jetzt hundert pro Woche. Ein bekanntes Risiko mal einem unbekannten Faktor ist immer noch ein unbekanntes Risiko.

Und dann ist da noch das Rücknahme-Problem, das gern übersehen wird. Freigaben zu erteilen ist ein Klick. Freigaben zurückzunehmen ist eine Archäologie-Übung. Der Zugriff endet erst, wenn die laufende Unterhaltung nach dreißig Minuten Leerlauf ausläuft. Trennst du den Teams-Kanal, bleibt der Agent bei allen installiert, die ihn schon haben — er antwortet nur nicht mehr. War er vom Admin freigegeben, steht er weiter im Bereich „Built for your org“, bis der Admin ihn dort herausnimmt. Und die Environment-Maker-Rolle, die beim Teilen zugewiesen wurde, bleibt. Immer. Beim Teilen kann Copilot Studio Rollen zuweisen — entfernen kann es sie nicht.

Was müssen wir jetzt schon vorbereiten?

Die Funktion ist da, sie ist allgemein verfügbar, und sie fragt dich nicht um Erlaubnis. Wer jetzt „erst mal beobachten“ sagt, beobachtet in drei Monaten die Aufräumarbeiten. Diese Punkte gehören vor die erste Team-Freigabe:

Umgebungsstrategie klären: Eine eigene Umgebung für Agents, getrennt von der Standardumgebung. Das ist die einzige wirksame Grenze für Transkript-Zugriffe und Maker-Rollen. Nachträglich umziehen ist kein Spaß.

Rollen sauber schneiden: Eine benutzerdefinierte Sicherheitsrolle mit ChatBotReaders bauen und vorab zuweisen, statt beim Teilen reflexhaft Environment Maker verteilen zu lassen. Bot Transcript Viewer bleibt bei den Leuten mit Datenschutzschulung, nicht bei allen.

Authentifizierung erzwingen: „Manuell authentifizieren“ mit Entra ID plus „Anmeldung erforderlich“ als verbindlicher Standard für alle internen Agents. Ohne das ist jede Freigabe ein Blankoscheck.

Verbindungen entpersonalisieren: Service Principal oder Verbindungen auf Umgebungsebene für alles, was produktiv gehen soll. Sonst baust du Agents, die exakt einen Nutzer haben — dich.

Flow-Freigaben mitdenken: Jeder Agent mit Power-Automate-Aktionen braucht eine separate Flow-Freigabe. Das gehört in die Checkliste, nicht in die Fehlersuche.

Verteilweg festlegen: Team-Share für Pilot und Fachbereich, Admin-Freigabe für alles, was mehr als eine Abteilung betrifft oder auf Mobilgeräten laufen soll. Der Installationslink funktioniert in der Teams-Mobile-App nicht — wer den Außendienst adressiert, kommt am App Store nicht vorbei.

Namenskonvention und Besitzer: Jeder Agent bekommt einen fachlichen Besitzer und einen Namen, aus dem hervorgeht, ob er offiziell ist. „HR-Assistent (Pilot, Fachbereich Personal)“ verhindert mehr Missverständnisse als jede Richtlinie.

Und ein organisatorischer Punkt, der keiner Technik bedarf: Sag deinen Leuten, was eine Agent-Benachrichtigung im Haupt-Kanal bedeutet und was nicht. Ein kurzer Post, der klarstellt, dass solche Empfehlungen von Kollegen kommen und nicht von der IT geprüft sind, kostet zehn Minuten und erspart dir das Gespräch, in dem jemand erklärt, er habe der Sache vertraut, weil sie ja „offiziell in Teams“ stand.

Häufig gestellte Fragen

Brauchen alle Team-Mitglieder eine Copilot-Studio-Lizenz, damit die Freigabe funktioniert?

Ja. Ein Agent lässt sich nur mit Nutzern teilen, die über eine Copilot-Studio-Lizenz pro Nutzer verfügen; ohne Lizenz bleibt der Installationslink wirkungslos. Wer testen will, kann sich für eine Testversion registrieren — für den Produktivbetrieb ist die Lizenzfrage aber vor der ersten Team-Freigabe zu klären, nicht danach.

Warum funktioniert mein Agent bei mir, aber nicht bei den Kollegen im Team?

Der mit Abstand häufigste Grund sind Verbindungen zu externen Diensten, die an der Identität des jeweiligen Nutzers hängen, sowie Power-Automate-Flows, die beim Teilen des Agents nicht automatisch mitfreigegeben werden. Abhilfe schaffen ein Service Principal oder Verbindungen auf Umgebungsebene sowie eine separate Freigabe der Flows in Power Automate.

Kann ich einen Agent über den Team-Share auch für Teams auf dem Smartphone verteilen?

Nein. Der Installationslink lässt sich in der Teams-Mobile-App nicht verwenden. Wenn dein Agent auch auf Mobilgeräten verfügbar sein soll, musst du ihn im Teams App Store anzeigen lassen — entweder im Bereich „Built with Power Platform“ für freigegebene Nutzer oder nach Admin-Freigabe im Bereich „Built for your org“.

Was passiert genau, wenn ich die Freigabe wieder entziehe?

Betroffene Nutzer verlieren den Zugriff erst, wenn ihre laufende Unterhaltung nach dreißig Minuten Leerlauf ausläuft — nicht sofort. Bereits installierte Agents bleiben in Teams sichtbar und müssen manuell entfernt werden, und ein vom Admin freigegebener Agent verschwindet erst aus dem Bereich „Built for your org“, wenn der Admin ihn dort herausnimmt.

Warum antwortet mein Agent im Teams-Kanal plötzlich ohne sein SharePoint-Wissen?

Weil Copilot-Studio-Agents in Teams-Kanälen und Gruppenchats keine Wissensquellen nutzen können, die eine Authentifizierung des Endnutzers erfordern — SharePoint gehört dazu. Diese Einschränkung ist beabsichtigt und soll ungewollte Datenoffenlegung verhindern; solche Agents sind ausschließlich im 1:1-Chat vollständig funktionsfähig.