Solo.io has published the open source distributions of kagent and agentgateway on all three major cloud marketplaces: AWS Marketplace, Microsoft Azure Marketplace, and Google Cloud Marketplace. Both kagent and agentgateway are free to deploy, and both install into your cluster the same way you already consume other cloud services: subscribe, pick a cluster, done. No Helm repo setup, no copying manifests from a README, and the deployment shows up in your cloud account alongside everything else you run there.
A quick word on the projects themselves. Both started at Solo.io and both were donated to open foundations: kagent is a CNCF project, and agentgateway is part of the Linux Foundation. Kagent is a Kubernetes-native framework for building and running AI agents. You declare agents, model configurations, and MCP tools as Kubernetes resources, and the kagent controller runs them, with a web UI on top and pluggable LLM providers (OpenAI, Anthropic, Azure OpenAI, Gemini, Ollama). Agentgateway is an AI-native data plane built on the Kubernetes Gateway API. It speaks the protocols agents actually use, MCP and A2A, and adds LLM routing and failover, prompt guards, and observability for agent traffic.
Each one is useful on its own. Together, one extends the other: kagent gives you agents running in your cluster, and agentgateway extends them with a real network edge, so agents and tools stop being cluster-internal experiments and become services you can expose, secure, and observe like anything else in production. In the walkthrough below we deploy both from the marketplace and connect them.
Here is where you can find the open source listings today:
On Google Cloud Marketplace you will also find the Enterprise versions, Solo Enterprise for kagent and Solo Enterprise for agentgateway, for teams that want commercial support and the enterprise feature set on top of the same open source core.
The exact install flow differs per cloud (EKS add-on or Helm on AWS, a Kubernetes application on Azure, click-to-deploy on Google Cloud), and we cover each one in a dedicated post:
- Installing kagent and agentgateway from AWS Marketplace (EKS add-on and Helm)
- Installing kagent and agentgateway from Azure Marketplace
- Installing kagent and agentgateway from Google Cloud Marketplace
The rest of this post is the part that is the same everywhere: what you get after the marketplace install, and how the two products work together. Everything below was run on real marketplace installs across the three clouds with both products installed.
From marketplace install to a running agent
You need a Kubernetes cluster, kubectl access to it, and an LLM provider API key (we use OpenAI here). Kagent does not run any agents until a provider is configured, so the key is the one real prerequisite.
Agentgateway builds on the upstream Kubernetes Gateway API, so its only prerequisite is the standard CRDs:
kubectl apply --server-side -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.5.0/standard-install.yaml
Install both products from your cloud's marketplace (steps in the per-cloud posts above). Agentgateway lands in the agentgateway-system namespace and kagent in the kagent namespace. Whichever cloud you used, the result looks the same:
$ kubectl get pods -n agentgateway-system
NAME READY STATUS RESTARTS AGE
agentgateway-cdd8744df-4rb7k 1/1 Running 0 2m
$ kubectl get pods -n kagent
NAME READY STATUS RESTARTS AGE
kagent-controller-7974bb886-ch8v7 1/1 Running 0 5m
kagent-kmcp-controller-manager-bc49969c4-crhjv 1/1 Running 0 5m
kagent-postgresql-85d75cbd57-knpqf 1/1 Running 0 5m
kagent-tools-6cb4449d6b-hzfsr 1/1 Running 0 5m
kagent-ui-75f8449979-96km2 1/1 Running 0 5m
That is the whole platform: the kagent controller and UI, kmcp for serving MCP tools, a bundled PostgreSQL for state, and the agentgateway control plane watching for Gateway API resources. (Exact resource names vary a little per platform: on AKS, for example, they carry the extension instance name you chose at install, so kagent-controller becomes <extension-name>-controller.) Kagent also registers a set of CRDs that make agents ordinary Kubernetes resources:
$ kubectl get crd | grep kagent.dev
agentharnesses.kagent.dev
agents.kagent.dev
mcpservers.kagent.dev
memories.kagent.dev
modelconfigs.kagent.dev
modelproviderconfigs.kagent.dev
remotemcpservers.kagent.dev
sandboxagents.kagent.dev
toolservers.kagent.devConfigure a model provider
Deployed on Google Cloud? Skip this section: the deploy form already collected your provider choice and created the ModelConfig (and secret, if the provider uses a key), so jump straight to creating an agent.
On AWS and Azure, give kagent an LLM to talk to. Create a secret with your API key and a ModelConfig that references it:
kubectl create secret generic kagent-openai -n kagent \
--from-literal=OPENAI_API_KEY=$OPENAI_API_KEY
kubectl apply -f - <<EOF
apiVersion: kagent.dev/v1alpha2
kind: ModelConfig
metadata:
name: default-model-config
namespace: kagent
spec:
model: gpt-4o-mini
provider: OpenAI
apiKeySecret: kagent-openai
apiKeySecretKey: OPENAI_API_KEY
Note: Other providers (Anthropic, Azure OpenAI, Gemini, Ollama) work the same way; see the kagent provider docs.
Create an agent
An agent is a resource like any other. The declarative type means the whole agent, model, instructions, and tools, is described by the resource and runs on kagent's built-in runtime. The tools reference attaches the MCP tool server that ships with kagent, so the agent can actually inspect the cluster it lives in (the name follows the install, like the controller service; check with kubectl get remotemcpservers -n kagent):
kubectl apply -f - <<EOF
apiVersion: kagent.dev/v1alpha2
kind: Agent
metadata:
name: k8s-helper
namespace: kagent
spec:
description: Answers questions about workloads in this cluster
type: Declarative
declarative:
modelConfig: default-model-config
systemMessage: |
You are a Kubernetes assistant. Answer questions about the
workloads running in this cluster using the tools available to you.
tools:
- type: McpServer
mcpServer:
apiGroup: kagent.dev
kind: RemoteMCPServer
name: kagent-tool-server
The controller spins up a pod for the agent and reports readiness on the resource:
$ kubectl get agents -n kagent
NAME TYPE RUNTIME READY ACCEPTED
k8s-helper Declarative python True True
For a look around, port-forward the UI at kubectl -n kagent port-forward svc/kagent-ui 8080:8080 (use kagentaks-ui in Azure) and open http://localhost:8080 (hit Skip Wizard on the bottom for this demo). Now you can chat with the agent there, and kagent ships prebuilt agents and MCP tools for Kubernetes, Helm, Istio, and more.
Put agentgateway in front of it
So far the agent lives inside the cluster, reachable through a port-forward. That is fine for a demo and not fine for anything real: other teams, other agents, and external callers need a governed way in, and you need to see and control that traffic. This is where agentgateway extends kagent.
Kagent exposes every agent over A2A (Agent2Agent), the open protocol for agent-to-agent communication, served by the kagent controller at /api/a2a/<namespace>/<agent-name>. Agentgateway understands A2A natively, so exposing the agent is a plain Gateway API exercise:
kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: kagent-gateway
namespace: kagent
spec:
gatewayClassName: agentgateway
listeners:
- name: http
port: 8080
protocol: HTTP
allowedRoutes:
namespaces:
from: Same
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: k8s-helper-a2a
namespace: kagent
spec:
parentRefs:
- name: kagent-gateway
rules:
- backendRefs:
- name: kagent-controller # in AKS use kagentaks-controller
port: 8083
The backendRef points at the kagent controller service on port 8083; check the service name in your cluster with kubectl get svc -n kagent (it follows the install name, for example kagentaks-controller on AKS).
The agentgateway controller picks up the gateway, deploys a proxy for it, and (on a cloud cluster) provisions a load balancer. Within a minute the gateway is programmed and has an address:
$ kubectl get gateway,httproute -n kagent
NAME CLASS ADDRESS PROGRAMMED AGE
gateway.gateway.networking.k8s.io/kagent-gateway agentgateway aacf335c...elb.amazonaws.com True 60s
NAME HOSTNAMES AGE
httproute.gateway.networking.k8s.io/k8s-helper-a2a 60s
Now the agent has an address outside the cluster. Grab it and fetch the agent card, the A2A discovery document that tells other agents what this one can do:
GW=$(kubectl get gateway kagent-gateway -n kagent \
-o jsonpath='{.status.addresses[0].value}')
curl -s http://$GW:8080/api/a2a/kagent/k8s-helper/.well-known/agent-card.json | jq .
{
"name": "k8s_helper",
"description": "Answers questions about workloads in this cluster",
"capabilities": { "streaming": true },
"preferredTransport": "JSONRPC",
"protocolVersion": "0.3",
...
}
And talk to it. A2A is JSON-RPC over HTTP, so a plain curl works; any A2A client library works the same way:
curl -s http://$GW:8080/api/a2a/kagent/k8s-helper/ \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":"1","method":"message/send","params":{"message":{"kind":"message","messageId":"demo-1","role":"user","parts":[{"kind":"text","text":"In one sentence: what do you do?"}]}}}' \
| jq -r '.result.artifacts[0].parts[0].text'
I provide information and answers regarding the workloads running in the Kubernetes cluster.
That request went from the internet, through the agentgateway proxy, to the agent's A2A endpoint. And because the data plane understands what it is routing, you get structured visibility into agent traffic for free:
$ kubectl logs -n kagent deploy/kagent-gateway --tail 1
2026-08-11T20:34:26.791178Z info request gateway=kagent/kagent-gateway listener=http route=kagent/k8s-helper-a2a endpoint=10.48.0.7:8083 src.addr=10.48.1.1:22687 http.method=POST http.host=136.115.154.87 http.path=/api/a2a/kagent/k8s-helper/ http.version=HTTP/1.1 http.status=200 protocol=http duration=1008ms
From here the interesting part starts. Because the traffic flows through agentgateway, you get the things you would expect from a gateway, applied to agent protocols: per-route policies, authn/z in front of agents, rate limits, and metrics and traces for every agent and tool call (the chart ships Prometheus endpoints and a Grafana dashboard out of the box). The same gateway can also front MCP tool servers and route LLM traffic with failover between providers, so as your agent footprint grows, the governance model does not change.
The extension works in the other direction too: agents you build in kagent become A2A services other teams can consume through the gateway, and tools you put behind agentgateway become available to any MCP-capable agent, not just kagent's.
Wrapping up
Two open source projects, three marketplaces, one deployment model: pick your cloud, subscribe, and you have an agent runtime and an agent-aware gateway running in your cluster. The per-cloud posts cover the marketplace specifics:
- AWS Marketplace: EKS add-on and Helm
- Azure Marketplace: Kubernetes application
- Google Cloud Marketplace: click-to-deploy
Docs and source, if you want to go deeper: kagent.dev (GitHub) and agentgateway.dev (GitHub). If you are interested in the Enterprise versions on Google Cloud Marketplace, talk to us.
%20(1).png)
%20a%20Bad%20Idea.png)
