1. Docs
  2. Changes and releases
  3. AI Agents

AI Agents

  • AI Agents muster v5.15.2

    Fixed

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.15.1...v5.15.2

  • AI Agents klaus v0.1.4

    Fixed

    Full Changelog: https://github.com/giantswarm/klaus/compare/v0.1.3...v0.1.4

  • AI Agents agent-platform v3.22.2

    Changed

    • components.kagent.versionRange is >=0.2.0 <1.0.0 (was 0.2.x): the floor stays at the flattened chart the wiring needs, the ceiling moves to the next major, as for the other 0.x components. The giantswarm/kagent wrapper released 0.3.0 and 0.3.1 on 2026-09-09 from CI-only changes (giantswarm/kagent#73, a feat(ci) title — a minor bump to git-cliff — and the align run giantswarm/kagent#71) with a chart identical to 0.2.2 in templates, values and dependencies: only Chart.yaml’s version and its tag-derived annotation URLs differ. The 0.2.x range excluded both, so every installation would have stayed on 0.2.2 and missed every wrapper release from here on, the next fix included. Every installation with kagent on upgrades the kagent release 0.2.2 → 0.3.1 on its next reconcile: two labels change on every object (helm.sh/chart, app.kubernetes.io/version — the wrapper stamps its chart version as the app version) and the pod annotations that hash the labelled ConfigMaps and Secret change with them, so the kagent controller and UI pods roll once; nothing else in the render changes. The meta chart’s fleet render differs by the kagent OCIRepository’s semver line only. make verify-meta asserts the range; examples/customer-bom.yaml keeps its exact 0.2.0 pin.
  • AI Agents agent-platform v3.22.1

    Changed

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v3.22.0...v3.22.1

  • AI Agents muster v5.15.1

    Fixed

    • (mcpserver) Recover the MCP session after a streamable-http backend is redeployed in #1186 by @fiunchinho

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.15.0...v5.15.1

  • AI Agents agent-platform v3.22.0

    Added

    • gitops.forbidPinnedLoginConnector (default false): with true the render fails when muster.muster.oauth.server.dex.connectorId is set, naming the key. A pinned connector makes muster (through mcp-oauth) append connector_id to every Dex authorization request, so Dex’s connector chooser never appears; on an installation whose Dex serves several identity providers — the operator’s and the tenant’s — the pin hides every other connector, and people from those providers either cannot sign in to muster or, when the pinned connector is not the provider their MCP-server allowlists (allowedGroups, RBAC) are written for, receive a token without those groups. Backstage and the kagent UI leave the choice to Dex; the knob lets a fleet template hold muster to the same rule against a per-installation override, at render time and with the same shape as gitops.forbidInlineSecrets. Meta-package plumbing: not forwarded to the muster release. No installation needs to act: off by default, every render is unchanged. make verify-login-connector asserts the four cases (default renders and forwards a pin; on plus a pin fails naming the key and never repeating the value; on plus an empty or absent key renders; the knob reaches no child release).
  • AI Agents muster v5.15.0

    Fixed

    • oauth.mcpClient.tokenExchange.allowPrivateIP (Helm: muster.oauth.mcpClient.tokenExchange.allowPrivateIP): the token endpoint of a remote Dex muster exchanges tokens with (spec.auth.tokenExchange.dexTokenEndpoint) may resolve to a private or loopback address – a management or workload cluster whose Dex sits behind an internal-only load balancer. Until now only --extra-ca-file lifted the token-exchange client’s SSRF guard, so an exchange against such a Dex failed with a DNS-rebinding error although the endpoint was reachable. Off by default; emits a startup warning when set; TLS verification is unchanged.
  • AI Agents agent-platform v3.21.2

    Fixed

    • The data-plane NetworkPolicy admits the Prometheus scrape of the agentgateway data plane (pod port 15020, /metrics), in both flavours. The PodMonitor this chart renders targets that port, but the policy’s only ingress rule listed the Gateway’s listener ports — 8080, and 8081 once llmRouting is on — so Cilium dropped every scrape: measured on graveler, the target reported up=0 with scrape_samples_scraped=0 for as long as the monitor had existed, JobScrapingFailure sat pending against it, and not one GenAI or HTTP series ever reached the tenant’s Mimir. The monitor was therefore inert from the moment it was added, and the LLM cutover’s whole point — tokens, cost and latency per model call — produced nothing on an installation that had done both rollout steps correctly. A second fromEntities: ["cluster"] rule now admits 15020, exactly as the sibling controller policy admits the controller’s own 9092/9093; the port is fixed by the agentgateway controller (it names the container port metrics and sets the prometheus.io/* annotations), not an operator choice, so it is written literally rather than as a value. Unconditional, like that sibling rule, because a cluster may scrape by pod annotation with no PodMonitor at all. An installation with the agentgateway component on gains one ingress rule on that policy and starts reporting the data plane’s metrics; nothing else changes and no pod rolls. make verify-llm-routing asserts the port in both flavours and with llmRouting off, where the monitor already renders; reverting either template fails it.
  • AI Agents agent-platform v3.21.1

    Changed

    • Ignore graphify-out/ (regenerable knowledge graph) in #322 by @teemow

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v3.21.0...v3.21.1

  • AI Agents klaus-operator v0.0.157

    Changed

    • Ignore graphify-out/ (regenerable knowledge graph) in #209 by @teemow

    Full Changelog: https://github.com/giantswarm/klaus-operator/compare/v0.0.156...v0.0.157