1. Docs
  2. Changes and releases

agent-platform release v4.121.0

AI Agents agent-platform v4.121.0

Added

  • agent-manager’s session tools reach the kagent controller: agent-manager.kagent.controllerTarget is derived, and agent-manager’s egress admits the agentgateway data plane (giantswarm/agent-manager#3). With the kagent and agentgateway components on and kagent.controllerRoute.enabled, the target is grpc://<gateway.name>.<namespace>.svc.cluster.local:<gateway.listeners[0].port> (grpc://agentgateway.agent-platform.svc.cluster.local:8080 on a default install); with the route off it is empty, which turns list_sessions, get_session and start_session off. A differing agent-manager.kagent.controllerTarget fails the render naming the key. components.agent-manager.versionRange is >=1.10.0 <2.0.0 (the floor the migrate entry below sets): 1.10.0 is the first agent-manager release whose schema takes kagent.controllerTarget (giantswarm/agent-manager#101), so a BOM that pins agent-manager pins 1.10.0 or later (examples/customer-bom.yaml does). With agent-manager’s OAuth on and the route on, its network policy (both flavors) admits the data plane on the listener port.

Changed

  • The agentgateway line moves to 2.3.0 (controller and data plane), and llmRouting.modelCatalog.providers is empty by default in both charts. 2.3.0’s built-in catalog prices anthropic/claude-sonnet-5-5 at the rates the overlay carried, so the overlay entry is dropped (make verify-model-catalog refuses an overlay that shadows the gateway’s own catalog); cost attribution for that model is unchanged. An installation that sets its own providers keeps them. The line dropped its fork patch for oversized MCP answers in 2.2.2 (agentgateway#3714 was declined upstream and the carry reverted in giantswarm/agentgateway-upstream#36), so an MCP answer above the gateway’s buffer is reported as upstream’s body exceeded buffer limit / length limit exceeded again instead of the named buffer error.
  • The connectivity chart’s agent-manager migrate run moves the agents from Generic chart 1.x to 2.x, and components.agent-manager.versionRange is >=1.10.0 <2.0.0 (was >=1.7.0 <2.0.0), agentManager.migration.image.tag 1.10.0 (was 1.7.0), in both charts. agent-manager 1.10.0 reads the 2.x range of agent-manager.agentChart.semver as the 1.x to 2.x path (giantswarm/agent-manager#100): every Generic-chart release is validated against the chart 2.x schema, the writable ones are rewritten (sub-agent bindings to subAgent, the 1.x Harness admission label to agent.harness) and their namespace’s OCIRepository agent moves to 2.x, GitOps-owned releases and sources get a diff in the report, and the leftover kagent.dev AgentTemplates are deleted once the Agents are Ready. An older image read the same range as the 0.x to 1.x path and rewrote nothing. The run deletes no CRD, so its ClusterRole and ClusterRoleBinding on the five kagent.dev CRDs of the 0.x line are gone: the migration holds no cluster-scoped right (make verify-identity asserts none renders). AGENT_CHART_SEMVER falls back to 2.x.
  • components.kagent-crds.ownedCrds is [modelconfigs.api.kagent.dev] (was [modelconfigs.kagent.dev]): the one-owner guard looks up the CRD the kagent-crds chart on the api.kagent.dev line installs.
  • agent-manager.agentChart.semver is >=2.0.0 <3.0.0 (was >=1.5.0 <2.0.0): the Generic agent chart 2.x renders one api.kagent.dev/v1alpha3 Agent (giantswarm/agent#56) in place of the kagent.dev AgentTemplate, which the kagent line on api.kagent.dev no longer serves; every agent namespace’s OCIRepository follows and the agents re-render as Agents.
  • components.model-manager.versionRange is >=1.14.0 <2.0.0 (was >=1.10.2 <2.0.0), in both charts (giantswarm/model-manager#247). 1.14.0 writes its ModelConfigs at api.kagent.dev when the cluster serves it: a bare kagent.apiVersion (the platform’s v1alpha3) keeps the version and discovers the group, re-checked every minute and at once on a NotFound, so the served models stay listed for the agents after the cut-over; an older model-manager keeps writing kagent.dev, which the line’s agents do not read.
  • components.kagent{,-crds}.versionRange is >=1.4.0 <1.5.0 and components.substrate{,-crds}.versionRange is >=1.5.0 <1.6.0: the kagent line on upstream bf8afa56 (api.kagent.dev/v1alpha3, Agents and Sessions) and the Substrate release it was built against. kagent 1.4.0 fences a session’s Pause and Suspend with a Substrate lease token (giantswarm/kagent-upstream#216), which Substrate takes from 1.5.0 (giantswarm/substrate#182); Substrate 1.5.0 also gives the carried ExternalSnapshot source field its own number and rewrites the rows a 1.3 or 1.4 release wrote when it reads them (giantswarm/substrate#165), so an Actor paused under the 1.3 line resumes on this one. The kagent WorkerPool’s worker image follows the Substrate floor to ateom-gvisor:1.5.0. The cut-over of an installation is docs/kagent-v1alpha3-cutover.md (a fresh kagent database; every session is lost).
  • The kagent catalog is api.kagent.dev/v1alpha3: the connectivity chart’s ModelConfigs and RemoteMCPServers, the LLM routing admission policy’s modelconfigs rule and the CRD validation (make verify-kagent-crds) move to the group the re-pinned kagent line serves (kagent-dev/kagent#2952). The line renders explicit Agents: the Generic agent chart renders one Agent per release with its template inline and its Harness by name (spec.harnessRef), and the display-name and icon annotations are read off the Agent. The kagent controller GRPCRoute (kagent.controllerRoute.grpc.services) carries kagent.api.v1alpha1.AgentService and kagent.api.v1alpha1.SessionService in place of AgentInstanceService, next to AgentTemplateService, ModelService, SystemService and lf.a2a.v1.A2AService; kagent’s MCP server on muster offers list_sessions and invoke_session. The ModelConfig helpers admit the Mistral provider the line’s CRD adds, with its mistral.baseUrl block. The floors of components.kagent.versionRange and components.kagent-crds.versionRange move to the first release of the re-pinned kagent line once it is tagged; until then the range admits the 1.2.x line, and make verify-kagent-crds runs against the candidate’s CRDs through KAGENT_CRDS_DIR.
  • The platform Harness has no admission selector: kagent.harness forwards create, the snapshot location, the env and the compaction alone. The line’s Harness CRD (api.kagent.dev) has no allowedAgentTemplates; an Agent names its Harness by spec.harnessRef and the label agent-platform.giantswarm.io/harness means nothing to the platform any more. kagent.controller.auth.mode is insecure or trusted-proxy on the line (the chart renders it as KAGENT_AUTH_MODE; the platform’s default trusted-proxy is unchanged, and the retired spelling unsecure is gone from the comments). The line’s session lifecycle knobs (kagent.controller.sessionIdleTTL, sessionShareMaxTTL, stalledTurnTimeout, pausedRuntimeTTL) travel as written; the platform sets none. make verify-kagent-harness and make verify-meta assert the forwarded block, and make verify-components-charts asserts the rendered Harness carries no selector, which holds once the range resolves to the re-pinned line. The ATS suites apply a declarative Agent and wait on the Agent’s Ready condition.
  • The line starts on a fresh kagent database; nothing migrates from 1.x. The re-pinned kagent line rewrites its initial schema (000001_initial.sql) for the Session baseline and does not migrate a 1.x database: a controller of the line pointed at one refuses to start before any migration, with KAGENT_SKIP_MIGRATIONS too. An installation cuts over the way the API v2 cut-over did (giantswarm/agent-platform#346): a new CNPG Database in postgres.databases for the controller, the 1.x database kept as it is for a retention period and dropped afterwards, together with the Substrate ActorTemplates, golden snapshots, parked Actors and snapshot-store checkpoints its rows reference. The fresh database does not carry conversations and their history, session shares (the klaus-gateway thread bindings that point at them), scheduled-run executions or the sessions’ checkpoints; Agents, templates and schedules are Kubernetes objects and are recompiled on the first reconcile. docs/kagent-v1alpha3-cutover.md is the per-installation checklist.
  • The agentgateway policies hold on the re-pinned agentgateway line (upstream main at c9573ed1). Checked against the three upstream changes the line carries: no AgentgatewayPolicy of either chart reads backend.endpoint in CEL (agentgateway/agentgateway#3679 removes it for Service backends); the one transformation the charts render sets the x-user-id request header on the kagent controller route from the verified JWT claim and touches no body, so the null-body change (agentgateway/agentgateway#3653: a null body expression keeps the upstream body) changes nothing here; and the llm path fronts Anthropic only by default (llmRouting.models: provider Anthropic, https://api.anthropic.com/v1), whose Messages input passes through untranslated, while agentgateway/agentgateway#3647 makes an llm backend translate Anthropic Messages to OpenAI Responses first and Completions second. An installation that adds a Completions-only OpenAI-compatible provider to llmRouting.models and sends it Anthropic Messages sets AGENTGATEWAY_MESSAGES_PREFER_COMPLETIONS=true on the data plane (gateway.parameters.dataPlaneEnv) until it serves the Responses API; upstream drops the switch in v1.7. A served model behind LLMEndpoint answers whichever API its runtime exposes and is unaffected. The floor of components.agentgateway.versionRange moves to the first release of the re-pinned agentgateway line once it is tagged.
  • The Substrate values are ready for the re-pinned Substrate line (kagent-dev/substrate v0.3.0-alpha1 plus the carried patches). Every key the meta chart forwards to the substrate release keeps its name and shape there (credentialProvider.namespacePolicies, postgres, rustfs, otel, podLabels, images, atelet.*, metrics.podMonitor), so no value changes. What the line changes underneath: ate-controller and ate-api-server name the atelet and router ServiceAccounts (--atelet-service-account, --router-service-account), the router names its Service (--router-service-name), the credential provider serves a status endpoint on 4040 (--status-address; its probes stay on the metrics port, so the network policies are unchanged) and names the egress injector with --injector-identity, its credential URIs are ate-secret://k8s.io/default/<namespace>/<secret>/<key> (uriAuthority: k8s.io; the charts render none), atelet tolerates the ate.dev/sandboxClass taint itself, and a microvm SandboxConfig no longer needs a kata-config asset (the platform runs gVisor). substrate.images.agentgateway is not forwarded: the atenet router and egress run the agentgateway build the Substrate release stamps (2.2.1 on alpha1), which moves with the Substrate release, not with this chart. The floors of components.substrate.versionRange and components.substrate-crds.versionRange move to the first release of the re-pinned Substrate line once it is tagged; until then the range admits the 1.1.x line.

Removed

  • kagent.harness.allowedAgentTemplates and kagent.controller.substrate.defaultWorkerPool. The re-pinned kagent line’s Harness has no selector and its chart no defaultWorkerPool key (every ActorTemplate is pinned to the pool of the Harness the Agent names). An installation that set either removes it from its values; an AgentTemplate labelled agent-platform.giantswarm.io/harness: kagent is not admitted by the label any more, it needs an Agent that names the Harness.
  • The kagent CRDs’ storage-version hooks of the 3.x → 4.x cut-over (giantswarm/agent-platform#396): <release>-kagent-storage-version-backup and -restore, make verify-kagent-storage-version. The kagent line serves api.kagent.dev, and the kagent.dev CRDs the hooks moved from v1alpha2 to v1alpha3 leave the cluster with the kagent-crds release that stops rendering them; the restore hook waited on modelconfigs.kagent.dev and would have failed every upgrade after the cut-over. With the engine off the meta chart renders no hook, no hook identity and no hook policy (a pure app-of-apps render; the serving slice’s teardown aside); with the engine on the hook identity is at pre-install,pre-upgrade,pre-delete,post-delete. An installation still on 3.x upgrades through a 4.x release that carries the hooks first (UPGRADE.md).