Agent Router: ein Envoy-basiertes Steuerungszentrum für LLM- und Agent-Traffic

Ein Problem, das erst ab dem zweiten Anbieter entsteht

Solange eine Anwendung genau einen Modellanbieter mit genau einem Schlüssel anspricht, braucht sie keine Vermittlungsschicht. Sobald aber mehrere Teams, mehrere Modelle und mehrere Anbieter im Spiel sind, verteilen sich Zugangsdaten über Repositories, Routing-Regeln leben in Anwendungscode, und niemand kann sauber sagen, welches Team welches Kontingent verbraucht hat. Genau an dieser Stelle setzt Agent Router an. Das README beschreibt den Zweck so: eine konsistente, OpenAI-kompatible API für jedes Modell und Werkzeug, von gehosteten Anbietern bis zu selbst betriebener Inferenz und MCP-Servern. Die Zielgruppe sind damit zwei Rollen. Anwendungsteams sollen ihre Clients nicht umbauen müssen, wenn der Anbieter wechselt. Plattformteams sollen Zugangsdaten, Routing, Kontingente, Failover und Nutzungszuordnung an einer Stelle kontrollieren. Das ist kein Bibliothekspaket für eine einzelne Anwendung, sondern Infrastruktur für ein Cluster.

Zwei Ebenen: warum eine Gateway-Schicht nicht reicht

Das README nennt ein Zwei-Ebenen-Muster. Die Tier-One-Gateway ist der zentrale Einstiegspunkt und übernimmt Authentifizierung, Top-Level-Routing und globales Rate Limiting. Die Tier-Two-Gateway sitzt vor einem selbst betriebenen Modell-Cluster und regelt den feinkörnigen Zugriff auf diese Modelle, einschließlich Endpoint-Picker-Unterstützung zur Optimierung der LLM-Inferenz. Die Trennung ist sinnvoll, weil die beiden Ebenen unterschiedliche Fragen beantworten. Oben geht es um Mandanten, Schlüssel und Kontingente. Unten geht es um Lastverteilung zwischen Inferenz-Replikaten, die andere Skalierungs- und Latenzprofile haben als gewöhnliche HTTP-Dienste. Wer nur eine einzige Gateway-Ebene betreibt, muss beides in derselben Konfiguration vermischen. Eine Schwäche der Materialbasis ist, dass die Abbildung zur Referenzarchitektur nur als Bilddatei vorliegt und der Text die Endpoint-Picker-Funktion nicht weiter ausführt. Wie die Auswahl eines Endpunkts konkret konfiguriert wird, lässt sich aus dem README nicht ableiten.

Die API-Gruppe bleibt, der Name ändert sich

Das Projekt hieß früher Envoy AI Gateway und ist heute ein Projekt der Agentic AI Foundation. Für den Betrieb ist diese Umbenennung fast folgenlos, und das ist eine bewusste Entscheidung, die sich aus der Aufzählung im README ablesen lässt. Die CRDs AIGatewayRoute, AIServiceBackend und BackendSecurityPolicy bleiben ebenso unverändert wie die API-Gruppe aigateway.envoyproxy.io. Die CLI heißt weiterhin aigw, der Namespace envoy-ai-gateway-system ebenfalls. Container-Images, Helm-Charts und der Go-Modulpfad github.com/envoyproxy/ai-gateway wurden nicht umbenannt. Geändert haben sich das Repository und die Website, alte Links werden umgeleitet. Wer also Manifeste aus der Zeit vor der Umbenennung im Git liegen hat, muss sie nicht anfassen. Das ist in der Praxis der wichtigste Satz der ganzen Ankündigung.

Start auf dem Laptop, Deployment im Cluster

Der schnellste Einstieg ist ein Einzeiler, den das README zeigt: OPENAI_API_KEY=sk-your-key aigw run. Danach zeigt man einen beliebigen OpenAI-kompatiblen Client auf http://localhost:1975/v1. Das ist die Standalone-Variante, bei der Agent Router als lokaler Router fungiert. Für den produktiven Betrieb verweist das README auf den Getting-Started-Leitfaden und das Deployment auf Kubernetes mit Envoy Gateway. Die CLI-Dokumentation soll laut README auch die Installation und eine automatische Anbieterkonfiguration abdecken. An dieser Stelle ist der Text allerdings knapp: Die konkreten Konfigurationsschlüssel für Routing-Regeln, Kontingente und Failover stehen nicht im README, sondern nur in der verlinkten Dokumentation. Wer die Seite vor dem Ausprobieren liest, sollte mit den CRD-Namen rechnen, nicht mit YAML-Ausschnitten aus der Projektstartseite.

Anbieterbreite als eigentliche Entscheidungsgrundlage

