Microsoft 365 Copilot on DR.365

Team Knowledge Base in SharePoint: Copilot kompiliert das Wissen, Agents lesen es

Wed, 14 Oct 2026 07:00:00 +0200

Microsoft hat am 14. Oktober 2026 im SharePoint-Blog eine „Team Knowledge Base“ vorgestellt. Copilot stellt dabei aus den Inhalten eines Teams eine eigene Wissensbasis zusammen: eine Bibliothek aus verlinkten Markdown-Dateien, die Menschen lesen können und die Agents als Grounding dient. Das Ganze startet als Frontier Preview und läuft über usage-based billing.

Für mich ist das die spannendste SharePoint-Ankündigung seit Längerem, weil sie verändert, worauf ein Agent seine Antworten stützt. Aus demselben Grund habe ich dazu auch die meisten Fragen.

Was ist eigentlich neu?

Bisher lief das Grounding in Microsoft 365 über Retrieval. Copilot oder ein Agent sucht zur Frage passende Stellen in den Originaldokumenten und formuliert daraus die Antwort. Der Knowledge Agent in SharePoint hat diese Dokumente zwar aufgewertet, mit Metadaten und Struktur. Die Grundlage der Antwort blieb aber immer das Original.

Die Team Knowledge Base schiebt eine Schicht dazwischen. Copilot liest die Teaminhalte und kompiliert daraus eine eigene Wissensbasis. Technisch ist das eine spezielle Bibliothek, deren Markdown-Dateien untereinander verlinkt und so aufgebaut sind, dass Agents gut damit arbeiten können. Erzeugt wird sie von der „Knowledge Compilation Engine“, die zu Work IQ gehört. Was Work IQ sonst umfasst, habe ich im Beitrag zu RAG und Foundry IQ kurz eingeordnet.

Beim Retrieval entsteht das Wissen bei jeder Anfrage neu aus den Rohdaten. In der Knowledge Base liegt es vorab aufbereitet als eigenes Artefakt, das man öffnen, lesen und korrigieren kann. Ein Agent muss sich seine Antwort dann nicht mehr aus zwanzig Versionen derselben Präsentation zusammensuchen.

So funktioniert’s

Am Anfang steht eine bewusste Entscheidung im Team: Die Mitglieder steuern gezielt E-Mails, Chats, Meetings und Inhalte der Site bei. Die Knowledge Compilation Engine macht daraus die verlinkten Markdown-Dateien. Danach hält Copilot den Bestand aktuell. Anlegen, ergänzen und kuratieren können sowohl Copilot als auch Agents, die Wissensbasis ist also kein einmaliger Export.

Hängen lässt sie sich an jede SharePoint-Site, ausdrücklich auch an Sites hinter Teams-Kanälen und Microsoft-365-Gruppen. Das sind in den meisten Tenants genau die Orte, an denen die eigentliche Teamarbeit liegt.

Genutzt wird die Wissensbasis über Copilot in SharePoint und über den Autopilot in der neuen Copilot-App. Über den Autopilot kommt man auch aus Teams heran oder schreibt ihm einfach eine E-Mail. Der Autopilot wird allerdings separat ausgerollt. Nur weil die Knowledge Base im Tenant aktiv ist, steht er also nicht automatisch zur Verfügung.

Zur Leistung nennt Microsoft Zahlen aus eigenen internen Tests vom Oktober 2026: Agent-Antworten seien mit der Wissensbasis bis zu viermal schneller und 30 % tokeneffizienter. Das sind Herstellerangaben. Ich würde sie erst einplanen, wenn ich sie mit eigenen Inhalten nachvollzogen habe.

Als Beispiele skizziert Microsoft Szenarien aus drei Bereichen. Im Legal-Team bündelt die Wissensbasis das Wissen rund um Verträge. In der Entwicklung liefert sie Kontext für Coding-Agents und hilft beim Onboarding neuer Teammitglieder. Im Vertrieb entstehen Account-Snapshots. Das Engineering-Szenario finde ich am interessantesten: Ein Coding-Agent, der die Architekturentscheidungen aus dem Teams-Kanal kennt, schreibt vermutlich brauchbareren Code als einer, der nur das Repository sieht.

