Microsoft Agent 365 vs. Microsoft 365 Agents

Microsoft Agent 365 vs. Microsoft 365 Agents ist die praxisrelevante Unterscheidung für IT-Teams und Architekten: Der eine Begriff beschreibt den gesteuerten Betrieb von Agenten, der andere die Agenten, die Anwender innerhalb der Microsoft-365-Erlebnisse erstellen und ausführen. Dieser Praxisleitfaden sortiert die Begriffe.

Wenn du die letzten zwölf Monate im Microsoft-KI-Ökosystem verbracht hast, hast du immer wieder dasselbe Muster beobachtet: Jede Ankündigung verpackt dasselbe Thema unter einem leicht abgewandelten Banner. Copilot. Copilot Studio. Microsoft Foundry. Microsoft Agent Framework. Declarative agents. Custom engine agents. Und jetzt zwei Begriffe, die fast identisch klingen, aber sehr unterschiedliche Dinge bedeuten Microsoft 365 Agents und Microsoft Agent 365.

Ich sehe immer wieder, dass sie austauschbar verwendet werden, auch in ernst gemeinten technischen Beiträgen. Sie sind nicht austauschbar. Da Agent 365 am 1. Mai 2026 allgemein verfügbar wird, ist es keine reine Spitzfindigkeit mehr, diese Unterscheidung richtig zu treffen es ist eine Entscheidung für Beschaffung, Governance und Architektur.

Dieser Beitrag ist die Version, die ich mir gewünscht hätte, bevor ich mit dem Bauen begonnen habe.

Die beiden Begriffe im direkten Vergleich

	Microsoft 365 Agents	Microsoft Agent 365
Was es ist	Die Agenten selbst + das SDK, um sie zu bauen	Die IT-/Sicherheits-Steuerungsebene, die Agenten verwaltet
Für wen es ist	Entwickler, Maker, Fachbereichsverantwortliche	IT-Admins, Sicherheitsteams, Compliance-Verantwortliche
Beispiele	Declarative agents, custom engine agents, Copilot Studio Agents, in Foundry erstellte Agenten	Registry, Entra Agent ID, Agent Blueprints, Work IQ MCP Governance
Lizenzierung	Im Lieferumfang von Microsoft 365 Copilot, Foundry-Verbrauch, Copilot Studio	Separate SKU: 15 USD / Benutzer / Monat oder gebündelt in Microsoft 365 E7 (Frontier Suite)
Status	GA für die meisten Komponenten	GA seit 1. Mai 2026

In einem Satz: Microsoft 365 Agents sind das, was du baust. Microsoft Agent 365 ist das, was du nutzt, um sie im großen Maßstab sicher zu halten. Gehen wir das nun Ebene für Ebene durch.

Microsoft 365 Agents – die Agentenebene

Lässt man das Branding beiseite, sind Microsoft 365 Agents vier Wege, einen Agenten zu bauen, alle aufbauend auf demselben Identitäts-, Grounding- und Governance-Modell:

• Declarative agents – über ein Manifest beschriebene Agenten, die innerhalb des Microsoft 365 Copilot Hosts laufen. Kein eigenes Backend. Du beschreibst die Persona, die Grounding-Quellen (SharePoint, OneDrive, Graph, Web), Connector-Tools und Gesprächseinstiege. Microsoft führt sie innerhalb von Copilot Chat in Teams, Word, Outlook und Microsoft365.com aus.
• Agent Builder – der No-Code-Erstellungsweg innerhalb von Microsoft Copilot. Dasselbe Ausführungsmodell wie declarative agents, mit Vorlagen und einer visuellen Einrichtung. Hervorragend für Fachbereichsverantwortliche, die denselben Ablauf andernfalls in Power Apps bauen würden.
• Copilot Studio Agents – der Low-Code-Weg. Themengesteuerte Erstellung, Veröffentlichung über mehrere Kanäle, Modellauswahl, MCP-Unterstützung. Die natürliche Heimat für von Citizen Developern getriebene Automatisierung, die mehr Kontrolle braucht, als ein declarative Manifest bietet.
• Custom engine agents – Agenten mit voller Kontrolle, die du mit dem Microsoft 365 Agents SDK baust (dem Nachfolger des Bot Framework, KI-Stack-agnostisch, .NET GA / JS / Python). Du bringst dein eigenes Modell mit (Foundry, Azure OpenAI, Anthropic über Foundry, Open-Weights), deinen eigenen Memory Store, deine eigene Tool-Oberfläche. Microsoft kümmert sich um Distribution, Identität und die Kanal-Anbindung über Teams, M365 Copilot, Web und eingebettete Oberflächen.

