Ein Agent, der Tools aufrufen, Arbeit an einen weiteren Agenten übergeben und über Stunden laufen kann, ist nicht mehr bloß ein Prompt mit einem Modellaufruf. Er ist ein kleines verteiltes System mit Identitäten, Credentials, Budgets, Sessions, Provider-Auswahl und Richtlinien. Diese Belange brauchen einen Ort, der weder der vorübergehende Context des Modells noch jeder einzelne Anwendungsservice ist.

Dieser Ort wird zunehmend als Agent control plane bezeichnet: als Management- und Governance-Ebene, die von dem Code getrennt ist, der die Aufgabe eines Agenten ausführt. Der Begriff ist nützlich, aber kein vollständig standardisierter Architekturbegriff. Unterschiedliche Teams meinen damit unterschiedlich große Bereiche: eine zentralisierte Multi-Tenant-Verwaltung, ein Runtime-Policy-Gateway oder ein umfassenderes Management einer Agentenflotte. Beständig ist die Architekturgrenze, nicht ein vorgeschriebenes Produkt oder eine festgelegte Komponentengröße.

Einfach gesagt: Eine Agent Control Plane hält Regeln und Aufzeichnungen für den Betrieb von Agenten. Der Ausführungspfad erledigt die Arbeit; die Control Plane entscheidet, unter welchen Bedingungen diese Arbeit erlaubt ist und betrieben wird.

Diese Grenze wird greifbarer. Die Langfuse-Releases vom 11. September ergänzten Arbeiten an Gateway-Kontrollen auf Organisationsebene, benutzerausgelöste Session-Revoke-Funktionen, Evaluator-Kontrollen und -Historie, Verbesserungen der Session-Timeline, Trusted-Execution-Resolution und die Zuordnung von Provider-Verbindungen. Das sind operative Fähigkeiten, die über einzelne Modellaufrufe hinaus bestehen, und keine Funktionen eines einzelnen Prompts oder Tool-Aufrufs. Langfuse v4.34.0 und v4.35.0 zeigen, wie sich diese Grenze herausbildet; sie belegen keine universelle Implementierung.

Was eine Agent Control Plane steuert

Ein Agentensystem besitzt eine Execution Plane: den Pfad, der eine Anfrage annimmt, Context zusammenstellt, ein Modell aufruft, Tools aufruft und ein Ergebnis zurückgibt oder speichert. Dort findet das fachliche Verhalten statt. Ein Support-Agent könnte ein Konto nachschlagen, ein Coding-Agent ein Repository untersuchen und ein Hintergrund-Agent einen Bericht vorbereiten.

Daneben liegt die Control Plane. Sie besitzt dauerhaften Managementzustand: Welche Organisation eine Anfrage besitzt, welche Agent-Konfiguration aktiv ist, welche Provider-Verbindungen zulässig sind, welche Richtlinien gelten, ob eine Session noch gültig ist und welche Evaluator-Version ein Ergebnis bewerten soll. Sie kann außerdem Nutzungs- und Metering-Daten für Kapazitätsplanung oder interne Verrechnung führen.

Ein Tenant ist eine Organisation oder ein Kunde, deren Daten, Konfiguration und Berechtigungen von anderen getrennt bleiben müssen. AWS ordnet der Control Plane Konfiguration, Tenant- und Agent-Observability, Verbrauch und Metering sowie Tenant-Richtlinien zu und grenzt sie von der Application Plane ab. AWS nennt außerdem Tenant-Identität, Ressourcenbereitstellung pro Tenant, Anwendung von Routen und Geltungsbereichen sowie Authentifizierung und Autorisierung zwischen Agenten als Onboarding-Belange. AWS Prescriptive Guidance verwendet diese Einordnung für Multi-Tenant-Umgebungen.

Das bedeutet nicht, dass jeder Agent von Beginn an eine zentralisierte Plattform braucht. Ein einzelner interner Workflow benötigt vielleicht nur einen Konfigurationseintrag, eine Zugriffsprüfung und einen sauberen Audit-Trail. Die Trennung wird wichtig, wenn dieselben Entscheidungen über mehrere Agenten, Worker, Modell-Provider und Tenants hinweg konsistent sein müssen.

