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

AI Agents

  • AI Agents agent-platform v4.8.1

    Fixed

    • A deleted platform Harness is recreated by the kagent release on its next reconcile (giantswarm/agent-platform#409): the kagent HelmRelease carries spec.driftDetection.mode: enabled — on every reconcile (gitops.interval) helm-controller compares the release manifest with the cluster and re-applies what differs or is missing, as a server-side apply without a Helm revision. Without it a plain reconcile of the unchanged release reported “in-sync”, and the Harness a consumer skipping 4.7.19 lost on the 4.8.0 upgrade stayed deleted — every template unadmitted, 600 s observed — until a forced reconcile. components.<name>.driftDetection is a passthrough for every component entry (HelmRelease v2 spec.driftDetection: mode, ignore), set for kagent only; tests/verify-kagent-wiring.py asserts it and that no other release carries one by default, and the ATS smoke deletes the Harness and sees it back on a requested (not forced) reconcile with both templates Ready and no revision written. UPGRADE.md’s 4.8.0 note names the forced-reconcile recovery for an installation on 4.8.0 exactly; the customer BOM example pins the connectivity chart to the release it is published with.
  • AI Agents agent-platform v4.8.0

    Added

    • (kagent) The kagent chart names its own images — drop kagent.tag, the workerImage and Harness pins; the platform Harness is the kagent release’s; atelet’s pinned set from the chart’s ConfigMap (#406 step 3) in #408 by @teemow

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.7.19...v4.8.0

  • AI Agents agent-platform v4.7.19

    Fixed

    • (kagent) Keep the platform Harness across the 4.8.0 hand-over to the kagent release (#406 step 2) in #407 by @teemow

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.7.18...v4.7.19

  • AI Agents agent-platform v4.7.18

    Fixed

    • The substrate release pins the platform Harness’s image in atelet’s image cache, and the Substrate line re-pins to v0.0.27-gs.6 (giantswarm/giantswarm#37764; giantswarm/giantswarm#37742 rows 34 and 35): atelet’s image GC evicted every image older than two minutes on every pass while the cache volume sat above the 85 % watermark — the Harness image included — so the first turn after a few idle minutes paid a cold pull and unpack that did not fit the resume’s restore budget and failed with context canceled. The line’s sixth release (giantswarm/substrate#21, #23, #24) makes the pinned set configurable (--image-cache-pinned-images; chart atelet.imageCache.{gcPeriod,highPercent,lowPercent,minAge,maxBytes,pinnedImages}, unset by default) and raises the router’s request-parking budget to 30 s. The meta chart derives atelet.imageCache.pinnedImages for the substrate release from kagent.harness.image (agent-platform.componentDerivedValues, next to the CNPG connection Secret): the platform Harness’s digest joins whatever substrate.atelet.imageCache.pinnedImages lists — the installation’s own pins first, once each — so atelet pulls it at every GC pass and never evicts it, and a Harness re-pin moves the pinned set with it; no second copy of the digest anywhere. The other imageCache knobs stay the chart’s defaults (an installation or a lab tunes them in substrate.atelet.imageCache). components.substrate/components.substrate-crds move to >=0.0.27-gs.6 <0.0.28-0 and kagent.substrateWorkerPool.workerImage to …:0.0.27-gs.6; examples/customer-bom.yaml and tests/verify-components.py move with the pin. make verify-components asserts the derived pin (the default render, a re-pinned Harness image, an installation’s own list). An installation on the 4.x line rolls the atelet DaemonSet once (--image-cache-pinned-images=<Harness digest>) on its next reconcile; the lab proof — no Image cache evicting image record for the Harness image, the first turn after ten idle minutes completing — is the audit’s next step. No installation acts — the release stays inert behind the fleet’s <4.0.0 bound.
  • AI Agents agent-platform v4.7.17

    Fixed

    • The kagent line re-pins to v0.11.0-gs.4 (giantswarm/giantswarm#37763, giantswarm/giantswarm#37010): the line’s fourth release (commit ca399a3a; the upstream pin stays kagent-dev/kagent main @ 6a6b54ff) carries one more patch, giantswarm/kagent-upstream#15 — the A2A gateway fails a task whose dispatch to the AgentInstance runtime fails (a failing dial, a failing ingester start, or a runtime stream that errors before its first event) instead of leaving it TASK_STATE_SUBMITTED for good, which kept it as the instance’s active task, refused every later message as a conflict and showed every client a turn that never ends; a submitted task the runtime does not know is failed by the reconciler after the one-minute dispatch grace period. kagent.tag moves to 0.11.0-gs.4 (the controller and UI image build) and kagent.harness.image to the gs.4 Go ADK index digest sha256:6e510b241e2d000b7d10879c9fde3dd34a37879854278f0a5d386426049a88bf (meta and connectivity charts); components.kagent/components.kagent-crds keep the range >=0.11.0-gs.1 <0.11.1-0. examples/customer-bom.yaml and tests/verify-kagent-crds.py (KAGENT_LINE_REF) move with the pin. An installation on the 4.x line rolls the kagent controller, UI and the platform Harness to the new build on its next reconcile; the lab proof of the released chart is the audit’s next step (giantswarm/giantswarm#37763). make verify-wiring’s whole-render comparison against origin/main leaves image references out, so a re-pin — which moves kagent.harness.image by design — no longer trips it.
  • AI Agents agent-platform v4.7.16

    Changed

    • (deps) Update gsoci.azurecr.io/giantswarm/agent-manager docker tag to v1.1.3 in #397 by @renovate[bot]

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.7.15...v4.7.16

  • AI Agents agent-platform v4.7.15

    Fixed

    • The managers are pinned to the kagent API version the 4.x line serves (giantswarm/agent-platform#401): model-manager.kagent.apiVersion and agent-manager.kagent.apiVersion are v1alpha3 in the meta chart’s values — the managers’ charts default to auto, which discovers the served kagent.dev version once at start-up and bakes it into the client. On an in-place 3.x → 4.x upgrade nothing in model-manager’s values or pod template changed, so its pod never rolled: it kept the v1alpha2 it had discovered under kagent 0.10 while kagent-crds had replaced the CRDs with v1alpha3 only, and every ModelConfig call failed with list ModelConfigs in kagent: the server could not find the requested resource — a pulled model could not be wired until the pod happened to restart (found by the migration rehearsal, giantswarm/agentlab#143, models-test on a lab upgraded in place from 3.23.1 to 4.7.14; agent-manager’s pod rolled only because its chart moved to 1.1.x). Both charts render the key as the container’s --kagent-api-version=v1alpha3, so the pin is the values change that rolls both Deployments on the cut-over, after kagent-crds is Ready (both dependsOn it), and every manager speaks v1alpha3 from its first request. make verify-components asserts the pin in both forwarded release values; verify-components-charts renders both manager charts with the forwarded values and asserts the argument reaches the pod template. UPGRADE.md “3.x → 4.0 (the kagent line)” carries the operator’s side: the managers roll once, nothing to do. No installation acts — the release stays inert behind the fleet’s <4.0.0 bound; an installation already on 4.x sees both managers roll once on the next reconcile.
  • AI Agents agent-platform v4.7.14

    Fixed

    • A connectivity chart release no longer stalls on the completed migrate Job (giantswarm/agent-platform#399). The Job <release>-agent-manager-migrate-<hash> was named with a hash of its image, args and environment so that a changed Job renders under a new name (Job.spec.template is immutable), but its pod template carried labels.common — helm.sh/chart and app.kubernetes.io/version, which change on every chart release while the hash did not — so the next release within the Job’s day-long TTL re-applied the same-named Job with a different immutable template and the apiserver refused it (Job.batch "…-agent-manager-migrate-16c89a3a" is invalid: spec.template: Invalid value: … field is immutable); helm-controller exhausted its retries, rolled the connectivity release back (Stalled=True RetriesExceeded) and every dependant — substrate, kagent, the managers, backstage — read dependency not ready until the TTL removed the Job (found by the migration rehearsal, giantswarm/agentlab#143, on the connectivity release moving 4.7.12 → 4.7.13). Two changes: the pod template carries the stable labels only — app.kubernetes.io/name, app.kubernetes.io/instance, app.kubernetes.io/component: agent-manager-migrate (the network policy’s selector) and the team label (agent-platform.kagent.migration.podLabels); the Job’s own labels keep labels.common — and the Job’s name hashes the whole rendered pod template (agent-platform.kagent.migration.podTemplate: image, args, environment, identity, labels, everything the apiserver makes immutable), so any template change renders a new Job and an unchanged template is re-applied as is; a chart release changes neither. An installation that has the completed Job of an earlier 4.x release (its template carries that release’s version) sees this release render the Job once more under a new name — Helm creates it and removes the old one — and migrate runs again, idempotent (nothing left to rewrite; the contract phase where its gates are met), instead of the refused apply. make verify-migration packages the connectivity chart at two versions and asserts the Job’s name and spec.template are identical while its own labels follow the chart version, and that a changed image tag or identity changes the name. No installation acts — the release stays inert behind the fleet’s <4.0.0 bound; an installation already on 4.x moves to it on the next reconcile, a stalled connectivity release included (a new chart version resets helm-controller’s retries).
  • AI Agents agent-platform v4.7.13

    Fixed

    • The 3.x → 4.x upgrade migrates the storage version of the kagent CRDs, and keeps the hand-created ModelConfigs (giantswarm/agent-platform#396). A cluster that ran kagent 0.10 stores modelconfigs, modelproviderconfigs and remotemcpservers.kagent.dev at v1alpha2; the line’s kagent-crds chart declares v1alpha3 only, the apiserver refuses the CRD update (v1alpha2 was previously a storage version, and must remain in spec.versions until a storage migration …), kagent-crds never installs and the connectivity, substrate and kagent releases behind it never move (found by the migration rehearsal, giantswarm/agentlab#143). Two hook Jobs of the meta chart, as the hook identity in alpine/k8s, rendered whenever components.kagent-crds is on — with the bundled engine and, the one exception to “no hook without the engine”, through a cluster’s own Flux, so the cut-over stays “lift the bound and let Flux upgrade” on every installation: <release>-kagent-storage-version-backup (pre-install,pre-upgrade, weight -7) records every object of each of the three CRDs still stored at v1alpha2 into ConfigMap kagent-storage-version-migration in the kagent namespace (status and the server-set metadata stripped; recorded-at) and deletes those CRDs, so kagent-crds installs them at v1alpha3, then — on every run — re-points the three kinds from kagent.dev/v1alpha2 to v1alpha3 in every Helm release manifest that still names them (the release Secrets, patched in place: what helm mapkubeapis does for a removed API — Helm reads a release’s stored manifest back through the cluster’s REST mappings on each upgrade, and the 3.x connectivity release’s catalog and the kagent 0.x release’s default ModelConfig and tool-server RemoteMCPServer otherwise fail with unable to build kubernetes objects from current release manifest: no matches for kind "RemoteMCPServer" in version "kagent.dev/v1alpha2", as the lab showed); <release>-kagent-storage-version-restore (post-install,post-upgrade, weight 0) waits for modelconfigs.kagent.dev to be Established serving v1alpha3 (up to 8 min — under a cluster’s own Flux the post hooks run before kagent-crds has installed) and re-creates every recorded ModelConfig no Helm release owned at kagent.dev/v1alpha3 with name, namespace, labels, annotations and spec unchanged (the spec is identical in both versions), leaves one that is already present to its owner, fails the upgrade on any other refusal, and marks the ConfigMap restored-at so it runs once (a ModelConfig removed by hand after the cut-over must not come back). The chart-rendered ModelConfigs come back from their releases, model-manager’s from model-manager; RemoteMCPServers and ModelProviderConfigs are recorded, never restored — the 4.x charts render their own. A CRD that is absent or stores v1alpha3 is left alone: a fresh install and a second run change nothing (the ATS smoke sees the hooks do nothing). The hook identity <release>-hooks is created for the hooks’ events too (agent-platform.hooks.serviceAccountEvents composes them) and, without the engine, for those alone. make verify-kagent-storage-version asserts the pair, the scripts, the identity’s events, the engine-off render and the kagent-off render; verify-engine / verify-self carry the family in their expected hook sets. UPGRADE.md “3.x → 4.0 (the kagent line)” has the operator’s side: what comes back and from where, the downtime window, the record and when to delete it.
  • AI Agents agent-platform v4.7.12

    Changed

    • (deps) Update gsoci.azurecr.io/giantswarm/agent-manager docker tag to v1.1.2 in #395 by @renovate[bot]

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.7.11...v4.7.12