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

AI Agents

  • AI Agents muster v5.31.0

    Added

    • A pinned server can receive the person’s ID token next to its grant. A server that acts for the person on two systems needs two of their credentials – the grant of its pinned authorization server (a GitHub App user token, say) and the person’s own identity for calls back through muster – but an MCPServer carried one: forwardToken is rejected next to authorizationServer, so such a server was registered twice. spec.auth.forwardIdentity: true, valid only with type: oauth and an authorizationServer pin (CEL rule, and the same check in filesystem mode and core_mcpserver_validate), sends the session’s upstream ID token – the token forwardToken would put in Authorization, read on every request so a refreshed one is used – in the X-Muster-Id-Token header; Authorization keeps the pinned grant. A session without an upstream ID token sends no header, a server without the field never receives it, the server’s requiredAudiences are requested at login as for a forwardToken server, and a change of the field resets the sessions’ connections. As with forwardToken, the forwarded token is not audience-scoped to the server. muster create mcpserver gained --forward-identity. (#1317)
  • AI Agents muster v5.30.1

    Fixed

    • The helm.sh/chart label is valid for any chart version. The label is <name>-<version> cut to 63 characters, and the cut of a long version (a branch build’s X.Y.Z-dev.<branch>.<date>.<time>.h<sha7>, or the <tag>+<digest> helm-controller installs) could end in ., _ or --., which the API server refuses for every labelled object. The muster and muster-crds helpers now trim the whole run of -, . and _ at the ends of the cut, and a helm-unittest suite renders the label for such versions. (#1319)
  • AI Agents agent-platform v4.62.1

    Changed

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.62.0...v4.62.1

  • AI Agents agent-platform v4.62.0

    Changed

    • valkey.valkey.auth.usersExistingSecretChecksum is documented (giantswarm/valkey-app#72, giantswarm/giantswarm-platform-manager#212). From valkey-app 0.1.5 the Valkey chart renders that value verbatim as the pod’s checksum/users-secret annotation, so a password rotated in usersExistingSecret restarts the Valkey when the mark changes with it. The key passes through the open valkey block as it always did and this chart sets no default for it, so no installation’s render changes; components.valkey.versionRange (0.x) picks the release up on its own, nothing is pinned. muster’s own mark is giantswarm/muster#1315.

    Removed

    • Breaking: The klausGateway keys the Slack-only gateway ignores, the /v1, /web and /cli/v1 prefixes of its route, and components.klaus-gateway.versionRange below 2.0.0 (giantswarm/klaus-gateway#319, after giantswarm/agent-platform#633). The meta chart no longer forwards klausGateway.cli, klausGateway.lifecycle, klausGateway.upstream, klausGateway.agentgateway, klausGateway.routing.defaultTTL and klausGateway.a2a.saToken: klaus-gateway 2.0.0 accepts them as no-ops and does nothing with them, and the connectivity chart drops the same six, which no template of it read. The component’s range is >=2.0.0 <3.0.0 and examples/customer-bom.yaml pins 2.0.0, because the values this chart now sends do not start a 1.x gateway: it reads lifecycle.driver, and with none forwarded it falls back to operator with no operatorMCPURL. An installation that sets components.klaus-gateway.versionRange itself replaces the chart’s range and nothing checks it, so a pin below 2.0.0 has to move — UPGRADE.md, “the klausGateway keys the Slack-only gateway ignores are no longer forwarded”. The connectivity chart’s klaus-gateway HTTPRoute publishes /channels/slack alone — /v1, /web and /cli/v1 answer 404 on 2.x — and, having nothing else to publish, renders only while klausGateway.slack.enabled; the OBO route (/auth/slack/, /connectors/complete) is unchanged. An installation that still sets one of the six keys in its own values keeps forwarding it, harmlessly, until that values file drops it.
  • AI Agents agent-platform v4.61.1

    Added

    • A release whose component floor is unpublished is refused before either chart is pushed: make verify-release-floors, the strict run of tests/verify-components-charts.py on the tag pipeline (giantswarm/agent-platform#624). A floor bump merged before the component’s chart was pullable (klaus-gateway 1.20.0, tagged with a GitHub release while its chart pipeline had failed) produced 4.55.0, a release every installation on the line failed on twice over. On a tag the check resolves every components.<name>.versionRange and every BOM pin the way Flux does and pulls the chart it resolves to; UNRELEASED and RENDER_AGAINST do not apply there, and a range that admits nothing published, or a pin that is not published, fails naming the component and the version the release waits for. The connectivity push requires the job; the meta chart’s generated push-chart-release requires it through gen.ci.chartReleaseGateJob in giantswarm/github. Recovery is a rerun of the tag’s workflow from failed once the component chart is out — the tag stands. The branch pipeline keeps rendering against the fallbacks, so a PR can still land before the component release; without a fallback entry a PR bumping to an unpublished floor is red naming the version it waits for.
  • AI Agents muster v5.30.0

    Added

    • Spans name the backend of a tool call. A call through call_tool set mcp.tool.name=call_tool on muster’s spans and no tool name on the client span to the backend, so a trace could not be filtered by backend tool or server. The client span to the backend now carries gen_ai.tool.name (the backend-native tool name, from the OpenTelemetry GenAI semantic conventions for MCP) and mcpserver.name; the inbound mcp.tools/call server span and the tool.<tool> span carry mcpserver.name and muster.downstream.tool.name (the exposed name, as in muster_downstream_tool_calls{tool}), and mcp.tool.name still names the invoked tool. A workflow.step span is labelled by its own dispatch; the workflow’s server span is not. (giantswarm/giantswarm#36711)
  • AI Agents agent-platform v4.61.0

    Added

    • The data plane’s buffer is the platform’s own number: gateway.http.maxBufferSize, 8Mi, rendered as the Gateway-scoped <release>-http AgentgatewayPolicy (frontend.http.maxBufferSize) (giantswarm/agent-platform#630). The MCP path reads every tool answer of every server behind muster whole before it forwards it, and an answer above the limit is refused with agentgateway’s body exceeded buffer limit — at the 2 MiB default a whole-registry dry run of the platform manager was lost this way, an error naming neither the size nor the limit. 8Mi is sized from what the platform’s tools answer (the manager’s own 1 MiB bound wrapped once more by muster’s call_tool, with the same room several times over for a server that bounds nothing) and stays inside the data plane’s 512Mi memory limit a dozen times over. A quantity or a byte count; empty leaves agentgateway’s default in force; frontend policies merge field by field, so this policy owns frontend.http alone (make verify-dataplane-buffer). Both charts carry the default. README “The data plane’s buffer”.
  • AI Agents muster v5.29.4

    Fixed

    • kubectl logs shows muster’s log when an OTLP endpoint is set. In OTLP mode mcp-toolkit’s logging replaced the console handler, so muster wrote nothing to stdout or stderr, and with the collector down its log went nowhere. muster serve now passes mcp-toolkit’s WithStderrMirror in OTLP mode: every record also goes to stderr as JSON with trace_id and span_id. --silent still writes nothing to the console. (giantswarm/giantswarm#36711)
  • AI Agents agent-platform v4.60.1

    Changed

    • Drop the agentgateway and klaus-gateway UNRELEASED entries and the klaus-gateway monitor hold in #637 by @QuentinBisson

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.60.0...v4.60.1

  • AI Agents agent-platform v4.60.0

    Added

    • Claude Opus 5.5 is priced in the LLM routing catalog: llmRouting.modelCatalog.providers.anthropic.models.claude-opus-5-5 (giantswarm/giantswarm-configs#885). Input $4, output $20, cache reads $0.20 and 5-minute cache writes $5 per million tokens, from Anthropic’s pricing page. Without the entry, every lookup for the model misses and the gateway emits no cost sample for its calls. Both charts carry it.