Pro-Code-Teams kombinieren das M365 Agents SDK typischerweise mit dem Microsoft Agent Framework (v1.0 GA April 2026 für .NET und Python) für Orchestrierung, Multi-Agent-Muster und das Erstellen von Skills.

Die Wahl zwischen diesen Optionen ist kein Feature-Häkchen – es ist eine Architekturentscheidung:

• Setze standardmäßig auf declarative agents oder Agent Builder für Abläufe, die hauptsächlich aus Grounding, Zusammenfassung oder Q&A über Microsoft-365-Inhalte bestehen. Günstiger, gesteuert, und du erfindest die Identität nicht neu.
• Greife zu Copilot Studio, wenn Fachanwender den Lebenszyklus selbst verantworten sollen, du aber dennoch IT-Leitplanken haben möchtest.
• Greife zu custom engine agents, wenn du orchestrierte Tool-Nutzung, deterministischen Zustand, eigenes Memory, Nicht-Microsoft-Modelle oder strikte Latenzkontrolle brauchst. Genau dort beginnen sich Evaluierung, Monitoring und Observability von Foundry wirklich auszuzahlen.

Microsoft Agent 365 – die Steuerungsebene

Nun der Teil, der tatsächlich verändert, wie die IT ihre Arbeit macht. Microsoft Agent 365 ist kein Ort, um Agenten zu bauen. Es ist die zentrale Ebene, die es IT-, Sicherheits- und Compliance-Teams ermöglicht, jeden Agenten im Tenant zu beobachten, zu steuern und abzusichern – unabhängig davon, ob er in Copilot Studio, Foundry, dem Microsoft Agent Framework, dem OpenAI Agents SDK, dem Claude Code SDK, LangChain gebaut oder von einer Drittanbieter-Plattform registriert wurde.

Es richtet sich an vier Admin-Domänen und fünf Kernfunktionen aus und folgt demselben Muster, das Microsoft bereits für Benutzer, Geräte und Apps verwendet – nur auf Agenten angewendet.

Die vier Admin-Oberflächen

• Microsoft 365 Admin Center – der zentrale Knotenpunkt. Inventar, Blueprint-Freigabe, Lebenszyklus, Agenten-Analytics.
• Microsoft Entra – Identität und Zugriff. Entra Agent ID gibt jedem Agenten seine eigene erstklassige Identität, sodass Conditional Access, risikobasierter Zugriff und Least-Privilege-Scoping nativ greifen.
• Microsoft Purview – Datenschutz. Sensitivity Labels, DLP, Insider Risk, Audit. Agenten, die in SharePoint oder OneDrive grounden, erben bestehende Labels; custom engine agents, die auf externe Daten zugreifen, benötigen eine explizite DLP-Anbindung.
• Microsoft Defender – Bedrohungsschutz. Posture Management, Anomalieerkennung, Advanced Hunting über Tool-Calls von Agenten.

Die fünf Funktionen

1. Registry – ein einheitliches Inventar über von Microsoft erstellte, von Partnern erstellte (zum Start Genspark, Zensai, Egnyte, Zendesk, Kasisto, Kore, n8n) und selbst registrierte Agenten hinweg. Der Registry-Sync mit AWS Bedrock und Google Cloud ist in der Public Preview, sodass Multicloud-Umgebungen an einem Ort sichtbar sind.
2. Access Control – jeder Agent erhält eine Entra-gestützte Identität. Admins setzen Leitplanken dafür, wer Agenten erstellen, onboarden und verwalten darf.
3. Visualisierung – die Agent Map: wie Agenten mit anderen Agenten, MCP-Servern, Identitäten und Cloud-Ressourcen verbunden sind.
4. Interoperabilität – gesteuerter Zugriff auf Microsoft-365-Workloads über Work IQ MCP Server (Outlook, Word, Teams, SharePoint, Dataverse und mehr). Admins erlauben oder blockieren Server über das M365 Admin Center; Defender Advanced Hunting verfolgt jeden Tool-Call.
5. Security – Durchsetzung von Laufzeit-Richtlinien, Agent-zu-Agent-Segmentierung und die Shadow AI-Erkennungsoberfläche für nicht verwaltete Agenten.

