Agent Registry im Unternehmen: Discovery für 50+ Agents

Pexon Consulting | 11 Min. Lesezeit | 08.06.2026

TL;DR

Agent Registry Unternehmen ist 2026 die Antwort auf das nächste Skalierungs-Problem im Mittelstand: Bei drei bis fünf produktiven AI-Agents reicht ein Spreadsheet, ab acht bis zehn wird die Governance unkontrollierbar — niemand weiß mehr, welcher Agent welche Daten anfasst, welche Permissions hat, welche Kosten anfallen, wer ihn betreibt. Pexon Consulting baut eine Agent Registry mit Datenmodell, APIs und Compliance-Schicht — als 6-8-Wochen-Sprint, der die Voraussetzung für AI-Act-konforme Skalierung ab 2026 schafft.

Warum dein Mittelstand eine Agent Registry braucht

Wir sehen das Muster aktuell wöchentlich: Ein CTO eines 1.500-MA-Mittelständlers hat in 18 Monaten die ersten drei Agents produktiv gebracht — Customer-Support-Agent, Document-Intelligence-Pipeline, Code-Review-Assistent. Erfolg. Daraufhin haben die Fachbereiche gemerkt, dass das funktioniert, und jetzt sitzen sechs weitere Agent-Initiativen in unterschiedlichen Stadien zwischen PoC und Production. Jede Initiative hat ihren eigenen LangGraph-Stack, eigene MCP-Server-Anbindung, eigenes Logging, eigene Permissions-Logik. Niemand hat den Überblick, was wo läuft.

Die Symptome kommen vorhersagbar. Erstens: Der Datenschutzbeauftragte fragt, welche Agents personenbezogene Daten verarbeiten — niemand kann das aus dem Stand beantworten. Zweitens: Der Einkauf möchte wissen, was die kumulierten OpenAI-Bills monatlich kosten — drei verschiedene Cost-Centers, fünf verschiedene Accounts, keine zentrale Sicht. Drittens: Die IT-Sicherheit findet einen Vorfall in einem Agent — und entdeckt, dass sechs weitere Agents ähnliche Permissions haben, ohne dass jemand das proaktiv gewusst hätte.

Das ist nicht „schlechtes Management“ — das ist die natürliche Konsequenz davon, dass jede Agent-Initiative isoliert gestartet wurde, mit eigener Geschwindigkeit, eigenem Stack, eigener Doku-Disziplin. Spätestens ab 8-10 produktiven Agents wird klar, dass das nicht skaliert. Die Pexon-Antwort darauf heißt Agent Registry — ein zentrales Verzeichnis aller produktiven, in Entwicklung befindlichen oder zur Stilllegung vorgesehenen Agents, mit Metadaten, Verantwortlichkeiten, Permissions und Compliance-Anbindung.

Was eine Agent Registry konkret tut

Der Begriff ist 2026 noch nicht stabil — manche reden von „Agent Catalog“, andere von „Agent Marketplace“, einige Großkonzerne von „AI Asset Inventory“. Wir nennen es Agent Registry, weil die Analogie zur Container Registry präzise ist: Ein zentraler Ort, an dem Agents registriert sind, mit Metadaten versehen, versioniert, auf Compliance geprüft und für Konsumenten auffindbar.

Konkret deckt eine Agent Registry vier Funktionen ab. Erstens Inventar: Welche Agents existieren überhaupt, in welcher Version, in welchem Lebenszyklus-Status (Pilot, Production, Deprecated). Zweitens Metadaten: Wer ist Owner, welche Daten werden verarbeitet, welche Permissions sind nötig, welche Modelle werden genutzt, was sind die Kosten. Drittens Discovery: Wenn der Einkauf einen „Lieferanten-Audit-Agent“ sucht, findet er ihn statt einen neuen zu bauen. Viertens Governance: Compliance-Status, Audit-Trail, AI-Act-Klassifikation, DSGVO-Folgenabschätzung.