Verfügbarkeit und Lizenzierung

Stand heute gibt es die Team Knowledge Base nur in der Frontier Preview und nur für User mit usage-based billing. Gesteuert wird sie im Microsoft 365 Admin Center. Microsoft weist ausdrücklich darauf hin, dass sich die Abrechnungsbedingungen bis zur allgemeinen Verfügbarkeit noch ändern können.

Praktisch heißt das: Es gibt keinen festen Preis pro Lizenz, die Kosten hängen von der Nutzung ab, und die Regeln dafür sind noch nicht final. Für einen Pilot würde ich mir deshalb ein Team mit überschaubarem, gut gepflegtem Inhalt suchen. Die Abteilungs-Site mit zehn Jahren Altlasten ist dafür der falsche Startpunkt.

Roadmap

Für die Zeit nach der Preview hat Microsoft mehrere Ausbaustufen angekündigt, allerdings ohne Termine:

Knowledge Bases auch in Cowork, in Copilot in Teams und in Agents aus Copilot Studio
engere Integration mit Microsoft-365-Gruppen, inklusive Bootstrapping der Wissensbasis aus Kanälen und Mail
automatische Kuratierung über Agent Flows in Copilot Studio
Skalierung auf größere Bestände über einen Ansatz namens „Corpus Map“
Anbindung an CLIs und Coding-Agents über Work IQ

Im selben Zug gab es eine Reihe weiterer SharePoint-Neuigkeiten. Copilot in SharePoint ist jetzt allgemein verfügbar, die SharePoint-Tools in Work IQ sind nutzbar, und dazu kommen ein SharePoint Admin Agent, Catalog Management, ein Berechtigungsreport für EEEU („Everyone except external users“) auf Dateiebene, Insights zum Zugriff von Agents und ein Governance Hub für Site Owner. Den EEEU-Report und die Insights zum Agent-Zugriff würde ich mir als Erstes ansehen. Mit ihnen findet man Oversharing, bevor zu weit geteilte Inhalte in eine Wissensbasis wandern.

Einordnung und offene Fragen

Viele meiner Kunden arbeiten in regulierten Umgebungen, bei KRITIS-Betreibern oder unter NIS2. Dort entscheidet sich ein Feature wie dieses an Fragen, die die Ankündigung nicht beantwortet. Ich formuliere sie bewusst als offene Fragen, weil ich die Antworten nicht kenne.

Berechtigungen. Die Markdown-Dateien sind neue Dateien in einer Bibliothek. Erben sie die Berechtigungen der Quellen oder die der Bibliothek? Was passiert, wenn eine Mail einfließt, die nur ein Teil des Teams lesen durfte? Sieht dann das ganze Team die daraus abgeleitete Zusammenfassung?

Sensitivity Labels. Übernimmt eine Datei, die aus einem als vertraulich gelabelten Dokument entsteht, dieses Label? Und welches Label gilt, wenn eine Datei Inhalte aus mehreren Quellen mit unterschiedlichen Labels zusammenführt? Bei Mails und Chats ist das besonders heikel, weil dort Labels oft anders gesetzt werden als in Dokumentbibliotheken.

Retention. Mails, Chats und Site-Inhalte unterliegen häufig unterschiedlichen Aufbewahrungsrichtlinien. Wird ein abgeleiteter Inhalt entfernt, wenn das Original nach Ablauf der Frist gelöscht wird? Oder lebt er in der Wissensbasis nach den Regeln der Bibliothek weiter? Für Löschpflichten und eDiscovery macht das einen erheblichen Unterschied.

Kostenkontrolle. Wenn Copilot die Wissensbasis laufend aktuell hält, wie viel Verbrauch entsteht dann, auch wenn gerade niemand eine Frage stellt? Lässt sich der Verbrauch pro Site oder Team begrenzen, und wie gut sieht man vorab, was ein Pilot kosten wird?

