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

AI Agents

  • AI Agents muster v5.19.7

    Fixed

    • A suspended MCPServer is not started when muster boots (#1216). The orchestrator’s boot pass created and started a service for every definition with autoStart: true without looking at spec.suspended (what core_service_stop and a portal’s Deactivate write), and the reconciler’s first pass then stopped it again: per restart and per suspended server one Creating MCPServer service / Starting MCP server service / Suspending MCPServer service <name> (spec.suspended=true) sequence in the log, one connection attempt against a backend the operator had switched off, a MCPServerStarting and a MCPServerStopped event, status.lastAttempt moved to the boot time, and – when the connect won the race against the stop – a window in which the deactivated server’s tools were registered in the aggregator and callable. The boot pass now skips a suspended definition the way it skips autoStart: false (Skipping MCPServer <name>: Suspended=true at debug level); the server keeps reading Disconnected (stdio: Stopped) through the reconciler’s no-service branch, its status keeps its pre-restart lastAttempt, and spec.suspended: false still starts it. muster test: a pre-configured mock server accepts suspended: true, which also takes it out of the readiness gate. Scenario: mcpserver-suspended-not-started-at-boot.
  • AI Agents agent-platform v4.13.1

    Fixed

    • klaus-gateway’s egress reaches its stores: the platform’s Valkey and the Kubernetes API (giantswarm/agent-platform#443; a Cilium installation, 2026-09-14). The connectivity chart’s two policies selecting the gateway pod (-klausgateway-a2a-egress: DNS and the agentgateway data plane on 8080; -klausgateway-obo-egress: world / cluster on 443 and 10443) put it in Cilium default-deny egress and neither named the Valkey pods or the kube-apiserver entity — the API’s Service address is resolved by Cilium’s socket-LB before the policy applies, so the cluster port rule never matched it. Every installation ran the shapes that never leave the pod (memory routing, the bolt link store, no controller), so nothing showed it until klaus-gateway 1.3.0’s Secret link store (klausGateway.obo.store: secret, giantswarm/klaus-gateway#245) was switched on: the gateway crash-looped at start on read secret …/klaus-gateway-obo-links: … context deadline exceeded (not forbidden: the Role was there, the route was not) and was rolled back by hand after about 95 s of downtime; the Valkey routing store this release adds (klausGateway.routing.store: valkey, klaus-gateway 1.6.0, giantswarm/klaus-gateway#252) would have hung every binding write and the readiness probe the same way. A third policy, -klausgateway-store-egress, now renders exactly while a store or the controller reaches beyond the pod, one rule per store: the platform’s Valkey pods (agent-platform.valkey.podSelector, the release namespace) on valkey.valkey.service.port with routing.store: valkey and the valkey component on — an out-of-band Valkey (the component off) gets no rule, its egress is the installation’s; the kube-apiserver entity (cilium) / networkPolicy.kubernetes.apiServerCIDR (kubernetes) with obo.store: secret and OBO on, routing.store: configmap or crd, or controller.enabled; DNS as in the siblings (agent-platform.klausGateway.valkeyEgress / apiServerEgress; the keys are the klaus-gateway chart’s, forwarded by the meta chart and read with that chart’s defaults when unset). The default shape renders as before, byte for byte; the five policies selecting or targeting the pod now share one agent-platform.klausGateway.fullname helper. make verify-klausgateway-netpol asserts every gate (each store alone, both together, the port following the Service, the out-of-band Valkey, the Secret store with OBO off, the bolt routing store), both flavours, the selector following klausGateway.fullnameOverride and the off switches; ci/test-klausgateway-store-values.yaml lints the cilium render with both stores, ci/test-netpol-kubernetes-values.yaml the kubernetes one. Not reproducible in agentlab (networkPolicy.enabled: false, kind runs no Cilium): verified by render and the chart’s CI; the live proof is a store switch on a Cilium installation (hubble observe --verdict DROPPED on the gateway pod stays empty). No installation acts: every one runs the default shape; a switch to obo.store: secret or routing.store: valkey needs this release first — UPGRADE.md.
  • AI Agents agent-platform v4.13.0

    Added

    • The gateway’s routing store can be the platform’s Valkey with one line (giantswarm/klaus-gateway#252, klaus-gateway 1.6.0’s routing.store: valkey). With klausGateway.routing.store: valkey the klaus-gateway release’s routing.valkey.url, existingSecret and passwordKey are filled from the valkey release — its Service (<valkey.valkey.fullnameOverride>:6379, the bare name muster’s own storage.valkey.url uses), the Secret its default user authenticates from (valkey.valkey.auth.usersExistingSecret, else the one muster reads, else global.identity.existingSecret) and that user’s passwordKey — so every thread’s binding to its agent instance and the record of a turn in flight survive a gateway restart without a volume or API-server access. An operator’s own url, Secret or key wins (an out-of-band Valkey); with any other store nothing about Valkey is forwarded, so an installation whose klaus-gateway release still resolves 1.5.x sees no new key. make verify-klausgateway-valkey asserts the three cases. On a Cilium installation the switch also needs the gateway pod’s egress to the Valkey pods on 6379 (#443, the Valkey half) — until that rule ships, routing.store: valkey is for installations without the Cilium policies only.
  • AI Agents agent-platform v4.12.3

    Fixed

    • muster-valkey gets a memory bound of its own (giantswarm/agent-platform#446; gazelle 2026-09-14). The valkey.valkey block set no maxmemory, so Valkey ran with maxmemory 0 and the container limit was its only bound: once muster’s capability cache had grown the dataset to ~246 MB (giantswarm/muster#1217) the kernel killed the process, the pod restarted, loaded the RDB back to the same size and the next background save — a fork, copy-on-write on top of the dataset — tipped it over again: 19 OOM kills in 90 minutes, nine orphaned temp-*.rdb files on the PVC, every muster token refresh blocked while the store was down, the muster connector unusable in the Dev Portal and Claude, until the limit was raised by hand (the entry above makes that limit the default). Now valkey.valkey.valkeyConfig — the upstream subchart’s raw valkey.conf fragment, which the chart had left empty — carries maxmemory 640mb and maxmemory-policy volatile-lru (evict the least recently used key that carries a TTL; every muster record does, and the store is a cache: an evicted token is one re-sign-in, an evicted capability entry one re-list on the next connect): maxmemory at ~60 % of the 1Gi limit leaves the fork’s copy-on-write pages, the client buffers and the allocator their headroom under the cgroup, and a store that grows past it evicts instead of dying. An installation’s own valkeyConfig replaces the fragment whole. make verify-valkey (tests/verify-valkey.py) holds the fragment, maxmemory at or under two thirds of the limit and above the request, the policy, no AOF, and the override’s passage (helm/agent-platform/ci/test-valkey-override-values.yaml). The config checksum rolls the muster-valkey pod once more (Recreate, a few seconds without the store; the RDB on the PVC carries the data across) — UPGRADE.md. Lab proof (agentlab, platform.chartPath from this branch): the live muster-valkey answers CONFIG GET maxmemory = 671088640 and maxmemory-policy = volatile-lru, agentlab platform-test passes.
  • AI Agents agent-platform v4.12.2

    Added

    • tests/verify-bom-charts.py, wired into make verify-meta: every chart the BOM pins is rendered against the values the meta chart forwards to it (giantswarm/agent-platform#278). verify-meta rendered the meta chart alone — it proved the HelmReleases and their values were shaped as intended, never that the chart on the other end accepts them, so a key forwarded unconditionally against a pin whose schema forbids it was invisible until an installation failed to reconcile. The check pulls each pinned chart at the version and from the registry its rendered OCIRepository names (so the ghcr.io components — kagent, Substrate — and cloudnative-pg are covered, not just the gsoci ones) and renders it with exactly the values its release carries, failing only on a schema rejection: a later template error means the values were accepted and the chart wanted an input the BOM alone does not carry, which is reported apart and counted apart. Every BOM-pinned component is enabled for the render, so a pin cannot drop out of the check because the golden render leaves that component off, and a pin with no OCIRepository or one resolved to another version fails rather than skipping silently — 21 of 21 pins covered. A self-test proves against the installed Helm that a schema rejection and a template failure are still told apart, so a reworded Helm message fails the check loudly instead of downgrading the break it exists for into a passing line. Deliberately stdlib-only, like tests/verify-toolset-presets.py: the CI image has no PyYAML. It found the two pins above on unmodified main on its first run.

    Fixed

    • The actors’ egress opens the host model servers model-manager fronts (giantswarm/agent-platform#278). model-manager with a host backend (ollama, lemonade, lmstudio) wires every pulled model into kagent as a ModelConfig pointing at that server — but only model-manager’s own policy opened it, and an actor’s inference request leaves through Agent Substrate’s egress gateway (substrate-atenet-egress), whose allow-list carries muster, the kagent controller, the tool server and world:443. A host model server is on neither 443 nor HTTPS, so every such request was dropped while model-manager reported the model as wired and healthy. The egress gateway now opens each host backend at the address the ModelConfigs actually carry — model-manager.<backend>.agentHost, falling back to .endpoint — as a toCIDR for an IP and a toFQDNs plus cluster arm for a hostname, and renders nothing while model-manager is off, for a kserve-only backend list or in the kubernetes flavour. A hostname arm also switches that policy’s DNS rule to agent-platform.dnsEgressWithProxy: Cilium fills its FQDN cache only from answers its own proxy sees, so without it the toFQDNs selector never matches and the name stays blocked; an IP-only backend list keeps the plain rule, so no installation gains an L7 DNS proxy on every actor lookup it did not need. model-manager.<backend>.agentHost is now guarded like .endpoint — an http(s) URL with a host — because the policies parse it with urlParse, which answered an empty matchName with port 80 for a scheme-less value and died on a raw parse error for a host:port one. make verify-kagent-netpol covers all of it.
    • The customer BOM pins two charts that reject the values the meta chart forwards to them (giantswarm/agent-platform#278, found by the check below). gateway.parameters.podAnnotations and klausGateway.podDisruptionBudget / .podAnnotations travel unconditionally since #431, and vm-manager / vmManager since #441, while the BOM pinned agent-platform-connectivity 4.8.0 and klaus-gateway 1.0.2 — both additionalProperties: false, so a BOM-pinned installation got two releases that could not install or upgrade whatever the operator set (additional properties 'podAnnotations' not allowed; additional properties 'vmManager', 'vm-manager' not allowed). Checked release by release: connectivity is rejected through 4.10.0 on the #431 keys and through 4.10.6 on the #441 ones, and accepted from 4.11.0; klaus-gateway is rejected at 1.0.3 and accepted from 1.1.0 — the release the #431 entry already names for its budget knob. A BOM-pinned installation should take these pins.
  • AI Agents muster v5.19.6

    Fixed

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.19.5...v5.19.6

  • AI Agents muster v5.19.5

    Fixed

    • The Valkey capability store keeps each capability document once, content-addressed, instead of once per session (#1217). A session’s hash {prefix}cap:{sessionID} held, per connected server, the server’s full tool/resource/prompt list with every input schema — 9–180 KB a server, 0.9 MB a session on one installation — for 30 days, and every forwarded bearer (a Dev Portal, kagent or Backstage ID token) is a session of its own, so identical documents were written again and again: 448 session hashes, 462 MB, and muster-valkey was OOM-killed 19 times in 90 minutes with every token refresh blocked meanwhile. The hash field is now a 71-byte reference sha256:<hex>; the document lives once under {prefix}capblob:<hex> with the store TTL, refreshed by every Set that references it. Reads resolve the references (one pipelined GET per distinct document); a reference whose document has expired is a cache miss, which the aggregator already answers by listing the server again on the next connect. Fields written by an earlier muster still read, and on start the aggregator rewrites them to references in the background (MigrateInlineEntries: one SCAN, idempotent, logged with the session, field, document and byte counts) — an installation shrinks on its first start with this release instead of after 30 days. The store is proportional to the number of distinct documents now (that installation: 84 documents ≈ 1.3 MB, the references ≈ 3.6 MB). Unit tests run the store against an in-process miniredis.
  • AI Agents agent-platform v4.12.1

    Fixed

    • muster-valkey gets the memory a grown token store needs (valkey.valkey.resources: requests 256Mi, limits 1Gi, from 64Mi / 256Mi). Valkey loads the whole RDB into memory on every start; gazelle’s store held 247 MB after three weeks and every restart under the 256Mi limit was OOM-killed — when 4.12.0 rolled the pod once for the new annotation, muster’s token endpoint stayed down for five minutes until the limit was raised by hand. UPGRADE.md carries the recognition and the recovery.
  • AI Agents agent-platform v4.12.0

    Added

    • The stateful singletons can be pinned to on-demand capacity, and muster-valkey takes the #431 guards (giantswarm/agent-platform#439; on gazelle, all-spot workers, one spot-interruption wave took muster’s OAuth token store down for two minutes — every token refresh blocked inside muster, 27 s before the Slack bot reacted — and killed klaus-gateway mid-turn, its replacement waiting four minutes on Multi-Attach). #431’s guards address voluntary disruption only; a spot reclaim terminates the instance whatever the budget says. New meta-chart block scheduling.singletons (nodeSelector, tolerations; empty by default, so no installation changes behaviour until it is set): merged into, and appended to, the scheduling knobs of the four single-replica stateful pods before their releases render — muster (muster.nodeSelector), muster-valkey (valkey.valkey.nodeSelector), the kagent controller (kagent.controller.nodeSelector), klaus-gateway (klausGateway.nodeSelector) — with a component’s own keys winning (agent-platform.scheduling.apply); held back from the connectivity release (components.agent-platform-connectivity.omitKeys), so a live connectivity chart that predates the block is never failed by it. The intended value on a Karpenter spot installation is karpenter.sh/capacity-type: on-demand (one small on-demand node for the four; the fleet’s NodePools admit it untainted) — UPGRADE.md carries the cost note, the roll and the “never on a cluster without Karpenter” warning. klaus-gateway takes the keys from chart 1.3.3 on (giantswarm/klaus-gateway#253: the earlier 1.x schemas refused every key under nodeSelector — found in the lab when the release failed validation). muster-valkey now carries karpenter.sh/do-not-disrupt: "true" (the valkey subchart’s valkey.valkey.podAnnotations) and a PodDisruptionBudget muster-valkey (valkey.podDisruptionBudget, minAvailable: 1, AlwaysAllow) rendered by the connectivity chart — neither the wrapper nor the upstream subchart has a budget knob — selecting the pod as the subchart labels it (name valkey, instance valkey), named after valkey.valkey.fullnameOverride; the key never reaches the valkey release (components.valkey.omitKeys). Every installation rolls the muster-valkey pod once. make verify-disruption extended: the merge and its precedence, the empty default (byte-identical component values), the hold-back, the valkey budget on/off/inert and its guards, a stray key under the block refused by the schema.
  • AI Agents agent-platform v4.11.0

    Added

    • (meta) Components.vm-manager — the platform’s VM provisioner as a pod of a KVM node, off by default in #441 by @teemow

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.10.6...v4.11.0