Damit verschiebt sich die Logik weg von „jedes Team baut seinen Agent isoliert“ hin zu „jeder neue Agent muss durch die Registry, die Compliance-Status erzwingt und Wiederverwendung ermöglicht“. Bei einem unserer Pilotkunden hat das in den ersten sechs Monaten dazu geführt, dass von zwölf neuen Agent-Initiativen vier auf bereits existierende Agents zurückgeführt wurden — Wiederverwendung statt Neubau, mit Engineering-Save von rund 600.000 EUR.

Wichtig: Die Registry ist nicht der einzige Ort, an dem Agents laufen. Sie ist das Metadaten- und Governance-System dazu. Die Agents selbst laufen weiterhin in Bedrock, in Azure, auf eurer eigenen K8s-Infrastruktur — die Registry hält den Überblick.

Architektur: Datenmodell, APIs, Governance

Das Pexon-Standard-Datenmodell für eine Agent Registry hat sich in mehreren Kundenprojekten geschärft. Hier die Kern-Entitäten in Code-Form als Pydantic-Modell.

from pydantic import BaseModel
from enum import Enum
from datetime import datetime

class Lifecycle(str, Enum):
    EXPERIMENT = "experiment"
    PILOT = "pilot"
    PRODUCTION = "production"
    DEPRECATED = "deprecated"
    RETIRED = "retired"

class AiActRiskLevel(str, Enum):
    MINIMAL = "minimal"
    LIMITED = "limited"
    HIGH_RISK = "high_risk"
    UNACCEPTABLE = "unacceptable"

class Agent(BaseModel):
    id: str
    name: str
    description: str
    owner_team: str
    owner_contact: str
    lifecycle: Lifecycle
    version: str
    repo_url: str
    deployment_env: str
    data_classifications: list[str]
    permissions_required: list[str]
    models_used: list[str]
    mcp_servers: list[str]
    monthly_cost_eur: float
    ai_act_risk_level: AiActRiskLevel
    dsgvo_dpia_link: str | None
    audit_trail_backend: str
    created_at: datetime
    last_review_at: datetime

Was im Datenmodell wichtig ist: data_classifications (z.B. „personenbezogen“, „geschäftsgeheimnis“, „vs-nfd“) triggert automatisierte Compliance-Checks. ai_act_risk_level ist Pflicht ab 2026 für jeden Agent, weil die EU-AI-Act-Klassifikation bei der Konformitätsbewertung relevant ist. mcp_servers und models_used ermöglichen Cross-Cutting-Analysen — „welche Agents nutzen Claude Opus 4.7?“ oder „welche Agents hängen am SAP-MCP-Server?“.

Auf API-Ebene exponieren wir typisch fünf Endpoints. POST /agents für die Registrierung neuer Agents, GET /agents/{id} für Detail-Lookup, GET /agents?owner=X&risk=high_risk für Discovery-Queries, PATCH /agents/{id} für Lifecycle-Updates, POST /agents/{id}/review als Trigger für Compliance-Reviews. Die Registry ist self-service — Teams registrieren ihre Agents über CI/CD-Hooks, die Governance-Schicht greift bei kritischen Klassifikationen automatisch.

Governance konkret: Jede Lifecycle-Transition (Pilot → Production) löst einen Compliance-Check aus. Bei high_risk-Klassifikation muss eine DSGVO-Folgenabschätzung verlinkt sein, bei personenbezogenen Daten muss der Datenschutzbeauftragte freigeben. Bei VS-NfD-Daten gilt das Geheimschutz-Pattern, bei Geschäftsgeheimnissen das GeschGehG-Logging.

Drei Killer-Funktionen aus Pexon-Projekten

Über die letzten zwölf Monate haben wir bei drei Kundenprojekten Patterns identifiziert, die sich als besonders wertvoll erwiesen haben — über das reine Inventar hinaus.

