agent-platform release v4.54.0

Added

• Four more boards in Shared Org / Agent Platform, from the connectivity chart’s dashboards/ directory (giantswarm/giantswarm#36711). LLM usage (uid agent-platform-llm-usage) and Usage by person (uid agent-platform-usage-by-person) move here from giantswarm/dashboards, unchanged, where they were loaded into the staff-only Giant Swarm organization; the agent_platform sub-chart there goes with them. LLM usage lives under dashboards/llm-routing/ and renders only with llmRouting.enabled: every panel of it reads a GenAI series the LLM listener alone produces. Usage by person reads the data plane’s request series by user and renders whenever the boards do. Two new boards: Klaus Gateway (uid agent-platform-klaus-gateway) over the klaus_gateway_* families the gateway’s admin port serves: requests by route and status, turns by outcome, the phases of a turn from the message’s arrival to the final flush, the Slack streaming lifecycle and rate limiting. And Valkey (uid agent-platform-valkey) over the redis_* series of the wrapper chart’s redis_exporter sidecar: memory against the limit, evictions, keys, commands, clients, hit ratio, network, rejected connections, for every instance in the platform’s namespaces. Both gate their rows on the series they read, the Overview pattern, so an installation without the component opens an empty board rather than one of “No data”. The Overview’s intro table names the four and its Valkey panels link to the Valkey board. verify-llm-routing asserts the LLM usage ConfigMap follows the switch and Usage by person does not.

Changed

• The agentgateway packaging chart’s own monitors and dashboard are on: agentgateway.monitoring.enabled (giantswarm/giantswarm#36711, giantswarm/agentgateway#60). It follows the resolved global.observability.metrics.serviceMonitor.enabled like every other monitor of this chart (auto | true | false), at the fleet’s 60s interval and with the observability.giantswarm.io/tenant label on both monitors. It turns on three objects the platform did not have: the controller ServiceMonitor, which nothing scraped, and with it the only view of the control plane that serves the data planes their config; upstream’s proxy PodMonitor; and upstream’s own Grafana board — Overview, Requests, LLM, MCP tool calls, Latency, XDS, Runtime — vendored in the packaging chart since 2.0.0 and never rendered. The MCP and runtime series it reads were already collected and had no consumer. The board is upstream’s to maintain, so a version bump carries its fixes; the boards the platform writes itself (LLM cost per agent and per person) ship in this chart’s dashboards/ directory.