Copilot Studio: Multi-Agent-Funktionen starten durch

Warum das Thema plötzlich wichtig ist (und nicht nur „noch ein Copilot-Update“)

Copilot Studio war bisher für viele im Kopf ein ziemlich klares Bild: ein Agent als dialogfähige Schaltzentrale, der Fragen beantwortet, Wissen nutzt, Aktionen ausführt und über Connectoren auf Daten zugreift. Das funktioniert – bis Aufgaben nicht mehr „eine Sache“ sind, sondern ein kleiner Firmenroman: erst Daten einsammeln, dann prüfen, dann rechnen, dann formulieren, dann freigeben, dann dokumentieren.

Genau hier setzt Microsoft mit Multi-Agent Orchestration an: Mehrere spezialisierte Agents arbeiten gemeinsam, teilen Arbeit nach Expertise auf und koordinieren Abläufe. Microsoft beschreibt das als Fähigkeit, mehrere Agents zu verbinden, damit sie „Skills kombinieren“ und breitere, komplexere Aufgaben lösen.

Das ist mehr als Feature-Fassade. Das ist ein Architekturwechsel: von „KI spricht“ zu „KI organisiert Arbeit“.

2) Was Microsoft unter Multi-Agenten in Copilot Studio versteht

In Copilot Studio bedeutet „Multi-Agent“ nicht, dass plötzlich ein Agent Stimmen im Kopf hat (auch wenn das manchmal so wirkt). Es geht um modulare Agents, die sich gegenseitig aufrufen, Aufgaben übergeben („handoff“) oder auf autonome Trigger reagieren. Microsoft nennt das explizit: Agents lassen sich verbinden, Interaktionen können übergeben werden, und man skaliert Lösungen über modulare Agents für bestimmte Aufgaben oder Datensätze.

Praktisch entstehen dabei drei Rollen:

a) Der Orchestrator (Hauptagent)
Er nimmt die Anfrage entgegen und entscheidet: selbst lösen, Wissen abfragen, Tool ausführen – oder einen Spezialagenten beauftragen.

b) Spezialagenten (Teilagenten)
Ein Agent für Finanzen, einer für Wissensdatenbank, einer für Ticketanlage, einer für Angebotstexte. Jeder mit klarer Aufgabe und klaren Grenzen.

c) Externe Agents (Connected Agents), zum Beispiel aus Microsoft Foundry
Copilot Studio kann auch Agents anbinden, die außerhalb von Copilot Studio gebaut wurden, etwa Microsoft Foundry Agents (Preview). Microsoft dokumentiert dafür einen konkreten Verbindungsweg („Add an agent“ → „Connect to an external agent“ → „Microsoft Foundry“) inklusive Hinweis: Für die Nutzung externer Agents trägt man selbst Verantwortung.

Das Ergebnis ist eine Art „Agenten-Baukasten“: Copilot Studio als Front- und Integrationsschicht, Foundry optional als Ort für besonders anspruchsvolle Agentenlogik und Backend-Orchestrierung.

3) Wie das Zusammenspiel technisch wirkt: Delegation statt Alleskönner

Der Kernmechanismus ist simpel: Delegation.

1. Nutzer stellt eine Aufgabe („Erstelle Angebot…“, „Löse Supportfall…“).

2. Orchestrator zerlegt die Aufgabe in Teilprobleme.

3. Orchestrator ruft nacheinander oder parallel Spezialagenten auf.

4. Ergebnisse werden konsolidiert, geprüft (idealerweise) und als Endergebnis ausgeliefert.

Microsoft beschreibt außerdem Muster, die stärker deterministisch sind: workflow-orientierte Multi-Agent-Modelle mit strikter Sequenzierung, um Variabilität zu reduzieren – inklusive Beispielen wie mehrstufige Freigaben, Compliance-Evidenz, Incident-Triage oder ETL-Abläufe.

Das ist wichtig, weil Unternehmen nicht nur „kreative Antworten“ wollen, sondern verlässliche Abläufe: Schritt 1, 2, 3 – ohne dass die KI plötzlich beschließt, erst mal ein Gedicht zu schreiben.

4) Warum Multi-Agenten in der Praxis Vorteile bringen

Saubere Spezialisierung
Ein Finanzagent rechnet und kennt Regeln. Ein Vertriebsagent formuliert und steuert den Prozess. Ein Wissensagent findet belastbare interne Quellen.

