agentgateway (voorheen Gloo AI Gateway): een eerlijke review van Solo.io's AI-gateway

Zoek vandaag naar Gloo AI Gateway en solo.io stuurt u ergens anders heen: de oude productpagina op solo.io/products/gloo-ai-gateway omleid naar agentgateway. Achter de omleiding heeft Solo zijn AI-gatewayfuncties verplaatst van Envoy naar een nieuwe proxy gebouwd voor MCP- en agent-verkeer.

Dat staat in de aankondigingen van Solo. We wilden weten wat de gateway daadwerkelijk doet, dus we hebben hem zelf gedraaid en het gedrag gecontroleerd dat er toe doet in productie, met versienummers waar een resultaat daarvan afhangt. Als u Solo vergelijkt met het bredere veld, behandelt ons overzicht van Solo.io-concurrenten en alternatieven die onderwerpen. Dit bericht richt zich uitsluitend op de gateway zelf.

agentgateway (voorheen Gloo AI Gateway) review in één oogopslag

Wat is er gebeurd met Gloo AI Gateway

De AI-gatewayfuncties van Solo draaiden voorheen op Gloo Gateway, de op Envoy gebaseerde API-gateway van Solo. Solo heeft de open-source Gloo Gateway geschonken aan de CNCF, waar het werd omgedoopt tot kgateway en in maart 2025 werd geaccepteerd als een Sandbox-project. In dezelfde maand creëerde Solo vanaf nul een nieuwe proxy in Rust: de agentgateway-repository dateert van 18 maart 2025.

De overdracht duurde ongeveer acht maanden, verspreid over twee kgateway-releases, één Solo-aankondiging en een verhuizing naar een stichting:

Aan de commerciële kant werd Gloo Gateway omgedoopt tot Solo Enterprise for kgateway, en Solo Enterprise for agentgateway, ooit inbegrepen in Gloo Gateway, werd een afzonderlijk product met zijn eigen Helm charts, controllers en API's.

Bestaande configuratie wordt niet ongewijzigd overgenomen. kgateway v2.2 vereiste de migratie van agentgateway-instellingen naar de nieuwe resources vóór de upgrade, en de merknaamwijziging van Solo Enterprise 2.1 verwijderde "Gloo" uit CRDs en Helm charts.

Wat is agentgateway?

agentgateway is een open-source AI-gateway, self-hosted, die zich bevindt tussen uw applicaties en de modelproviders, tools en agents die zij aanroepen. Applicaties communiceren ermee via het standaard OpenAI-verzoekformaat, dus het toepassen ervan is voornamelijk een wijziging van de base-URL. Het beheert drie soorten verkeer: LLM-aanroepen, Model Context Protocol (MCP)-verkeer tussen agents en tools, en agent-to-agent (A2A)-aanroepen. (Zie ons bericht over het beheren van multi-agent A2A-verkeer bij de gateway voor de reden waarom A2A-verkeer eigen controles nodig heeft.) Het proxiet ook gewoon HTTP en gRPC. (Wat is een LLM-gateway? behandelt het algemene patroon.) Zie onze gids over agent gateways voor de bredere categorie.

De documentatie van Solo legt de herschrijving uit: MCP-sessies zijn langdurig en statusvol (stateful), en traditionele gateways waren niet ontworpen voor dat type sessiebewustzijn, dus bouwde Solo een nieuwe proxy in plaats van Envoy uit te breiden.

Versiegeschiedenis

Kleine releases verschijnen ongeveer maandelijks, wat regelmatig upgradewerk betekent. v1.6.0 alleen al bevatte vijf breaking changes, en twee daarvan staan in de onderstaande migratiechecklist.

Hoe we hebben getest

We hebben de open-source standalone binary, v1.5.0, gedraaid tegen lokale mock providers, plus een paar echte OpenAI-aanroepen waarbij de provider zelf werd getest. Toen v1.6.0 uitkwam, hebben we de vier bevindingen die hierdoor het meest waarschijnlijk veranderden opnieuw getest op beide versies. We hebben de commerciële editie niet gedraaid, aangezien daarvoor een door de verkoopafdeling uitgegeven licentiesleutel nodig is; wat we erover zeggen is dus afkomstig uit de documentatie van Solo.

