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

AI Agents

  • AI Agents muster v5.20.2

    Fixed

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.20.1...v5.20.2

  • AI Agents muster v5.20.1

    Changed

    • The muster and muster-crds chart READMEs no longer render a version badge (chart.badgesSection removed from both README.md.gotmpl files): a release PR bumping Chart.yaml’s version or appVersion no longer changes the checked-in README.md, so the helm-docs pre-commit hook no longer fails on it. (giantswarm/devctl#2180)
  • AI Agents agent-platform v4.19.3

    Added

    • make verify-all: every verify-* target of Makefile.custom.mk in one target, which is what CI runs. The list is read out of that file, so a new verify-* target reaches CI by existing and nothing names the set twice; make help lists what each one asserts. The test-ingress-modes job named all 37 of them on one line, which drifted from the Makefile on every addition.
    • make e2e KUBECONFIG=… [SCENARIO=…] [CLUSTER_TYPE=…] [VALUES=…]: runs one ATS scenario against any cluster. It packages the chart and hands the suite its inputs. SCENARIO is the pytest marker (smoke or functional), CLUSTER_TYPE picks the scenario defaults (kind or eks), and VALUES replaces the scenario’s values-file list. E2E_DOMAIN, E2E_ISSUER_URL, E2E_CLIENT_ID and E2E_IDP_SECRET_NAME (the name of a Secret already on the cluster, not a credential) become a temporary values overlay layered last and removed on exit; tests/e2e_overlay.py renders it, and the target prints its line count, never a value. Each of those names one fact the chart and the tests both need, so the target derives the suite’s ATS_ISSUER_URL, ATS_CLIENT_ID, ATS_IDP_CA_SECRET and — on a cluster type other than kind — ATS_MUSTER_BASE_URL from them, and an ATS_ variable already in the environment wins. A KUBECONFIG with a leading ~ is expanded, which zsh does not do for an argument of that form. Documented in tests/ats/README.md.
    • helm/agent-platform/examples/kind-lab-dex.yaml: the kind lab shape as a shipped example, moved from tests/test-values.yaml with its values unchanged (its header comment carries the install recipe and the no-secret statement). It is the file the ATS smoke installs, and test_the_scenario_installs_the_example_file asserts the scenario names an example file the repository ships. .ats/main.yaml and make verify-self’s lab-shape render follow the new path.

    Changed

    • The ATS suite takes its cluster-specific inputs from a Scenario (tests/ats/scenarios.py, one per cluster shape) instead of kind literals, so the same assertions run on any cluster. Five groups become fields, each with its own environment variable: the values files (ATS_VALUES, plus ATS_OVERLAY_VALUES layered last), the identity provider (ATS_ISSUER_URL, ATS_CLIENT_ID, ATS_CLIENT_SECRET, ATS_REGISTRATION_TOKEN, ATS_IDP_USER, ATS_IDP_PASSWORD, ATS_IDP_CA_SECRET), the OAuth redirect (ATS_OAUTH_CALLBACK), muster’s base URL and how it is reached (ATS_MUSTER_BASE_URL, ATS_MUSTER_REACH) and the budgets (ATS_INSTALL_TIMEOUT, ATS_UNINSTALL_TIMEOUT, ATS_UNINSTALL_BUDGET_S, ATS_READY_TIMEOUT_S). A port is read out of the URL that carries it, so the two can never disagree. ATS_CLUSTER_TYPE gains eks, whose scenario installs no lab Dex, port-forwards nothing and carries no default issuer, client, base URL or values file. An unknown cluster type, an unknown reach, a budget that is not an integer, a missing issuer, client or base URL, a values file that does not exist, and a non-kind scenario without ATS_VALUES, each fail the run with a message naming the variable. make verify-scenarios asserts the loader and the make e2e overlay offline. Every field defaults to the value it had, so ATS_CLUSTER_TYPE=kind with nothing else set installs the same three values files with the same ports, budgets and credentials.
  • AI Agents agent-platform v4.19.2

    Changed

    • The kagent line moves to v0.11.0-gs.16: context compaction in the Go ADK runtime and spec.context.compaction on the AgentTemplate (giantswarm/giantswarm#37792). After prompt caching (4.16.0) the remaining cost of a long agent turn was the model’s first pass over new tokens: every tool result stayed in the history verbatim and every later model call of the turn re-read it — on gazelle the status question’s ten calls grew from 6 k to 62 k input tokens, waited 9.2 s for the first token after 16 k new tool-result tokens and 18.8 s after 21.9 k, model time 59 s of the turn’s 68 s. kagent 0.11.0-gs.16 carries kagent-dev/kagent#2790 (giantswarm/kagent-upstream#41): google.golang.org/adk/v2 v2.3.0 with its native session/compaction, spec.context.compaction on the v1alpha3 AgentTemplate CRD (tokenThreshold / eventRetentionSize for tail retention inside a turn, compactionInterval / overlapSize for a sliding window over turns, an optional summarizer.modelConfig + promptTemplate, CEL for the half configurations), the kagent compiler writing it into config.json and the Go runtime handing it to the ADK runner (context compaction enabled … in the actor’s startup log). components.kagent / components.kagent-crds move to >=0.11.0-gs.16 <0.11.1-0: the floor, because the platform’s agent chart (giantswarm/agent 1.3.0) renders a compaction default on every platform agent — tail retention at 24 000 prompt tokens keeping the last four events, the summaries on the agent’s own model — and an older CRD would prune the field at admission, leaving every long turn re-reading its whole history in silence. The meta chart renders no AgentTemplate itself; the default and its knobs (context.compaction.*, enabled: false to opt out) live in the agent chart, which every agent HelmRelease follows on range 1.x. tests/verify-kagent-crds.py validates the connectivity chart’s kagent objects against the gs.16 CRDs; the BOM example and tests/verify-components.py follow the pin. Every installation rolls kagent once (the controller, then the platform Harness recompiles every admitted AgentTemplate; about 20 s per template) and, once the agent chart release is admitted, every agent recompiles once more with its spec.context — UPGRADE.md.
  • AI Agents muster v5.20.0

    Added

    • muster test: scenarios can run their instance on Valkey storage and restart it. pre_configuration.storage: {type: valkey} starts an in-process Valkey stand-in (miniredis) per instance and points every backed store – session auth, capabilities, OAuth tokens, state, client credentials, the OAuth server’s own store – at it, the way an installation’s stores outlive a pod; start_delay makes it answer only after muster serve started, for “Valkey is late” scenarios. test_restart_instance stops and starts muster serve on the same configuration while the store and the mock servers keep running and reconnects every user client with the bearer it held, so the steps after it act as the sessions that lived through a rollout; test_stop_valkey / test_start_valkey take the store away and bring it back with its data. Three scenarios reproduce bugs that were first seen on an installation because the suite could not express them: a family tool call after a restart without a listing (fails on v5.18.2, #1204), a Valkey that answers late at start being waited for rather than replaced by memory stores (fails on v5.19.12, #1229), and a pinned bare-401 server staying connectable and its grant revocable after a restart with no login in the new process (fails on v5.8.3, #1150, #1154). (#1236)

    Fixed

    • The DPoP replay cache’s Valkey client no longer enables valkey-go’s client-side cache: nothing reads through it, and its CLIENT TRACKING handshake failed against a server without the feature, which left muster’s OAuth server in degraded mode (service_unavailable on every request). The session stores and the mcp-oauth store already ran without it since v5.19.13.
  • AI Agents muster v5.19.16

    Fixed

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.19.15...v5.19.16

  • AI Agents klaus v0.1.17

    Changed

    Full Changelog: https://github.com/giantswarm/klaus/compare/v0.1.16...v0.1.17

  • AI Agents agent-platform v4.19.1

    Changed

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

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.19.0...v4.19.1

  • AI Agents agent-platform v4.19.0

    Added

    • klaus-gateway’s traces go to the platform’s OTLP gateway by default, and the gateway’s egress rule to it renders (giantswarm/klaus-gateway#263). Until now klausGateway.observability.otlpEndpoint was empty on every installation, so the gateway’s tracer provider was a no-op, the A2A call carried no trace context and the kagent controller’s SendStreamingMessage trace in Tempo had no parent — a Slack round trip could only be reconstructed from five logs. klaus-gateway 1.10.0 opens one span per turn (slack.turn, the parent of the controller’s trace and of the actor’s spans under it), takes a URL endpoint and an otlpHeaders knob; the meta chart now sets both to the target kagent’s exporters use — http://otlp-gateway.kube-system.svc:4317 with X-Scope-OrgID: giantswarm — under a new klausGateway.observability.enabled: auto that follows the resolved global.observability.metrics.serviceMonitor.enabled the way kagent.otel.*.enabled does (an explicit true/false wins; off, the release gets an empty endpoint and no headers; the knob itself never reaches the klaus-gateway chart, whose closed observability block takes the endpoint and headers only — components.klaus-gateway.omitKeys). The connectivity chart renders -klausgateway-otlp-egress exactly while the endpoint is set — DNS plus the endpoint’s namespace on its port (the cluster entity for a host that is not an in-cluster Service), in both policy flavours — through the destination parsing and the rule the kagent controller’s and the actors’ OTLP egress already used, now shared as agent-platform.otlpTarget / agent-platform.otlpEgressRule. components.klaus-gateway.versionRange moves to >=1.10.0 <2.0.0 (the floor: an older chart’s schema refuses the headers knob) and the example BOM pins 1.10.0. make verify-klausgateway-otlp asserts the forwarding, the auto resolution and the overrides, both flavours of the policy, the guards, and that the kagent controller’s rule is unchanged. Every installation with the klaus-gateway component on rolls it once (the new chart and the two new arguments) and starts exporting one trace per Slack turn to its Tempo tenant.
  • AI Agents muster v5.19.15

    Fixed

    • A new session’s first request no longer waits for the SSO fan-out (#1226). A session that arrives with a forwarded or trusted-issuer token – an agent’s session – had muster connect every session-authenticated server (one RFC 8693 token exchange or ID-token forward per server, in parallel, bounded by the slowest remote authorization server) inside its first request: initialize and the agent’s first tools/list answered only after the last server had connected, 2.7-3.2 s on an installation with 81 such servers, although tools/list returns the meta-tools and needs none of the connections. The fan-out now starts on the first request and runs in the background; initialize and tools/list answer at once. A call_tool (or resource read, or prompt) for a server still connecting waits for that server’s connect alone, resolved from the tool name’s prefix or its family, not for the whole fan-out; list_tools, filter_tools and describe_tool wait for the fan-out so a session’s first listing is complete. The person’s subject-scoped grants (GitHub-style connectors) are adopted in the same fan-out instead of sequentially on the first call that misses them. Requests arriving while the fan-out runs share it; the sign-in flow still connects before it issues the access token. The fan-out logs its total duration, outcome counts and slowest server (SSO: fan-out finished … duration_s=… slowestServer=…), each connect logs its duration, and a held request logs how long it waited (SSO: tool call waited for its server's connect). muster test: a step’s max_duration bounds one invocation and fails the step when it ran longer; an OAuth-protected mock takes connect_delay to stand in for a backend that is slow to connect. Scenario: oauth-sso-session-start-answers-during-fan-out.