Kong Risks Exclusion by AI Teams

This reveals a developer distribution problem, not just a feature gap. AI-native teams usually start with a Python app, a model SDK, and a lightweight gateway they can run or extend in the same codebase, so tools like Portkey and LiteLLM feel closer to the workflow. Kong’s AI Gateway is layered onto Kong Gateway as a set of AI plugins, which fits central platform teams better than small AI product teams moving fast inside Python heavy stacks.

• Kong’s plugin model comes from its core gateway architecture. Its docs describe AI Gateway as AI plugins installed on Kong Gateway, and Kong’s plugin docs center Lua as the standard built in extension model. That makes customization feel more like infrastructure work than application code for many AI engineers.
  4 konghq 5 konghq
• Portkey and LiteLLM meet AI teams where they already build. Portkey promotes a production stack for AI builders with official Python SDK support, and LiteLLM can be used as either a proxy server or Python SDK. That makes the first purchase decision feel like adding a developer tool, not adopting a broader gateway platform.
  2 portkey 3 portkey 6 litellm
• This matters because the buying center is shifting. Kong is expanding into Agent Gateway, Context Mesh, MCP, and broader AI connectivity, while rivals like Gravitee and WSO2 also pitch unified control planes. If the initial AI team standardizes on a Python native gateway first, Kong may only re enter later as a governance overlay, not the primary runtime.
  7 sacra 9 konghq

The market is heading toward a split where AI teams choose the fastest Python native tool first, then larger enterprises add governance on top. Kong’s path is to make its AI products feel native enough to win that first implementation, otherwise the center of gravity moves upward to orchestration and policy while day to day developer adoption accrues elsewhere.