Bessere Governance durch Trennung
Statt einem Agenten „viel zu viel“ Zugriff zu geben, kann man pro Agent Rechte und Datenräume sauber trennen.

Wartbarkeit
Ändert sich die Rabattrichtlinie, wird der Finanzagent angepasst – nicht der komplette „Superagent“.

Qualität
Weniger Halluzination, wenn ein Agent nur das tut, was er gut kann, und dafür auf definierte Datenquellen zugreift.

5) Konkrete Anwendungsfälle (die auch in echten Firmen überleben)

Use Case A: Vertriebsagent (Foundry Agent) + Finanzagent → Angebotserstellung

Ziel: Vertrieb will in Minuten ein belastbares Angebot, nicht in Tagen eine Tabellenkollision.

Ablauf:

• Der Nutzer sagt: „Angebot für Kunde X: 250 Lizenzen, 36 Monate, inklusive Support-Option.“

• Der Vertriebsagent (z. B. ein Foundry Agent) erkennt: Es fehlen Preise, Rabattlogik, Marge, Zahlungsbedingungen.

• Er fordert beim Finanzagenten Daten an: Preisstaffeln, Rabattrichtlinie, Mindestmarge, Währungslogik, Zahlungsplan.

• Der Finanzagent liefert strukturierte Ergebnisse zurück.

• Der Vertriebsagent erstellt daraus das Angebot, ergänzt Annahmen und legt es in SharePoint ab; optional startet er einen Freigabeprozess.

Dass Copilot Studio Foundry Agents verbinden kann, ist explizit in der Microsoft-Doku beschrieben (Preview).
Und Microsoft unterscheidet Copilot Studio und Foundry auch strategisch: Copilot Studio für Endnutzer-Erlebnisse, Foundry für komplexe Backend-Logik.

Use Case B: IT-Support-Agent + Wissensdatenbank-Agent → schneller, sauberer First-Level

Ziel: Weniger „Haben Sie schon neu gestartet?“, mehr „Hier ist der Fix, inkl. Quelle“.

Ablauf:

• Nutzer meldet: „Teams-Add-in in Outlook fehlt seit Update.“

• Support-Agent fragt standardisiert nach: Version, Gerätetyp, VDI ja/nein, letzter Patchstand.

• Support-Agent ruft den Wissensdatenbank-Agenten auf: „Suche interne KB/SharePoint-Artikel, priorisiere nach Aktualität und Umgebung, liefere Fix-Schritte.“

• Wissensagent liefert: Ursache, Steps, Links, ggf. bekannte Nebenwirkungen.

• Support-Agent entscheidet: Sofortmaßnahme oder Ticket. Bei Ticket ruft er zusätzlich einen Ticket-Agenten auf (Incident anlegen, Kategorie setzen, Logs anhängen, SLA wählen).

Der Mehrwert ist die klare Rollenverteilung: Der Support-Agent führt das Gespräch und steuert, der Wissensagent verhindert das „frei erfundene Troubleshooting“.

6) Admin-Steuerung: Sicherheit, Datenschutz und „wer darf hier eigentlich was?“

Multi-Agenten sind wie ein sehr motiviertes Team: großartig, wenn jeder einen Ausweis hat und Türen nicht einfach aufgehen.

a) Agent-Policies im Copilot Control System
Microsoft beschreibt ein Administratorhandbuch für Microsoft 365 Copilot Agents: Agent-Richtlinien sind Mandanteneinstellungen im Copilot Control System im Microsoft 365 Admin Center, inklusive Regeln zu Agent-Zugriff, Agent-Freigabe und Agent-Veröffentlichung.

b) Security & Governance in Copilot Studio / Power Platform
Microsoft verweist auf DLP-Funktionen (Data Loss Prevention) und Governance-Kontrollen über Power Platform-Datenrichtlinien. Außerdem kann man etwa das Veröffentlichen bestimmter generativer Funktionen mandantenweit steuern.

c) Das Prinzip „jeder Agent hat definierte Rechte“ – praktisch umgesetzt
Für uns als Architektur heißt das:

• Least Privilege pro Agent: Jeder Agent bekommt nur die Connectoren und Datenquellen, die er wirklich braucht.

• Segmentierte Datenräume: Wissensagent liest z. B. nur KB-Sites, Finanzagent nur freigegebene Finanzdaten, HR-Agent nur HR-Prozesse – nicht alles überall.