Warum gerade jetzt: Vorübergehender Context ist die falsche Datenbank

Modelle arbeiten mit vorübergehendem Context: den Anweisungen, Nachrichten, abgerufenen Materialien und Tool-Ergebnissen, die für eine Inference bereitgestellt werden. Context ist leistungsfähig für Schlussfolgerungen, aber ein schlechter Ort für dauerhaften Betriebszustand. Er kann gekürzt oder bei Retries anders zusammengestellt werden und kann selbst keine Tenant-Grenze zuverlässig erzwingen oder eine bereits ausgestellte Session widerrufen.

Stell dir eine Anfrage an einen interaktiven Agenten vor. Vor der Ausführung muss die Plattform möglicherweise die Tenant-Identität bestimmen, die zulässige Agent-Version auflösen, einen freigegebenen Modell-Provider auswählen, einen Satz Richtlinien laden, kurzlebige Credentials ausstellen und prüfen, ob die angeforderte Session noch aktiv ist. Der Execution Worker führt die Aufgabe anschließend anhand dieser Entscheidungen aus. Danach kann das System Nutzungs- und Evaluationsergebnisse denselben Identitäten und Konfigurationsversionen zuordnen.

Einfach gesagt: Bewahre langlebige Fakten – wer was, für wen und unter welchen Regeln ausführen darf – außerhalb des Chatverlaufs auf. Übergib jedem Run nur die nötigen Entscheidungen.

Diese Trennung macht Änderungen sicherer. Du kannst eine Provider-Verbindung oder eine Organisationsrichtlinie ändern, ohne die Änderung mit Repository-spezifischer Fachlogik zu vermischen. Du kannst die Session eines Nutzers widerrufen, ohne ein Modell bitten zu müssen, einen Satz in seinem Context zu beachten. Und du kannst Ergebnisse zweier Evaluator-Versionen vergleichen, ohne ältere Scores als Messungen desselben Maßstabs zu behandeln.

Wie die Grenze Schritt für Schritt funktioniert

Ein praktisches Design einer Control Plane beginnt gewöhnlich bei der Annahme einer Anfrage. Ein API-Gateway oder Service empfängt eine Anfrage und authentifiziert den Aufrufer. Die Control Plane ordnet diese Identität einem Tenant, Rollen, Scopes und einem zulässigen Agenten oder Workflow zu. Sie löst die Konfiguration auf: etwa eine bestimmte Modellverbindung, einen freigegebenen Satz Tools, ein Ausgabenlimit und eine Richtlinienversion.

Die Execution Plane erhält statt einer vagen globalen Konfiguration einen engen Ausführungsvertrag. Dieser Vertrag kann Tenant, gewählte Agent-Version, erlaubte Ressourcen, Session-ID, Richtlinienreferenzen und Korrelations-IDs benennen. Der Worker führt weiterhin Modell-Inference und Tool-Aufrufe aus. Entscheidend ist, dass er nicht stillschweigend entscheiden sollte, zu einem anderen Tenant zu gehören oder eine nicht freigegebene Provider-Verbindung zu ersetzen.

Provider Routing ist ein gutes Beispiel. Es bedeutet, den Modellservice oder Endpoint für eine Ausführung anhand verwalteter Regeln und Metadaten auszuwählen. Ein Model Gateway vereinheitlicht oder routet primär Inference-Anfragen. Es kann Teil einer Control Plane sein, ist aber nicht die ganze Sache: Eine weiter gefasste Ebene behandelt auch Sessions, Identitäten, Richtlinien, Evaluations und administrativen Zustand. Die Langfuse-Release-Notes nennen ausdrücklich Trusted-Execution-Resolution und die Zuordnung von Provider-Verbindungen im AI Gateway. Langfuse v4.35.0

Der Session Lifecycle verdient dieselbe Behandlung. Erstellung, Widerruf, Wiederherstellung, Timeout und Beendigung einer Session sind operative Übergänge, kein generierter Text. Wird eine Session widerrufen, brauchen alle Ausführungspfade, die ihr Credential akzeptieren, eine konsistente Antwort. Ein lang laufender Hintergrund-Task benötigt ebenfalls festgelegtes Verhalten: sicher abschließen, einen Checkpoint setzen, stoppen oder in einen für Operatoren sichtbaren Prüfzustand wechseln. Der benutzerausgelöste Session-Widerruf in Langfuse v4.34.0 zeigt, warum dies in dauerhaften Plattformzustand gehört. Release Notes