Architectuur

Er zijn twee manieren om het te draaien.

Standalone is het één proces dat één YAML-bestand leest. Het heeft geen Kubernetes, Postgres of Redis nodig om LLM-verkeer te routen, en bevat een web-UI en een ingebedde SQLite-verzoeklogboekenbank. Een minimale LLM-configuratie beslaat minder dan tien regels, zonder dat u een account hoeft aan te maken.

Op Kubernetes bekijkt een controller Gateway API-resources en pusht de configuratie naar afzonderlijke proxy-deployments via xDS. agentgateway heeft zijn eigen GatewayClass en CRDs (AgentgatewayPolicy, AgentgatewayBackend, AgentgatewayParameters). Solo's optionele Helm-waarden voor ClickHouse, Redis en OpenTelemetry vallen buiten het ondersteuningsbeleid.

Wat we in de praktijk hebben gecontroleerd op v1.5.0:

• Verlies van control-plane. We hebben de controller in een lokaal Kubernetes-cluster verwijderd terwijl er verkeer stroomde. De proxy's bleven vanuit hun bestaande configuratie verzoeken afhandelen met nul mislukte verzoeken gedurende een uitval van 66 seconden, en het twee keer doden van de actieve controller droeg het leiderschap over naar de standby in 16 en 17 seconden.
• Geen phone-home. Op een netwerk zonder internetroute verwerkte de gateway het verkeer van begin tot eind en maakte geen uitgaande verbindingen buiten de geconfigureerde providers. We zagen geen licentiecontrole, telemetrie-callback of gebruiksrapportage.
• Live reload. Routingregels, policies, backends en zelfs listener-poorten worden in ongeveer twee seconden herladen, zonder herstart. Een ongeldige configuratie wordt geweigerd met een foutmelding die het veld noemt, en de laatst bekende goede configuratie blijft verkeer afhandelen.
• De uitzondering op live reload. Een paar instellingen, zoals de locatie van de verzoeklogboekdatabase, worden alleen toegepast bij het opstarten. Wijzigt u er een terwijl de gateway draait, dan meldt het dat de nieuwe configuratie is geladen, maar er verandert niets en de config-sync metric geeft nog steeds aan in sync te zijn.

Prestaties: wat Solo's gepubliceerde benchmarks tonen

We hebben agentgateway zelf niet aan een belastingstest onderworpen. Solo.io heeft verschillende benchmarks gepubliceerd op het eigen blog en op de agentgateway-projectblog, allemaal uitgevoerd door Solo-medewerkers of mensen dicht bij het project. We samenvatten ze hier, met de voorbehouden die horen bij door leveranciers uitgevoerde cijfers.

Proxy throughput en latency

In Designing agentgateway, gepubliceerd op de Solo.io-blog in juni 2026, meldt Lin Sun van Solo ongeveer 500.000 verzoeken per seconde met 512 verbindingen, waarvan het bericht vermeldt dat het beter presteert dan vergelijkbare proxy's onder soortgelijke omstandigheden zonder deze bij naam te noemen. Een tweede resultaat is een P99-latency van minder dan 0,2 ms bij 30.000 verzoeken per seconde, opnieuw met 512 gelijktijdige verbindingen.

De methodologie is afkomstig uit John Howards Gateway API benchmark, waarin agentgateway naast Envoy Gateway, Istio en NGINX op Kubernetes draait. De meest opvallende cijfers komen uit een route-schalingstest in plaats van een verkeerstest: het data plane van agentgateway bleef onder 1% CPU terwijl de andere 20% tot 240% gebruikten, en het geheugen groeide van 4 MB naar 40 MB, terwijl de andere begonnen op 60 tot 90 MB en groeiden naar 1 tot 2 GB. Het rapport vermeldt dat de auteur en zijn werkgever bijdragen aan verschillende van de geteste projecten, waaronder agentgateway.

