Agent Registry vs. Agent 365: Who Should Own Your Agent Landscape?

As soon as you move from “Copilot writes me nicer emails” zu “Agents führen Workflows aus”, taucht eine sehr praktische Frage auf:

Wer hat eigentlich noch den Überblick, welche Agents es gibt, was sie können und mit welchen Berechtigungen sie laufen?

Microsofts Antwort darauf heißt inzwischen unter anderem Agent 365: ein zentraler Ort, an dem autonome Workflows und Agenten registriert, verwaltet und überwacht werden sollen.

Ich halte das für den richtigen Weg – aber nicht die ganze Antwort.

In diesem Artikel geht es darum, wie ich das Thema Agent Registry aus Kundensicht sehe: welche Probleme Agent 365 adressiert, wo du trotzdem eine eigene Sicht brauchst und wie ich beides zusammen denken würde.

Was eine Agent Registry grundsätzlich leisten muss

Egal, ob sie Agent 365, „Agent Hub“ oder anders heißt – eine sinnvolle Registry löst aus meiner Sicht vier Probleme:

• Inventar: Welche Agenten existieren überhaupt?
• Ownership: Wer ist für welchen Agent verantwortlich?
• Capabilities: Was darf ein Agent tun, in welchen Systemen?
• Transparenz: Was hat ein Agent tatsächlich in der letzten Zeit getan?

Wenn du ehrlich bist: viele Organisationen könnten diese vier Fragen heute nicht einmal für ihre klassischen Skripte, Cronjobs und Admin-Tools gut beantworten. Mit AI-Agents wird das nicht besser, wenn du es nicht bewusst angehst.

Wie Agent 365 in dieses Bild passt

Ich vereinfache hier stark, aber die grobe Idee hinter Agent 365 ist:

• Copilot- und andere Microsoft-Agents an einer Stelle sichtbar machen,
• Policies für autonome Workflows definieren und zentral enforce’n,
• die „Blast Radius“-Frage besser beantworten: was kann welcher Agent potenziell anrichten?

Das ist hilfreich, weil es eine Alternative zu „wir haben irgendwo in Copilot Studio und anderswo noch drei Flows und niemand weiß mehr genau, was läuft“ bietet.

Aber: Agent 365 sieht naturgemäß nur den Teil der Welt, der im Microsoft-Ökosystem lebt. Alles, was du außerhalb baust – Foundry/MCP-Agenten, OpenClaw-Skills, eigene Backend-Services – taucht dort nicht automatisch auf.

Genau deshalb brauchst du aus meiner Sicht eine eigene Agent Registry-Story, in die Agent 365 dann ein Baustein wird, nicht der ganze Tempel.

Die minimale eigene Agent-Registry

Du musst dafür kein riesiges Tool einführen. Ein erster brauchbarer Schritt ist ein sehr unspektakuläres, aber ehrliches Agent-Register – zur Not als Tabelle oder YAML-Datei im Repo.

Für jeden Agent würde ich mindestens festhalten:

• Name und kurze Beschreibung („Sync Insights SAP↔Entra“, „Ticket-Triage für IT-Support“, …)
• Owner (Person oder Team), inklusive Kontakt
• Scope (in welchen Bereichen darf er arbeiten, z.B. nur Test-Tenant, nur internes HR, nur Dev-Systeme)
• Capabilities (welche Systeme liest/schreibt er, welche Aktionen sind erlaubt: create/update/delete/approve)
• Identity (unter welchem technischen Konto / welcher App-Registration läuft er?)
• Frontends (wird er über Copilot genutzt, Teams, Web-UI, CLI?)
• Logs (wo finde ich Logs und Metriken?)

Das ist nichts, was Agent 365 dir abnehmen kann, wenn du es nicht definierst. Umgekehrt kann Agent 365 ein Datenlieferant für genau diese Tabelle sein – aber das Model musst du dir selbst überlegen.

Wie ich Agent 365 und eine eigene Registry zusammendenken würde

