How One Platform Team Scaled AI Adoption with Kagent and Agentgateway

The platform team at DNB, Norway's largest financial services group, scaled AI adoption by building an agentic platform using kagent and agentgateway to automate support and operations without adding headcount. The modular architecture connects Slack, internal systems, and MCP servers while maintaining security and access control, enabling the team to handle growing demand efficiently.

For many enterprise platform teams, the challenge isn’t a lack of ideas for AI. It’s finding a way to scale support and automation without adding headcount, compromising security, or creating another platform to maintain. That was the challenge facing the platform team who run payments for DNB https://www.linkedin.com/company/dnb/about/ , Norway’s largest financial services group. After attending KubeCon Europe in Amsterdam which David Karlsen jokingly refers to as “AICon” because of the sheer amount of AI content , the team returned with a simple question: how could they use these new ideas to make themselves more effective? What started as an idea for a Slack bot evolved into a broader agentic platform. Using kagent and agentgateway, the team built a foundation that could connect Slack, internal systems, and MCP servers while keeping security and access control front and center. The starting point wasn’t AI experimentation. It was a practical operational challenge. “We came back home and thought, how can we kind of automate our team so we are more efficient with the same set of hands?” — David Karlsen, Staff Engineer at DNB Like many platform teams, they were responsible for infrastructure, architecture, and internal support. As demand grew, they needed a way to help more users without increasing operational overhead. Their first instinct was to build a Slack bot. But the team quickly realized they wanted something broader than a chat interface. They wanted an architecture that could support multiple user experiences while keeping intelligence, access control, and integrations cleanly separated. That decision became foundational to the project. Rather than building a single tightly coupled assistant, the team adopted a modular architecture using agentgateway and kagent. As David put it: “We don’t want our bot to be too smart. We want to build the smartness into the agents.” That idea became one of the key architectural decisions behind the project. At a high level, the design looked like this: Users Slack, IDEs → Agentgateway → Kagent-managed Agents → Agentgateway → MCP Servers → Enterprise Systems In this architecture: This separation gave the team something more valuable than a chatbot: a reusable control plane for agentic experiences where users may have different experience and background: Different users could access the same underlying capabilities through different interfaces while security, governance, and observability remained consistent. The team evaluated several approaches before settling on kagent and agentgateway. One alternative would have required a more intrusive installation model and a new networking stack that didn’t fit their environment. Other solutions required additional configuration and operational complexity. Kagent stood out because it was straightforward to deploy and easy to extend. “After we tried kagent we said, okay, this is pretty easy to use, easy to add agents, easy to add MCP servers. We like it that everything is configurable. You have to just provide a manifest and everything got deployed nicely.” — Ibrahim Umar, Senior DevOps Engineer at DNB That declarative model aligned naturally with the team’s existing Kubernetes, OpenShift, and GitOps workflows. The ability to deploy agents and MCP servers through declarative YAML meant they could experiment quickly without introducing operational friction. Just as importantly, agentgateway remained a separate control layer rather than being bundled into a monolithic platform with kagent. That flexibility allowed the team to manage their MCP servers’ access independently from agent deployment and orchestration. Because the team operates in an enterprise environment and works with real systems, security requirements shaped the architecture from the beginning. Agentgateway was integrated with Microsoft Entra ID and configured to use JWT-based identity propagation and authorization controls. This allowed the team to enforce identity-aware policies while remaining aligned with existing Azure-native authentication workflows. As the project evolved, they also explored broader questions around agent identity, delegated access, and authorization boundaries. “Security needs to be in the driver’s seat.” — David Karlsen, Staff Engineer at DNB The team viewed security as a prerequisite for adoption rather than something to be added later. That perspective influenced everything from gateway design to access control decisions. One of the most important aspects of the project was deciding what agents should do—and what they shouldn’t do. The team deliberately focused on use cases where AI could accelerate understanding and troubleshooting without introducing unnecessary operational risk. One of the first MCP servers Ibrahim built connected to DB2, a system many enterprises still depend on. Within a short time, the team could inspect database structures, review lock reports, and look at performance data through natural language interactions instead of manually digging through tools and dashboards. The same pattern extended to other systems as well. The team connected MQ, Jira, Atlassian tools, and other internal platforms to create a broader developer support ecosystem capable of helping users navigate increasingly complex environments without understanding their specific APIs. Many AI initiatives struggle not because of technology limitations but because users don’t change their habits. That wasn’t the case here. The team had already invested heavily in Slack and digital-first collaboration. Because the assistant appeared in a familiar environment, users could begin interacting with it immediately without learning an entirely new workflow. The result was faster adoption than the team anticipated. The team didn’t spend weeks training users. People simply started talking to the bot in Slack. Because the organization had already invested heavily in digital-first collaboration, adding another helper into the same environment felt natural. One night, David found himself asking the assistant about a problem in the assistant itself. Because the agent had access to its own source code and traces, it was able to explain what was happening and help diagnose the issue. “It was a bit meta but fascinating,” David said. “It could actually explain very well what was going on.” It wasn’t a planned use case, but it was one of those moments that made the team’s investment in the architecture feel worthwhile. For the team, open source wasn’t simply a philosophical preference. It was a practical requirement. Both David and Ibrahim have long histories with open source software, so transparency mattered. When they hit a roadblock, they wanted to inspect the code, understand the architecture, and potentially fix the problem themselves rather than wait for someone else to solve it. And they wanted the freedom to adapt the architecture as requirements evolved. “Being an open source project is very fascinating… if we have time, we try to implement it ourselves and contribute.” — Ibrahim Umar, Senior DevOps Engineer at DNB The team also valued support for open standards including: These standards helped reduce lock-in while making it easier to connect existing systems to the emerging agentic ecosystem. In many cases, they didn’t need to rebuild services at all. Existing REST APIs could be exposed as MCP servers easily via agentgateway, creating a practical bridge between traditional enterprise systems and modern AI workflows. That approach allowed them to build on investments they had already made rather than introducing an entirely new platform from scratch. As the team became more familiar with the architecture, they moved beyond adoption and started contributing ideas back to the kagent open source community. Their path into the community started with a real problem. While evaluating the architecture, David began digging into security boundaries and access enforcement. That investigation led him into the project’s backlog, Discord discussions, and eventually to writing a design proposal https://github.com/kagent-dev/kagent/issues/1270 issuecomment-4778333681 for a security enhancement. They look forward to working with the kagent community to implement this feature. Looking back, several lessons stood out: For teams evaluating agentic AI, their recommendation is simple: start with a concrete use case, understand the security model thoroughly, and build on composable foundations that can evolve over time. When the team came back from KubeCon, they weren’t looking for a new AI project. They were trying to answer a practical question: How do we become more efficient with the same set of hands? For them, the answer wasn’t a smarter chatbot. It was a modular architecture built around agents, MCPs, and clear security boundaries. Kagent and agentgateway provided the building blocks, but the bigger lesson was that successful AI adoption starts with solving a real operational problem, not with chasing the latest trend.