Supervisor Agent und Agent Registry für eine Multi-Agent-KI-Plattform im Unternehmen
Wie ein Supervisor Agent, ein Planning Agent und eine Agent Registry Orchestrierung von Implementierung trennen, damit eine KI-Plattform von fünf auf hundert Agents wachsen kann.
Einen einzelnen KI-Agent zu schreiben ist der leichte Teil. Schwer ist eine Plattform, auf der viele Agents zusammenarbeiten, mehrstufige Workflows abarbeiten, sich jeweils in eigenem Rhythmus ändern und trotzdem unter Last stabil bleiben. In einer Multi-Agent-Plattform im Unternehmen macht das der Supervisor Agent möglich, die eine Stelle, an der Arbeit ins System gelangt.
Nutzer sprechen nie mit einzelnen Agents. Eine Anfrage geht an den Supervisor, und der Supervisor bündelt die Fähigkeiten, die der Auftrag braucht.
Von einzelnen Agents zur Orchestrierung
Nehmen wir einen Aufbau ohne Supervisor. Der Aufrufer hat es direkt mit jedem Agent zu tun:
User
├── Planning Agent
├── Retrieval Agent
├── Research Agent
├── Analysis Agent
└── Report Agent
Wer auch immer das System aufruft, ein Mensch oder eine andere Anwendung, muss wissen, welchen Agent er in welcher Reihenfolge aufrufen soll. Dieses Wissen sickert überallhin und bindet die Aufrufer an die Interna.
Ein einziger Einstiegspunkt beseitigt das Problem:
User Request
│
▼
Supervisor Agent
│
▼
Planning Agent
│
▼
Structured Execution Plan
Hier verwandelt der Planning Agent eine allgemeine Geschäftsanfrage in einen strukturierten Plan, und der Supervisor steuert diesen Prozess. Der Supervisor führt nicht jeden Schritt selbst aus. Er darf nie zu einem riesigen Agent anwachsen, der alles erledigt. Seine Aufgabe ist Orchestrierung und sonst nichts.
Das ist ein echter Wendepunkt in der Architektur. Aus einem Haufen KI-Skripte wird allmählich eine durchdachte Multi-Agent-Plattform.
Der Supervisor koordiniert und delegiert
Stellen Sie sich eine Anfrage wie diese vor:
Analysiere die Quartalsfinanzberichte, vergleiche sie mit dem Vorjahr, benenne die größten Risiken und erstelle eine Zusammenfassung für die Geschäftsführung.
Ein Planning Agent könnte sie in kleinere Schritte zerlegen:
Business Request
│
▼
Planning Agent
│
▼
Execution Plan
│
├── Retrieval Agent
├── Research Agent
├── Analysis Agent
├── Report Agent
└── Quality Review Agent
Der Supervisor führt diesen Workflow von Anfang bis Ende. Strukturell sieht das am Ende so aus:
User
│
▼
Supervisor
│
▼
Execution Plan
│
▼
Agent Resolution
│
├── Retrieval Agent
├── Research Agent
├── Analysis Agent
├── Report Agent
└── Quality Review Agent
│
▼
Final Result
Der Supervisor fungiert als Control Plane. Die spezialisierten Agents sind die ausführenden Fähigkeiten, die er steuert.
Erst die Architektur, dann die Features
An diesem Punkt liegt es nahe, einfach weitere Agents hinzuzufügen. Besser ist es, zuerst das Fundament zu festigen.
Der Grund ist einfach. Wenn der Supervisor jeden spezialisierten Agent selbst baut, verschweißt er sich nach und nach mit jeder Implementierung. Im Pseudocode sähe das so aus:
Supervisor
├── Create PlanningAgent
├── Create RetrievalAgent
├── Create ResearchAgent
├── Create AnalysisAgent
├── Create ReportAgent
└── Create QualityReviewAgent
Bei fünf Agents geht das. Bei 25 wird es unangenehm, und bei 100 ist es ein echtes Problem:
- Jede neue Fähigkeit bedeutet, den Supervisor anzufassen.
- Eine Implementierung auszutauschen bedeutet, den Supervisor anzufassen.
- Tests werden schwerer zu schreiben und schwerer zu glauben.
- Die Orchestrierungsschicht sammelt Aufgaben an, die nie ihre sein sollten.
Genau diese Art von Kopplung vermeidet gutes Design.
Die Agent Registry
Die Lösung ist eine Agent Registry. Der Supervisor baut keine Agents mehr. Er fragt bei der Registry nach der Fähigkeit, die er braucht:
Supervisor Agent
│
▼
Agent Registry
│
┌───────────────────┼───────────────────┐
▼ ▼ ▼
Planning Agent Retrieval Agent Research Agent
│ │ │
▼ ▼ ▼
Analysis Agent Report Agent Quality Review Agent
Jetzt muss der Supervisor nicht mehr wissen, wie ein Agent erzeugt wird. Er kann schlicht sagen, was er will:
"Give me the retrieval-agent."
Die Registry ermittelt, welche Implementierung diese Anfrage bedient. Das ist ein Design im Stil von Factory plus Registry, und es zieht eine saubere Linie zwischen der Entscheidung, was passieren soll, und dem Wissen, wie es passiert.
Warum das in der Praxis zählt
Angenommen, ein Agent wird durch einen besseren ersetzt:
ResearchAgent
wird zu
DeepResearchAgent
Ohne Abstraktionsschicht müsste der Orchestrierungscode vermutlich angepasst werden. Mit einer Registry ändert man die Registrierung und sonst nichts. Die Schnittstelle des Supervisors bleibt genau wie vorher.
Supervisor
│
▼
"research-agent"
│
▼
Agent Registry
│
├── Today → ResearchAgent
│
└── Future → DeepResearchAgent
Der Supervisor fragt weiterhin nach derselben Fähigkeit, während das, was hinter diesem Namen steht, sich frei verbessern kann. Die Regel, an der man auf der ganzen Plattform festhalten sollte:
Auf Fähigkeiten und Verträge setzen, nicht auf konkrete Implementierungen.
Das Orchestrierungs-Framework austauschbar halten
Dieselbe Denkweise gilt eine Ebene höher. Die Plattform für immer an ein einziges Orchestrierungs-Framework zu binden, wäre ein Fehler. Eine dünne Abstraktionsschicht lässt Platz für Werkzeuge wie:
- LangGraph
- OpenAI Agents SDK
- Semantic Kernel
- CrewAI
Grob gesagt sitzt die Plattform über dieser Schicht:
Enterprise AI Platform
│
▼
Orchestration Abstraction
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
LangGraph OpenAI Agents SDK Semantic Kernel
│
▼
CrewAI
Man muss nicht alle von Anfang an implementieren. Es geht darum, die Grenzen an die richtigen Stellen zu setzen, damit das heute gewählte Framework nicht zu einer Beschränkung erstarrt, an der man später festsitzt.
Denken wie ein Platform Engineer
Die größte Umstellung im Kopf ist, das System nicht mehr als Sammlung von Agents zu sehen. Betrachten Sie es als Laufzeitumgebung für KI-Arbeit, als eigenständige Plattform. Die Agents sind spezialisierte Plugins auf dieser größeren Plattform, und die Plattform liefert die gemeinsame Mechanik, auf die sich alle stützen:
- Evaluierung und Observability
- Logging und Sicherheit
- Konfiguration und Gedächtnis
- Tool-Ausführung
- Orchestrierung und Workflow-Management
Das verändert die Form des Systems. Ein typisches frühes Design packt Infrastruktur in jeden einzelnen Agent:
Agent + Infrastructure
Agent + Infrastructure
Agent + Infrastructure
Agent + Infrastructure
Das Zieldesign zieht diese Infrastruktur heraus und teilt sie:
Shared Platform Infrastructure
│
┌────────────────────┼────────────────────┐
▼ ▼ ▼
Configuration Memory Observability
│ │ │
├────────────── Orchestration ────────────┤
│ │ │
▼ ▼ ▼
Security Evaluation Tool Layer
│
▼
Agent Registry
│
┌────────────────┼────────────────┐
▼ ▼ ▼
Agent A Agent B Agent C
Gemeinsame Fähigkeiten leben in der Plattform. Fachspezifische Geschäftslogik lebt in den Agents.
Von fünf Agents auf hundert
Bei Skalierung geht es nicht um die reine Zahl der Agents. Hundert eng gekoppelte Agents sind kein besseres Engineering als fünf saubere. Die Frage, an der sich ein Design wirklich messen lassen muss, lautet:
Was passiert mit der Architektur, wenn Agent Nummer 101 dazukommt?
Wenn ein Neuzugang Änderungen am Supervisor, eine zweite Kopie der Infrastruktur, ein neu geschriebenes Logging, neue Konfiguration und umgebaute Workflows erzwingt, skaliert das Design nicht sauber. Ein neuer Agent sollte über bereits bestehende Verträge andocken:
Implement Capability
↓
Use Shared Agent Framework
↓
Register Agent
↓
Expose Through Orchestration
↓
Test
↓
Deploy
Die Architektur sollte neue Fähigkeiten ohne größeres Redesign aufnehmen.
Der Supervisor beginnt die Geschichte, ist aber nicht das ganze Gehirn
Den Supervisor das Gehirn der Plattform zu nennen, ist als Bild praktisch, doch die Verantwortung ist bewusst auf mehrere Teile verteilt:
- Der Planning Agent entscheidet, welche Arbeit anfällt.
- Der Supervisor koordiniert, wie sie abläuft.
- Die Agent Registry bestimmt, welche Fähigkeit die Arbeit erledigt.
- Die spezialisierten Agents übernehmen die fachlichen Aufgaben.
- Plattformdienste stellen gemeinsame Infrastruktur bereit.
- Observability und Evaluierung halten fest und bewerten, was tatsächlich passiert ist.
Zusammen geben diese Teile der Plattform sowohl ihre Intelligenz als auch ihre operative Struktur.
User
│
▼
Supervisor
│
▼
Planning Agent
│
▼
Execution Plan
│
▼
Agent Registry
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
Retrieval Research Analysis
│ │ │
└──────────────────┼──────────────────┘
▼
Reporting
│
▼
Quality Review
│
▼
Final Result
───── Shared Platform Layer ───── Configuration • Memory • Security • Logging
Observability • Evaluation • Tools • Workflows
Die größere Lehre
Die wichtigste Erkenntnis aus dem Bau des Supervisors: KI-Architektur im Unternehmen ist kein Wettbewerb darum, wer die meisten Agents aufstellt. Es geht um Infrastruktur, mit der sich spezialisierte Fähigkeiten finden, koordinieren, austauschen, testen, beobachten und skalieren lassen, ohne das ganze System neu zu bauen.
Der Weg ist leicht zu erkennen:
Wiederverwendbares Framework → spezialisierte Agents → Supervisor → Agent Registry → dynamische Orchestrierung → verteilte Ausführung
Jeder Schritt verringert die Kopplung und gibt der Plattform mehr Raum zum Wachsen. Ob das System am Ende 5 Agents hat oder 100, das Ziel bleibt dasselbe:
Orchestrierung bleibt getrennt von Implementierung. Gemeinsame Infrastruktur bleibt getrennt von fachspezifischer Geschäftslogik.
Das ist der Sprung vom Bauen einzelner KI-Agents zum Engineering einer Multi-Agent-Plattform. Bauen Sie nicht einfach mehr Agents. Bauen Sie die Architektur, in die sich jeder künftige Agent mit möglichst wenig Aufwand einklinken, skalieren und verändern lässt.