Schließlich zeichnet die Ebene Entscheidungen und Ergebnisse auf. Semantic Observability bedeutet, nicht nur Latenz und Fehler zu beobachten, sondern auch, was ein Agent versucht hat, welche Tools er aufgerufen hat und ob er ein aufgabenbezogenes Qualitätsmaß erfüllt hat. Die GenAI Semantic Conventions von OpenTelemetry bieten einen standardisierten Telemetrie-Wortschatz für KI- und Agentensysteme; sie sind eine Hilfe für Interoperabilität, keine Architektur für eine Control Plane. OpenTelemetry Die Control Plane kann solche Daten mit Tenant-, Konfigurations-, Session-, Provider- und Richtliniendaten verknüpfen.

Was sie nicht ist

Eine Control Plane ist kein Agent Harness. Ein Harness steuert normalerweise einen einzelnen Agent-Loop: Er stellt Context zusammen, ruft ein Modell auf, behandelt Retries und ruft Tools auf. Eine Control Plane regelt gemeinsamen, Run-übergreifenden Zustand rund um viele solche Loops. Gerade am Anfang kannst du einen guten Harness ohne eine umfassende Control Plane haben.

Sie ist auch nicht nur Capability Mediation. Capability Mediation ist die Sicherheitsentscheidung darüber, ob ein Agent eine bestimmte Ressource oder ein Tool aufrufen darf. Eine Control Plane kann diese Entscheidung konfigurieren und auditieren, aber Sessions, Evaluator-Verwaltung, Metering und Provider-Zuordnung sind weiter gefasste Belange.

Ebenso ist sie nicht selbst die Evaluation. Evaluation ist die systematische Messung des Verhaltens eines Agenten anhand definierter Kriterien. Eine Control Plane kann Evaluator-Definitionen versionieren, Score-Historien bewahren und entscheiden, wo Evaluations gelten. Sie macht einen Agenten nicht allein dadurch korrekt, dass sie mehr Scores speichert. Semantische Qualität bleibt eine Aufgabe der Anwendung mit Testfällen, Review und Schutzmechanismen.

Einfach gesagt: Die Control Plane denkt nicht für den Agenten. Sie macht den Betrieb von Agenten steuerbar und die Entscheidungen rund um einen Run nachvollziehbar.

Ein praktisches Beispiel: eine interne Coding-Plattform

Stell dir ein Unternehmen mit einem interaktiven Coding-Agenten und einem Hintergrund-Agenten für Pull-Request-Reviews vor. Beide können Repositories lesen; nur der Review-Agent darf einen Kommentar veröffentlichen. Mehrere Geschäftsbereiche nutzen die Plattform, und verschiedene Projekte haben unterschiedliche Modellbudgets und freigegebene Integrationen.

Ohne eine Control Plane könnte jeder Agent-Service eine eigene Kopie von Projektzuordnung, Credential-Lookup, Modellauswahl und Budgetlogik enthalten. Ein Session-Widerruf könnte den interaktiven Service erreichen, aber nicht einen eingeplanten Review-Job. Eine Provider-Umstellung könnte in einem Codepfad geändert und in einem anderen übersehen werden. Evaluation-Scores könnten gespeichert werden, ohne festzuhalten, welche Rubrik sie erzeugt hat.

Mit einer Control Plane erstellt das Onboarding eine Tenant-Identität, ordnet Projekte und Scopes zu, registriert freigegebene Provider-Verbindungen und hängt Richtlinien an. Wenn ein Review-Job startet, erhält er einen Ausführungsvertrag: Tenant, Repository-Geltungsbereich, Agent-Version, erlaubte Tool-Fähigkeiten, Provider-Route und Budget. Der Review-Worker erledigt die eigentliche Aufgabe. Sein Trace und seine Nutzungsdaten kehren mit den aufgelösten Identifikatoren zurück; ein Evaluator kann die Ausgabe danach anhand der richtigen versionierten Kriterien vergleichen.