Funktion 1: Cost Attribution per Agent. Die Registry verknüpft jeden Agent mit seinen Modell-Calls über eine standardisierte Cost-Tag-Konvention. Beim Aufruf von Bedrock oder Anthropic-API setzt der Agent einen Cost-Tag, der in den Provider-Bills auftaucht — daraus rechnet die Registry monatlich pro Agent die Kosten, ordnet sie dem Cost-Center des Owners zu und meldet bei Anomalien (Agent X kostet plötzlich 5x so viel). Bei einem Kunden hat das einen Loop-Bug aufgedeckt, der unbemerkt 14.000 EUR im Monat verbrannt hatte — vor der Registry hätte das niemand gesehen.

Funktion 2: Permissions Reverse-Lookup. Die Registry weiß, welcher Agent welche Permissions hat. Bei einem Security-Vorfall (z.B. kompromittiertes Service-Account) kann man in Sekunden alle Agents abfragen, die diese Permission nutzen, und sie gezielt deaktivieren. Vor der Registry war das eine Tagesarbeit aus Logs und Code-Reviews — mit der Registry zwei Minuten. Das ist ein konkreter Incident-Response-Vorteil, der in Audits gut ankommt.

Funktion 3: Wiederverwendungs-Discovery. Bevor ein Team einen neuen Agent baut, wird in der Registry gegen Semantic-Search auf Beschreibung, Tags und Datenklassifikationen geprüft — gibt es bereits einen ähnlichen Agent? Bei vier von zwölf Initiativen bei einem Kunden war das der Fall, die jeweiligen Teams haben dann den bestehenden Agent erweitert statt neu gebaut. Das Pattern ist analog zur Service-Discovery in einer Microservice-Landschaft — und es spart Engineering-Zeit im sechsstelligen Bereich pro Jahr.

AI-Act-Querbezug: Was die Registry für Compliance bringt

Seit August 2026 gelten die übrigen Teile des EU-AI-Act, die Pflichten für Betreiber von High-Risk-AI-Systemen nach Anhang III ab Dezember 2027 und für Anhang I ab August 2028. Was bedeutet das praktisch für eine Agent-Landschaft im Mittelstand?

Jeder Agent, der unter Annex III des AI-Acts fällt (Recruiting-Entscheidungen, Credit-Scoring, Versicherungs-Underwriting, kritische Infrastruktur-Aspekte, etc.), muss klassifiziert sein, eine Risk-Management-Doku haben, einen Audit-Trail bereitstellen, menschliche Aufsicht ermöglichen und in einem AI-Register erfasst sein. Die Liste klingt überschaubar, ist aber ohne strukturierte Datenhaltung pro Agent kaum erfüllbar.

Genau hier setzt die Agent Registry an. Sie ist nicht das AI-Register im Sinne des AI-Acts — das ist eine separate Registrierung beim Marktüberwacher — aber sie ist die operative Datenquelle, aus der die formale AI-Register-Pflege gespeist wird. Bei jeder Agent-Registrierung wird die AI-Act-Klassifikation zwingend ausgefüllt. Bei High-Risk-Klassifikation wird ein Compliance-Workflow gestartet, der Risk-Management-Doku, DSGVO-Folgenabschätzung und Audit-Trail-Backend prüft.

Bei einem Versicherer-Kunden haben wir Anfang 2026 genau dieses Compliance-Setup eingeführt — sieben Monate vor dem produktiven AI-Act-Wirksamwerden. Das Ergebnis: Bei den ersten Audit-Anfragen im Oktober/November 2026 konnten alle relevanten Agents in zwei Stunden vollständig dokumentiert werden, statt in zwei Wochen Notarbeit. Mehr zum AI-Act-Praxisbezug in unseren Compliance-Posts.

Pexon-Setup-Pattern: 6-8 Wochen für die erste produktive Registry

Wir liefern die Agent Registry als 6-8-Wochen-Sprint mit festem Preis. Lieferumfang: Postgres-basiertes Datenmodell mit Standard-Schema, REST-API plus optionales Web-UI, Anbindung an euer IdP für Auth (Keycloak, Entra ID), CI/CD-Hooks für Self-Service-Registrierung, Compliance-Workflow-Engine für AI-Act- und DSGVO-Trigger, Cost-Attribution-Integration mit Bedrock und/oder Azure OpenAI, Schulung von vier bis sechs Power-Usern aus Engineering, Compliance und Datenschutz.

