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

AI Agents

  • AI Agents muster v5.43.7

    Fixed

    • A client connection through a gateway survives a replaced aggregator pod. For a while after muster’s pod was replaced, the gateway in front of it answered upstream call failed: Connect: deadline has elapsed, and every CLI command failed with failed to connect to aggregator on the first such answer, although the new pod was healthy. The agent client’s Connect now retries a connection that did not reach the aggregator (a refused, reset or timed-out connection, or a gateway’s 502, 503, 504 or failed upstream call) with a fresh session for up to 30 seconds, bounded by the caller’s context; a 401 or any other refusal is final. muster auth token prints a valid stored access token without contacting the aggregator and connects only to renew an expired one. (#1536)
  • AI Agents muster v5.43.6

    Fixed

    • The chart takes an affinity. values.schema.json declared affinity as an object with no properties allowed, so every affinity a deployment set, a pod anti-affinity spreading two replicas over nodes for one, failed the install with Additional property podAntiAffinity is not allowed. The key now accepts any affinity, like nodeSelector. (giantswarm/agent-platform#1080)
  • AI Agents agent-platform v4.142.0

    Changed

    • The portal moves to the backstage 3.x line, the Agent Platform shell (giantswarm/agent-platform#1067). components.backstage.versionRange is >=2.68.0 <4.0.0, so the portal resolves the latest 3.x release, the shell with the connectors’ display names, without an own range or a patched Deployment. 3.0.0 changes the portal’s UI, not its chart values; the connectivity chart’s app-config already turns the shell on (app.portals.agentPlatform). An installation that keeps the classic portal sets components.backstage.versionRange: ">=2.68.0 <3.0.0".
  • AI Agents muster v5.43.5

    Changed

    Fixed

    • (helm) MCPServer alerts leave out person-registered servers in #1530 by @teemow
    • (metatools) Rank filter_tools queries over the full description in #1537 by @marians

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.43.4...v5.43.5

  • AI Agents muster v5.43.4

    Fixed

    • A call to a backend that is reconnecting is no longer answered server not found. Three failed health probes move a server to Failed with a reconnect due, and the aggregator removed its registry entry until the reconnect registered it again; a call in that window, typically while the backend’s only pod is replaced, was told server not found: <server> as if the server had never existed. The aggregator now remembers a server whose entry it removed while its service is still alive: a call waits up to 10 seconds (or its own deadline) for the reconnect and is dispatched to the reconnected backend, or is answered server <server> is reconnecting: … retry the call shortly. A stopped or deleted server is still server not found. (#1531)
  • AI Agents agent-platform v4.141.1

    Changed

    • (deps) Envoy v1.40.0, livenessprobe v2.20.0 for the CSI companion in #1071 by @teemow

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.141.0...v4.141.1

  • AI Agents muster v5.43.3

    Fixed

    • muster auth login reports why it cannot reach the server instead of a missing challenge. Against a server whose TLS certificate the host does not trust, or one that refuses the connection, the sign-in failed with no auth challenge available, hiding the x509 or connection error. The discovery probe now keeps the error of a request that got no response, and the login and --force re-login report it (cannot reach <endpoint>: … x509: certificate signed by unknown authority). A server that answers without a challenge still reports no auth challenge available. (#1527)
  • AI Agents agent-platform v4.141.0

    Added

    • (tenants) Credential refs name only tenant credentials in #1068 by @teemow
    • The Google access-token credential provider runs beside Substrate in #1046 by @QuentinBisson

    Changed

    • (deps) Update gsoci.azurecr.io/giantswarm/agent-manager docker tag to v2.3.1 in #1001 by @renovate[bot]
    • (connectivity) Drop the portal’s dead rootRedirect and nav-item:agent-platform in #1070 by @marians

    Fixed

    • (tests) Retry a throttled registry with backoff honouring Retry-After in #1073 by @teemow

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.140.0...v4.141.0

    Release-candidate proof (v4.141.0-rc.5)

    agentlab v0.110.2, a local kind test installation with tenants.organizations.enabled. agent-platform 4.140.0 upgraded in place to 4.141.0-rc.5. It moves no Substrate or kagent range (Substrate 1.12.0, kagent 1.13.0 before and after).

    • All releases: 15 of 15 HelmReleases Ready on 4.141.0-rc.5.
    • #1046: google-access-token-credential-provider 0.1.0 Ready in ate-system, after substrate; Deployment 1/1, Service :50051 and its CiliumNetworkPolicy in place. It loads its namespace policy and admits only spiffe://cluster.local/ns/ate-system/sa/atenet-egress. Nothing is routed to it in this release.
    • #1001: the agent-manager migration Job ran on agent-manager:2.3.1; agent-manager is Ready.
    • #1070: the portal’s app-config carries no rootRedirect and no nav-item:agent-platform; / answers 200 with the Agent Platform shell.
    • #1068: proven on rc.1 (in #1068); agentlab tenants-test passes again here.
    • #1073: test code only.
    • agentlab platform-test: 13 PASS, 0 FAIL. agentlab tenants-test: 6 PASS, 0 FAIL.
  • AI Agents muster v5.43.2

    Fixed

    • (cli) Store the client_id a token was obtained with and refresh with it in #1525 by @teemow

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.43.1...v5.43.2

  • AI Agents muster v5.43.1

    Fixed

    • Helm: MusterMCPServerFailed stays silent for a sibling installation that is down. A hub reaches a sibling’s servers as <mc>-mcp-<type>; when every one of them, two at least, is Failed, the sibling counts as down, its own heartbeat is the alert, and its servers no longer fire one alert each on every hub. A sibling server failing while another of the sibling’s servers is not Failed still fires, and so do a single-server sibling, the installation’s own <installation>-mcp-<type> servers and every server outside the naming. The promtool suite covers the three cases. (giantswarm/agent-platform#1066)