iFLYTEK (科大讯飞) is a publicly listed AI company headquartered in Hefei, China, founded in 1999. We are best known for our speech and language technology — speech recognition, machine translation, and cognitive intelligence — and more recently for our Spark large language model family and the agent platform built on top of it.
Within iFLYTEK, our team builds the infrastructure that powers internal agentic applications, such as astron-agent, which was the No. 1 trending repository on GitHub as of August 7, 2026. Our work includes connecting agents to tools through MCP, enabling agent-to-agent communication through A2A, and routing traffic to LLM backends.
That infrastructure is exactly where agentgateway entered our story.
We started evaluating agentgateway in spring 2026 and have been running it in our test environments for about three months.
The experience has been surprisingly smooth for a young project. The single-binary deployment model made adoption straightforward—we didn’t need to stitch together a proxy, MCP middleware, and separate observability components. Out of the box, we got routing, authentication, and OpenTelemetry-based visibility into our MCP traffic.
And when we did hit rough edges, the community was responsive. Issues we filed received meaningful responses within days. That experience ultimately pulled me deeper into the project and, as you’ll see below, from a user into a contributor.
Three things stood out.
1. MCP and A2A are first-class citizens.
Most gateways treat AI traffic as “HTTP with extra steps.” agentgateway understands MCP sessions, tool calls, and A2A message flows natively. That means we can apply policy and observability at the level where agents actually operate—per tool, per session, and per interaction—not simply per HTTP URL.
2. A unified data plane.
We already had traditional microservice traffic running behind API gateways. Having a single gateway that can handle HTTP, gRPC, MCP, A2A, and LLM traffic—rather than introducing a separate “AI sidecar”—aligned well with our platform team’s goal of reducing operational complexity and the number of moving parts.
3. Performance and governance.
The Rust implementation has a small enough footprint to run alongside our workloads without significant resource overhead. Just as importantly, the project’s governance under the Agentic AI Foundation gave us the vendor-neutral confidence that a large organization needs before standardizing on an open-source component.
We looked at three broad categories of solutions:
agentgateway was the only option that is purposefully built for the entire agent connectivity path.
Our adoption of agentgateway also led us to make several architectural decisions:
Early on, we spent half a day chasing a mysterious latency spike. Eventually, we discovered that one of our own MCP servers was holding sessions open longer than expected. The gateway’s per-session metrics gave us the answer almost immediately, once we stopped guessing and actually looked at the dashboard.
That experience reinforced something we now consider fundamental: agent infrastructure needs observability from day one.
About two months after we started running agentgateway, I began reading the source code to answer deployment questions. Before long, I had opened my first pull request in early July.
Since then, I’ve submitted a dozen pull requests, most of which have been merged, covering several areas of the project.
I’ve contributed fixes that align the Kubernetes API with upstream conventions. For example:
PolicyConditionType
and PolicyConditionReason
to string type aliases to match metav1.Condition
(reflect.DeepEqual
with apiequality.Semantic.DeepEqual
to eliminate spurious diffs caused by metav1.Time
comparisons (These may sound like relatively small changes, but correctness at the controller layer matters enormously when you’re operating Kubernetes infrastructure at scale.
Performance has also been an area of focus:
I added an agentgateway_controller_build_info
metric and fixed a SetRegistry
lifecycle issue along the way (#2399). I’ve also contributed improvements to the project’s engineering infrastructure, including:
goleak
to detect goroutine leaks in controller packages (gosec
and kube-api-linter
configurations (One of the contributions closest to our real-world experience is a refactor of MCP session error handling with MissingClientCapability
support, currently under review (#2645). This is one of the things I appreciate most about contributing to infrastructure projects: real-world usage changes the kinds of problems you notice. Once you’ve operated MCP sessions yourself, some edge cases stop looking theoretical.
Of course, not every PR landed.
My proposal to add an fgprof
profiling endpoint to the admin server (#2464) was ultimately closed after discussion.
I actually see that as a sign of a healthy open-source community.
The maintainers didn’t simply rubber-stamp the proposal. They engaged with the idea, explained the trade-offs, and ultimately decided not to merge it. The discussion itself sharpened my understanding of the project’s admin-server design.
That’s an important part of open source: contributing isn’t just about getting your code merged. It’s about participating in the engineering conversation.
One of the most rewarding parts of this journey has been seeing the relationship evolve beyond individual contributions.
As someone contributing from China, in a different timezone and corporate environment, what impressed me most was how quickly and constructively the community responded to our contributions.
That same experience happened when I filed website#826 to add iFLYTEK to the Contributing Companies section. The maintainers took the time to verify the contribution and engage with us directly.
That kind of interaction matters.
It is what turns an open-source project that you use into a project that you want to contribute to.
And eventually, it turns an individual contributor into a contributing company.
Our journey with agentgateway has taught us several lessons.
Agent communication is fundamentally different from traditional request/response APIs.
Sessions can be long-lived. Communication can be bidirectional. State matters. Tool calls can trigger additional agent interactions.
Infrastructure designed purely around stateless HTTP request/response semantics needs to evolve for this new model. Understanding that distinction early helped us avoid architectural rework.
Instrument MCP and A2A traffic from day one.
Without visibility into sessions, tool calls, latency, and errors, it’s easy to spend hours debugging symptoms rather than understanding the underlying behavior.
Our own experience with the “mysterious latency spike” made this lesson very real.
Security shouldn’t depend on every individual agent implementing authentication, authorization, and auditing correctly.
Centralizing those concerns at the gateway gives us a consistent policy surface across agents, tools, and teams—and makes those policies easier to evolve as the platform grows.
Every patch we contribute upstream is one less patch we have to maintain ourselves.
More importantly, upstream contributions make the project better for everyone running similar workloads.
For us, reading the source code to answer deployment questions turned out to be one of the fastest ways to understand the project. Contributing those improvements back was the natural next step.
For iFLYTEK, agentgateway transformed “agent connectivity” from a collection of glue code into a governed and observable infrastructure layer: **one gateway, one policy surface, and one audit trail across MCP, A2A, and LLM traffic.**
But technology is only part of the story.
What started as an evaluation of an open-source project became hands-on adoption, then individual contributions, and ultimately a relationship between iFLYTEK and the agentgateway community.
That journey has been one of the most rewarding parts of working with agentgateway.
If you’re building agentic systems and thinking about where security, observability, and connectivity should live, give agentgateway a try. And when you hit a rough edge, don’t just work around it. Open an issue. Start a discussion. Send a PR. You might be surprised where that journey takes you.