opensource.google.com

Menu
Showing posts with label Agents. Show all posts
Showing posts with label Agents. Show all posts

Disrupting the presentation layer using autonomous workflows

Thursday, May 21, 2026

Empowering every engineer to do more with Kubernetes

Kubernetes is the gold standard for container orchestration. Its power, flexibility, and rich API surface are exactly why it has become the foundation of modern cloud-first infrastructure. Today, engineers express that power through the K8s API, declarative YAML manifests, and cloud consoles, a remarkably expressive toolbox.
We believe the next step is to expand how engineers interact with that toolbox. A Kubernetes expert should be able to converse with a deep-domain peer that speaks fluent control-plane and can reason about cluster state in real time. An engineer who isn't a Kubernetes specialist should be able to express higher-order intent, such as "deploy my application," "rebalance this workload" and have it carried out safely against the same powerful APIs. Both audiences get more leverage out of the platform they already trust.
This is the vision behind Kube-Agents: a system of intelligent, autonomous, and human-in-the-loop agents that act as a new, intent-driven presentation layer for Kubernetes. We are moving from declarative intent via API to higher-order, human intent-driven operations while preserving everything that makes Kubernetes great underneath.

The Vision: Expanding the Presentation Layer

Today, engineers do impressive work stitching together metrics, alerts, and multi-step commands to keep clusters healthy. Agents extend that work, not replace it. By complementing existing interfaces with autonomous agents, engineers can choose the level of abstraction that fits the task: drop down to kubectl and YAML when precision matters, or describe intent in plain language when speed and clarity matter more. The agents continuously observe system state and can execute complex operations in real time on the engineer's behalf. This isn't about hiding Kubernetes. It's about giving every engineer a more capable collaborator on top of it.

Meet the Agents: A Specialized Team

Our architecture is currently built upon three core specialized agents, each acting as a new kind of intent-driven collaborator for different stakeholders:

  1. The Platform Agent
    • Role: A partner for the central governance layer, your management plane.
    • Focus: Codifying best practices and keeping platform blueprints evergreen and synchronized across the entire fleet.
    • Example: When a new egress policy is defined at the org level, the Platform Agent propagates it to the Dev Team agents and confirms enforcement, giving platform teams confidence in compliance while letting developers stay focused on their applications.
  2. The Cluster Operator Agent
    • Role: A trusted teammate for your infrastructure operators.
    • Focus: Global concerns like multi-cluster balancing, automated provisioning, security patching, and zero-downtime version upgrades.
    • Example: It can detect a degrading node and proactively migrate workloads before application latency spikes, expanding what a single operator can safely manage at scale.
  3. The Development Team Agent
    • Role: A production-savvy peer for developers.
    • Focus: The primary collaborator for developers. It supports the full workload lifecycle — reconciling manifest drift, right-sizing resources, and assisting with real-time debugging.
    • Example: When a developer asks "Why is my service failing?" in chat, the agent responds with relevant logs, correlated metrics, and a diagnosis of recent config changes — meeting a Kubernetes expert at depth and meeting a less specialized developer at intent.

Leveraging Industry Benchmarks

DevOps Bench is a comprehensive suite of benchmarks. These specialized agents learn from those results so they are equipped with the context to make well-reasoned decisions when autonomously supporting infrastructure work.

The First Demo

