Die AI-Gateway-Landschaft: agentgateway, LiteLLM und Kong

Hinweis: Dieser Beitrag wurde aus dem Englischen übersetzt. Fachbegriffe, Code und Befehle wurden bewusst im Original belassen.

Hier betritt das AI Gateway die Bühne. In diesem Beitrag schauen wir gemeinsam, wo agentgateway als cloud-native bzw. AI-native Option einzuordnen ist und wie es sich gegenüber LiteLLM und den übrigen Gateways schlägt, die Plattformteams 2026 evaluieren.

Die zwei Herkunftslinien

Die heutigen AI Gateways stammen aus einer von zwei Ausgangslagen:

1. LLM-Request-first-Gateways wie LiteLLM, Portkey, Bifrost oder Cloudflare AI Gateway. Sie sind aus dem Problem entstanden: „Ich brauche eine API vor über 100 Modellanbietern" – und haben Routing, Budgets, virtuelle Schlüssel und Observability ergänzt.

1. Traffic-Infrastructure-first-Gateways wie Kong AI Gateway, Envoy AI Gateway (kgateway), Apigee, F5 und agentgateway. Sie gehen von einem bestehenden (oder neu gebauten) L7-Proxy bzw. einer Data Plane aus und erweitern diese so, dass sie KI-spezifischen Traffic versteht: Tokens, Prompts, Tool-Aufrufe und nun auch Agentenprotokolle.

agentgateway gehört klar ins zweite Lager – allerdings mit einer Besonderheit: Statt KI-Verständnis auf einen bestehenden Proxy aufzusetzen, haben seine Entwickler eine neue Data Plane von Grund auf in Rust gebaut. Genau deshalb, weil sie zu dem Schluss kamen, dass der erste Ansatz nicht trägt, sobald MCP- und A2A-Traffic ins Spiel kommen.

Ich betrachte es als die Lösung für ein agentisches, massiv skaliertes System auf Enterprise-Niveau.

Was agentgateway tatsächlich ist

agentgateway ist ein Open-Source-Proxy, inzwischen unter dem Dach der Linux Foundation (über die Agentic AI Foundation), der im Wesentlichen vier Arten von Traffic bedient:

• Service-Traffic: einfaches HTTP/gRPC/TCP – also das, was ein gewöhnliches API Gateway oder Envoy abwickelt: mTLS, OIDC, Retries, Timeouts.

• LLM-Traffic: eine OpenAI-kompatible Eingangstür zu OpenAI, Anthropic, Bedrock, Gemini, Vertex, Azure OpenAI und einer langen Liste weiterer Anbieter – mit Credential-Verwaltung, Failover, Budgets und semantischem Caching.

• MCP-Traffic: behandelt als vollwertiges, zustandsbehaftetes Protokoll statt als generischer HTTP-Durchreicher – mit Tool Discovery, Föderation über mehrere Backend-MCP-Server hinweg, RBAC je Tool und Audit-Logging.

• A2A-Traffic: Agent-zu-Agent-Aufrufe über Frameworks wie LangChain, CrewAI und Google ADK – mit eingebauter Identität und Tracing.

Die Integrationsschicht von agentgateway

Ohne allzu tief einzusteigen: Die architektonisch bemerkenswerte Aussage betrifft MCP. MCP ist JSON-RPC über eine langlebige, bidirektionale Sitzung. Ein Client öffnet also eine Verbindung, der Server kann asynchron Nachrichten zurückschicken, und ein einzelner „list tools"-Aufruf muss unter Umständen auf mehrere Backend-MCP-Server ausfächern und die Ergebnisse zu einer stimmigen Antwort zusammenführen – je Sitzung begrenzt auf das, was der jeweilige Client tatsächlich sehen darf. Klassische Gateways, Envoy eingeschlossen, wurden unter der Annahme kurzlebiger, zustandsloser Request-Response-Zyklen gebaut; dieses Muster lässt sich daher nicht sauber auf ihr Data-Plane-Modell abbilden. Der bislang branchenübliche Behelf besteht darin, einen ext_proc-Sidecar (häufig in Go geschrieben) an Envoy anzuflanschen, um die fehlende Sitzungslogik nachzurüsten – ein unabhängiger Review des agentgateway-Designs bezeichnete die Ergebnisse in der Praxis als „mittelmäßig".

