AI Agents

  • Added

    • clusterManager.networkPolicy.workloadClusters.provider: aws opens the CAPA API server load balancers, *.*.elb.amazonaws.com (giantswarm/agent-platform#487). cluster-manager dials the server: of a cluster’s Cluster API kubeconfig Secret, which on CAPA is the API server’s load balancer, never the api.*.<base domain> pattern the values used to document. The preset renders next to fqdns in cluster-manager’s egress and in model-manager’s, which follows cluster-manager’s block. An unknown provider is refused and the presets are named. The values now say which host to select and that Cilium’s * matches one DNS label.
  • Fixed

    Full Changelog: https://github.com/giantswarm/klaus-operator/compare/v0.0.172...v0.0.173

  • Changed

    Full Changelog: https://github.com/giantswarm/klaus/compare/v0.1.40...v0.1.41

  • Changed

    • The kagent line at 1.2.0, and kagent.otel in the chart’s SDK-spec shape (giantswarm/giantswarm#37742). components.kagent.versionRange and components.kagent-crds.versionRange are >=1.2.0 <1.3.0 (upstream kagent main@dd3b2405, Substrate 1.1.0 unchanged). kagent.otel is exporter.otlp.{endpoint,protocol,timeout} (auto, auto, "500": endpoint and protocol follow global.observability.traces.otlp), traces.enabled and logs.enabled (auto, off while the signal has no endpoint); kagent.otel.tracing and kagent.otel.logging are gone, and so is their insecure (the endpoint’s scheme decides), and so are OTEL_LOGGING_ENABLED and KAGENT_TRACE_FLUSH_TIMEOUT_MS in kagent.harness.env. The connectivity chart reads the same shape for the OTLP egress rules of the kagent controller and the Substrate egress gateway: a signal’s own endpoint and protocol, else exporter.otlp’s. UPGRADE.md. The kagent log exporter honors the protocol on this line, so global.observability.traces.otlp.protocol: http/protobuf no longer fails the render over it.
  • Fixed

    • A rolling muster takes traffic only once it can mint tokens. The chart’s readiness probe read /health, which answers 200 while OIDC discovery is still pending, so a new pod joined the Service and the old one was stopped while the new one still answered every /oauth/token with 503 service_unavailable (“OIDC discovery in progress”) – a burst of failed exchanges for every client at once, the Developer Portal’s cluster-token exchange across all installations included. The new /readyz answers 503 until discovery succeeds and the chart’s readiness probe uses it; /health stays the liveness probe and keeps answering 200, so a Dex outage still does not restart the pod. (giantswarm/giantswarm#37348)
  • Added

    • The Klaus Gateway board shows the whole turn as a person sees it: “Turn done (final flush), p50 and p95” (giantswarm/giantswarm#37787). The panel sits beside “Time to first text” and shows the time from the message’s arrival to the last edit of the answer in the channel, from klaus_gateway_turn_phase_seconds{phase="final_flush"}. Before, the board showed only this phase’s p95, inside “Turn phases, p95”.
  • Added

    • model-manager, agent-manager, vm-manager, cluster-manager, the portal and mcp-kubernetes export their traces to the platform’s OTLP collector (giantswarm/giantswarm#36711). <component>.observability.otel.{endpoint,protocol,headers} of the four managers and backstage, and mcp-kubernetes.mcpKubernetes.instrumentation.{tracingExporter,otlpEndpoint,otlpInsecure,otlpProtocol,otlpHeaders}, are auto and follow global.observability.traces.otlp like the other exporters: the endpoint (host:port for mcp-kubernetes, with otlpInsecure from the scheme and tracingExporter: otlp while it is set), the protocol, and the tenant as X-Scope-OrgID next to headers. The connectivity chart’s egress policy of each manager and of the portal opens the resolved endpoint (its namespace and port, or the cluster entity / any address outside the cluster); mcp-kubernetes’ own policy already admits the cluster. The ranges move to the first releases that export: model-manager >=1.3.0, agent-manager >=1.2.0 <2.0.0, vm-manager >=0.24.0, cluster-manager >=0.19.0, backstage >=2.68.0, mcp-kubernetes >=1.3.0 (giantswarm/model-manager#183, giantswarm/agent-manager#69, giantswarm/vm-manager#112, giantswarm/cluster-manager#111, giantswarm/backstage#2601, giantswarm/mcp-kubernetes#649). make verify-otlp-global asserts the derivation and the egress rules. UPGRADE.md.
  • Fixed

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.32.6...v5.32.7

  • Changed

    • kagent.harness.compaction.tokenThreshold is 600000 (was 24000); eventRetentionSize stays 4 and the summaries stay on the agent’s own model (giantswarm/giantswarm#37792). Every Anthropic agent on the platform has the full 1M context window and nothing on the path limits the input, so 24 000 was the only bound below it, and it did not bound a turn: a large tool result stays in the retained tail and the prompt grows past the threshold anyway. Measured on a six-turn session with 100–290k-token tool results, every compacting threshold (24k, 64k, 200k) put a 13–50 s summary in front of each follow-up’s first token (median 27–38 s against 4 s uncompacted), lost three of five facts across turns, and saved nothing in a warm session, where the history is a 0.1× cache read. At 600 000 the session never compacted, its follow-ups started in 4.5 s median, recall held and it was the cheapest of the Sonnet-summarised variants. Compaction now fires only for a session heading for the edge of the window. Untested at its own size: a summary over several hundred thousand tokens may exceed the Go ADK’s 60 s bound, in which case the call goes ahead uncompacted (the harness log says so). An agent on a model with a smaller window (a self-served model) is not compacted before its window fills.
  • Fixed

    • A node drain no longer waits on the single-replica components’ budgets. The PodDisruptionBudgets of muster, klaus-gateway, agent-manager, muster-valkey and the kagent controller were minAvailable: 1 on one replica, which refuses every eviction: a cluster upgrade rolling its machines waited for each drain’s timeout. They are maxUnavailable: 1, so a drain evicts the pod and goes on. Karpenter’s consolidation stays away from those pods through their karpenter.sh/do-not-disrupt annotation (giantswarm/agent-platform#431), not through the budget. muster and klaus-gateway get minAvailable: "" next to it to clear their charts’ default of 1, and the kagent controller keeps its chart’s own default. A platform Postgres with postgres.instances: 1 renders enablePDB: false, because the operator’s budget on a lone primary has no replica to switch over to; two or more instances keep the operator’s budgets and its switchover on drain.