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

AI Agents

  • AI Agents klaus-operator v0.0.144

    Changed

    Full Changelog: https://github.com/giantswarm/klaus-operator/compare/v0.0.143...v0.0.144

  • AI Agents muster v5.6.6

    Fixed

    • (testing) Make readiness failures self-attributing in CI logs in #1109 by @teemow

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.6.5...v5.6.6

  • AI Agents muster v5.6.5

    Fixed

    • muster test --readiness-timeout: the per-instance deadline for expected resources (tools, workflows, MCP servers) to become available after startup is now configurable (default 15s, previously hardcoded). (#1101)
    • muster test no longer starts every scenario’s instance at t=0: at high --parallel the cold-start herd (50 Go processes at once) is what starved small CI containers into intermittent 15s readiness timeouts and scenario-timeout kills. Startups are now bounded (--startup-parallel, default 8) without limiting steady-state scenario parallelism, and spawned test instances run with GOMAXPROCS=2 so a container that reports the host’s core count (CircleCI docker executors allocate CPU by cgroup shares, which Go cannot right-size against) no longer produces fifty host-sized runtimes on a 4-vCPU slice. The suite banner prints GOMAXPROCS/NumCPU so CI logs show the runtime sizing. (#1101)
  • AI Agents muster v5.6.4

    Fixed

    • (testing) Make the instance readiness deadline configurable, raise it for CI in #1105 by @teemow

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.6.3...v5.6.4

  • AI Agents muster v5.6.3

    Fixed

    • (deps) Bump x/mod and pin goldmark for fresh OSS Index CVEs in #1106 by @teemow

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.6.2...v5.6.3

  • AI Agents agent-platform v3.0.4

    Changed

    • The valkey component ships deploymentStrategy: Recreate. The single pod owns an RWO PVC, so under RollingUpdate every values or chart change deadlocked the rollout: with one replica maxUnavailable is 0, the new pod waited on Multi-Attach for a volume the old pod held, and Helm timed out after 5 minutes. An installation that pinned valkey.valkey.deploymentStrategy keeps its own value. The store is a cache, so the restart gap between the two pods costs nothing.
  • AI Agents agent-platform v3.0.3

    Changed

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v3.0.2...v3.0.3

  • AI Agents agent-platform v3.0.2

    Added

    • A PolicyException for the CNPG instance pods, and the kyvernoPolicies.volumeTypesPolicyName (restrict-volume-types) and kyvernoPolicies.volumeTypesRuleNames (restricted-volumes, autogen-restricted-volumes) keys it targets, in both charts. The connectivity chart renders it only when postgres.vector.extensionImage.reference is set, the one configuration where a CNPG pod mounts an image volume, which is not in that policy’s allowed types. Without the exception admission rejects every instance pod, the Cluster reaches no active instance, and the kagent controller crashloops on its pgvector check. The exception matches on the cnpg.io/cluster label of postgres.clusterName, so it covers that Cluster’s pods and the operator’s bootstrap Jobs only. No installation needs to act unless its cluster names those policies differently.
  • AI Agents agent-platform v3.0.1

    Fixed

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v3.0.0...v3.0.1

  • AI Agents agent-platform v3.0.0

    Added

    • components.<name>.enabled on agent-platform-connectivity, the same key path the meta chart reads. The meta chart forwards the component roster, stripped to enablement, into the values of that release, so the wiring the chart renders for a component agrees with whether the component has a release. Set it directly only when installing agent-platform-connectivity on its own.
    • kyvernoPolicies.enabled (default true) in both charts. Set it to false on a cluster that has no Kyverno: the connectivity chart then renders none of its kyverno.io objects (the two kagent declarative-agent ClusterPolicies, the kagent seccomp PolicyException, the agent-sandbox pod-security ClusterPolicy), which otherwise fail the install on an unknown API group. No installation needs to act. A cluster that enforces restricted PSS through PSA labels instead of Kyverno must set components.agent-sandbox.enabled: false as well, or agentSandbox.podSecurity.enabled: false where nothing enforces restricted PSS; the render now fails with that instruction instead of shipping a controller Deployment with no securityContext.

    Changed

    • The agentgateway component tracks the 2.x chart line, which flattened the upstream keys onto the chart root. The forwarded values block is no longer nested under an agentgateway key. The top-level agentgateway: values block otherwise keeps its shape, so only the toggle moves. examples/customer-bom.yaml pins 2.0.0.

    Removed

    • The six per-chart component toggles: agentgateway.enabled, valkey.enabled, mcps.enabled, kagent.enabled, klausGateway.enabled and agentSandbox.enabled. components.<name>.enabled is now the only on/off switch for a component, and every installation that sets one of the old keys must move it — see UPGRADE.md for the key-by-key move. components.<name>.enabled already existed and already won over the old enabledFrom indirection, so a component could be disabled two ways and the two answers could disagree: components.agentgateway.enabled: false with agentgateway.enabled: true rendered no agentgateway release but still rendered that controller’s ListenerSet ClusterRole.
    • components.<name>.enabledFrom, the indirection from a component entry to a per-chart toggle. There is nothing left to point at.
    • Both charts fail the render when one of the removed keys is still set, and name its replacement. Those value blocks accept unknown keys, so an ignored enabled would silently turn the component off.
    • The mcps: values block. It only ever held the toggle; the chart’s values keep living under agent-platform-mcps:.