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

AI Agents

  • AI Agents klaus v0.0.320

    Fixed

    Full Changelog: https://github.com/giantswarm/klaus/compare/v0.0.319...v0.0.320

  • AI Agents muster v5.8.2

    Fixed

    • muster serve with kubernetes: true no longer falls back to filesystem mode when the Kubernetes client cannot be created at startup. The fallback was silent (one debug-level line) and left muster split in two: the reconciler’s change detector still watched the apiserver, so every existing MCPServer CR arrived as a create event, was looked up in the empty config directory as “not found” and had its service deleted (Deleting MCPServer service: … for each CR), while the orchestrator’s auto-start listed zero definitions — muster served no server tools, and the CRs kept their stale Connected status because the status writes went to the filesystem as well. It happened after a node restart, when the muster container came back before the apiserver (and the kube-proxy rules in front of it) did and the CRD discovery call failed. Startup now retries the client for about half a minute (client.KubernetesClientBackoff, each attempt logged) and then exits with kubernetes mode is configured but no Kubernetes client could be created … refusing to fall back to filesystem mode, so the kubelet restarts the container; the change detector also takes its mode from the client that was actually created rather than from the configuration flag, so the two can no longer disagree. Automatic detection (no configured mode) keeps the fallback, now logged at warning level. (#1143)
  • AI Agents muster v5.8.1

    Fixed

    • (deps) Bump golang.org/x/crypto to v0.56.0 (CVE-2026-56855) in #1146 by @teemow

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.8.0...v5.8.1

  • AI Agents klaus-operator v0.0.147

    Changed

    Full Changelog: https://github.com/giantswarm/klaus-operator/compare/v0.0.146...v0.0.147

  • AI Agents agent-platform v3.7.1

    Changed

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v3.7.0...v3.7.1

  • AI Agents muster v5.8.0

    Fixed

    • Authorization servers muster cannot discover or register with (GitHub). spec.auth.authorizationServer gains three optional fields: authorizationEndpoint/tokenEndpoint pin the endpoints of an authorization server that publishes no RFC 8414 document (muster then performs no discovery for that issuer and assumes S256 PKCE); clientCredentialsSecretRef names a Secret with a client registered out of band (a GitHub App or OAuth App), which muster uses instead of its CIMD URL or a dynamic registration (clientIdMethod: preregistered); grantScope: subject files the tokens under the user’s identity as well as the session, so any later session of the same person reuses the grant without a new consent until core_auth_logout on that server or “sign out everywhere”. Together they connect the hosted GitHub MCP server – or any in-house server that verifies GitHub tokens – to the person’s own GitHub account. See docs/how-to/connecting-non-rfc9728-mcp-servers.md.
  • AI Agents agent-platform v3.7.0

    Added

    • (model-manager) Accept a backends list — one model-manager in front of several serving backends: guards for every listed driver (enum, duplicates, Ollama/Lemonade endpoint, kserve API), one host-server egress rule per listed host backend and the Hub egress when kserve is listed, in both flavors in #263 by @teemow

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v3.6.0...v3.7.0

  • AI Agents klausctl v0.2.55

    Fixed

    Full Changelog: https://github.com/giantswarm/klausctl/compare/v0.2.54...v0.2.55

  • AI Agents agent-platform v3.6.0

    Added

    • (model-manager) Accept backend lemonade — a Lemonade Server (FastFlowLM on AMD Ryzen AI NPUs, llama.cpp) as the second host-proxying backend: lemonade.{endpoint, agentHost} in the model-manager block, the render guard, and network-policy egress to its endpoint in both flavors in #261 by @teemow

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v3.5.0...v3.6.0

  • AI Agents muster v5.7.21

    Fixed

    • A forwarded-token rejection is now attributed to the token’s audiences, not only its issuer. When a forwardToken backend answers the forwarded ID token with 401, the log line and the auth://status detail used to name the token’s iss and hint at the issuer’s JWKS — which sent an investigation towards JWKS and egress when the backend had in fact trusted the issuer and refused the token’s audience (agent-manager on gazelle: the Backstage client’s audiences were not in its trusted set). The diagnostic now reads forwarded token iss=…, aud=[…]; the backend must trust this issuer's JWKS and one of these audiences, and when the backend’s 401 carries a WWW-Authenticate challenge its error and error_description are quoted as well (agent-manager sent no identity token to act with towards the Kubernetes API; muster used to drop the header at the transport). auth://status returns the same account in the server’s error field next to reauth_required / sso_attempt_failed, so a client can show why SSO failed instead of a generic pointer to an administrator; muster auth status --server <name> prints it as Reason:. Audiences are client identifiers, and the token itself is never logged. (#1141)