You are a platform engineer who has just been told to find out whether the AI gateway your team runs beside your API gateway can be retired. Two gateways, two sets of policy, two places to check authentication, two dashboards. Then a post from Solo.io lands in front of you, and you read it with a pen in hand.
In Designing agentgateway for AI and API Traffic, Lin Sun explains why Solo.io built a new gateway instead of extending Envoy. The argument is that agents behave like distributed systems. They call tools, route across models, and talk to MCP servers and other agents. Running a separate AI gateway beside the API gateway, the post says, duplicates policy, authentication, observability, routing and governance. Agentgateway is the answer: one control plane and one Rust data plane for HTTP, gRPC, MCP, A2A and LLM traffic, configured over xDS so routes change without a restart.
You check the claim about what it is not. The post says: "Not because existing API gateways are broken. And not because AI traffic somehow replaces traditional application traffic." That is a narrower pitch than you expected, and a more believable one.
Then you reach the numbers, and you slow down. Roughly 500k QPS at 512 connections and under 0.2 ms P99 latency at 30k QPS come from Solo.io's own benchmarks, with a pointer to John Howard's Gateway API benchmark for method. Weekly downloads rising from about 100,000 to more than 1 million since February, more than 7 million in total, and the list of adopters are all self-reported. You can treat them as the vendor's account, not as measurements you can lean on.
What you can lean on is the governance record, because you can check it. Agentgateway was created in March 2025 and donated to the Linux Foundation on August 25, 2025. It was proposed to the Agentic AI Infrastructure Foundation on April 8 and approved by that foundation's Governing Board on May 21 as a Growth-stage project. For someone deciding whether to build on a gateway, a home under a foundation is evidence that doesn't depend on a press release.
So you do what you would do with any vendor: you look at what Solo.io publishes about itself. The APIs.io catalog record for Solo.io names agentgateway in its description. But none of its 15 API pages describe it. They describe Gloo Portal: the API Products API, the Subscriptions API, the API Keys API and the OAUTH Credentials API. Those are exactly the consumer-side controls the post says should be unified. The one page that touches AI traffic is the Webhooks API, a guardrail webhook contract with a request hook and a response hook that the AI gateway calls out to.
You stop yourself before reading too much into that. Agentgateway is configured, not called, so its absence from the API pages is a fact about what it is, not a failing. A gateway has no endpoints for a catalog to describe in the usual way.
The scores are where the record turns on the company itself. The Kin Score is 60.2, strong, with developer ergonomics at 78.6, discoverability at 76.7 and contract quality at 64.5. Contract governance sits at 28.0. Agent Readiness is 34.8. The MCP server, error semantics and OpenAPI examples are lit. The agent card, delegated identity and protected resource metadata are not.
That last group is the one that catches your eye. A gateway built to sit between agents and MCP servers is the natural place to answer delegated identity and protected resource metadata, and Solo.io's own published surface answers neither. That gap is not about the product's architecture. It is about what Solo.io publishes.
You close the post with a clear split in your notes. Take the architecture argument and the foundation record at face value, because they hold up without the marketing. Treat the throughput and adoption figures as claims to reproduce in your own environment. And when you evaluate it, ask for the identity story directly, because the catalog did not find it in the published surface.
Read the original: https://apis.io/2026/11/09/solo-io-unifies-ai-and-api-traffic-and-the-catalog-sees-only-the-portal/