• Freigabe- und Veröffentlichungspfade: Entwickeln ≠ produktiv. Für produktive Agents braucht es klare Freigaben, Versionierung und Verantwortliche.

d) Bedrohungsbild: „CoPhish“ und Consent-Missbrauch
Im Herbst 2025 wurde breit berichtet, dass Angreifer Copilot-Studio-Agents für OAuth-Consent-Phishing missbrauchen können („CoPhish“), also Nutzer zu einer scheinbar legitimen Anmeldung/Einwilligung verleiten, um Tokens abzugreifen. Medienberichte nennen als Gegenmaßnahmen u. a. strengere Consent-Policies, Conditional Access, MFA und Monitoring verdächtiger App-Registrierungen sowie Token-Widerruf.

Das ist für Multi-Agenten doppelt relevant: Je mehr Agents und Connectoren, desto wichtiger ist ein sauberer Consent-Prozess und eine harte Governance.

7) Auswirkungen auf die KI-Strategie im Unternehmen

Multi-Agenten verschieben die Grundfrage. Nicht mehr: „Welchen Copilot geben wir den Mitarbeitern?“ Sondern: „Welche Agenten-Rollen bauen wir als Unternehmensfähigkeit?“

Typische Konsequenzen:

• Agenten werden zu Produkten: Mit Ownership, Roadmap, Versionierung, Qualitätsmetriken.

• Agent-Layer in der Architektur: Neben Apps/APIs entsteht ein Orchestrierungs-Layer aus Agents, die Arbeitsschritte koordinieren.

• Compliance wird operativ: Klassifizierung, DLP, Zugriffskontrolle, Audit – nicht als Folie, sondern als Betriebsmodell.

Und ja: Das wird auch politisch im Unternehmen – weil plötzlich sichtbar wird, wie viele Prozesse nur deshalb „funktionieren“, weil Leute stillschweigend Abkürzungen nehmen. Ein Agent macht das nicht stillschweigend. Er macht es entweder gar nicht – oder sehr laut im Log.

8) Teams vorbereiten: Technik ist nur die halbe Miete

Damit die Zusammenarbeit mit Agents klappt, brauchen Teams drei Dinge:

1) Erwartungsmanagement
Ein Agent ist kein Orakel. Er ist ein System mit Aufgaben, Grenzen und Datenquellen. Mitarbeiter müssen lernen, Ziele klar zu formulieren und Ergebnisse zu prüfen.

2) Betriebsmodell
Was darf automatisch passieren? Was braucht Freigabe? Wo muss ein Mensch entscheiden? Multi-Agenten sind ideal für Prozesse mit klaren Stufen (auch Microsoft nennt solche Muster).

3) Schulung und Rollout wie bei jeder Plattform
Pilotgruppen, begrenzte Datenräume, klare Policies, Monitoring, Feedbackschleifen. Dann Skalierung.

Schlussbild (ohne Pathos, aber mit Nachdruck)

Microsofts Multi-Agenten-Ansatz in Copilot Studio bringt uns weg vom „Chat-Assistenten“ hin zu arbeitsteiligen Agentensystemen, die Prozesse wirklich tragen können – inklusive Anbindung externer Foundry Agents und Governance über Admin-Policies und DLP-Kontrollen.

Für uns als IT-Architektur heißt das: Jetzt ist der Moment, Agenten nicht als Spielzeug zu behandeln, sondern als Betriebssystem für Arbeitsschritte. Mit sauberer Rechtevergabe, klarer Datenfreigabe, klarer Verantwortung – und einem gesunden Misstrauen gegenüber allem, was per Consent-Dialog freundlich lächelt.

Neu im Intranet: Copilot liest mit – und vor 🎧

Ab sofort bekommt unser Intranet eine praktische „Ohren-Option“: Microsoft 365 Copilot erzeugt KI-basierte Audio-Zusammenfassungen für Inhalte in SharePoint (Seiten und News-Beiträge) und in Viva Connections (News-Reader). Damit gibt es über Artikeln und News-Posts einen kurzen Audio-Überblick, der die Kernaussagen vorliest – wie ein Mini-Podcast, nur ohne Intro-Jingle und ohne „Lasst ein Abo da“.
Rollout: Ende Januar bis Ende Februar 2026.

Was bringt mir das im Alltag?

Kurzfassung: Weniger Scrollen, schneller Bescheid wissen.