To be truly useful at the presentation layer, these agents can't be short-lived request/response scripts. They need to be persistent, long-running "team members" capable of continuous learning and collaboration.
As a first step, we've launched a set of workspaces compatible with OpenClaw for a demo, installable into your OpenClaw environment, leveraging existing out-of-the-box capabilities around identity, storage persistence, and memory. The agents included are: the Platform Agent, the Cluster Operator Agent, and the Development Team Agent.

  • Autonomous GitOps & JIT Probing (Dev Team Agent): Demonstrates prompt-driven staging deployments and dynamically generated, context-aware probers. The agent adheres strictly to GitOps workflows by opening PRs for infrastructure updates (such as node failure tolerance) and actively prevents configuration drift by reconciling manual manifest edits upon merge.
  • Self-Healing Infrastructure (Dev Team Agent): Showcases automated troubleshooting when a manifest is deployed with an image name typo. The agent executes a complete, autonomous 5-step remediation loop—Notification, Learning, Recommendation, Mutation, and Validation—to detect, fix, and verify the deployment without human intervention.
  • Multi-Agent Governance & Policy Coordination (Cluster Operator & Dev Team Agents): Highlights cross-agent negotiation when the Cluster Operator attempts to downscale underutilized resources for cost savings. The Dev Team Agent steps in to enforce minimum capacity policies, successfully prioritizing application reliability and governance over financial savings.
Animated walkthrough showcasing three OpenClaw agent demos in sequence: first, the Platform Agent configuring core infrastructure and identity; second, the Cluster Operator Agent managing cluster health and scaling; and finally, the Development Team Agent deploying applications and managing developer workflows.

Going forward, we will further productize this pattern, building on open standards to define agents and their capabilities (AGENTS.md, skills, MCP), and provide an out-of-the-box harness to orchestrate these agents.

Redefining the Stack

An intent-driven presentation layer is just the beginning. With an agentic interface in place, we can keep evolving the underlying infrastructure — adopting new components or integrating directly with additional infrastructure APIs — while engineers continue to interact with the system the way they already do. The interface stays intent-driven and stable; the agents adapt to the evolving stack underneath, so investment in how teams work today carries forward.

Call to Action

We're building Kube-Agents in the open because we believe the best infrastructure solutions are built collaboratively. Our goal is to use our expertise to give back to the open source community, while also actively learning from the ecosystem's real-world challenges. By working together, we can define best practices that benefit everyone.
If you're interested in helping shape the future of Kubernetes management, check out the Kube Agents repo.

We are seeking engagement on two fronts:

  • Share your use cases: What would you most like an autonomous teammate to help with? We want to learn from your unique operational needs—whether it's multi-cluster balancing, specific debugging scenarios, or policy enforcement—to ensure we're building tools that provide real leverage.
  • Define future roles: What new specialized agents should exist? We value your input on the roles these agents should fulfill to best serve diverse team structures and operational requirements.

Join the conversation, contribute your ideas, and help us build a self-driving cloud that works for everyone. Check out the Kube Agents project to open an issue or start a discussion.

Celebrate A2April!

Thursday, April 9, 2026

Happy 1st Birthday to A2A! Join the community in celebrating the first anniversary of the A2A and its recent 1.0 release. April 9th marks the official birthday, and we're celebrating all month long with #A2April. To help you celebrate, we've used Gemini to make a party hat.

Use the template and instructions below to create your commemorative party hat.

Assembly Instructions

  1. Print: Print this document on heavy cardstock for the best results.
  2. Cut: Carefully cut along the solid outer border of the semi-circle template.
  3. Fold: Gently curve the template into a cone shape, overlapping the "Glue/Tape Tab" underneath the opposite edge.
  4. Secure: Use double-sided tape or a glue stick along the tab to hold the cone shape.
  5. Finish: Punch two small holes on opposite sides of the base and thread through an elastic string or ribbon to secure the hat to your head.

Party Hat Visualization

Make sure to print in landscape mode

Ways to Celebrate

  • Social Media: Share a photo of yourself wearing your hat with the tag #A2April to help generate that social media buzz.
  • Blog Series: Keep an eye out for the upcoming A2April blog series featuring quotes from the team and stories from the open source community.
  • Community Quotes: If you're using A2A in production, reach out to us via social media and share your story for the birthday post.

Unleashing autonomous AI agents: Why Kubernetes needs a new standard for agent execution

Tuesday, November 11, 2025

Unleashing autonomous AI agents: Why Kubernetes needs a new standard for agent execution

