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

AI Agents

  • AI Agents agent-platform v4.47.0

    Added

    • (model-serving) Presets on four GPUs — tensor parallel beside resources.gpus; Mistral Small 4 and gpt-oss-120b on g6e.12xlarge in #598 by @teemow

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.46.0...v4.47.0

  • AI Agents agent-platform v4.46.0

    Added

    • qwen3-8-27b-l40s serves NVIDIA’s own Qwen3.8-27B-NVFP4 checkpoint from its signed model image (giantswarm/agent-platform#591): nvidia/Qwen3.8-27B-NVFP4 (20.4 GiB — NVFP4 on the MLPs and the language-model head, FP8 on the attention layers) replaces the Inferact repack’s hf:// source; the preset gains the model-image environment (HOME, HF_HOME and VLLM_CACHE_ROOT under /tmp) and declares 21 + 20 GiB. Parsers, the thinking-off default and the 64k context are unchanged; qwen3-8-27b, the Blackwell recipe, still serves the Inferact repack.

    Removed

    • The presets no single card holds: qwen3-5-27b, qwen3-coder-next and qwen3-5-35b-a3b (giantswarm/agent-platform#591): 54 GiB BF16, 80 GiB FP8 and 70 GiB BF16 of weights exceed the 48 GB GPU they would target; the presets above are their model-image successors of the same shape. The shipped set goes from twelve to eleven presets; tests/verify-gpu-pool.py leaves each side’s own presets out of the golden comparison until the golden carries this change.
  • AI Agents muster v5.27.9

    Fixed

    • muster agent --mcp-server and the REPL wait for a slow tool. The CLI’s MCP client bounded every request at 30 s, tool calls included, while a tool behind the aggregator may legitimately take longer – an MCPServer’s spec.timeout allows up to 300 s – so a tool that answered after a minute succeeded through the aggregator and failed through the bridge with transport error: ... context deadline exceeded after exactly 30 s; muster agent --timeout was bound to nothing. A tool call now runs under a timeout of its own, five minutes by default (the aggregator’s largest tool timeout), for the bridge, the REPL’s call and every CLI command that calls a tool (muster call among them); the handshake, listings, resources and prompts keep their 30 s. muster agent --timeout sets the call timeout for the REPL and the bridge, and the bridge’s call_tool takes an optional timeout argument (seconds) that bounds one call in its place – for a client that knows a read takes longer; the argument is the bridge’s own and never reaches the aggregator. (#1293)
  • AI Agents agent-platform v4.45.1

    Fixed

    • The image-verification egress names the registry’s blob storage (giantswarm/agent-platform#599, the live check of 4.44.3). The registry redirects a blob read — the Sigstore bundle’s layer — to an Azure Storage account (<account>.blob.core.windows.net), not to a dedicated data endpoint: with 4.44.3’s allow-list Kyverno’s admission controller got past DNS and the registry and stopped at failed to fetch referrer layer: Get "https://<account>.blob.core.windows.net/…", every model pod still denied. modelServing.imageVerification.kyvernoEgress.hosts defaults to *.blob.core.windows.net in place of *.*.data.azurecr.io (a registry with dedicated data endpoints names that pattern itself), mirrored in both charts; make verify-model-serving-policies holds the default list.
  • AI Agents agent-platform v4.45.0

    Removed

    • The Qwen3 small presets qwen3-4b-instruct, qwen3-8b-fp8 and qwen3-14b (giantswarm/agent-platform#591). They pinned 2025 checkpoints whose successors are smaller or stronger under the same licence and are replaced by the 24 GB line-up above (qwen3-5-4b for the 4B, qwen3-5-9b-fp8 or gemma-4-12b for the 8B, gpt-oss-20b or gemma-4-12b for the 14B — which, at 28 GiB of BF16 weights, never fit a 24 GB card and was tuned for a 128 GB node). The upgrade removes their ConfigMaps; a model already served from one keeps serving (the LLMInferenceService is model-manager’s object), and an installation that wants one back carries its file under modelServing.presets (UPGRADE.md).
  • AI Agents agent-platform v4.44.3

    Fixed

    • Image verification renders the egress Kyverno’s admission controller needs, so a model pod is admitted on an installation whose Kyverno may reach the API server only (giantswarm/agent-platform#599). A verifyImages rule is evaluated by Kyverno’s admission controller itself: it fetches the image’s Sigstore bundle from the registry and verifies it against the Sigstore trust root. The fleet’s Kyverno chart gives the admission controller a CiliumNetworkPolicy allowing egress to the API server only, and Cilium’s default-deny takes the rest — DNS included —, so every fetch failed before it started (failed to fetch bundles: … dial tcp: lookup gsoci.azurecr.io: i/o timeout), and since verifyImages runs in the mutating webhook with failurePolicy: Fail, the error denied the pod whatever failureAction said (Audit too): from the switch’s default-on (4.43.0) every model pod on such an installation was refused, its ReplicaSet retried with backoff, the LLMInferenceService stayed MinimumReplicasUnavailable and no GPU node was launched — seen on an installation minutes after the release rolled, invisible to the lab’s proof, whose Kyverno runs without that policy. The connectivity chart now renders, where the image-verification ClusterPolicy renders and the network-policy flavor is cilium, one CiliumNetworkPolicy <release>-model-serving-image-verification-egress in Kyverno’s namespace selecting the admission controller pods, with DNS through Cilium’s DNS proxy and TCP 443 to the registry hosts (gsoci.azurecr.io, the Azure Container Registry data endpoints *.*.data.azurecr.io a blob read is redirected to) and the Sigstore hosts (tuf-repo-cdn.sigstore.dev, the trust root; rekor.sigstore.dev, the transparency log the keyless attestor names) — additive to whatever Kyverno’s own policies allow. The block is modelServing.imageVerification.kyvernoEgress (enabled, namespace, podSelector, hosts as toFQDNs entries), mirrored in both charts; enabled: false renders none for a Kyverno that reaches the registry already; an empty podSelector (the default) selects the upstream chart’s admission-controller labels and a set one renders alone; the guards refuse an empty namespace or host list, a selector that is no mapping, a host that is no toFQDNs entry, a nulled block and an unknown key, naming the key. make verify-model-serving-policies asserts the default render, the switches, the guards and the meta chart’s forwarded values. UPGRADE.md, “image verification renders the egress Kyverno’s admission controller needs”.
  • AI Agents agent-platform v4.44.2

    Fixed

    • The hook Jobs get memory headroom, and the storage-version backup no longer parses this chart’s own release (giantswarm/agent-platform#593; a lab, 2026-09-19). The pre-upgrade backup hook pod ran with a 128Mi limit and was OOM-killed three seconds into its first kubectl calls — the kernel’s report shows the pod’s cgroup at 128Mi with only sh and one kubectl (17 MiB) alive, the rest held by nothing that was still running — and the Job’s retry pod finished nine seconds later: a headroom problem, not a leak. Measured in the hook image against a large installation (1069 release Secrets, 715 CRDs): one kubectl run peaks near 50 MiB with a cold discovery cache, the decode of the largest release Secret (4.3 MB of JSON) near 35 MiB, helm get values on this chart’s release near 80 MiB — nothing a hook does scales with the cluster, so every hook Job (agent-platform.hooks.job and the self-management hooks) now runs with limits.memory: 512Mi, the requests unchanged at 10m / 32Mi. The one allocation that did grow with the payload is gone: the backup’s release scan pre-filtered with a plain grep for kagent.dev/v1alpha2, which this chart’s own release matches on every installation — the hook script is stored under .hooks[] — so jq parsed every kept revision of the meta release on every upgrade; the pre-filter is now the JSON-encoded marker apiVersion: kagent.dev/v1alpha2\n (the version followed by an encoded newline, what only a manifest document carries; script text encodes the same newline as a doubled backslash), and a 4.x installation’s upgrade runs no jq at all. make verify-kagent-storage-version asserts the marker, refuses the plain grep, runs the marker against two fixtures (this chart’s rendered backup Job stored as a hook next to a manifest without kagent objects; a manifest naming a v1alpha2 object) and pins both hook Jobs’ resources.
  • AI Agents agent-platform v4.44.1

    Changed

    • The substrate chart’s third-party image defaults are pinned to their gsoci copies in the forwarded substrate.images block, and make verify-images sees a bare Docker Hub name (giantswarm/agent-platform#575, #580). The substrate release ran postgres:18-alpine@…, rustfs/rustfs:… and amazon/aws-cli:… from Docker Hub — short names whose registry is the node runtime’s call — and the atenet router’s and egress’s agentgateway from the line’s ghcr build: the chart’s own images: defaults, forwarded verbatim by a block that set none of them, so the check that holds every default to gsoci never saw them. substrate.images.{postgres,rustfs,agentgateway} now name the gsoci.azurecr.io/giantswarm/… copies at the same digest (postgres:18.4-alpine@… — the mirror carries Docker Hub’s floating 18-alpine digest under its own tag — rustfs:1.0.0-beta.3@…, agentgateway:v1.5.1-gs.4); images.awsCli is forwarded at the chart’s own short name on purpose — the rustfs-bucket-init Job is a release resource whose pod template is immutable, so a changed image fails the upgrade of every installation running the bundled store — and moves with the Substrate release whose Job can be recreated. tests/verify-images.py fails a string under a key named image, or an entry of a map or list named images, that is shaped like an image reference off gsoci — a bare name included — and tolerates the bucket-init image by name until then; the new make verify-substrate-images pulls every Substrate release the range admits and holds each pin to the release default’s digest or tag under gsoci, renders the release with the forwarded block and the bundled store on, and refuses a third-party image left off gsoci, so a Substrate re-pin that moves a default (another agentgateway build, a newer postgres) cannot leave the meta chart forwarding the old one. README “Agent Substrate”; UPGRADE.md.
  • AI Agents muster v5.27.8

    Fixed

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.27.7...v5.27.8

  • AI Agents klaus-operator v0.0.164

    Changed

    • (deps) Update gsoci.azurecr.io/giantswarm/alpine docker tag to v3.24.2 in #215 by @renovate[bot]

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