Kong har gjort Kong AI Gateway 2.0 generelt tilgjengelig, og markerer et nytt skritt i overgangen fra enkel LLM-proxy mot et bredere kontrollplan for modeller, agenter, verktøy og AI-utgifter.

Utgivelsen fra 1. september bringer flere funksjoner som er viktige for team som allerede kjører produksjons AI-arbeidsbelastninger: MCP Server-bunting for styrt styringsverktøy som gir tilgang til ulike modifiserte administrasjonsverktøy, og bredere kostnadsstyringsverktøy-modeller. dekning, identitetsbevisste AI-policyer og innebygd IAM-autentisering for Amazon Bedrock AgentCore. Kong sier også at produktet nå er tilgjengelig i Kong Konnect uten betaaktivering.

Denne kombinasjonen er nyhetene. AI-gateway-kategorien handler ikke lenger bare om å ta en forespørsel i OpenAI-stil, videresende den til en leverandør og logge svaret. Enterprise-kjøpere ønsker i økende grad at gatewayen skal bestemme hvem som kan ringe hvilken modell, hvilke verktøy en agent kan nå, hvordan forbruket skal måles, og hvordan disse beslutningene kartlegges til identitetssystemer som allerede brukes av virksomheten.

Hva endret seg i Kong AI Gateway 2.0

Det mest bemerkelsesverdige tillegget er MCP Server Bundling. MCP, eller Model Context Protocol, har blitt en vanlig måte å eksponere verktøy og ressurser for AI-agenter på. Bunting av MCP-servere ved gateway-laget gir plattformteam et sted å samle og styre disse verktøyforbindelsene i stedet for å overlate alle applikasjonsteam til å koble og kontrollere sine egne agentintegrasjoner.

Dette er en meningsfull produktretning. Når agenter beveger seg fra demoer til interne arbeidsflyter, er risikoen mindre om at en modell svarer dårlig på ett spørsmål og mer om at en modell er koblet til for mange verktøy med for lite tilsyn. En gateway som kan pakke og kontrollere MCP-tilgang er nærmere det operasjonelle problemet: hvilke agenter som kan nå hvilke systemer, under hvems identitet og med hvilke policy-grenser.

Kong la også til dynamisk modalitetsbevisst kostnadsstyring. Dette er viktig fordi AI-priser ikke lenger er en enkelt token-måler. Tekst-, bilde-, lyd-, video-, verktøyanrop, bufret kontekst og resonnementmoduser kan hver ha forskjellig økonomi avhengig av leverandøren. Et kostnadskontrolllag som forstår modalitet kan gi team mer nøyaktige grenser og rutingsregler enn en generisk forespørselsteller.

Utgivelsen utvider også modell- og leverandørdekningen og legger til identitetsbevisste AI-policyer. Kongs opprinnelige IAM-autentisering for Amazon Bedrock AgentCore er spesielt relevant fordi Bedrock AgentCore er i ferd med å bli et av stedene hvor bedrifter driver og administrerer agenter. Å koble gatewaypolicy til skyidentitet reduserer gapet mellom AI-spesifikke kontroller og tilgangssystemselskapene som allerede reviderer.

Hvorfor dette er viktig for utviklere og plattformteam

For utviklere er den praktiske effekten at gatewayen blir en del av applikasjonsarkitekturen, ikke bare et infrastrukturtillegg. Et team som bygger en intern støtteagent, kodeassistent eller arbeidsflyt for dataanalyse kan nå trenge gateway-regler for modelltilgang, verktøytilgang, budsjettterskler og identitetsformidling før appen når produksjon.

Dette kan legge til noen oppsettskostnader, men det tar også opp en reell feilmodus. Uten et delt gateway-lag har modellvalg, leverandørlegitimasjon, verktøytillatelser og kostnadskontroller en tendens til å spre seg over applikasjonskode, CI-hemmeligheter, SDK-innpakninger og teamspesifikke dashboards. Denne fragmenteringen gjør hendelser vanskeligere å undersøke og modellmigreringer vanskeligere å utføre.

Kongs utgivelse er også et signal til leverandører som bygger OpenAI-kompatible API-lag og multi-modell API-produkter. Kompatibilitet alene blir bordspill. Kunder forventer i økende grad styring rundt forespørselen: håndhevelse av retningslinjer, bruksanalyse, tilgang på teamnivå, budsjettkontroller, reserveruting og modell/leverandørsynlighet.

For Model Gate-brukere er forbindelsen direkte. Samlet fakturering, API-nøkkeladministrasjon, bruksanalyse og teamkontroller blir alle mer verdifulle når modelltilgang bare er én del av arbeidsflyten. Ettersom agenter får verktøytilgang gjennom grensesnitt i MCP-stil, må gatewayer ikke bare representere hvilken modell som ble kalt, men også hvilket team, nøkkel, verktøypakke og policykontekst som var involvert.

Konkurransereferansen endrer seg

Kong er ikke alene i denne retningen. Nylige bevegelser på tvers av markedet viser AI-infrastrukturleverandører som konvergerer om det samme bredere problemet: Enterprise AI trenger en styrt vei mellom brukere, modeller, agenter, verktøy og forbruk. Gateway-produkter vurderes mindre etter om de kan normalisere forespørselsformater og mer etter om de kan støtte produksjonskontroller.

Det legger press på kjøpere til å stille skarpere spørsmål. Forstår gatewayen leverandørspesifikke priser og modaliteter? Kan administratorer angi retningslinjer etter team eller identitet? Kan den rute på tvers av leverandører uten å miste revisjonsevnen?Kan det styre agentverktøy, ikke bare modellendepunkter? Kan den avsløre bruks- og kostnadsdata på en måte som økonomi, sikkerhet og ingeniørkunst kan bruke?

Disse spørsmålene er ikke lenger teoretiske. Langkontekstmodeller, agentverktøysamtaler og multimodale arbeidsbelastninger kan raskt endre kostnadsprofiler. En arbeidsflyt som ser billig ut under testing kan bli dyr når gjentatt kontekst, bildeinndata eller verktøytunge agentløkker kommer inn i produksjonen. En gateway som ikke kan skille disse mønstrene kan fortsatt sentralisere tilgangen, men den vil ikke gi operatørene nok kontroll.

Det som fortsatt er usikkert

Kunngjøringen etablerer generell tilgjengelighet og navngir nøkkelfunksjonene, men implementeringen i den virkelige verden vil avhenge av implementeringsdetaljer: hvordan teamene konfigurerer MCP-bunter, hvor detaljerte policyene er, hvor mye kontroll er, hvor mye kostnadskontroller er, hvor mye kontrollert er, og hvor mye kontroll er på tvers av kostnadene. operativ synlighet kunder får i praksis.

Det er også for tidlig å vite om bedrifter vil standardisere agentstyring i en enkelt AI-gateway eller dele ansvaret på tvers av skyplattformer, sikkerhetsverktøy, utviklerplattformer og leverandører av observerbarhet. AWS, vertsplattformer, IDE-leverandører og frittstående gateway-leverandører prøver alle å eie deler av den samme kontrollflaten.

Retningen er likevel klar. Kong AI Gateway 2.0 behandler AI-trafikk som et styrt bedriftssystem i stedet for en strøm av modellanrop. For utviklere og bedrifter som bygger på modell-API-er, betyr det at gateway-beslutninger blir arkitekturbeslutninger: de påvirker kostnader, sikkerhet, modellvalg, verktøytilgang og påliteligheten til agentarbeidsflyter.