Ein Werkzeug dafür gibt es schon: Im Microsoft 365 Admin Center lassen sich unter Copilot > Cost Management Ausgabenrichtlinien mit Limits für die Organisation und pro User festlegen (Microsoft Learn). Die Einstellung „Auto-apply new services“ ist dort standardmäßig aktiv, neue unterstützte Dienste fallen also automatisch unter bestehende Richtlinien. Ob die Knowledge Base dort als eigener Dienst auftaucht, geht aus der Ankündigung nicht hervor. Wer neue Features vor der Freigabe prüfen will, sollte die Einstellung in den betroffenen Richtlinien abschalten.

Solange diese Punkte nicht geklärt sind, würde ich die Knowledge Base an keine Site hängen, auf der regulierte oder personenbezogene Daten liegen. Für einen Pilot mit unkritischem Inhalt spricht dagegen nichts.

Fazit

Die Team Knowledge Base ist ein echter Architekturwechsel: Agents antworten auf Basis einer gepflegten, lesbaren Zwischenschicht statt direkt auf Rohdokumenten. Wie gut das in der Praxis trägt, hängt an der Vererbung von Berechtigungen, Labels und Aufbewahrung. Darauf würde ich in der Preview zuerst schauen, noch vor den Performance-Zahlen.

Quellen

Agent Lifecycle: Wie viel Governance braucht ein Copilot-Agent?

Mon, 12 Oct 2026 07:00:00 +0200

📝 Diese Serie wurde erweitert

Diese Serie wurde im Oktober 2026 um einen Einstiegsteil erweitert. Dieser Beitrag war ursprünglich Teil 1 und ist jetzt Teil 2. Teil 1 ordnet die Werkzeuge Agent Builder, Copilot Studio und Foundry danach, wer das Risiko trägt.

Einen Agent zu bauen dauert mit dem Agent Builder in Microsoft 365 Copilot ein paar Minuten. Ihn wieder loszuwerden dauert in vielen Tenants ewig, weil sich niemand zuständig fühlt. Der Kollege, der im Frühjahr einen Agent für die Reisekostenrichtlinie gebaut hat, ist inzwischen in einer anderen Abteilung. Der Agent beantwortet trotzdem weiter Fragen, auf Basis einer Richtlinie, die seit Juli nicht mehr gilt.

Genau hier setzt ein Agent Lifecycle an. In diesem Artikel beschreibe ich, wie ich so einen Lifecycle für Agents aus Agent Builder und Copilot Studio aufbauen würde, und welche Werkzeuge Microsoft dafür inzwischen mitbringt. Meine These dabei: Nicht jeder Agent braucht den vollen Prozess. Aber jeder Agent braucht einen Owner. Das setzt voraus, dass der Agent überhaupt registriert ist: Nur was in der Agent Registry auftaucht, kann ich einer Person zuordnen, prüfen und abschalten.

Der Lifecycle je Plattform

Welches Werkzeug zu welchem Builder passt und wer dabei das Risiko trägt, beschreibe ich in Teil 1. Für den Lifecycle heißt das: Die Phasen bleiben gleich, aber sie laufen je nach Plattform an einer anderen Stelle ab.

Agents aus dem Agent Builder (intrinsisches Modell, die Plattform zieht die Grenzen) verwaltet die IT im Microsoft 365 Admin Center. Dort steuert sie Sichtbarkeit, Teilen, Owner und das Sperren oder Löschen. Versionen und Umgebungen gibt es nicht. Der Lifecycle besteht hier vor allem aus Teilen, Ownership und Aufräumen.

Copilot Studio (konfigurierbares Modell, der Administrator setzt die Regeln) arbeitet mit Application Lifecycle Management über getrennte Entwicklungs-, Test- und Produktionsumgebungen. Datenrichtlinien, Connector-Regeln und die Freigabe zur Veröffentlichung hängen an diesen Umgebungen (Microsoft Learn).