Agent Blueprints – das Governance-Primitiv

Das Element, das alles zusammenhält, ist das Entra Agent Blueprint: eine von der IT freigegebene, vorkonfigurierte Definition eines Agententyps. Das Blueprint legt die Fähigkeiten des Agenten, die erforderlichen Work-IQ-Tools, Sicherheits- und Compliance-Vorgaben, Audit-Anforderungen und verknüpfte Richtlinienvorlagen (DLP, externer Zugriff, Logging) fest.

Sobald es in einem Tenant aktiviert ist, fordern Benutzer im M365 Admin Center Agenten-Instanzen aus Blueprints an. Jede Instanz erbt standardmäßig die Sicherheitslage des Blueprints. Das ist das App-Catalog-Muster aus der SCCM-/Intune-Ära, angewendet auf Agenten – und es ist das mit Abstand wichtigste Agent-365-Konzept, das du verinnerlichen solltest, bevor deine Benutzer anfangen, Agenten aus beliebigen GitHub-Repos hochzuladen.

Das Agent 365 SDK und CLI

Entwickler müssen nicht das Framework wechseln, um teilzunehmen. Das Agent 365 SDK (NuGet, PyPI – Pakete mit dem Präfix Microsoft.Agents.A365 / microsoft-agents-a365) erweitert jeden Agenten – ob auf dem M365 Agents SDK, dem Microsoft Agent Framework, dem OpenAI Agents SDK, LangChain oder dem Claude Code SDK aufgebaut – um Observability auf Enterprise-Niveau (OpenTelemetry), Benachrichtigungen (Teams, Outlook, Word-Kommentare) und gesteuerten MCP-Zugriff.

Das Agent 365 CLI automatisiert den Lebenszyklus: Blueprint-Erstellung, Identitäts-Anbindung, MCP-Integration, Azure-Deployment, Veröffentlichung im M365 Admin Center und Aufräumen.

Was das für Endpoint-Admins bedeutet

Wenn dein Job darin besteht, einen Tenant sauber zu halten – und besonders, wenn du deine Tage in Intune und Defender verbringst – ergänzt Agent 365 drei neue Admin-Oberflächen, die du vor einem Jahr noch nicht hattest:

1. Shadow-AI-Erkennung über Defender + Intune

Microsoft hat angekündigt, dass Agent-Kontext-Mapping, richtlinienbasierte Kontrollen und Laufzeit-Blocking im Juni 2026 in die Public Preview gehen – über Intune und Defender. Kunden im Frontier-Programm sehen lokale Agenten (in Microsofts Terminologie die OpenClaw-Oberfläche) bereits auf der neuen Shadow-AI-Seite im M365 Admin Center und in Intune. Du kannst Intune-Richtlinien anwenden, um verwaltete Geräte zu erkennen, auf denen nicht verwaltete Agenten laufen, und die gängigen Ausführungspfade blockieren.

Für Intune-Admins ist das die natürliche Erweiterung der Arbeit, die du ohnehin schon für nicht verwaltete Software leistest. Das Muster ist dasselbe; nur das Inventarziel ist neu.

2. Conditional Access für Agenten, nicht nur für Benutzer

Jede Aktion eines Agenten läuft als Entra-gestützte Identität. Custom engine agents authentifizieren sich als Anwendungsidentitäten (oder über On-Behalf-Of-Flows als der Benutzer). Declarative agents erben Benutzerberechtigungen, wenn sie über Connectors Graph aufrufen. So oder so greifen deine bestehenden Conditional-Access-Richtlinien – Gerätekonformität, Standort, MFA, Risiko – automatisch.

Das ist das mit Abstand am meisten unterschätzte Feature. Gut konzipierte Agenten werden genauso gesteuert wie die Benutzer, die sie sponsern.

3. Windows 365 for Agents