Die Antwort von agentgateway ist eine eigens gebaute Rust-Data-Plane, die Sitzungen als vollwertige Bürger behandelt und Erkenntnisse aus Solo.ios ztunnel (dem sidecar-losen Proxy hinter Istio Ambient Mesh) wiederverwendet, statt zu versuchen, Zustandsbehaftung auf Envoys Cluster-/Listener-Modell aufzupfropfen. Zudem nutzt es ein eigenes, von xDS abgeleitetes Control-Plane-Protokoll, statt Envoys Listener-/Cluster-/Route-Typen zu übernehmen – ausdrücklich damit eine Policy-Änderung an einem einzelnen Feld nicht dazu führt, dass megabyteweise Route-Konfiguration an jede Proxy-Instanz erneut ausgerollt werden muss. Letzteres kann in großen Envoy-Deployments ein echter Schmerzpunkt im Betrieb sein.

Und noch etwas habe ich gerade gelernt: Solo.io hat die AI-Data-Plane des eigenen kgateway-Projekts bereits von Envoy+ext_proc auf agentgateway umgestellt – ein deutliches Signal, wo der Aufsatz-Ansatz aus ihrer Sicht an seine Grenzen stößt.

Was LiteLLM tatsächlich ist

Sehen wir uns nun LiteLLM an und wie es das Problem von der entgegengesetzten Seite angeht. Es handelt sich um eine MIT-lizenzierte Python-Bibliothek samt Proxy-Server, deren Kernabstraktion lautet: „ein OpenAI-kompatibler Endpunkt vor über 100 (tatsächlich wohl eher über 140) Modellanbietern". Betreiben lässt es sich als:

• Python-SDK, direkt in Ihre Anwendung importiert, oder

• eigenständiger Proxy-Server, hinter einem Load Balancer betrieben, gestützt auf Postgres (für virtuelle Schlüssel, Teams und Ausgabenerfassung) und optional Redis (für verteilte Rate Limits und Routing-Zustand).

Und es bringt viele Funktionen mit: virtuelle Schlüssel, Budgets je Team und Schlüssel, Load Balancing, automatische Fallback-Ketten, Response-Caching, eine Admin-Oberfläche sowie Export-Hooks nach Langfuse, Prometheus und OpenTelemetry. So hat es sich für sehr viele Teams zum Standardeinstieg entwickelt. Die Installationsbasis ist sehr groß, und das Ökosystem aus Tutorials, Terraform-Modulen und Integrationen entsprechend tief.

Die LiteLLM-Oberfläche

LiteLLM bringt allerdings auch Kompromisse mit:

• Es skaliert als Request-Router, nicht als zustandsbehafteter Protokoll-Proxy. MCP-Unterstützung existiert, doch MCP und A2A wurden auf ein Designzentrum aufgesetzt, das nach wie vor „die Completion-Anfrage an ein Modell" ist – nicht die langlebige Sitzung.

• Pythons GIL und Garbage Collection setzen dem reinen Durchsatz eine Grenze, verglichen mit Alternativen auf Rust- oder Go-Basis. Das zeigt sich in unabhängigen wie in herstellereigenen Benchmarks, in denen LiteLLM unter Dauerlast durchgängig hinter Kongs Nginx-/Lua-basierter Data Plane und hinter neueren Go-basierten Anbietern wie Bifrost landet.

• Die Angriffsfläche in der Lieferkette ist ein reales Betriebsthema. Im März 2026 bestätigte LiteLLM, dass zwei PyPI-Releases über eine kompromittierte CI-Abhängigkeit manipuliert worden waren und rund 40 Minuten lang eine Payload zum Abgreifen von Zugangsdaten auslieferten, bevor der Vorfall entdeckt wurde. Eine nützliche Erinnerung daran, dass „einfach den Proxy per pip installieren" dieselbe Lieferketten-Angriffsfläche mitbringt wie jedes andere schnelllebige PyPI-Paket – und das hat manche Produktivumgebungen zu gepinnten, signierten Image-Tags und konservativeren Upgrade-Rhythmen bewegt. (Das kann auch anderen Programmiersprachen und deren Ökosystemen passieren, doch Skriptsprachen trifft es häufiger.)