agentgateway vs LiteLLM

Lin Sun vergelijk ook agentgateway met LiteLLM in drie berichten op de agentgateway-blog: een test op maximale doorvoer, een vervolgtest op vaste doorvoer en een herhalingstest tegen LiteLLM's Rust-modus. Elk plaatst beide gateways voor een mock modelserver die direct antwoordt, waardoor de tests uitsluitend de proxy-overhead meten. Fortio genereert de belasting over 32 verbindingen.

De tests met een vaste snelheid zijn een eerlijkere vergelijking, omdat beide gateways worden gevraagd dezelfde belasting te verwerken. In de test van 3.000 verzoeken per seconde verwerkte LiteLLM er slechts 2.466. De Rust-modus verlaagt het geheugengebruik van LiteLLM van ongeveer 11,7 GiB naar 2,1 GiB, maar de P99-latency is nog steeds ongeveer 30 keer zo hoog als die van agentgateway. Ten tijde van die test ondersteunde de Rust-modus het OpenAI API-pad niet, dus werd in plaats daarvan de Messages-indeling van Anthropic gebruikt.

Inference routing op GPU's

De documentatie van agentgateway publiceert ook een inference-routing benchmark voor v1.4.1, met acht vLLM-servers die Qwen3-32B draaien op 16 NVIDIA H100 GPU's. Bij 60 verzoeken per seconde verhoogde het routen via agentgateway in plaats van een normale Kubernetes Service de output-doorvoer van 6.910 naar 16.178 tokens per seconde, en de mediane tijd tot de eerste token daalde van 62,9 seconden naar 0,1 seconden. De mediane inter-token latency steeg van 30,3 ms naar 52.7 ms. De Service-nulmeting was bij die snelheid overbelast, wat het grootste deel van het verschil in tijd tot de eerste token verklaart, en elke configuratie werd slechts één keer uitgevoerd.

Hoe u deze cijfers moet interpreteren

Samen beschrijven de benchmarks een snelle, lichte proxy: sub-milliseconde P99-overhead bij matige belasting, en geheugengebruik gemeten in tientallen megabytes. Ze kennen ook beperkingen. Elke test is uitgevoerd door Solo of door mensen die aan het project zijn verbonden, de proxy-tests maken gebruik van mock backends, en geen van de berichten vermeldt de hardware waarop de proxy's draaiden. Het cijfer van 500.000 verzoeken per seconde bevat geen genoemde vergelijking en geen gepubliceerde opstelling buiten het aantal verbindingen.

Proxy-overhead is ook minder van belang zodra een echt model wordt gebruikt. Wanneer een model honderden milliseconden nodig heeft om zijn eerste token te retourneren, is een verschil van 30 ms tussen twee proxy's merkbaar, maar 0,5 ms tegenover 1 ms niet. In productie hebben de routing-, failover- en timeout-eigenschappen die in het volgende gedeelte worden behandeld een groter effect op wat gebruikers ervaren. Solo publiceert de scripts en ruwe resultaten voor de LiteLLM-tests, dus de meest nuttige volgende stap is om ze opnieuw uit te voeren op uw eigen hardware met uw eigen verkeer.

Belangrijkste functionaliteiten, zoals gedocumenteerd en getest

Providers en formaten

Het schema van v1.6.0 heeft zeven ingebouwde providertypes (OpenAI, Gemini, Vertex AI, Anthropic, Amazon Bedrock, Azure en GitHub Copilot) en 14 presets, waaronder Groq, Mistral, DeepSeek, Together AI, Ollama en OpenRouter. Een aangepast providertype bereikt elke andere host die een van de negen ondersteunde API-formaten spreekt, dus in de praktijk is het bereik elk OpenAI-compatibel eindpunt.

De passthrough-nauwkeurigheid was uitstekend in onze tests. We hebben tool calls, strikte JSON-schema gestructureerde outputs, systeem-prompts, afbeelding-inputs, logprobs en requests met een seed zowel rechtstreeks naar OpenAI als via de gateway gestuurd, en de resultaten kwamen overeen. Een afzonderlijke controle op "stille onderbrekingen", waarbij een verzoek HTTP 200 retourneert met lege of verkeerde inhoud, leverde geen problemen op voor de geteste functies.