Foundry (explizites Modell, die Organisation verantwortet Modell und Code) folgt dem eigenen Entwicklungsprozess: Versionierung, Evaluierung und Veröffentlichung laufen über die Werkzeuge und Pipelines des Entwicklungsteams (Microsoft Learn). Veröffentlichte Foundry-Agents erscheinen in der Agent Registry und lassen sich dort auch stoppen (Microsoft Learn). Den Rest dieses Beitrags richte ich auf Agent Builder und Copilot Studio aus. Für Foundry gelten dieselben Phasen, umgesetzt mit klassischer Softwareentwicklung.

Die Brücke zwischen Agent Builder und Copilot Studio ist die Kopierfunktion: Ein Agent aus Microsoft 365 Copilot lässt sich nach Copilot Studio übernehmen, wenn er mehr braucht als ein persönlicher Helfer. Für den Lifecycle ist das der Moment, in dem ein Agent seine Zone wechselt.

Drei Zonen statt eines Prozesses für alle

Ein einziger Freigabeprozess für jeden Agent scheitert in der Praxis an zwei Seiten. Für den persönlichen Agent, der mir meine eigenen Meeting-Notizen zusammenfasst, ist ein IT-Review übertrieben. Für einen Agent, der für 3.000 Mitarbeitende Fragen zur Personalabrechnung beantwortet, ist ein Klick auf “Teilen” zu wenig.

Microsoft löst das mit einem Zonen-Modell (Microsoft Learn). In Zone 1 bauen alle Mitarbeitenden Agents für die eigene oder die Team-Produktivität, und zwar auf Inhalten, auf die sie ohnehin Zugriff haben. In Zone 2 entwickeln von der IT zugelassene Maker Agents für andere Teams. Diese Agents laufen durch einen IT-Review und landen in Umgebungen, die die IT verwaltet. Zone 3 ist für unternehmensweite Agents reserviert, die wie jede andere Unternehmensanwendung behandelt werden. Auch das aktuelle Whitepaper Administering and Governing Agents ist inzwischen nach den Ebenen persönlich, Team und Unternehmen aufgebaut.

Bei den Werkzeugen ordnet Microsoft inzwischen enger zu: Zone 1 für Agent Builder und SharePoint-Agents, Zone 2 für Copilot Studio, Zone 3 für Foundry und Copilot Studio in professioneller Entwicklung. Ich lasse in Zone 2 trotzdem Agent-Builder-Agents zu, solange sie für ein Team nur Inhalte lesen, auf die dieses Team ohnehin Zugriff hat. Für die Zone zählt bei mir die Reichweite und nicht das Werkzeug.

Für den Lifecycle heißt das: Die Zone entscheidet, wie viele Phasen ein Agent durchläuft und wie streng sie sind. Ein Agent in Zone 1 nimmt den Kurzpfad. Sobald Reichweite, Datenzugriff oder Kritikalität steigen, wechselt er in die nächste Zone und damit in einen strengeren Ablauf.

Die sieben Phasen im Überblick

Das Schema basiert auf einem Lifecycle-Modell, das im Netz kursiert. Ich habe es um die Zonen, die konkreten Microsoft-Werkzeuge pro Phase und eine eigene Entscheidungsstufe erweitert.

1. Identifizieren

Am Anfang steht ein konkretes Problem. Ideen landen in einem Backlog, zum Beispiel einer Liste in SharePoint oder einem Planner-Board. Jede Idee bekommt einen kurzen Steckbrief mit Problem, Zielgruppe und einem verantwortlichen Owner. Ohne Owner geht es nicht weiter.

2. Bewerten und priorisieren

Hier fällt die wichtigste Entscheidung des ganzen Lifecycles: In welche Zone gehört der Agent? Dafür schaue ich auf Nutzen und Aufwand, aber vor allem auf die Daten. Welche Wissensquellen nutzt der Agent, wer darf sie lesen, und soll er Aktionen in anderen Systemen auslösen? Daraus ergibt sich auch das Werkzeug. Agent Builder reicht für viele Fälle in Zone 1 und 2. Spätestens bei Aktionen, Konnektoren zu Fachanwendungen oder breitem Rollout führt der Weg zu Copilot Studio. Braucht der Agent ein eigenes Modell oder eine eigene Orchestrierung, landet er bei Foundry und damit im Prozess des Entwicklungsteams.

