Steuerung von KI-Agenten auf mehreren Plattformen

Die meisten Unternehmen haben sich nicht bewusst dafür entschieden, KI-Agenten auf fünf Plattformen einzusetzen. Es ist einfach passiert. Microsoft Copilot kam mit der Produktivitätssuite. ServiceNow lieferte Now Assist in die Ticket-Warteschlange. Salesforce aktivierte Agentforce im CRM. Andere Daten- und SaaS-Plattformen begannen, Agenten neben den Systemen der Aufzeichnung zu betreiben. Jede Plattform brachte ihre eigene KI-Laufzeitumgebung mit – und, stillschweigend, ihre eigene Governance-Strategie, die an der Grenze der Plattform endet.

Das Ergebnis ist eine Governance-Lücke, die für einen einzelnen Anwendungsplattform-Anbieter allein schwer zu schließen ist. Wenn ein Agent innerhalb einer Plattform eine API aufruft, wer hat das autorisiert? Wenn ein Agent in einer anderen Plattform ein sensibles Dokument zusammenfasst, welche Richtlinie hat die Antwort gesteuert? Und wenn sich ein Agent im Produktivbetrieb falsch verhält, wer kann ihn schnell eindämmen – ohne die Koordination über mehrere Anbieterkonsolen oder Support-Warteschlangen hinweg?

Dies ist kein zukünftiges Risiko. Es ist die operative Realität für jede Organisation, die mehr als eine KI-Plattform unabhängig voneinander eingeführt hat – was in großen Unternehmen immer häufiger vorkommt.

Die Struktur des Problems

Bevor man über eine Lösung spricht, sollte man genau darlegen, warum dies wirklich schwierig ist. Die Schwierigkeit ist strukturell und zeigt sich an vier Stellen gleichzeitig.

Und es gibt ein fünftes Problem, das erst in dem Moment sichtbar wird, in dem ein Benutzer tatsächlich versucht, etwas zu tun mit einem Drittanbieter-Agenten: der Anmeldedaten-Aufwand.

Der verborgene Anmeldedaten-Aufwand

Man stelle sich eine routinemäßige Anfrage vor, die an einen offiziellen Drittanbieter-Agenten gesendet wird, der in einem Copilot-ähnlichen Assistenten installiert ist. Wenn ein Benutzer ihn zum ersten Mal nutzt, kann der Agent erst antworten, nachdem sich der Benutzer direkt bei diesem Drittanbieterdienst angemeldet hat.

Dies ist kein Fehler. Es ist die einzig sichere Architektur, wenn jeder Agent ein separat vertriebenes Produkt ist. Doch im gesamten Tool-Inventar eines Unternehmens gestapelt, hat dies echte operative Konsequenzen:

• Reibungsverluste pro Benutzer und pro Tool. Jeder Mitarbeiter autorisiert jeden Agenten bei der ersten Nutzung erneut. Multiplizieren Sie dies mit der Belegschaft und dann mit dem Tool-Inventar.
• Token-Wildwuchs. OAuth-Tokens für jeden verbundenen Dienst landen verstreut in den Benutzeridentitätsspeichern. Compliance wird zu einer Frage pro Anbieter anstatt eines einzigen Audit-Trails.
• Keine zentrale Widerrufmöglichkeit. Wenn sich ein Vertrag ändert oder ein Vorfall das Abschneiden des Zugangs erfordert, verfolgt die Organisation dies über jede Anbieterbeziehung, anstatt an einer zentralen Stelle.

Wie eine plattformübergreifende Steuerungsebene funktionieren kann

Ein Architekturmuster, das diese Lücke direkt schließt, ist die Steuerung auf der Ebene, die all diese Plattformen gemeinsam haben. Jeder Agent, unabhängig davon, welche Plattform ihn hostet, führt letztendlich einen LLM-Aufruf oder einen Tool-Aufruf aus. Abfangen und steuern dort, und Sie steuern die Agentenaktivität, die über diese gemeinsame Ausführungsebene geleitet wird — ohne jede Anwendungsplattform aufzufordern, sich neu aufzubauen.

Dies ist die Prämisse hinter TrueFoundry’s Agent Gateway: eine dedizierte Steuerungsebene für KI-Agenten in der Produktion, die vor den Modellen und Tools sitzt, von denen jeder Agent abhängt. TrueFoundry zieht eine klare Grenze zwischen einem KI-Gateway, das zustandslose Prompts und Tokens verwaltet, und einem Agenten -Gateway, das die Datenebene für agentische KI darstellt — zustandsbehaftete Sitzungen, mehrstufige Ausführung und die Daten, die sich zwischen Agenten und ihren Tools bewegen. Es verhält sich wie ein Service Mesh, das speziell für agentische Systeme entwickelt wurde.

Über den Gateways befindet sich eine vierte Ebene: das Agent Harness. Ein Harness ist die Laufzeitumgebung um ein LLM — die Orchestrierungsschleife, die plant, Tools aufruft, den Kontext verwaltet, sensible Aktionen durch Genehmigungen absichert und jeden Schritt in einem Trace aufzeichnet. Es ist das, was einen Modellaufruf in einen zuverlässigen, langlebigen Agenten verwandelt.

TrueFoundry liefert dies als Managed Service statt als Framework. Eine sandboxed Ausführungsumgebung führt Code und langlaufende Aufgaben aus. Genehmigungs-Gates mit menschlicher Beteiligung pausieren sensible Tool-Aufrufe, bis ein Benutzer sie genehmigt. Ein versioniertes Skills Registry enthält wiederverwendbare Anweisungen mit RBAC. Und entscheidend ist — keine API-Schlüssel oder Anmeldeinformationen befinden sich jemals in Agenten-Definitionen; sie leben in den Gateways, wo Plattformteams den Zugriff einmal konfigurieren und Agenten-Entwickler niemals Geheimnisse berühren.

Entscheidend ist, dass die Erkennung nicht auf Agenten beschränkt ist, die Sie auf der Plattform erstellt haben. Agenten, die anderswo laufen — auf Bedrock, LangGraph, einem benutzerdefinierten HTTP-Dienst oder der Plattform eines anderen Anbieters — registrieren sich im selben Inventar wie Remote-Agenten, mit denselben Metadaten und denselben Kontrollen. Die fragmentierte Flotte wird zu einer einzigen Karte.

04Fünf Funktionen, auf die man achten sollte

Für Teams, die bewerten, wie diese Lücke geschlossen werden kann, sind die folgenden fünf Funktionen einer genauen Prüfung wert — mit einem Hinweis darauf, was jede einzelne unter der Haube tendenziell erfordert.

‍