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

AI Agents

  • AI Agents agent-platform v4.146.1

    Changed

    Fixed

    • (workspaces) Refuse workspaces without the agents at render time in #1119 by @teemow

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.146.0...v4.146.1

  • AI Agents muster v5.44.2

    Changed

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.44.1...v5.44.2

  • AI Agents agent-platform v4.146.0

    Changed

    • components.substrate.versionRange and components.substrate-crds.versionRange are >=1.14.0 <1.15.0 (were >=1.13.0 <1.14.0), the kagent WorkerPool’s worker image follows to ateom-gvisor:1.14.0, the customer BOM pins Substrate 1.14.0, and substrate.credentialProvider.additionalProviders routes google-access-token.k8s.io to the credential provider plugin (giantswarm/giantswarm#38547). Substrate 1.14.0’s bundled Kubernetes credential provider serves k8s.io alone (giantswarm/substrate#455); the Google access token a Vertex AI ModelConfig’s actor needs comes from components.google-access-token-credential-provider, deployed since 4.141.0, which the egress gateway now reaches for that class. Vertex AI ModelConfigs and their Secrets are unchanged.
    • One source of truth for the component version floors (giantswarm/agent-platform#1102). components.<name>.versionRange in values.yaml is the one place a floor is declared: tests/floors.py reads the ranges and floors from it, and the checks that named a floor (verify-presets’ muster, verify-meta’s agentgateway and BOM, verify-components’ ranges, Substrate pin and release-candidate filters, verify-cluster-manager, verify-workspace-manager) ask it instead; a feature floor a check holds a range to stays a minimum (floors.py floor <name> --min). The customer BOM pins every component with a >= floor at that floor: make golden-update writes the pins, make verify-meta fails on one that differs. A floor move is one edit of values.yaml plus make golden-update. The BOM’s agent-manager pin moves from 2.1.0 to 2.3.0, the floor of its range.

    Removed

    • ingress.mode: agentgateway-direct is gone (giantswarm/agent-platform#252). The mode never rendered: its guard failed every install for want of a DCR-capable IdP. The connectivity chart now refuses it as an unknown mode (must be one of: agentgateway-muster, muster-direct); its viaMuster: false guard, the meta chart’s unused copies of the ingress guard and the mode’s values comments go with it. No installation renders differently. make verify-modes asserts the refusal.
  • AI Agents muster v5.44.1

    Fixed

    • A server that refuses the stored grant on connect answers its sign-in link, not a 401. A session marked signed in to an OAuth server but without a live connection to it (after a restart, or once the pooled connection was retired) opens one on its next tool call; when the server refused the stored token on that handshake, every call failed with failed to initialize on-demand client ... 401 while muster auth status kept showing the server connected. The call now answers the server’s auth_required challenge with its sign-in link, as a 401 during a call already did: the refused grant is dropped, the session is no longer marked signed in to the server, and core_auth_login issues the sign-in. muster auth login --force --server <name> signs out of a server the session reads connected and signs in to it again; without --force the command says so instead of claiming the server needs no authentication. (#1574)
    • A core_auth_login that starts no OAuth flow no longer spends the person’s authentication attempts. Every call was charged to the per-user rate limit (10 attempts a minute) before muster looked at the session, so a client checking a server’s connection with core_auth_login (the portal does before it acts for the person) used up the attempts with answers like “already authenticated” and the next real sign-in was refused with “Rate limit exceeded … Remaining attempts: 0”. An attempt is now charged only when the answer needs an OAuth flow, a held grant reused or a new challenge; answers that start none (already authenticated, no authentication needed, a deactivated or SSO-managed server) are free. The limit itself is unchanged. (#1567)
  • AI Agents agent-platform v4.145.1

    Changed

    Fixed

    • (connectivity) Delete the orphaned workspace-manager sign-in keys Secret on upgrade in #1099 by @teemow
    • (components) Cap every component range at the line its values were proven against in #1100 by @teemow
    • (components) Select kagent 1.15, the workspace write path in #1110 by @teemow
    • (connectivity) The config-reload stamp carries its own field manager in #1101 by @teemow
    • (muster) Do not wait for muster’s pods until Substrate is Ready in #1109 by @teemow

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v4.145.0...v4.145.1

  • AI Agents agent-platform v4.145.0

    Fixed

    • A pull request behind main keeps its render goldens green (giantswarm/agent-platform#1093). The goldens of verify-modes and verify-wiring compare a branch’s render against GOLDEN_REF, which now defaults to the merge-base of HEAD and GOLDEN_BASE (origin/main), not main’s tip: a later main commit that changes an unrelated render no longer reads as the branch’s drift, and a branch whose own render is wrong still fails. An explicit GOLDEN_REF wins, GOLDEN_REF= still opts out. No chart change.
  • AI Agents muster v5.44.0

    Fixed

    • A subject-scoped issuer stays pinned while its MCPServer is down. An authorization server was pinned only once its MCPServer answered (connected, or 401 for a pending-auth entry), so after a muster restart with the issuer’s backend down, FetchSecret and the token broker answered “the person holds no grant” although the grant was intact in the store; a connected issuer whose backend then failed lost its pin on deregistration in the same way. muster now pins every MCPServer definition’s authorization server whatever the backend’s state (at start, on every MCP service event and on the 5 s reconcile tick), retries a deferred pin (Secret missing, OAuth not ready), keeps the pin when a Failed backend deregisters, and releases it when the definition changes or is deleted; the pin is logged at registration (Pinned authorization server … subjectScoped=true). (#1553)
  • AI Agents agent-platform v4.144.0

    Changed

    • The installation’s skills credential is never a tenant’s credential. agent-manager mints it as agent-manager-skills-token, the installation’s own name outside the tenant-credential- prefix; agent-platform-tenant-credential-refs refuses it in every Organization namespace under each of its names (agent-manager.skills.gitAuthSecretName or the minted Secret, and their earlier names, tenant-credential-agent-manager-skills-token included), as a git credentialRef or a headersFrom Secret, for every requester. The platform’s agents keep naming it in the kagent namespace. The connectivity chart’s agent-manager migrate run moves every agent naming tenant-credential-agent-manager-skills-token to agent-manager-skills-token, which agent-manager keeps filled; the earlier Secret stays filled until no agent names it. make verify-migration and make verify-tenant-rbac assert both.
  • AI Agents agent-platform v4.143.0

    Added

    • The data plane’s access log carries the request id: request_id (giantswarm/agent-platform#867). The <release>-access-log policy adds the x-request-id request header as request_id to every access log line, beside agent_instance_id. The Dev Portal’s backend sets that header on every call it makes through the data plane and names it in an error banner, so the banner’s id finds the gateway line of the failing call. The data plane generates no id: a request without the header logs none. The connectivity README’s “Access log attributes” lists the chart’s field set. make verify-access-log asserts both default fields. Every installation with the agentgateway data plane gets one more field on its access log; no pod rolls.
  • AI Agents agent-platform v4.142.1

    Changed

    • The Substrate workers run the release the control plane runs (giantswarm/agent-platform#822). The chart sets ateController.gvisorWorker.followRelease: true on the substrate release, so a Substrate patch within components.substrate.versionRange rolls the kagent worker pool with the atelet, with no chart release. The range is the one source of the Substrate version; the WorkerPool’s spec.workerImage stays the floor’s. An own followRelease: false fails the render. make verify-worker-image renders the substrate chart the range resolves to and fails when its ate-controller would run the workers on another release than its atelet.