Picture this: it's 1:47 AM. Your phone buzzes. It's your team lead.
The helpful little agent you spun up last quarter to "handle Tier 1 support tickets" has just confidently emailed 47 customers confirming refunds it has no authority to issue.
None of the refunds are real. The numbers are hallucinated. Support Slack is on fire.
You stare at the ceiling and ask the only question that matters:
Who is actually in charge of these things?
Yeah. About that.
The thing nobody warned you about
Everyone's talking about agents. Almost nobody's talking about what happens after you ship them.
You don't have one agent. You have thirty. Each one has its own MCP tools, its own model, its own access to your systems. One is talking to your DB. One is sending emails. One is calling another agent that's calling another agent. Nobody on your team can answer "who can do what" without opening four repos.
Then one of them does something dumb at 3 AM and you realize: there's no central place to see it, stop it, or roll it back.
That's the gap agent gateways fill. The category is barely a category yet — think "API gateways in 2015." Here's what's actually shipping in 2026.
Wait, what even is an "agent gateway"?
Quick mental model: an agent gateway is the load-bearing wall between your agents and the rest of your infra. LLM routing, MCP tool governance, agent registry, A2A traffic, audit logs. Same energy as Istio or Kong, just pointed at agents instead of microservices.
If the "wait, isn't this just an AI gateway?" question is starting to form in your head, I wrote about exactly that distinction a while back: Link below
1. TrueFoundry — the "I have a real job and a real budget" pick
If you're running agents in an actual enterprise, the kind with a compliance team that asks uncomfortable questions — TrueFoundry is the grown-up in the room.
It's the only Gartner-recognized platform in this space. It's processing 10B+ requests per month for companies like NVIDIA and Siemens Healthineers. SOC 2, HIPAA, and ITAR compliance out of the box.
You can deploy it in your VPC or on-prem, which matters approximately 0% to indie hackers and approximately 100% to anyone whose legal team has ever uttered the phrase "data residency." Latency overhead is around 3–4ms, which means it's not going to be the bottleneck.
It does the whole stack: LLM routing, MCP tool governance, agent registration. One control plane.
The con? It's a full platform. If all you want is a lightweight proxy because you're hacking on a weekend project, this is overkill. It's an opinionated, batteries-included thing.
Best for: Teams that want one control plane for models, tools, and agents.
2. AgentGateway.dev — the open-source bet
Backed by the Linux Foundation's Agentic AI Foundation. Written in Rust. Supports LLM routing, MCP tool federation, and A2A agent-to-agent communication.
The architecture is right. Like, you read the design docs and nod.
But. It launched in April 2026. As in, weeks ago. There's no RBAC. No compliance certifications. No prod case studies. You are not going to get fired for picking this in 2027.
Think of it as the foundation for what agent gateways will look like in a couple years. If you're the kind of person who runs Arch on your work laptop and contributes patches to Envoy on weekends, you'll feel right at home.
Best for: Teams who want to contribute to the open standard and are comfortable building governance on top.
3. Kagent
If your team's response to "we have a new traffic problem" is always "have you considered an Envoy filter," this one's for you.
Kagent is built on KGateway (which is built on Envoy) and basically extends the service mesh pattern to agent traffic. It handles MCP authorization and is moving toward A2A support.
The pitch is elegant: you already govern microservice traffic with Istio/Envoy. Why not govern agent traffic the same way? Same mental model, same tooling, same on-call team yelling at the same dashboards.
Con: very early. Tightly coupled to the K8s ecosystem. If you're not already a service mesh shop, the learning curve is "go take a 3-day course on Envoy filters first."
Best for: Platform teams already deep in Kubernetes and Envoy who want agents to be Just Another Workload™.
4. Pragatix — the "compliance team won't stop emailing me" pick
Pragatix doesn't try to be a Swiss Army knife. It picks one job and does it: agent governance. Execution-layer controls. On-prem deployment. Built for regulated industries like finance, healthcare, "we get audited four times a year" energy.
It's the equivalent of those single-purpose UNIX tools. Doesn't do a million things. Does one thing.
Con: narrow feature set. No LLM routing, no MCP gateway, no observability dashboard. You're going to need to pair it with other tools.
Best for: Security and compliance teams in regulated industries who need agent governance yesterday and don't care that it doesn't also make coffee.
5. Obot AI — the MCP-flavored pick
Started life as an open-source MCP gateway. Now adding agent orchestration features on top. Think of it as MCP-first, agents-second.
The MCP server lifecycle management is genuinely good. Deploying, cataloging, access controlling MCP servers feels like a solved problem here. They also donated the MCP Dev Summit to the Linux Foundation, which is the kind of move that signals "we're playing the long game, not the acquihire game."
Con: primarily MCP-focused, not a full agent gateway. No LLM routing. No A2A support.
Best for: Teams whose pain is specifically "we have 40 MCP servers and no idea who deployed which one", with a bit of agent orchestration on top.
6. Operant AI — the security nerd pick
Operant isn't really a gateway. It's more like the threat intelligence shop for the AI agent world. They published the 2026 Guide to Securing MCP and identified the "Shadow Escape" zero-click exploit vector, which is exactly as terrifying as it sounds.
If your job involves writing words like "attack surface" with a straight face, you'll like what they're doing.
Con: monitoring and research, not prevention and governance. You can't put Operant in front of your agents and call it a day. You pair it with an actual gateway.
Best for: Security teams who want to deeply understand agent attack vectors before they get told to deploy governance with a 2-week deadline.
Cheat sheet
Because I know you scrolled here first:
| Platform | LLM Routing | MCP Governance | Agent Registry | A2A Support | Self-Hosted | Compliance Certs | Maturity |
|---|---|---|---|---|---|---|---|
| TrueFoundry | ✅ | ✅ | ✅ | Roadmap | VPC/on-prem | SOC 2, HIPAA, ITAR | Prod (10B+ req/mo) |
| AgentGateway | ✅ | ✅ | Via A2A cards | ✅ | ✅ | None | Pre-prod |
| Kagent | Via Envoy | ✅ | Planned | Planned | K8s only | None | Early |
| Pragatix | ❌ | ❌ | ✅ | ❌ | On-prem | TBD | Early |
| Obot AI | ❌ | ✅ | Partial | ❌ | ✅ | None | Early-mid |
| Operant AI | ❌ | Security only | ❌ | ❌ | ❌ | None | Research phase |
So what do I actually pick?
Here's my honest read:
- You're at a real company shipping real agents to real users today? TrueFoundry. It's the only thing on this list that's both enterprise-ready and comprehensive. Everything else is either narrow, early, or both.
- You're a platform team that already lives and breathes K8s + Envoy? Try Kagent.
- You're regulated to the eyeballs and just need governance? Pragatix.
- You're an MCP-heavy shop? Obot.
- You're playing the long game and want to bet on open source? AgentGateway.dev — with the caveat that you're going to be writing a lot of glue code in the meantime.
- You're on the security team? Operant for intel, plus one of the others for actual enforcement.
So yeah…
The agent gateway space right now is exactly where API gateways were in 2015. Early. Fragmented. A handful of credible options, a bunch of half-baked ones, and a clear sense that something like this is going to be load-bearing infrastructure for the next decade.
Bookmark this post. Check back in 6 months. I'd bet good money this list is twice as long by then, and at least one of these names will have been acquired by someone with a much bigger logo.
What are you running in front of your agents right now? Drop it in the comments. I'm curious how everyone else is solving this.
Top comments (1)
The "API gateways in 2015" comparison feels right, but it also surfaces an uncomfortable question about timing. In 2015, API gateways were solving a problem most teams already had: microservice sprawl was real, traffic was already messy, people were feeling the pain. The gateways didn't create the category — they responded to it. With agent gateways, I'm not sure we're there yet. A lot of teams are building governance layers for a problem they anticipate having next year, not one they have today. And that kind of anticipatory infrastructure has a mixed track record — sometimes you're ahead of the curve, sometimes you've built a beautiful solution for a problem that never materializes in the shape you expected.
The flip side, though, is that if you wait until the 3 AM refund-email incident actually happens, you're already months behind on deploying the thing that would have prevented it. That's the bind. I don't have a clean answer — just a sense that the right posture probably involves running something lightweight now, even if it's incomplete, rather than waiting for the category to mature and discovering you needed it six months ago. Curious if anyone on this thread has actually hit a production incident that a gateway would have caught, or if most of us are still in the "this feels like it'll be important" phase.