Afbeeldinggeneratie en audio vormen de tekortkoming. Het LLM-bewuste pad herkent geen verzoeken voor afbeeldinggeneratie, transcriptie of spraak. U kunt dat verkeer nog steeds proxylaten verlopen als normale HTTP, en we hebben bevestigd dat het intact aankomt met toegepaste API-sleutelcontroles, maar zonder token-accounting, kostentracking of model-bewust beleid.

Routing en veerkracht

agentgateway ondersteunt gewogen routing, op prioriteit gebaseerde failover, voorwaardelijke routing, retries, timeouts, outlier eviction, mirroring en sessie-affiniteit. Failover werkt tussen providers met verschillende API-formaten: we hebben een chat-completions backend laten uitvallen naar een backend in Anthropic-formaat, en de client bleef antwoorden ontvangen in de vorm die het had gevraagd.

Drie gedragingen vereisen een bewuste configuratie.

Retries voeren één extra upstream-aanroep uit ten opzichte van wat het schema beschrijft (v1.5.0 en v1.6.0). Het schema beschrijft pogingen als het "totale aantal pogingen, inclusief het oorspronkelijke verzoek." In onze tests genereerden attempts: 1, 2 en 3 respectievelijk 2, 3 en 4 backend-aanroepen. Het eigen retry.attempt logveld van de gateway telt op dezelfde manier, dus het gedrag is consistent en alleen de documentatie wijkt af. Retries hebben ook geen backoff tenzij u er een configureert. Houd rekening met één extra aanroep per storing en stel een backoff in.

Failover vereiste health checks in v1.5.0, en v1.6.0 lost dit op. In v1.5.0 verplaatste failover geen verkeer van een falende primaire backend tenzij er een evictiebeleid was geconfigureerd. Op v1.6.0 zonder health-beleid werd de primaire backend na één storing verwijderd en gingen de volgende vijf verzoeken naar de back-up. Op beide versies bereikte het verzoek dat de fout veroorzaakte nog steeds de client als een fout en werd het niet opnieuw geprobeerd op de back-up.

Vastgelopen streams hebben een expliciete timeout nodig. In v1.5.0 beëindigden noch requestTimeout noch backendRequestTimeout een stream die zijn eerste chunk verzond en vervolgens stil werd. v1.6.0 voegt responseIdleTimeout toe, en ingesteld op 5 seconden verbrak het onze vastgelopen stream op 5,04 seconden. De client heeft op dat moment al een 200 en het eerste chunk ontvangen, dus ziet hij een afgekapte stream, geen foutcode. Zonder geconfigureerde timeout hangt de stream op v1.6.0 nog steeds zolang de client wacht. Dit is de routepolicy die we hebben getest:‍

Identiteit, toegang en MCP-autorisatie

Aanroepers authenticeren met API-sleutels of met JWT's die zijn gevalideerd bij uw identiteitsprovider. Sleutels bevatten metadata zoals gebruiker en team, en die metadata komt terecht in het verzoeklogboek. Model-allowlists per sleutel werken in de open-source build, en het intrekken van een sleutel werd in onze tests binnen twee seconden van kracht.

MCP-autorisatie is het sterkste onderdeel van het product en loopt voor op het grootste deel van de categorie. CEL-policies (Common Expression Language) bepalen welke individuele tools een aanroeper mag gebruiken, en de gateway filtert ook tools/list per aanroeper, zodat een agent alleen de tools ziet die hij mag gebruiken. We hebben beide in de praktijk bevestigd. Als u nieuw bent met hoe MCP-identiteit werkt, is MCP-authenticatie uitgelegd een goede introductie. agentgateway kan ook verschillende MCP-servers bundelen achter één eindpunt en OpenAPI-services beschikbaar stellen als MCP-tools.