Parallel zur GA von Agent 365 hat Microsoft Windows 365 for Agents in der Public Preview gestartet (vorerst nur in den USA): eine abgesicherte, verwaltete Cloud-PC-Umgebung, die speziell auf Agenten-Workloads zugeschnitten ist. Agent 365 steuert, was ein Agent tun darf; Windows 365 for Agents steuert, wo er die Arbeit erledigt. Ein Pilot lohnt sich, wenn deine Szenarien Agenten umfassen, die Desktop-Anwendungen steuern.

Meine Architektur-Faustregeln

Nachdem ich eine Handvoll davon in produktive Tenants ausgerollt habe, sind hier die Regeln, die ich inzwischen standardmäßig anwende:

• Setze standardmäßig auf declarative agents oder Copilot Studio für Grounding-lastige Abläufe. Greife nur dann zum M365 Agents SDK, wenn der Anwendungsfall den operativen Aufwand rechtfertigt.
• Definiere Blueprints, bevor Benutzer Agenten definieren. Die standardmäßige Blueprint-Oberfläche in deinem Tenant entscheidet darüber, ob Agent 365 tatsächlich etwas steuert oder es nur beobachtet.
• Behandle Agenten-Identitäten wie Service Principals. Schränke sie über Graph-Anwendungsberechtigungen eng ein; verwende niemals die Anmeldedaten eines Global Admins. Auditiere sie wie jeden anderen Service Principal.
• Liefere niemals ohne eine Eval-Suite aus. Ohne sie kannst du nicht erkennen, ob deine nächste Prompt-Änderung die vorherigen fünf Workflows zerstört hat. Führe Evals in der CI aus und sperre das Deployment hinter einer Qualitätsschwelle.
• Beschrifte deine Tools. Jedes Tool, das ein Agent aufrufen kann, erhält einen Docstring, ein Schema und eine Richtlinie, die festlegt, wann es erlaubt ist. Der Prompt des Agenten ist nicht der Ort, an den diese Richtlinie gehört.

Was du dieses Quartal tun solltest

Wenn du Admin oder IT-Architekt bist und Microsoft Agent 365 noch nicht angefasst hast, machen sich vier Schritte schnell bezahlt:

1. Richte Agent 365 im M365 Admin Center ein. Entweder über die eigenständige SKU (15 USD / Benutzer / Monat) oder als Teil von Microsoft 365 E7 (Frontier Suite). Aktiviere die Registry; setze standardmäßig auf Admin-Freigabe für neue Agenten-Installationen.
2. Inventarisiere Shadow AI. Defender for Cloud Apps klassifiziert KI-Tools bereits; kombiniere das mit der Agent-365-Registry, um ein einheitliches Bild über verwaltete, Partner- und selbst registrierte Agenten zu erhalten. Miss erst, bevor du blockierst.
3. Pilotiere einen declarative agent. Wähle einen internen Workflow, der derzeit eine Wiki-Seite oder eine Teams-FAQ ist. Declarative + Grounding ist dein minimal funktionsfähiges KI-Feature.
4. Richte Foundry plus das M365 Agents SDK für den nächsten Workflow ein. Evaluierungs-Framework, Monitoring, Prompt-Versionierung, Deployment Slots, vollständige Identitäts-Anbindung über Agent 365. Das ist die Plattform, die du dir wünschen wirst, wenn dein erster Agent um 3 Uhr morgens schiefgeht.

Abschließende Gedanken

Microsoft 365 Agents und Microsoft Agent 365 sind zwei Hälften derselben Geschichte, aber sie leben in unterschiedlichen Budgets und sind unterschiedlichen Teams verpflichtet. Microsoft 365 Agents ist das, womit deine Entwickler und Maker bauen. Microsoft Agent 365 ist das, womit deine IT- und Sicherheitsteams verhindern, dass das Gebaute zu einem Problem wird.

Der schwierige Teil für IT-Teams ist nicht die Technologie selbst – es ist die Erkenntnis, dass Agenten jetzt Teil der Identitäts-, Angriffs- und DLP-Oberfläche deines Tenants sind. Behandle sie mit derselben Sorgfalt, mit der du heute App-Registrierungen und Conditional Access behandelst, und alles wird gut. Behandle sie als Marketing-Kuriosität, und du wirst den Rest des Jahres damit verbringen, Shadow AI aufzuräumen.

Das Vokabular zählt, weil die Lizenzierung zählt, weil die Governance zählt. Bring zuerst die Begriffe in Ordnung; der Rest folgt von selbst.