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

AI Agents

  • AI Agents klaus v0.1.12

    Changed

    Full Changelog: https://github.com/giantswarm/klaus/compare/v0.1.11...v0.1.12

  • AI Agents agent-platform v4.7.11

    Fixed

    • components.klaus-gateway.versionRange is 1.x (giantswarm/klaus-gateway#234, giantswarm/giantswarm#37705 wave 1c): the 4.x roster still selected 0.x, the klaus-gateway that speaks REST to the 0.10 controller — against this line’s controller GRPCRoute (its klausGateway.a2a.url is already the grpc:// target) a 0.x gateway gets 404s for every REST path. klaus-gateway 1.x is the kagent API v2 client (A2A v1 over gRPC, AgentTemplate discovery, one AgentInstance per thread); the customer BOM pins 1.0.2; make verify-components asserts the range. No installation acts: components.klaus-gateway is off by default, and the one 4.x installation runs its gateway outside the chart. The 3.x meta chart keeps 0.x.
  • AI Agents agent-platform v4.7.10

    Changed

    • The Substrate pin moves to 0.0.27-gs.5 (components.substrate and components.substrate-crds floor, the customer BOM, kagent.substrateWorkerPool.workerImage): gs.3 plus a golden boot whose image the registry refuses failing instead of resuming forever (gs.4, giantswarm/substrate#14 — giantswarm/giantswarm#37742 row 27) and the podcertificate-controller-system namespace kept across an uninstall (gs.5, giantswarm/substrate#13 — #384).

    Fixed

    • A reinstall after helm uninstall brings Agent Substrate up with a consistent trust chain (giantswarm/agent-platform#384). The uninstall took the podcertificate-controller-system namespace and the two CA pools in it with the substrate release while the signers’ cluster-scoped ClusterTrustBundles stayed; the reinstall minted new roots and the podcertificate-controller republished the bundles within seconds, but every Substrate pod had projected the surviving bundle when it started and reads its CA once, at dial time — x509: certificate signed by unknown authority against ate-api-server from ate-controller, atelet and the atenet router, no golden boot (the own-Flux ATS scenario on the cluster the smoke had uninstalled from, PR #380). Two halves: the Substrate line keeps the namespace across an uninstall (helm.sh/resource-policy: keep, 0.0.27-gs.5, giantswarm/substrate#13 — the pin below), and the connectivity bootstrap hook publishes both signers’ ClusterTrustBundles from the pools (server-side, the way it applies actor-id-ca-certs) before the substrate release installs and on every upgrade, so a bundle never reaches a pod with roots its pool does not have; the hook’s ClusterRole gains clustertrustbundles (get, list, watch, create, patch) and attest on the two podcert signers (the apiserver admits a bundle that names a signer only from a client allowed to attest it). The ATS smoke no longer removes Substrate’s leftovers between its scenarios: the own-Flux scenario reinstalls onto the cluster the smoke uninstalled from — the kept namespace, pools and bundles in place — and asserts each signer’s bundle carries its pool’s roots; the smoke asserts what the uninstall leaves.
  • AI Agents agent-platform v4.7.9

    Fixed

    • The Substrate line re-pins to v0.0.27-gs.4 (giantswarm/giantswarm#37757; giantswarm/giantswarm#37742 row 27): the release carries giantswarm/substrate#14 — an actor whose image the registry refuses for good (a digest answered 404, a repository the pull may not read) is crashed with the registry’s answer instead of being resumed against the same reference forever, and ate-api’s ActorTemplate reconciler records the cause on the template. A Harness whose workload.image cannot be pulled therefore fails its golden boot at once as Ready=False ActorTemplateFailed (GoldenActorCrashed: actor … crashed: … MANIFEST_UNKNOWN: manifest unknown) instead of sitting in ActorTemplatePending with a worker pinned for as long as anyone waits (measured at 300 s without a message on gs.2). components.substrate/components.substrate-crds move to >=0.0.27-gs.4 <0.0.28-0 and kagent.substrateWorkerPool.workerImage to …:0.0.27-gs.4; examples/customer-bom.yaml and tests/verify-components.py move with the pin. Asserted end to end in giantswarm/agent’s ATS on the release (test_fail_fast.py::test_unpullable_harness_image_fails_fast: 5 s, giantswarm/agent#34). No installation acts — the release stays inert behind the fleet’s <4.0.0 bound.
  • AI Agents agent-platform v4.7.8

    Fixed

    • A kagent.modelConfigs[] entry’s provider is checked against the ModelConfig CRD’s enum at render time (giantswarm/agent-platform#357): agent-platform.modelConfigProvider fails the render for any other value, naming the entry and the ten providers — Anthropic, OpenAI, AzureOpenAI, Ollama, Gemini, GeminiVertexAI, AnthropicVertexAI, Bedrock, SAPAICore, Foundry, case-sensitive as the CRD’s. Until now provider: openai rendered and the API server refused the object at apply time with the enum error, after the chart had said nothing. The baseUrl already goes under the CRD’s block key through agent-platform.modelConfigBaseUrlKey (#333: anthropic, openAI, sapAICore, the three ModelConfigSpec gives one; the render refuses a baseUrl on the seven others), in templates/kagent/modelconfigs.yaml and the MutatingAdmissionPolicy alike; what was missing was the pin. ci/test-llm-routing-values.yaml carries an OpenAI entry with its own baseUrl, so make verify-kagent-crds validates the openAI key against the kagent line’s CRD on every run — and now sweeps every provider of the CRD’s spec.provider enum, read from the CRD at KAGENT_LINE_REF: each renders, a baseUrl lands under the block the CRD gives one to and nowhere else, the render refuses it where the CRD’s block has none, and a provider outside the enum (a lower-cased spelling included) fails naming the enum; a re-pin that moves the enum or a block’s fields fails the check naming the helper to move with it. make verify-llm-routing asserts the openAI key for an explicit URL and for the routed default with llmRouting.backend.provider: openai, and the enum guard. Lab-proven on agentlab (Kubernetes 1.37, the line’s controller): the fixture’s OpenAI ModelConfig applied as rendered, spec.openAI.baseUrl survived admission and the kagent controller reported Accepted and ResolvedRefs; the same object with the lower-cased openai block lost the field to pruning with a non-strict client and was Accepted all the same (a strict client refuses it as an unknown field) — the silent direct path the issue describes. No installation acts: every valid catalog renders byte-identically; only a render that the API server would have refused fails earlier.
  • AI Agents agent-platform v4.7.7

    Fixed

    • Uninstalling the platform through a cluster’s own Flux no longer races the Substrate CRD chart (giantswarm/agent-platform#385). With the engine off nothing orders the component uninstalls — helm-controller finalizes the platform HelmReleases the chart rendered concurrently — and substrate-crds could go before substrate, whose uninstall then failed for good on its SandboxConfig (failed to delete release: substrate: Helm cannot delete an object whose kind is gone) and was retried until the meta HelmRelease’s finalizer timed out (measured on the ATS own-Flux scenario, PR #380). The Substrate line re-pins to v0.0.27-gs.3 (components.substrate/substrate-crds >=0.0.27-gs.3 <0.0.28-0, kagent.substrateWorkerPool.workerImage 0.0.27-gs.3, examples/customer-bom.yaml, tests/verify-components.py): its one new carried patch (giantswarm/substrate#12, upstream-first, prepared for kagent-dev/substrate in giantswarm/giantswarm#37742 row 28) puts helm.sh/resource-policy: keep on the three ate.dev CRD templates, set at the generator as the kagent line does (giantswarm/kagent-upstream#10) — so every CRD chart of the platform keeps its CRDs and a consumer’s uninstall can always delete its CRs, whatever order the releases go in. The ATS own-Flux scenario’s way back is a test now (test_the_way_back_uninstalls_through_the_clusters_flux): the meta HelmRelease deleted, every platform release uninstalled concurrently by the cluster’s Flux with no UninstallFailed, the eight kept CRDs in place, no SandboxConfig or WorkerPool left — the delete_platform_releases_in_waves workaround is gone; the smoke’s ordered teardown asserts the same keep policy on ate.dev. Rejected: rendering the teardown-releases hook with the engine off (a cluster-admin hook in the fleet render for an order that stops mattering) and waiting for a Flux-side reverse-dependsOn uninstall (upstream’s open fluxcd/flux2#1744). README “Clusters that run Flux”, “Uninstalling”, “CRD lifecycle” and UPGRADE.md describe the uninstall order and what a kept CRD implies. No installation acts — the release stays inert behind the fleet’s <4.0.0 bound.
  • AI Agents agent-platform v4.7.6

    Removed

    • The portal’s app-config carries no agentPlatform.musterMcpUrl (giantswarm/agent-platform#299): the connectivity chart rendered the platform’s muster MCP URL into the Backstage app-config next to fluxServiceAccountName, but the Dev Portal reads no such key — it creates agents through agent-manager’s tools, and create_agent takes no muster argument. Where muster is reaches agent-manager alone: the meta chart derives its chart value muster.url from the agent-platform.musterMcpUrl helper (unchanged), agent-manager composes it into every agent’s RemoteMCPServer and reports it in get_info. make verify-wiring asserts the key stays gone; verify-identity keeps asserting the agent-manager leg. No installation acts — nothing read the key.
  • AI Agents agent-platform v4.7.5

    Changed

    • The ATS smoke runs the agent path on kagent API v2 (giantswarm/agent-platform#343): tests/ats/values-kagent.yaml turns kagent and agent-manager back on; Agent Substrate comes from the chart under test (one gVisor worker, the bundled RustFS as the snapshot store, the bundled Postgres at CI requests) on the CI job’s kind cluster with the ClusterTrustBundle, ClusterTrustBundleProjection and PodCertificateRequest gates (.ats/kind-config.yaml, the large class). The assertions are kagent.dev/v1alpha3: a declarative AgentTemplate reaches Ready on the platform Harness (status.harnesses[]), agent-manager’s create_agent through muster as a Dex user ends in a Ready HelmRelease, a Ready AgentTemplate and an Accepted per-agent RemoteMCPServer carrying the toolset header, the own-Flux agent likewise; the ordered teardown uninstalls the kagent-crds release and asserts the CRDs and the templates survive (the line’s keep policy) and nothing else does. The KAGENT_ON/AGENT_MANAGER_ON skips are gone. tests/ats/README.md documents the cluster shape, the sizing and the measured timings.

    Fixed

    • The ordered teardown uninstalls the platform releases in reverse dependency order. The pre-delete hook deleted every platform HelmRelease at once, so helm-controller uninstalled them concurrently and a CRD chart (substrate-crds, kagent-crds) could go before the releases whose objects are its CRs — Helm then fails the consumer’s uninstall (failed to delete release: substrate: its SandboxConfig kind was gone), helm-controller retries it forever and the hook waits out its timeout, failing helm uninstall. Found by the ATS smoke the moment it ran kagent and Substrate (giantswarm/agent-platform#343). The hook now deletes in waves computed from the roster’s dependsOn (agent-platform.teardownWaves: each wave’s releases concurrently, the next wave once the last is gone), as a script in gitops.hooks.helmImage; make verify-engine asserts the wave order against the rendered dependsOn.
  • AI Agents agent-platform v4.7.4

    Changed

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

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.7.3...v4.7.4

  • AI Agents agent-platform v4.7.3

    Changed

    • (ci) The test-ingress-modes tool-install step bounds and retries its network calls (apt with timeout, helm download with curl retries) so a stalled mirror fails fast instead of hanging into CircleCI’s 10-minute no-output timeout in #382 by @teemow

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.7.2...v4.7.3