Dieses Design verlangt weder eine einzelne Datenbank noch eine einzelne Runtime. Es verlangt, dass die Zuständigkeit für operative Fakten explizit ist. Für eine kleine Plattform können das einige Services und sorgfältig versionierte Datensätze sein. In einer Multi-Provider-Umgebung kann es die Föderation mehrerer Provider-eigener Control Planes erfordern. AWS weist darauf hin, dass solche Umgebungen getrennte Control Planes mit unvollständiger Autorität übereinander enthalten können; Verträge zu Vertrauen, Identität, Richtlinien und Lifecycle müssen deshalb explizit sein. AWS Prescriptive Guidance

Wo das Design scheitert

Zentralisierung schafft ein wertvolles Angriffsziel und eine Abhängigkeit. Kann ein sicher laufender Job fertig werden, wenn die Control Plane nicht verfügbar ist? Darf eine schreibgeschützte Anfrage mit einem gecachten Vertrag weiterlaufen? Das sind Produkt- und Sicherheitsentscheidungen, keine Implementierungsdetails. Autorisierungsfehler dort können jeden Agenten zugleich betreffen.

Auch Zustandskonsistenz ist unbequem. Ein Widerruf muss korrekt mit bereits eingeplanter oder laufender Arbeit konkurrieren. Provider-Failover kann Verhalten und Kosten ändern. Eine Session-Timeline muss bei Fehlern nicht exakt der Event-Zustellung entsprechen. Entwirf diese Dinge als explizite Zustandsübergänge mit Identifikatoren, Verantwortlichkeiten, Retries und Audit-Aufzeichnungen – nicht als aus einem Modelltranskript abgeleitete Schlussfolgerungen.

Datenschutz ist eine weitere Grenze. Zentralisierte Traces, Scores, Nutzungs- und Tenant-Metadaten können Pflichten zu Aufbewahrung und Datenresidenz schaffen. Erhebe genug Daten für einen sicheren Betrieb, definiere klare Aufbewahrungsregeln und behandle Observability nicht als Erlaubnis, beliebige Nutzerinhalte aufzubewahren.

Was du diese Woche tun kannst

Zeichne zuerst in einem vorhandenen System die Grenze ein. Erstelle zwei Spalten: Entscheidungen der Ausführung während eines Runs und dauerhafte operative Entscheidungen, die ihn überleben sollen. Identität, Richtlinienzuordnung, Session-Status, Provider-Verbindungen, Evaluator-Versionen und Nutzungsabrechnung gehören im Allgemeinen in die zweite Spalte.

Definiere zweitens für einen Workflow einen Ausführungsvertrag. Beginne nicht mit einer riesigen Plattform. Entscheide, was ein Worker erhalten muss, wer es auflöst und welche Felder der Worker nicht überschreiben darf. Nimm Tenant- und Scope-IDs von Anfang an auf.

Mache drittens Session-Widerruf testbar. Halte das erwartete Ergebnis für einen aktiven interaktiven Run, einen eingeplanten Task und einen lang laufenden Worker nach einem Widerruf fest. Wichtig ist nicht ein universelles Verhalten, sondern eines, das bewusst gewählt, erzwingbar und für Operatoren sichtbar ist.

Versioniere viertens deine Evaluation-Konfiguration zusammen mit der Agent-Konfiguration. Bewahre die Identität des Evaluators bei jedem Score. Diese kleine Disziplin verhindert einen häufigen Betriebsfehler: Ergebnisse verschiedener Maßstäbe zu vergleichen, als wären sie eine Kennzahl.

Instrumentiere schließlich die Grenze mit stabilem Telemetrie-Vokabular, wo es hilft. Die GenAI Conventions von OpenTelemetry können gemeinsame Korrelation zwischen Komponenten unterstützen, während Architektur- und Richtlinienentscheidungen bei deinem System bleiben. OpenTelemetry Das Ziel ist nicht die Behauptung, jeder Agent brauche eine Control Plane. Es geht darum, bereichsübergreifende operative Autorität nicht länger in Prompts, Workern und verstreuter Konfiguration zu verstecken.