Die Liste der unterstützten Dienste ist lang und gemischt. Sie umfasst OpenAI, Azure OpenAI, Google Gemini, Vertex AI, AWS Bedrock, Mistral, Cohere, Groq, Together AI, DeepInfra, DeepSeek, Hunyuan, SambaNova, Grok, Anthropic und den Tetrate Agent Router Service. Für Plattformteams ist das der Punkt, an dem sich die Adoption entscheidet. Ein Gateway, das den hauseigenen Anbieter nicht kennt, erzwingt entweder einen eigenen Backend-Typ oder einen Umweg über einen kompatiblen Endpunkt. Umgekehrt bedeutet eine breite Liste nicht, dass alle Anbieter gleich tief integriert sind. Das README zeigt Logos, keine Feature-Matrix. Ob ein bestimmter Anbieter Streaming, Werkzeugaufrufe oder bestimmte Authentifizierungsverfahren vollständig unterstützt, lässt sich daraus nicht beantworten. Diese Prüfung gehört vor die Entscheidung, nicht danach.

Wo das Projekt an seine Grenzen stößt

Agent Router ist ausdrücklich als Kontrollschicht über Envoy und Envoy Gateway gebaut, und daraus folgt die erste Einschränkung: Wer Envoy Gateway nicht betreiben will oder kann, für den ist das Projekt der falsche Hebel. Die Standalone-Variante mit aigw run mildert das für lokale Tests, ersetzt aber nicht die Kubernetes-Topologie, die das README für den Produktivbetrieb beschreibt. Zweitens bringt jede Vermittlungsschicht einen zusätzlichen Sprung im Anfragepfad mit. Das README macht keine Angaben zu Latenz oder Durchsatz, und ohne eigene Messung sollte man keine Zahlen annehmen. Drittens ist der Betrieb selbst ein System, das gepflegt werden muss: CRDs, ein Gateway-Controller, ein eigener Namespace. Für ein einzelnes Team mit einem Anbieter ist das mehr Beweglichkeit, als die Aufgabe verlangt. Der Nutzen skaliert mit der Zahl der Anbieter, Mandanten und Abrechnungsfragen, nicht mit der Zahl der Anfragen.

Der Unterschied zu einem einfachen SDK-Wrapper

Die naheliegende Alternative ist ein clientseitiger Wrapper: eine kleine Bibliothek, die Anbieter-Endpunkte und Schlüssel in der Anwendung kapselt und bei Bedarf zwischen ihnen umschaltet. Der Unterschied liegt nicht in der API-Form, denn beide Ansätze bieten eine OpenAI-kompatible Oberfläche. Er liegt im Ort der Durchsetzung. Ein Wrapper läuft im Prozess der Anwendung, kennt nur die eigenen Aufrufe und kann Kontingente nicht für ein ganzes Cluster durchsetzen. Agent Router verlagert diese Entscheidungen in Envoy, also in eine Schicht, die vor der Anwendung liegt. Damit werden Zugangsdaten aus den Anwendungen herausgezogen, Rate Limiting gilt einheitlich, und Nutzung lässt sich zentral zuordnen. Der Preis ist Betriebsaufwand und die Abhängigkeit von der Gateway-Konfiguration. Wer Anbieterwechsel nur gelegentlich braucht, fährt mit einem Wrapper einfacher. Wer sie für viele Teams gleichzeitig braucht, kommt mit einem prozessinternen Wrapper nicht weit.

Wartung, Versionen und Lizenz

Das Repository liegt unter Apache-2.0, was kommerzielle Nutzung und Änderungen erlaubt, solange Lizenz- und Urheberrechtshinweise erhalten bleiben. Das ist eine übliche und für Plattformteams unproblematische Wahl, ersetzt aber keine Rechtsberatung für den konkreten Fall. Bei den Versionen zeigt die Release-Historie v1.0.0 und v1.0.0-rc1 im Juni 2026 sowie v1.1.0 im August 2026. Der Sprung von der ersten stabilen Version zur nächsten dauerte rund zwei Monate, was auf einen regelmäßigen, aber nicht hektischen Rhythmus hindeutet. Das README selbst spricht von gleicher Release-Kadenz wie beim Vorgängerprojekt. Für die Upgrade-Kosten ist wichtig, dass die CRDs und die API-Gruppe stabil gehalten werden, denn genau dort entstehen sonst Migrationsarbeiten an den eigenen Manifesten. Wer die Version anhebt, sollte dennoch die Release Notes prüfen, weil das README keine Aussage über Deprecations oder Verhaltensänderungen zwischen v1.0.0 und v1.1.0 trifft.

Redaktionelles Fazit

Wer heute schon Envoy Gateway betreibt und mehrere Modellanbieter hinter einer einheitlichen, OpenAI-kompatiblen Schnittstelle zusammenführen will, findet hier ein Projekt mit klarer Arbeitsteilung: Agent Router steuert, Envoy trägt. Wer dagegen lediglich einen einzelnen Anbieter mit einem Schlüssel anspricht, braucht diese Kontrollschicht nicht, denn sie verlangt Envoy-Gateway-Wissen und eigene Kubernetes-Ressourcen. Vor dem ersten Rollout sollte man prüfen, ob die eigene Umgebung bereits Envoy Gateway nutzt, ob die benötigten Anbieter in der Liste der unterstützten Dienste stehen und ob die unveränderte API-Gruppe aigateway.envoyproxy.io zu den vorhandenen Manifesten passt.

Offizielle Quellen

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. theagentrouter/agent-router on GitHub