The arrival of autonomous AI Agents capable of reasoning, planning, and executing actions by generating their own code and interacting with the runtime environment marks a paradigm shift in how applications are built and operated. However, these new capabilities also introduce a fundamental security gap: how to safely allow agents to run untrusted, unverified generated code, perform actions and get access to data in runtime environments, especially pertaining to mission-critical infrastructure and environments that may have proprietary data.

We are excited to announce a major initiative within the Kubernetes community to address this exact challenge: we are launching Agent Sandbox as a formal subproject of Kubernetes SIG Apps, hosted under kubernetes-sigs/agent-sandbox.

This is more than just a tool; it is designed to standardize and evolve Kubernetes into the most secure and scalable platform for the agentic workloads.

The Latency Crisis for Interactive AI

Agent behavior often involves quick, iterative tool calls — checking a file, running a calculation, or querying an API. For security reasons, each of these calls requires its own isolated sandbox.

The challenge is that these sandboxes must be created from scratch, extremely quickly, to ensure isolated environments between executions. Because security and isolation are non-negotiable, the "spin-up" time becomes the critical bottleneck. If the secure execution environment takes too long to spin up, the entire agent application stalls, killing the interactive experience.

The Bottleneck of Massive Throughput

Enterprise platforms require infrastructure that can handle overwhelming scale. Users engaged in complex AI agent workloads demand support for up to tens of thousands of parallel sandboxes, processing thousands of queries per second. To meet this challenge, we are extending Kubernetes' proven capabilities of managing high-capacity, low latency applications, models and infrastructure to fit a growing class of single-instance workloads, like AI agent runtimes or dev environments, that require a lightweight, VM-like abstraction. A standardized, controller-based Sandbox API provides Kubernetes-native solution for these use cases, avoiding the workarounds required today, paving the way for the next generation of cloud-native AI applications.

The Agent Sandbox: A new Agent Standard for Kubernetes

To solve these problems, we are introducing a new, declarative resource focused strictly on the Sandbox primitive, designed from the ground up to be backend-agnostic.
The goal is to provide a persistent, isolated instance for single-container, stateful, singleton workloads, managed entirely through familiar Kubernetes constructs. The core APIs include:

  • Sandbox : The core resource defining the agent sandbox workload for running an isolated instance of the agent's environment
  • SandboxTemplate : Defines the secure blueprint of a sandbox archetype, including resource limits, base image, and initial security policies
  • SandboxClaim : A transactional resource allowing users or higher-level frameworks (like ADK or LangChain) to request an execution environment, abstracting away the complex provisioning logic.


In addition to the Sandbox primitive we are also launching with additional features that make the experience as a whole better for the user:

  • WarmPools — In order to support fast instance startup time, which is an important part of the usability of agenting sandboxes, we introduced the Warm Pool extension. The Sandbox Warm Pool Orchestrator utilizes a dedicated CRD to maintain a pool of pre-warmed pods, allowing the Sandbox Controller to claim a ready instance upon creation and reduce cold startup latency to less than one second.
  • Shutdown Time — Since agentic behaviour can be unpredictable, this feature supports clean termination and cleanup of sandboxes, it automates the deletion by providing an absolute time for the sandbox to terminate.
  • Python API/SDK — For better usability and a developer-friendly interface to programmatically interact with these CRDs, we provide an example SDK that abstracts away Kubernetes complexities with simple Pythonic functions.

The standard is designed to seamlessly support multiple isolation backends like gVisor and Kata Containers allowing developers to choose the technology that best fits their security and performance trade-offs.

The new Agent Sandbox features and implementations are available now in the github repo kubernetes-sigs/agent-sandbox and on our website agent-sandbox.sigs.k8s.io. We invite all developers, partners, and experts to join this critical community effort to define the secure scalable future of autonomous AI on Kubernetes.

We will be presenting a technical deep dive and officially launching the project at Kubecon Atlanta, November 2025. We hope to see you there!

.