Appearance
Agent Gateway
Agent Gateway is the shared data plane for model, MCP, and agent traffic in prokube. It connects agent runtimes to configured models and workspace tools, and exposes selected services to other applications. prokube builds this layer on agentgateway and the Kubernetes Gateway API.
Upstream references
This page explains how prokube uses Agent Gateway for agent workloads. For public paths, API-key scopes, and client authentication, see Agent Gateway in Foundation and API Keys.
Controlled Agent Traffic
Model providers
Locally hosted LLMs
External provider LLMs
Clients and apps
Internal AI apps
Upstream agents
External client apps
Agent Gateway
policy, routing, quotasAgent runtime
Agent identity
Sessions and memory
Agent capabilities
MCP tools
Other agents
Skills
Observability and audit
Logs
Metrics
Traces
Evals
Audit
Kubernetes-native foundation: GPUs, data layer, identity, GitOps, backups, and air-gapped operations
Agent Gateway provides common routing between the main parts of an agent workload:
- Agent to model: a kagent Agent uses its selected Model Configuration to reach a self-hosted or administrator-managed model.
- Agent to tool: workspace MCP endpoints are federated behind Agent Gateway and exposed to kagent through a
RemoteMCPServer. - Agent to agent: kagent agents are reachable over Agent2Agent (A2A) routes.
- Application to service: internal applications and authenticated external clients can call models, MCP servers, and agents through stable workspace routes.
prokube creates and maintains the required gateway backends, routes, workspace isolation policies, and kagent references when supported resources are created through pkui.
Model Access
Every declarative agent references a kagent ModelConfig. How its traffic reaches the model depends on the configuration's origin:
| Model path | How it is connected |
|---|---|
| Model deployed through LLM Serving | prokube creates an OpenAI-compatible route to the in-cluster model. |
| Administrator-managed external model | The ModelConfig points to an internal Agent Gateway provider route. Provider credentials remain centrally managed, and access is granted per workspace and model. |
User-created external ModelConfig | The agent uses the provider credential stored in the workspace Secret and connects through that configuration. This path is not automatically routed through the centrally managed provider gateway. |
Workspace users select an available Model Configuration when creating an Agent. Administrators manage centralized providers and workspace model grants under External Models.
MCP Federation and Tool Selection
prokube combines the MCP endpoints available in a workspace into a federated Agent Gateway backend. kagent discovers that backend through the workspace RemoteMCPServer named gateway-mcp. This gives agents one stable MCP connection even when the set of workspace MCP servers changes.
When configuring an Agent, you can either:
- select individual discovered tools, which stores their names in the Agent's
mcpServer.toolNamesfield; or - attach the complete
RemoteMCPServerwithouttoolNames, which makes all current and future tools from that connection available to the Agent.
Tool selection controls which tools kagent presents to that Agent. Do not treat it as an independent network-security boundary: prokube does not currently materialize a separate Agent Gateway authorization policy for each Agent and selected tool. Use workspace separation and narrowly scoped MCP servers when a capability requires stronger isolation.
See Agents for the UI workflow and MCP Servers for deploying and operating tool servers.
Agent-to-Agent Routes
prokube creates an A2A route for each supported kagent Agent. Other workloads can use that route to invoke the Agent without depending on its backing Pod or Service address.
Workloads in the same workspace can use the internal route with their workload identity and do not need an API key. Calls from other workspace or cluster namespaces are denied. External clients use the public /svc/a2a/<workspace>/<agent> path and an API key scoped to that Agent.
External Clients
Agent Gateway also exposes workspace services to SDKs, automation, CI jobs, and agents outside the platform. Public routes are grouped by service type: /svc/ai, /svc/mcp, and /svc/a2a.
External clients can also call an admin-granted model through /svc/ai/<workspace>/models/<route-id>/v1/.... Granted models are not listed as individual services on the API Keys page, so the client needs a Bearer-format key with All external AI models, All AI models, or Full workspace access. Such a key covers every granted model in the workspace. See API Keys.
External access is configured through service-scoped API keys, not on this page. See API Keys for creating, rotating, and restricting keys and Agent Gateway for the public routing model.
Observability
Traffic routed through Agent Gateway provides a common collection point for request metrics, logs, and traces. The currently documented user-facing view is the API Key Usage Dashboard, which covers requests authenticated with an API key and does not represent all internal agent traffic.
For workload logs, Kubernetes events, metrics, and currently available tracing workflows, see Observability. The underlying agentgateway data plane supports OpenTelemetry-based metrics and tracing integrations.