• Pendeln: Kopfhörer rein, Audio-Überblick an, und schon bist du inhaltlich im Bild, bevor der Zug wieder entscheidet, ob er heute „Betriebsablauf“ kann.

• Multitasking: Während du E-Mails sortierst, unterwegs bist oder zwischen Terminen hängst, kannst du News „nebenbei“ aufnehmen. Microsoft nennt das ausdrücklich als „Listen your way“-Prinzip: weiterarbeiten und trotzdem hören.

• Schneller Kontext: Audio-Overviews liefern eine kompakte Kernaussagen-Version – ideal, um zu entscheiden: „Lese ich das komplett oder reicht mir die Kurzfassung?“

Wo taucht das auf?

Viva Connections (Teams, Desktop oder mobil)

• Audio-Briefings für die Top-News im Viva-Connections-News-Reader: Copilot fasst die Top 10 personalisierten News-Elemente als Audio zusammen.

SharePoint (Intranet)

• Audio-Zusammenfassungen auf SharePoint-Seiten und News-Posts – wenn auf der jeweiligen Site der SharePoint Knowledge Agent aktiviert ist.

Wichtiger Punkt: Es ist nicht „irgendwo im Nirwana“, sondern direkt dort, wo man ohnehin liest: auf der Seite bzw. über dem News-Beitrag.

In welchen Sprachen klappt das?

Microsoft erweitert hier die Sprachunterstützung. Konkret gilt:

• In Viva Connections läuft das Audio-Briefing in der Profil- oder Gerätesprache.

• In SharePoint wird die Audio-Zusammenfassung in der Sprache der Site bzw. der Seite erzeugt.

Heißt praktisch: Wer sein Profil/Endgerät (bzw. die Intranet-Site) auf Deutsch nutzt, bekommt das Feature auch „deutsch denkend und deutsch sprechend“ – sofern die jeweilige Sprache unterstützt ist.

Muss man etwas einrichten?

Die angenehmste Nachricht für alle, die schon genug Schalter am Tag umlegen: Nein.
Das Feature ist standardmäßig aktiviert und erfordert keine Admin-Konfiguration.

Datenschutz & Berechtigungen: Hört Copilot Dinge, die er nicht hören soll?

Nein. Copilot arbeitet innerhalb der bestehenden Berechtigungen:

• Du bekommst Audio-Overviews nur für Inhalte, auf die du ohnehin Zugriff hast.

• Es wird nichts „aus dem Nichts“ erfunden, sondern aus dem vorhandenen Seiteninhalt eine Audio-Zusammenfassung erzeugt. (Die bestehenden SharePoint-/Viva-Einstellungen gelten weiter.)

Praktische Tipps: So nutzt du das im Intranet clever

1. Audio zuerst, Text danach: Höre den Überblick an, entscheide dann, ob du den ganzen Beitrag brauchst. Das spart Zeit – besonders bei langen News.

2. „News-Routine“ bauen: Zwei Minuten Audio am Morgen (oder im Bus) reichen oft, um den wichtigsten Kontext zu haben.

3. Mobil nutzen: Audio ist ideal, wenn du gerade keine Lust auf Mini-Schriftgröße und Daumenakrobatik hast.

4. Sprache prüfen: Wenn dir die Ausgabe „komisch“ vorkommt, prüfe deine Profil-/Gerätesprache (Viva Connections) bzw. die Seitensprache (SharePoint).

Tipp für Führungskräfte: Botschaften barriereärmer platzieren

Audio-Overviews machen wichtige Informationen leichter konsumierbar – gerade für Kollegen, die:

• Inhalte lieber hören als lesen,

• unterwegs sind,

• oder sich durch lange Textwüsten kämpfen müssen.

Das erhöht die Chance, dass Kernbotschaften wirklich ankommen – nicht nur „veröffentlicht“, sondern auch „verstanden“.

Kleiner Realitätscheck (damit niemand später sagt: „Stand aber nicht im Newsletter“)

Die Experience in SharePoint hängt daran, dass auf der Site der SharePoint Knowledge Agent verfügbar/aktiv ist. In Viva Connections betrifft es News im News-Reader für Copilot-lizenzierte Nutzer.

So wird aus Intranet-Lesestoff ein kleines Stück „Intranet-Hörfunk“ – nur ohne Wetterbericht. (Den übernimmt ja schon der Blick aus dem Fenster.)