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

AI Agents

  • AI Agents agent-platform v3.14.0

    Removed

    • The Argo CD render engine of the meta-package. gitops.engine accepts flux only (enum: [flux] in the schema, a template guard behind it); templates/components.yaml renders a Flux OCIRepository + HelmRelease per component and nothing else; gitops.argo.project / gitops.argo.server are gone from the values and the schema. The Argo Application branch was never verified against a running Argo CD and no installation selected it, and the platform cannot run on Argo CD in any case: agents are Flux objects on every path (the Backstage agent create flow and agent-manager write an OCIRepository + HelmRelease per agent). gitops.engine: argo now fails the render — the schema first, the guard with gitops.engine=argo is not supported; flux is the only engine — and gitops.argo.* fails the schema. make verify-meta asserts the refusal on both layers, that the Flux render carries no argoproj.io object and that an explicit gitops.engine: flux renders exactly the default; the Argo render assertions of verify-meta and verify-presets are gone with the branch. No installation needs to act: the Flux render is byte-identical. See UPGRADE.md.
  • AI Agents agent-platform v3.13.1

    Fixed

    • kagent.oauth2ProxyIngress is dropped from the values forwarded to the kagent chart (components.kagent.omitKeys). It is read by the connectivity chart only, and the flattened kagent 0.2.x chart rejects it (additional properties 'oauth2ProxyIngress' not allowed), so an installation that set it (glean) failed the kagent upgrade to 0.2.0. tests/verify-kagent-wiring.py now derives the umbrella-only keys from what the connectivity templates read under .Values.kagent, so a new one cannot be forwarded unnoticed.
  • AI Agents agent-platform v3.13.0

    Changed

    • The kagent component tracks the 0.2.x chart line, which flattened the upstream keys onto the chart root. The forwarded values block is no longer nested under a kagent key, and the umbrella-only keys (controllerRoute, modelConfigs, remoteMcpServers, serviceMonitor, uiRoute) are dropped before forwarding (omitKeys) because the flattened chart’s schema rejects them. The top-level kagent: values block is unchanged, so no installation has to move an override. examples/customer-bom.yaml pins 0.2.0. The kagent controller and UI pods roll once on the upgrade (three labels and the pod annotations that hash them change).
  • AI Agents agent-platform v3.12.0

    Added

    • model-manager.lmstudio.endpoint / .agentHost and the lmstudio backend in the connectivity chart’s model-manager wiring: an LM Studio on the host (llama.cpp on GPU and CPU, MLX on Apple silicon) as a serving backend. templates/model-manager/validate.yaml accepts the name and, as for ollama and lemonade, fails the render when the endpoint is missing or carries no scheme; _helpers.tpl gains modelManager.lmstudioEndpoint and the lmstudio arms of hostEndpoint/hostTargets, so the model-manager NetworkPolicy opens egress to the LM Studio host in both flavors. Requires model-manager >= 0.19.0, and that is a pin to move rather than a backend to select: values.yaml forwards the whole model-manager block — lmstudio included — to every release, and the key does not exist before 0.19.0, whose schema is additionalProperties: false, so a chart pinned below it rejects the values outright even on an installation that never touches LM Studio (examples/customer-bom.yaml floors it accordingly). LM Studio serves no delete (lms rm is host-only), so that call answers 501 unsupported.
  • AI Agents agent-platform v3.11.1

    Changed

    • components.kagent.versionRange is 0.1.x (was 0.x). kagent 0.2.0 flattens the upstream keys onto the chart root and takes no nested kagent: block, so the current wiring must not pick it up. The wiring change and the 0.2.x range ship together in a later release. No installation needs to act. A BOM that pins components.kagent.versionRange inside 0.1.x is unaffected.
  • AI Agents muster v5.14.0

    Added

    • (self-update) Install a release binary only after its cosign Sigstore bundle verifies in #1178 by @teemow

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.13.0...v5.14.0

  • AI Agents klaus v0.1.0

    Added

    • (self-update) Install a release binary only after its cosign Sigstore bundle verifies in #467 by @teemow

    Full Changelog: https://github.com/giantswarm/klaus/compare/v0.0.331...v0.1.0

  • AI Agents klausctl v0.4.0

    Added

    • (self-update) Install a release binary only after its cosign Sigstore bundle verifies in #342 by @teemow

    Full Changelog: https://github.com/giantswarm/klausctl/compare/v0.3.3...v0.4.0

  • AI Agents klaus v0.0.331

    Changed

    Full Changelog: https://github.com/giantswarm/klaus/compare/v0.0.330...v0.0.331

  • AI Agents muster v5.13.0

    Fixed

    • Core tools declare MCP annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint). Every core_* tool is classified where it is declared: the list/get/validate/probe tools are read-only (core_auth_login included — it issues a sign-in link for the caller and changes nothing on the platform), creates are additive writes, updates/deletes/stops are destructive writes. list_tools, filter_tools and describe_tool report them like a downstream server’s, so the built-in read-only toolset preset now includes the 16 read-only core tools and refuses the 13 writes without any tool: selector, and a workflow whose steps call a read-only core tool derives readOnlyHint: true. An agent on preset:read-only no longer needs tool:core_auth_login to connect SSO-protected servers. The table is in docs/reference/mcp-tools.md (“Core tool annotations”). (#1172)