Investment 75-130k EUR je nach Anbindungs-Komplexität (insbesondere Cost-Attribution und IdP-Integration). Für Kunden mit bestehenden Service-Catalog-Tools (Backstage, Port) bauen wir die Registry oft als Plugin in das vorhandene Tool — spart Setup-Aufwand und verankert die Registry an einer Stelle, die Engineering ohnehin nutzt.

Häufig gestellte Fragen

Brauchen wir das wirklich schon bei sechs Agents?

Klare Antwort: noch nicht zwingend, aber jetzt ist der richtige Moment zum Aufsetzen. Bei sechs Agents reicht ein Spreadsheet noch — die Pflege ist eine Stunde pro Woche. Ab zehn bis zwölf Agents kippt das. Wir empfehlen, die Registry aufzubauen, wenn drei bis fünf Agents produktiv sind und mindestens drei weitere im PoC. Dann ist der Aufwand des Aufbaus geringer als der spätere Migrations-Schmerz.

Wie unterscheidet sich das von einem Service-Catalog wie Backstage?

Backstage und ähnliche Service-Catalog-Tools sind generische Inventare für Services, Datenbanken, APIs. Sie können um AI-Agent-Plugins erweitert werden — wir haben das bei zwei Kunden so gemacht. Die Agent Registry als eigenständiges Tool macht Sinn, wenn ihr Backstage nicht habt und ein leichtgewichtiges Setup wollt, oder wenn ihr die AI-Governance-Funktionen tiefer ausbauen wollt, als ein generisches Catalog-Plugin abbildet.

Was passiert mit Agents, die wir nicht selbst gebaut haben — z.B. Microsoft Copilot?

Externe Agents werden auch registriert, mit eingeschränkten Metadaten. Bei Copilot tragen wir ein, welche Microsoft-Connectors aktiv sind, welche Lizenz-Klasse, welche Datenklassifikationen verarbeitet werden, welcher Owner-Team. Cost-Attribution funktioniert über die Microsoft-Billing-Exporte. Permissions-Reverse-Lookup ist eingeschränkter als bei selbst gebauten Agents, aber besser als gar keine Übersicht.

Wie integriert sich die Registry mit MCP-Servern und LangGraph-Agents?

Über zwei Mechanismen. Erstens: CI/CD-Hooks beim Deployment eines Agents (LangGraph, Claude Agent SDK, OpenAI Agents SDK) triggern ein Registry-Update. Zweitens: Runtime-Heartbeat — jeder Agent meldet alle 5-15 Minuten seinen Status an die Registry, sodass bei Ausfall der Lifecycle-Status automatisch auf „down“ wechselt. Bei MCP-Servern erfassen wir zusätzlich Tool-Liste und Aufruf-Statistiken, sodass die Registry weiß, welche Tools wie oft genutzt werden.

Reicht das, oder brauchen wir zusätzlich ein eigenes Compliance-Tool?

Für die meisten Mittelstands-Setups reicht die Registry plus die Standard-DSGVO- und AI-Act-Workflows, die wir mitgeben. Für stark regulierte Kunden (Banking, Versicherung mit DORA-Anforderungen) integrieren wir die Registry in vorhandene GRC-Tools wie ServiceNow GRC, OneTrust oder LogicGate. Das ist dann nicht „zusätzlich“, sondern eine spezifische Anbindung an euer bestehendes Compliance-Ökosystem.

Nächster Schritt

Wenn dein Unternehmen mehr als sechs produktive Agents hat und der Überblick auseinanderfällt: Wir machen einen 45-Minuten-Call mit dir und idealerweise einem Verantwortlichen aus Compliance oder Datenschutz. Du beschreibst die aktuelle Agent-Landschaft, wir skizzieren die Registry-Architektur für eure Realität mit Festpreis-Sprint.

Verwandte Themen