Handhaving werkte op dezelfde manier voor LLM-, MCP- en A2A-verkeer in onze tests. Eén kanttekening: de identiteit van de aanroeper wordt voor MCP- en A2A-verkeer niet naar het toeganglogboek geschreven, tenzij u dit configureert.

Kostenbeheer en rate limits

In de open-source standalone-build (v1.5.0) kunnen API-sleutels USD- of tokenbudgetten bevatten, en we hebben bevestigd dat een sleutel die zijn limiet bereikt wordt geblokkeerd terwijl andere sleutels gewoon doorgaan. Handhaving gebeurt achteraf. De gateway controleert het budget voordat een verzoek wordt toegelaten, maar leert de kosten pas na de respons, waardoor het verzoek dat de limiet overschrijdt nog steeds wordt voltooid. Beschouw budgetten als een bijna-realtime rem in plaats van een harde limiet. (We behandelen de algemene afwegingen in AI-gateway budgetten en quota's.)

Kosten zijn afhankelijk van een prijzenlijst. In v1.5.0 worden geen kosten berekend totdat u er een laadt, en een budget op een model dat niet in de lijst staat, brengt nooit kosten in rekening en blokkeert nooit. v1.6.0 bevat een ingebouwde catalogus die gpt-4o-mini heeft geprijsd zonder aanvullende configuratie, maar een self-hosted of intern model registreerde nog steeds geen kosten. We hebben de budgethandhaving niet opnieuw getest op v1.6.0.

Rate limits in de open-source build zijn lokaal voor elke gateway-instantie, en v1.6.0 voegt lokale limieten per sleutel toe, die we niet hebben getest. Globale rate limiting, de budget-resource en de Cost Management UI zijn enterprise-functies. We hebben budgetten getest op slechts één instantie, dus test hoe ze zich gedragen over meerdere standalone-instanties voordat u er op vertrouwt.

Caching

We hebben geen responscaching gevonden. We hebben het configuratieschema, de open-source documentatie en de enterprise-documentatie van Solo doorzocht op exacte en semantische caching en beide niet aangetroffen. Teams met herhaalde prompts zullen elders moeten cachen.

Guardrails en gegevensbescherming

Ingebouwde detectors vervangen gevoelige gegevens zoals e-mailadressen, kaartnummers en burgerservicenummers door gelabelde placeholders. Met een opnemende mock op de plek van de provider waren de gemaskeerde waarden al verdwenen voordat het verzoek de gateway verliet. Verzoeken kunnen ook worden geweigerd met een aangepast bericht. Externe guardrails omvatten webhooks, OpenAI Moderation, AWS Bedrock Guardrails en Google Model Armor, die we niet hebben getest.

Prompt- en responsinhoud wordt standaard niet opgeslagen. Wanneer u het opslaan inschakelt, kunnen CEL-regels dit beperken tot specifieke teams, kosten of guardrail-resultaten.

Observability

Prometheus-metrics omvatten verzoeken, latency, tokens en kosten. Een verzoeklogboek in SQLite of Postgres registreert gebruiker, team, model, tokens en kosten per verzoek, dus rapportage per gebruiker is een eenvoudige SQL-query. Traces en logboeken worden geëxporteerd via OpenTelemetry, en Solo documenteert integraties met LangSmith en Phoenix.

Kosten per team zitten echter niet in de metrics, wat van belang is als u via AI-gateway observability uw uitgaven wilt rapporteren. Prometheus-metrics bevatten geen gebruiker-, team- of sleutellabel, dus een kosten-per-team dashboard moet het verzoeklogboek uitlezen. Dat is een begrijpelijke keuze vanwege cardinaliteitsredenen, maar het betekent wel dat u een tweede datapad moet bouwen.

Wie beheert agentgateway

Solo.io, gevestigd in Cambridge, Massachusetts, bouwt agentgateway en verkoopt de enterprise-editie. De laatst aangekondigde financieringsronde was een Series C van $ 135 miljoen tegen een waardering van $ 1 miljard in oktober 2021.

Het project zelf wordt gehost door de Agentic AI Foundation onder de Linux Foundation, niet door Solo. De code is Apache 2.0, dus als de prioriteiten van Solo veranderen, blijven de code en de beheerstructuur bestaan.

Van dag tot dag komt de meeste code nog steeds van Solo. Van de 2.507 niet-merge commits op 25 augustus 2026 waren solo.io e-mailadressen goed voor 63,4% (een ondergrens, aangezien medewerkers die vanuit persoonlijke adressen commiten niet worden meegeteld) en één Solo-engineer schreef 38,9%. In de voorgaande 90 dagen hebben 118 mensen bijgedragen en was het aandeel van Solo 58,9%, waarbij Microsoft bijdroeg aan Windows-ondersteuning en AWS Bedrock-voorbeelden. Die concentratie is normaal voor een project van ongeveer 19 maanden oud, en externe bijdragen groeien. Een beslissing voor de langere termijn moet nog steeds meewegen hoeveel van het project afhankelijk is van Solo, en van één engineer in het bijzonder.

Migreren van Gloo AI Gateway: een checklist

Als u AI-beleidsregels uitvoerde op Gloo Gateway of het Envoy-pad van kgateway, is dit de volgorde waarin we te werk zouden gaan. Elk item is afkomstig uit de releaseopmerkingen en het gedrag dat hierboven is beschreven.

1. Inventariseer het AI-beleid dat u op de TrafficPolicy van het Envoy-pad hebt staan. kgateway v2.2 heeft dit verwijderd, dus niets daarvan blijft behouden na de upgrade.
2. Verplaats die configuratie naar de agentgateway GatewayClass en de bijbehorende CRDs (AgentgatewayPolicy, AgentgatewayBackend, AgentgatewayParameters) vóórdat u naar v2.2 upgradet, niet erna.
3. Op het commerciële spoor dient u manifests, Helm-waarden en automatisering die verwijzen naar "Gloo"-namen bij te werken. Solo Enterprise 2.1 heeft deze verwijderd uit CRDs en Helm charts.
4. Voeg op agentgateway v1.6.0 of hoger het pad toe aan elke provider-basis-URL (https://api.openai.com/v1, niet https://api.openai.com).
5. Als u Anthropic Messages-verzoeken converteert voor providers in OpenAI-stijl, controleer dan of u afhankelijk bent van de historie van extended-thinking, aangezien de conversie van Responses deze laat vallen.
6. Stel een retry backoff in en houd rekening met één extra upstream-call per fout dan het aantal pogingen suggereert.
7. Stel responseIdleTimeout in op streaming-routes, zodat een stille provider verbindingen niet open kan houden.
8. Bevestig dat elk model dat u routeert, inclusief self-hosted modellen, geprijsd is in de catalogus. Modellen zonder prijs registreren geen kosten en activeren nooit een budget.
9. Bepaal aan welke kant van de editiegrens u moet zitten. Globale rate limits, de budget-CRD en de Cost Management UI zijn enterprise-functies.

Open source vs Solo Enterprise

Solo's functiematrix markeert de onderstaande enterprise-toevoegingen.

Delen van Solo's functiematrix doen het gratis product tekort. Het vermeldt uitgavenbudgetten en virtuele sleutels onder de enterprise Cost Management UI, maar de open-source standalone binary handhaafde budgetten per sleutel in onze tests. Een deel van de reden is dat de open-source Kubernetes CRDs geen budget- of virtuele-sleutel-velden hebben, terwijl de standalone binary dat wel heeft. We hebben Solo de rest niet laten bevestigen, dus test de editiegrens voordat u eromheen gaat prijzen.

Prijzen en compliance

Kopen is sales-gestuurd, zonder openbare prijslijst, en licentiesleutels komen van een accountvertegenwoordiger. Het enige externe cijfer dat we vonden is Vendr's mediane Solo.io-contract van $ 68.000 per jaar (bereik $ 28.954 tot $ 530.656), wat betrekking heeft op Solo.io als geheel, niet op agentgateway specifiek.

Solo's trustportal toont SOC 2 Type II. Toen wij het controleerden, vermeldde het noch ISO 27001, noch een HIPAA business associate agreement. Een ontbrekende vermelding bewijst niet dat het papierwerk niet beschikbaar is, dus gereguleerde kopers moeten dit rechtstreeks aan Solo vragen.

Wanneer agentgateway een goede keuze is

agentgateway past bij een platformteam dat zijn gateway zelf wil beheren en één of enkele instanties uitvoert, agent-workloads waarbij MCP-toolautorisatie het belangrijkst is, en omgevingen zonder internetroute. Het is ook geschikt voor teams die echt waarde hechten aan een Apache 2.0-licentie en governance vanuit een stichting.

Het is geen goede keuze als u budgetten en rate limits nodig hebt die over vele instanties worden gedeeld zonder de enterprise-editie te kopen, of response caching in de gateway. Hetzelfde geldt voor teams die een gehoste dienst willen, maandelijkse upgrades met breaking changes niet kunnen opvangen, of kostentracking op het genereren van afbeeldingen en audio nodig hebben.

Hoe TrueFoundry dit aanpakt

De TrueFoundry AI Gateway is hetzelfde type controlepunt, inclusief het omliggende platform. Het draait als SaaS of self-hosted in uw VPC, on-prem of air-gapped, en ontsluit 1.000+ LLMs via één OpenAI-compatibele API. Rondom de gateway voegt het budgetten toe op basis van tenant, team, model of provideraccount met een warn-only modus, een console met RBAC, SSO via OIDC of SAML 2.0 en SCIM-provisioning, en MCP-governance met besturing per tool en menselijke goedkeuring vóór destructieve tool calls.

Eén kanttekening: TrueFoundry's guardrails voor contentmoderatie, PII en prompt-injectie werken alleen wanneer TrueFoundry de gateway host, terwijl agentgateway's ingebouwde PII-maskering op uw eigen infrastructuur draait.

agentgateway vs TrueFoundry AI Gateway

De TrueFoundry-kolom herhaalt TrueFoundry's eigen gepubliceerde documentatie. De agentgateway-kolom weerspiegelt onze tests van de open-source build en Solo's documentatie voor de enterprise-editie, per 8 oktober 2026.

Welke past bij u

Kies Solo Enterprise voor agentgateway als u gebonden bent aan agentgateway's dataplane, maar vlootbrede rate limits, een kosten-UI, FIPS-builds en een ondersteuningscontract nodig hebt.

Kies TrueFoundry als u liever niet zelf budgetten, toegangsbeheer en toolgoedkeuringen rondom een gateway bouwt, of als u de optie wilt van een beheerde SaaS-deployment naast VPC- en air-gapped installaties.

Gerelateerde artikelen

• Envoy AI Gateway (nu Agent Router): een eerlijke review, onze review van de andere door een stichting gehoste open-source AI gateway
• Solo.io concurrenten en alternatieven, de bredere markt rondom Solo's producten
• Wat is een Agent Gateway? Een complete gids (2026), onze gids voor de bredere categorie van agent gateways
• Kong AI vs Solo.io, vergelijking van Solo met Kong's AI gateway
• LiteLLM-alternatieven, voor teams die open-source proxies afwegen
• Beste MCP-gateways, een vergelijking van de MCP-laag bij verschillende leveranciers

Conclusie

Gloo AI Gateway als naam is verdwenen. Solo's AI gateway is nu agentgateway, een proxy die vanaf het begin is geschreven voor LLM-, MCP- en agent-verkeer, getrouw aan provider-APIs en royaler in zijn gratis editie dan Solo's eigen matrix toegeeft. Voordat u erop gaat bouwen, moet u testen waar de gratis editie stopt, een retry backoff en een idle timeout instellen, en controleren of elk model dat u gebruikt geprijsd is in de catalogus.

Als u agentgateway afweegt tegen een gateway met teambudgetten, toegangsbeheer en MCP-goedkeuringen die al zijn ingebouwd, boek dan een demo van de TrueFoundry AI Gateway en breng uw MCP- en budgetvereisten mee. U kunt ook eerst lezen hoe de gateway werkt.