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

AI Agents

  • AI Agents agent-platform v4.59.0

    Changed

    • components.klaus-gateway.versionRange admits the 2.x line (>=1.20.0 <3.0.0) (giantswarm/klaus-gateway#319). klaus-gateway 2.0.0 is the Slack-only gateway: the web and CLI channels, the OpenAI-compatible /v1 front door and the Klaus instance path are removed there; the values keys this chart still forwards for them (cli, lifecycle, upstream, agentgateway, routing.defaultTTL, a2a.saToken) are accepted by the 2.x chart as no-ops, so the installations roll to it unchanged. Those keys leave this chart in a later change, once the 2.x line has rolled.
  • AI Agents agent-platform v4.58.2

    Changed

    • The kagent controller’s memory limit is 1536Mi, and its VPA can recommend up to 1280Mi: kagent.controller.resources, kagent.controller.vpa.maxAllowed.memory (giantswarm/agent-platform#455 follow-up). The meta chart sets the controller’s resources to the kagent chart’s defaults with the memory limit raised from 512Mi, and the VPA’s memory cap moves from 480Mi to 1280Mi in both charts. make verify-kagent-vpa asserts the limits on the kagent release and the new cap. UPGRADE.md.

    Fixed

    • The agentgateway data plane declares cpu and memory on both sides of its budget, so CPU_LIMIT is the pod’s and not the node’s (giantswarm/agent-platform#629, mechanism corrected in #631). gateway.parameters.dataPlaneResources carried an ephemeral-storage request and limit only — the pair the require-emptydir-requests-and-limits Kyverno policy needs for the writable /tmp emptyDir the controller injects. The container’s cpu and memory requests came from the agentgateway controller’s own defaults (100m / 128Mi, merged in under the container’s name), and it had no cpu or memory limit at all. The cpu limit is load-bearing beyond capping the container: the generated pod carries CPU_LIMIT as a resourceFieldRef on this container’s own limits.cpu (divisor: 1), and a resourceFieldRef against an unset limit resolves to the node’s allocatable capacity, not the pod’s budget — so the data plane sized its worker threads for whatever node it landed on. On gazelle, a 3.4 CPU node gave CPU_LIMIT 4; it is now 2. The block declares requests cpu 100m / memory 128Mi (what the controller already injected, so the render of the requests is unchanged — stated here so the whole budget is in one place and a controller default change on an agentgateway bump cannot move it) and limits cpu 2000m / memory 512Mi, the ephemeral-storage pair unchanged. limits.cpu is read as whole cores rounded up, so the value IS what the proxy sees. The memory limit feeds no env var — the data plane is Rust, and the pod carries no GOMEMLIMIT/GOMAXPROCS — so it is a plain cgroup ceiling; 512Mi is roughly 15x the working set measured on gazelle (12-33 MiB across both replicas). Both charts carry the block: the meta chart forwards its whole values tree to the connectivity release and a forwarded copy of a default shadows the child’s, so a connectivity-only default would never have reached an installation (the #303 shape, and #522 again). make verify-dataplane-ha asserts cpu, memory and ephemeral-storage on each side of the rendered container’s budget — each side cut out on its own, because a grep window over limits: runs on into requests: and passes a container that has no limit at all — that an installation’s own limits reach the container in millicores, and that the meta chart forwards the two limits; tests/verify-mirrored-values.py holds all six leaves equal between the two charts, so the budget cannot drift the way the egress lists did. Every installation gets a data-plane pod roll. The PodDisruptionBudget does not cover it — a budget governs evictions, not a Deployment’s own rolling update — and the AgentgatewayParameters sets no strategy, so the roll runs at whatever the agentgateway controller defaults to across the two replicas.
  • AI Agents agent-platform v4.58.1

    Fixed

    • (connectivity) The agentgateway data plane’s cpu and memory limits make GOMEMLIMIT and GOMAXPROCS the pod’s, not the node’s in #629 by @marians

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.58.0...v4.58.1

  • AI Agents muster v5.29.3

    Fixed

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.29.2...v5.29.3

  • AI Agents klaus v0.1.28

    Changed

    Full Changelog: https://github.com/giantswarm/klaus/compare/v0.1.27...v0.1.28

  • AI Agents klaus v0.1.27

    Fixed

    • (deps) Update module github.com/giantswarm/mcp-toolkit to v0.2.10 in #496 by @renovate[bot]

    Full Changelog: https://github.com/giantswarm/klaus/compare/v0.1.26...v0.1.27

  • AI Agents klaus-operator v0.0.165

    Changed

    Full Changelog: https://github.com/giantswarm/klaus-operator/compare/v0.0.164...v0.0.165

  • AI Agents klaus v0.1.26

    Changed

    Full Changelog: https://github.com/giantswarm/klaus/compare/v0.1.25...v0.1.26

  • AI Agents muster v5.29.2

    Fixed

    • muster agent --mcp-server no longer loses a tool’s answer behind a notification. The bridge opens no standalone GET stream, so every notification the aggregator sends its session – notifications/tools/list_changed as SSO connections are established at connect, as the person’s session connects further servers, as a backend re-lists – is written onto the response stream of the call_tool in flight, ahead of the result. The bridge’s transport handed each one to Client.NotificationChan with a blocking send on the goroutine that reads that stream; the channel holds ten and nothing read it in this mode, so the eleventh notification of the process’s life stopped the reader in front of the call’s result and the call ended in the bridge’s timeout (Meta-tool execution failed: tool call failed: transport error: context deadline exceeded) while the aggregator had answered in seconds – giantswarm-platform-manager’s platformctl installation verify lost the live half of every verify of the hub that way. The hand-off never waits now (a notification the queue has no room for is dropped and logged; a list_changed is a signal to re-list, one queued stands for all that follow), and in --mcp-server mode the bridge reads the queue, lets its caches follow a list_changed and relays the aggregator’s list_changed notifications to the assistant as its own, which its tools.listChanged capability promised – after the pending-auth upgrade too. (#1309)
  • AI Agents agent-platform v4.58.0

    Added

    • The llm-d controller’s metrics reach the observability platform: kserve-llmisvc-resources.kserve.llmisvc.controller.serviceMonitor (giantswarm/giantswarm#36711, giantswarm/kserve#88). serviceMonitor.enabled is auto and follows the resolved global.observability.metrics.serviceMonitor.enabled like every other monitor of this platform, and serviceMonitor.labels carries the tenant label. metricsSecure: false serves the controller’s metrics as plain HTTP on :8443, because the fleet’s collector does not authenticate to the secure endpoint. The three kserve components move to 0.5.x, the first line with these keys.