1. Docs
  2. Changes and releases

agent-platform release v4.0.0

AI Agents agent-platform v4.0.0

Added

  • components.<name>.semverFilter and gitops.self.semverFilter select a dev channel: a Go regexp rendered as OCIRepository.spec.ref.semverFilter, which Flux applies to the registry’s tags before it evaluates the semver range. With a prerelease-admitting range (>=3.0.0-0 <4.0.0-0) and the filter of one branch’s dev builds (.*-dev\.<sanitized-branch>\..*) a component — or, under self-management, the chart itself — follows that branch’s newest build and never falls back to a stable tag. Unset by default. The dead components.<name>.filterTags block (an ImagePolicy field, never an OCIRepository one, undeclared in the schema) is gone.

Changed

  • BREAKING — meta chart 4.0: components.kagent delivers the kagent line (kagent API v2, kagent.dev/v1alpha3). components.kagent and the new roster entry components.kagent-crds resolve the charts kagent and kagent-crds of giantswarm/kagent-upstream (upstream kagent main at a pinned commit plus the carried patches) from oci://ghcr.io/giantswarm/kagent/helm on the line’s release range >=0.11.0-gs.1 <0.11.1-0 — the releases 0.11.0-gs.N of upstream 0.11.0, not the line’s 0.11.0-dev.giantswarm.… builds (Flux’s Masterminds semver compares prerelease identifiers left to right, dev < gs; the -0 on the ceiling admits prereleases at all, and the ceiling holds the patch because a prerelease is confined to no patch tuple; a bare 0.11.0 would be admitted, should upstream’s release ever appear at this OCI path) — instead of the giantswarm/kagent 0.x wrapper (kagent 0.10, v1alpha2) from gsoci. kagent-crds renders the five v1alpha3 CRDs as templates carrying helm.sh/resource-policy: keep (no crds/ dir, no crds: policy), follows components.kagent unless switched explicitly (agent-platform.componentEnabled), the kagent release and the connectivity release dependsOn it, and the render refuses kagent on without it (agent-platform.validateKagentCrds). The kagent: block names one build of the line: registry: ghcr.io, the fork’s image names (giantswarm/kagent/{controller,golang-adk,ui}), an explicit tag equal to the chart version of the build (upstream’s chart falls back to .Chart.Version, which under helm-controller is <version>+<oci digest>, an invalid image tag), kagent.harness.image — the Go ADK image by digest the connectivity chart renders the platform Harness from (the CRD accepts no tag) — controller.substrate.* (ate-api, atenet-router in ate-system, the default WorkerPool) and substrateWorkerPool (kagent-default, four gVisor workers on the Giant Swarm Substrate line’s worker image), pgvector on the bundled Postgres; a re-pin of the line moves the tag, the digest and the two ranges together from the fork’s builds.md ledger (README “Re-pinning the kagent line”). Every sibling range selects the kagent API v2 line: agent-platform-connectivity >=4.0.0 <5.0.0 (its own major; the 3.x line held <4.0.0), agent-manager and backstage 1.x (their 1.0 releases; until published the ranges resolve nothing — both are off by default), model-manager >=0.20.0 <1.0.0 (0.20.0 renders the ModelConfig version the cluster serves; the line stays 0.x); no semverFilter anywhere by default, gitops.self.semverFilter empty. agent-manager.agentChart.semver defaults to 1.x (was x.x.x, which would have rolled the Generic agent chart 1.0.0 to every existing agent the moment it is published). examples/customer-bom.yaml pins the line (kagent and kagent-crds 0.11.0-gs.1 — the same release, one build — agent-platform-connectivity 4.0.0, agent-manager and backstage 1.0.0, model-manager 0.20.0). Every installation acts (UPGRADE.md “3.x → 4.0”): the release is inert until the fleet’s agent-platform range bound (<4.0.0) is lifted per installation; a 4.0 installation with kagent on needs Kubernetes 1.35 with the ClusterTrustBundle, ClusterTrustBundleProjection and PodCertificateRequest feature gates and Agent Substrate in ate-system. make verify-meta (tests/verify-kagent-wiring.py, with tests/fluxsemver.py reimplementing Flux’s constraint semantics offline) asserts the sources, the range’s admitted and refused shapes, one build (tag and range on one upstream version, the Harness image a digest), the omitted keys and the retired ones; make verify-components the sibling ranges, kagent-crds following kagent and the BOM; make verify-components-charts pulls the managers’ and the kagent line’s charts at what the ranges resolve to (the way Flux resolves, -gs.N prereleases included) and renders the forwarded blocks against them — while a range waits for an unpublished release (a sibling’s 1.0, the line’s first tag) it renders against the build kagent.tag names or the newest 0.x and says so.

Removed

  • The ten bundled example agents’ value blocks (kagent.k8s-agent … kagent.cilium-debug-agent, each enabled: false with namespaceOverride: kagent), kagent.controller.skillsInitImage and the METRICS_BIND_ADDRESS / METRICS_SECURE entries of kagent.controller.env: the kagent line ships none of the agents and no skills-init image, and its controller serves no Prometheus /metrics. With that kagent.serviceMonitor.enabled defaults to false in both charts and the forwarded kagent.controller.metrics.enabled is false explicitly — the connectivity chart’s controller metrics Service and ServiceMonitor and upstream’s metrics Service would point at a port nothing listens on and sit at up=0; nothing reads those metrics (the fleet’s KagentControllerDown reads kube-state-metrics). make verify-global asserts the default renders no kagent monitor and that kagent.serviceMonitor.enabled: true still renders it under the global gate; both go back on when upstream serves metrics. The ATS kind smoke keeps kagent and agent-manager off and skips the agent round trips with the reason while the cluster has neither the feature gates nor Substrate (tests/ats/values-kagent.yaml, KAGENT_ON); agentlab proves them, giantswarm/agent-platform#343 turns them back on.