Wenn ich es mir als Kunde wünschen dürfte, sähe mein Setup so aus:

• Agent 365 verwaltet alle Agenten, die im Copilot-/Microsoft-365-Ökosystem leben (Copilot Studio, native M365-Agents, evtl. MCP-Tools, die direkt an Copilot hängen).
• Eine eigene, systemübergreifende Registry (kann am Ende auch nur ein ordentlich gepflegtes Repo sein) bildet das „Single Source of Truth“ über:
• Microsoft-Agents (über Sync/Exports aus Agent 365),
• Foundry/MCP-Agenten,
• OpenClaw-Agents,
• sonstige Automationen, die „AI-getrieben“ sind.

Agent 365 wäre in diesem Bild ein wichtiges Subsystem, aber keine Entschuldigung, die nicht-Microsoft-Welt zu vergessen.

Was du zusätzlich brauchst: Policies, nicht nur Inventar

Eine Registry ist die halbe Miete. Die andere Hälfte sind die Regeln, die du darauf anwendest.

Konkrete Fragen, die ich für alle Agenten klären würde – egal, ob sie in Agent 365 hängen oder nicht:

• Autonomie-Level: Darf dieser Agent eigenständig Änderungen vornehmen, oder nur Vorschläge machen?
• Umgebungen: In welchen Tenants/Umgebungen darf er laufen (Dev/Test/Prod)?
• Approval-Flows: Braucht es für bestimmte Aktionen (z.B. HR/Finance/Security) immer eine menschliche Bestätigung?
• Data Scope: Welche Datenkategorien sind explizit tabu (z.B. individuelle Gehaltsdaten, laufende Ermittlungen)?
• Review-Cadence: Wie oft schauen wir auf Logs, Fehlerraten und Nutzerfeedback für diesen Agent?

Das ist im Prinzip das gleiche Denken, das du für CI/CD-Pipelines oder Admin-Tools brauchst – nur angewendet auf Agents.

Ein einfacher Startpunkt: „Agent Fact Sheet“ pro Agent

Wenn dir eine vollständige Registry zu viel erscheint, fang mit einem Agent Fact Sheet pro wichtigem Agent an. Eine Seite, die folgende Fragen beantwortet:

• Was macht dieser Agent konkret?
• Wer ist der Owner?
• Welche Systeme liest/schreibt er?
• Unter welcher technischen Identität läuft er?
• Welche Sicherheitsmaßnahmen gibt es (Logging, Approvals, Limits)?
• Wie sieht der Rückfallpfad aus, wenn er deaktiviert werden muss?

Wenn du diese Facts sauber hast, ist der Schritt zu einer strukturierten Registry (Tabelle, YAML, eigenes Tool) nicht mehr weit.

Meine Einschätzung

Eine bessere Agent-Governance im Microsoft-Ökosystem ist absolut sinnvoll – und ich finde es gut, dass Microsoft mit Agent 365 und Co. in diese Richtung geht.

Aber: Kein Hersteller kann dir die Verantwortung abnehmen, ein eigenes Bild deiner Agentenlandschaft zu haben. Gerade weil du neben Copilot:

• Foundry/MCP für Enterprise-Agents,
• OpenClaw für Self-Hosted-/DevOps-Automation,
• und diverse Legacy-Automationen

parallel betreibst.

Mein Rat wäre deshalb:

• Nutze Agent 365, wenn es dir Sichtbarkeit und Policies für den Microsoft-Teil bringt.
• Bau dir trotzdem eine eigene, systemübergreifende Agent-Registry, auch wenn sie am Anfang „nur“ eine seriös gepflegte Tabelle ist.
• Definiere klare Regeln für Autonomie, Berechtigungen und Review – und wende sie auf alle Agenten an, nicht nur auf die, die in der neuesten Produktankündigung vorkommen.

Dann bist du nicht von einem Werkzeug abhängig – sondern hast ein eigenes Governance-Modell, in das du neue Plattformen wie Agent 365 einbauen kannst, statt ihnen hinterherzulaufen.