3. Konzipieren und erproben

Vor dem Bauen stehen Erfolgskriterien. Was muss der Agent beantworten können, und woran merke ich, dass er es gut macht? Erst dann entsteht ein Prototyp, in Zone 1 direkt im Agent Builder, in Zone 2 und 3 in einer Entwicklungsumgebung von Copilot Studio. Microsoft empfiehlt, Maker per Environment Routing automatisch in persönliche Entwicklungsumgebungen zu leiten, damit nicht alles in der Default-Umgebung landet (Microsoft Learn).

4. Validieren und entscheiden

Für diese Phase gibt es seit diesem Jahr ein ordentliches Werkzeug. Agent Evaluation in Copilot Studio ist seit Ende März allgemein verfügbar. Damit lassen sich Testsets anlegen, Bewertungsmethoden festlegen und Läufe über mehrere Versionen wiederholen. Über einen Power-Automate-Connector und eine REST-API (derzeit Preview) lassen sich die Evaluierungen auch in CI/CD-Pipelines einbinden (Microsoft Learn).

Neben der Qualität gehören Sicherheit und Datenschutz in diese Phase: Welche Daten sieht der Agent, mit welcher Identität läuft er, und passen die Berechtigungen zum geplanten Nutzerkreis? Ruft der Agent weitere Agents oder Tools auf, gehört eine zweite Frage dazu: Arbeiten diese mit den Rechten des Benutzers oder mit eigenen, womöglich breiteren Anmeldeinformationen? In Copilot Studio legt das jedes Tool einzeln fest, und ein verbundener Agent erbt die Einstellung des aufrufenden Agents nicht. Am Ende steht eine bewusste Entscheidung.

Das Gate: Go, Change, Hold oder Stop

Die Entscheidung nach Phase 4 hat vier mögliche Ausgänge. Go führt in die Produktion. Change schickt den Agent zurück in Phase 3, weil Qualität oder Konzept noch nicht passen. Hold parkt ihn im Backlog, etwa weil eine Datenquelle noch nicht sauber berechtigt ist. Stop beendet die Idee kontrolliert.

Gerade Stop wird in vielen Organisationen unterschätzt. Ein Agent, der den Test nicht besteht, sollte nicht als halbfertiger Prototyp im Tenant liegen bleiben.

5. Bereitstellen und skalieren

In Zone 3 wird ein Agent nie direkt in der Produktion bearbeitet. Microsoft empfiehlt, Agents als Managed Solutions zu paketieren und über Power Platform Pipelines von Entwicklung über Test nach Produktion zu bringen (Microsoft Copilot Blog). Damit bekommt man Versionierung, eine nachvollziehbare Änderungshistorie und die Möglichkeit eines Rollbacks.

Die Veröffentlichung für die Organisation läuft über das Microsoft 365 Admin Center. Dort können Admins eingereichte Agents freigeben oder ablehnen. Danach folgt ein schrittweiser Rollout. Die Schulung der Nutzer gehört gleich mit in den Plan, sonst bleibt auch ein guter Agent ungenutzt.

6. Betreiben und überwachen

Im Betrieb geht es um Nutzung, Qualität und Kosten. Copilot Studio liefert dafür Analytics, Purview deckt Audit und Datenschutz ab, und mit Agent 365 gibt es seit Mai 2026 eine eigene Steuerungsebene für Agents. Copilot-Studio-Agents erscheinen in der Agent Registry, sobald sie in Microsoft 365 bereitgestellt sind. Ein Agent kann dort mehrfach auftauchen, etwa als geteilte und als veröffentlichte Fassung (Microsoft Learn). Governance-Aktionen werden in Purview protokolliert.

