Most teams running on Google Cloud don't pick one compute model and stay there. Some services live on GKE because they need fine-grained control, sidecars, or GPU scheduling. Others run on Cloud Run because a stateless HTTP API doesn't need a cluster to babysit it. Increasingly, a third category has joined the mix: LLM calls, MCP tool servers, and autonomous agents, each with its own traffic patterns and risk profile.

Enterprises are rapidly shifting from conventional request-response APIs to composite, AI-native ecosystems. Standard REST and GraphQL endpoints are no longer just consumed by frontends; they are dynamically queried as tools by autonomous agents, LLM pipelines, and Model Context Protocol (MCP) servers.

At the same time, compute is split across Google Cloud platforms. Microservices run on Google Kubernetes Engine (GKE), while serverless APIs run on Cloud Run.

his fragmentation introduces a critical infrastructure question: How do you enforce uniform authentication, observability, and cost governance across GKE and Cloud Run without maintaining duplicate security stacks?

Kong AI Gateway 2.0 addresses this by treating AI primitives—models, providers, agents, and MCP servers—as first-class control plane entities rather than generic HTTP plugins.