Nichts davon macht LiteLLM zu einer schlechten Wahl. Es ist ein ausgereiftes, extrem weit verbreitetes Stück Infrastruktur – und für die meisten Teams, deren Problem tatsächlich lautet „LLM-Completion-Aufrufe vereinheitlichen und steuern", bleibt es einer der schnellsten Wege ans Ziel.

Kurz gesagt: LiteLLM und agentgateway setzen auf unterschiedliche architektonische Wetten.

Wo der Rest des Feldes steht

Ein paar weitere Namen tauchen in jeder dieser Bewertungen auf und gehören auf dieselbe Landkarte:

Zwei Beobachtungen zur Landschaft, die Mitte 2026 die Perspektive verändern:

• Portkey hat der Übernahme durch Palo Alto Networks zugestimmt (angekündigt am 30. April 2026), was mittelfristig eine Eingliederung in Prisma AIRS wahrscheinlich macht 👉 relevant, falls Sie auf Portkeys unabhängige Roadmap setzen.

• Envoy AI Gateway und agentgateway konvergieren, statt zu konkurrieren – zumindest innerhalb des Solo.io-/kgateway-Ökosystems: kgateway (das CNCF-gehostete, Envoy-basierte Kubernetes-Gateway) übernimmt agentgateway als KI-spezifische Data Plane, statt Envoy dafür weiter zu erweitern. Wenn Sie „Envoy AI Gateway" evaluieren, lohnt die Prüfung, ob das betrachtete Projekt diesen Schritt bereits vollzogen hat.

• Herstellereigene Benchmarks (Kongs Vergleich mit Portkey und LiteLLM, Solos Vergleich mit Envoy+ext_proc) sollten als grobe Orientierung gelesen werden, nicht als neutral. Jeder wurde von dem Projekt durchgeführt, das er begünstigt – und auf jener Lastform, die dessen Architektur schmeichelt.

Praktische Empfehlungen

Greifen Sie zu LiteLLM (oder Bifrost), wenn: Ihr Problem klar lautet „N Anbieter hinter einem Endpunkt vereinheitlichen, mit Budgets und Fallbacks", Sie das größte Ökosystem und den schnellsten Weg zu einem funktionierenden Proxy wollen und MCP-/A2A-Traffic heute nur einen kleinen Teil Ihres Aufkommens ausmacht. Genau das sehen wir sehr häufig in der Praxis – und es führt schnell zu verlässlichen Integrationen.

Greifen Sie zu Kong oder Portkey, wenn: Sie ein fertiges Produkterlebnis ($$$) mit Dashboards, Guardrails und Prompt-Management wollen und entweder Kong bereits für API-Management betreiben oder eine gemanagte bzw. gehostete Control Plane bevorzugen, statt eine weitere Komponente selbst zu betreiben.

Greifen Sie zu agentgateway, wenn: Sie sich bereits in einer Kubernetes-/Envoy-/Istio-Welt bewegen (oder darauf zusteuern), MCP-Tool-Serving und Agent-zu-Agent-Traffic zum Kern Ihrer Architektur gehören statt nachträglich ergänzt zu werden, und Sie eine Data Plane wollen, die sich nicht wie drei zusammengeflickte Gateways anfühlt. Für mich ist es die Ingenieurs- und Skalierungswahl, da es Service-Mesh-Traffic, LLM-Routing und Agentenprotokolle mit einheitlicher Policy, Identität und Observability integriert und abwickelt. Beachten Sie, dass es deutlich jünger ist: Rechnen Sie mit schnell wechselnder Dokumentation, gelegentlichen Abweichungen zwischen Funktionsumfang und Doku – typisch für ein Projekt in frühem Stadium – sowie einem xDS-basierten Konfigurationsmodell mit Lernkurve, falls Sie nie mit Control Planes im Envoy-Stil gearbeitet haben.

Weiterführende Quellen

• agentgateway.dev und das zugehörige GitHub-Repository

• LiteLLM auf GitHub und die Proxy-Dokumentation

• Solo.io, „Why Traditional Gateways Failed AI Workloads"

• Kong, „AI Gateway Benchmark: Kong AI Gateway, Portkey, and LiteLLM"