Zwei Dinge gehören für mich fest in den Betrieb: Wissensquellen aktuell halten, damit der Agent nicht auf veralteten Dokumenten antwortet, und Berechtigungen regelmäßig rezertifizieren. Wer mit Kunden aus regulierten Branchen arbeitet, kennt das Prinzip aus dem Identity-Management. Für Agents gilt es genauso.

7. Weiterentwickeln oder beenden

Jeder Agent endet irgendwann, als neue Version oder durch Außerbetriebnahme. Neue Versionen durchlaufen den Lifecycle erneut, je nach Umfang ab Phase 2 oder 3.

Für das Beenden bringt das Admin Center inzwischen die wichtigsten Aktionen mit (Microsoft Learn). Admins können Agent-Builder- und Copilot-Studio-Agents einen neuen Owner zuweisen, auch wenn der Agent bereits ownerless ist. Der neue Owner erhält volle Bearbeitungs- und Löschrechte und Zugriff auf die Dateien des Vorgängers. Der bisherige Owner verliert dabei jeden Zugriff. Agent-Builder-Agents können inzwischen mehrere Owner haben, die das Admin Center ergänzen oder entfernen kann. Agents ohne Zukunft lassen sich blockieren und löschen, mit 30 Tagen Frist zur Wiederherstellung.

Microsoft fasst den Gedanken dahinter in seinem Zero-Trust-Workshop gut zusammen: Eine Lifecycle-Richtlinie, die niemand durchsetzt, bleibt ein Dokument (Zero Trust Workshop). Ohne dieses Aufräumen wächst die Zahl der Agents nur in eine Richtung.

Leitplanken über alle Phasen

Unter dem Kreislauf liegen sechs Themen, die in jeder Phase und jeder Zone gelten: Identität und Ownership, Datenschutz und Compliance, Berechtigungen und Teilen, Umgebungen und ALM, Inventar und Transparenz sowie Qualität und Kosten. Im Schema habe ich jedem Thema die Werkzeuge zugeordnet, die es dafür heute gibt, von Entra Agent ID über Purview bis zur Agent Registry.

Wo es noch hakt

Ganz rund ist das Bild noch nicht. Agent-Builder-Agents haben kein echtes ALM mit Umgebungen und Versionen. Wer so einen Agent ernsthaft betreiben will, kommt um den Umzug nach Copilot Studio kaum herum.

Auch bei Copilot Studio gibt es Lücken. Die eingebauten Evaluierungen liegen in der Cloud und nicht im Quellcode-Repository. Automatische Qualitäts-Gates in einer Pipeline sind dadurch aufwendiger, als man es aus der klassischen Softwareentwicklung kennt. Stephan Bisser hat dazu in einem ESPC-Webinar ein eigenes CLI-Werkzeug vorgestellt, das Testfälle als YAML-Dateien versioniert.

Und schließlich die Lizenzfrage: Viele Registry-Funktionen stehen im Admin Center bereit. Risikosignale in der Registry und die erweiterten Sicherheits- und Compliance-Funktionen von Agent 365 setzen aber Microsoft 365 E7 oder eine Agent-365-Lizenz voraus (Microsoft Learn). Das sollte man vor dem Rollout klären.

Fünf Dinge, die du morgen prüfen kannst

Öffne im Microsoft 365 Admin Center die Agent Registry und filtere nach Agents ohne Owner.
Prüfe, ob Maker in Copilot Studio per Environment Routing in eigene Entwicklungsumgebungen geleitet werden oder alle in der Default-Umgebung bauen.
Lege fest, ab welchen Kriterien ein Agent von Zone 1 in Zone 2 wechselt, und schreib es auf.
Definiere für deinen wichtigsten Agent ein erstes Testset in Agent Evaluation.
Kläre, wer bei einem Austritt die Agents der ausscheidenden Person übernimmt.

Was passiert, wenn ein freigegebener Agent zur Laufzeit Tools aufruft und Arbeit an andere Agents abgibt, beschreibe ich in Teil 3.