AI Agents

  • Fixed

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.32.13...v5.32.14

  • Added

    • A “kagent Controller” Grafana board (giantswarm/giantswarm#36711). dashboards/kagent/kagent-controller.json (uid agent-platform-kagent-controller) plots the kagent-controller-metrics scrape job: the gRPC/A2A API surface (kagent_grpc_server_requests_total, kagent_grpc_server_request_duration_seconds by method, rpc type and code), the mcpserver-catalog and remotemcpserver controllers’ reconcile loops and workqueues (controller_runtime_reconcile_*, workqueue_*), and the controller process (process_*, go_*). It renders only with components.kagent.enabled, alongside the existing dashboards.enabled and service-monitor gates, and each row stays hidden until its own series exist. Linked from the Overview board’s intro table.
  • Added

    • model-manager.serviceMonitor, agent-manager.serviceMonitor and cluster-manager.serviceMonitor, enabled: auto by default like every other monitor of this platform (giantswarm/giantswarm#36711). The meta chart resolves auto from the resolved global.observability.metrics.serviceMonitor.enabled, scrapes every 60s and sets labels."observability.giantswarm.io/tenant": giantswarm. The connectivity chart’s ingress policies of the three managers admit each chart’s metrics port (<manager>.observability.metrics.port, 9464 by default) from the cluster entity while <manager>.observability.metrics.enabled, in both flavours, never the API port. components.model-manager.versionRange is >=1.5.0 <2.0.0 (giantswarm/model-manager#203), components.agent-manager.versionRange >=1.4.0 <2.0.0 (giantswarm/agent-manager#76) and components.cluster-manager.versionRange >=0.22.0 <1.0.0 (giantswarm/cluster-manager#138), the releases that carry serviceMonitor and observability.metrics; the customer BOM pins the same versions. make verify-managers asserts the ports and the forwarded monitors.
  • Changed

    • (golden) Compare against committed renders instead of origin/main in #635 by @fiunchinho

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.93.1...v4.93.2

  • Fixed

    • (deps) Update module github.com/giantswarm/selfupdate-cosign to v0.3.1 in #361 by @renovate[bot]

    Full Changelog: https://github.com/giantswarm/klausctl/compare/v0.4.19...v0.4.20

  • Fixed

    • (deps) Bump go.opentelemetry.io/otel to v1.46.0 (CVE-2026-81870) in #363 by @teemow

    Full Changelog: https://github.com/giantswarm/klausctl/compare/v0.4.18...v0.4.19

  • Fixed

    • The four Flux Operator CRDs upgrade with the chart (giantswarm/agent-platform#728). The flux-engine subchart carries fluxinstances, fluxreports, resourcesets and resourcesetinputproviders (fluxcd.controlplane.io) in crds/, which Helm and helm-controller install once and never upgrade, and the operator does not manage them: every installation kept the CRDs of its first install. With the bundled engine a pre-install/pre-upgrade hook Job <release>-flux-operator-crds (weight -9) now server-side applies them from a hook ConfigMap carrying the subchart’s file, field manager agent-platform. The seven Flux CRDs stay the operator’s. UPGRADE.md’s manual apply step is gone. make verify-engine asserts the hook and that the ConfigMap is the subchart’s file.
  • Fixed

    • A token exchange answered by a proxy names what answered. When something other than the remote Dex answers the RFC 8693 exchange, typically an ingress or proxy returning an HTML page, the exchange error and its audit line carried the whole page. mcp-oauth v1.4.10 describes such an answer by its status, content type and HTML title, or by the first 200 bytes of anything else (token exchange failed with status 401 (content type "text/html", not an OAuth error response): HTML page "401 Authorization Required"). A 5xx answer still marks the server Failed. (giantswarm/giantswarm#36943)
  • Fixed

    • (deps) Update module github.com/giantswarm/apptest-framework/v5 to v5.3.0 in #1346 by @renovate[bot]

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.32.11...v5.32.12

  • Added

    • mcp-kubernetes.mcpServer: the bundled mcp-kubernetes registers as a member of muster’s kubernetes family, or not at all (giantswarm/agent-platform#403). With managementCluster: <name> the connectivity chart renders the MCPServer the way agent-platform-mcps renders every management cluster’s: <name>-mcp-kubernetes, labelled muster.giantswarm.io/management-cluster: <name>, with spec.family {name: kubernetes, instanceArg: management_cluster}. A single-installation deployment (the agentlab) gets the fleet’s x_kubernetes_<tool> tools, management_cluster: <name>-mcp-kubernetes selecting it (muster offers a family’s members by their MCPServer names). With enabled: false it renders no CR, and an agent-platform-mcps.mcpServers entry does the registration without a duplicate. The default, the family-less singleton mcp-kubernetes, is unchanged. The meta chart drops the block from the values forwarded to the mcp-kubernetes chart. make verify-mcp-kubernetes-registration.