This Week in Open Source for November 13, 2026

by Daryl Ducharme and Remigiusz Samborski, Open Source Programs Office

A look around the world of open source

Open source communities are navigating a structural tension: automated tools are accelerating code generation and security probing faster than human maintainers can review pull requests, build consensus, or fund shared infrastructure. Across this edition, we look at how maintainers, foundations, and protocol builders are responding—from neutral governance for agent sandboxes and empirical supply-chain security to inspectable agent protocols, independent code forges, and permissioned spaces on the AT Protocol.

Upcoming events

🗓️ December 2026

• Yocto Project Virtual Summit 2026.12 (December 1–3, 2026) – Virtual. Community summit for embedded Linux engineers and maintainers building custom, reproducible Linux distributions across edge and Internet of Things (IoT) hardware.
• Open Source Summit Japan 2026 (December 7–9, 2026) – Tokyo, Japan. The Linux Foundation's premier Asia-Pacific conference connecting open source developers, kernel maintainers, and enterprise leaders across cloud, embedded Linux, and open AI—featuring a keynote by Google's Kaz Sato on building agents on open standards alongside sessions from Googlers Tanya Sharma, Tarun Sahu, and Anurag Sinha.
• Open Compliance Summit 2026 (December 10–11, 2026) – Tokyo, Japan. Specialized gathering uniting legal, security, and Open Source Programs Office (OSPO) practitioners around OpenChain, Software Package Data Exchange (SPDX), software bills of materials (SBOMs), and global open source supply-chain compliance.

🗓️ January 2027

• Free and Open Source Software Developers' European Meeting (FOSDEM) 2027 (January 30–31, 2027) – Brussels, Belgium. Europe's largest free, volunteer-organized gathering for free and open source software developers at the Université libre de Bruxelles—with calls for participation now open across 77 community developer rooms and main-track proposals open through November 16.

Open calls for proposals (CFPs)

• Free and Open Source Software Developers' European Meeting (FOSDEM) 2027 (Event: January 30–31, 2027 – Brussels, Belgium) – Main-track CFP deadline: November 16, 2026 (individual community developer room CFPs run on rolling deadlines from November 20 through December 3, with full devroom schedules published by December 7, 2026).
• AtmosphereConf 2027 (Event: April 29 – May 2, 2027 – Amsterdam, The Netherlands) – Round 1 CFP deadline: November 30, 2026 (Round 2: January 11 – February 14, 2027). Community conference uniting developers, researchers, and creators building on the Authenticated Transfer Protocol (AT Protocol), open social web standards, and decentralized agent substrates across Build, Create, Inform, and Govern tracks.
• NeoCloudCon Europe 2027 (KubeCon + CloudNativeCon Europe Co-Located Event) (Event: March 15, 2027 – Barcelona, Spain) – CFP deadline: November 30, 2026 (23:59 CET). Co-located CNCF summit bringing cloud-native infrastructure builders together around emerging AI cloud platforms, GPU orchestration, and open distributed infrastructure.
• CNCF Maintainer Summit Europe 2027 (Event: March 14, 2027 – Barcelona, Spain) – CFP deadline: December 1, 2026 (23:59 CET). Exclusive co-located gathering for CNCF Technical Oversight Committee (TOC) representatives, Technical Advisory Group (TAG) leads, and Graduated or Incubating project maintainers to collaborate on governance, API design, and project health.

We've already submitted talks to FOSDEM and AtmosphereConf—consider submitting a proposal to one of these open calls too, as we'd love to see your work on the schedule!

Open source reads and links

• [Article] Are good intentions hurting open source? - Code generation is no longer the bottleneck when Ingress NGINX runs across half of Kubernetes clusters on two maintainers flooded with AI pull requests. In this summary and keynote, Akamai Cloud's Ruckus Voxi highlights documentation, triage, and stewardship as the real gaps—raising an honest question: how do we recruit contributors beyond code when open source still feels like a "coding club"?
• [Article] Kubernetes, mark II? Why Google's giving away gVisor, a code sandbox used by Anthropic and OpenAI - Anthropic and OpenAI already use gVisor to isolate untrusted code, yet upstream Linux kernel maintainers resisted performance patches while Google kept sole control. Paired with the Cloud Native Computing Foundation (CNCF) donation of Agent Substrate and OpenRL (Google Cloud blog), can neutral governance turn agent sandboxes into shared cloud infrastructure the way Kubernetes did for containers?
• [Recap] OpenSSF Community Day Europe 2026: Driving Systemic Security and Operational Resilience in Open Source - Drawing 200+ practitioners in Prague—with session recordings now online and a Google-sponsored academic security track—speakers unveiled Model Context Protocol (MCP) audit tools like SandScope, skill-registry attack detection, empirical Software Bill of Materials (SBOM) studies, and European Cyber Resilience Act due diligence. As "cheap trust signals" collapse under automated noise, what empirical verification belongs in release pipelines?
• [Article] GitHub is experiencing an open-source exodus. Here’s where the developers are going instead - "Exodus" might be too strong of a word, but continuous integration (CI) outages and opt-out AI training have pushed projects like Zig and Ghostty off GitHub toward Codeberg, self-hosted Forgejo, and SourceHut—though as an AT Protocol watcher, decentralized forge Tangled should likely have earned a mention too. When communities weigh contributor network effects against hosting independence, could protocol-level identity help smaller forges bridge that gap?
• [Report] Navigating Open Source Software Development in the Generative AI Era - Surveying 234 contributors and maintainers (companion blog post), Linux Foundation Research finds generative AI cuts task time by up to 52%, yet maintainers estimate 25% of incoming pull requests are low-quality "AI slop"—with 64% reporting slower reviews, 63% citing burnout, and only 35% of projects holding a formal AI policy. Rather than blanket bans or unchecked noise, what lightweight verification norms actually scale across smaller maintainer teams?
• [Article] Munich dumps proprietary for open source (again) - As Munich renews its open-source push beneath the desktop layer, Matrix.org co-founder Amandine Le Pape highlights the other half of European public-sector sustainability: while civil servants across Europe now rely on Matrix, only one government agency funds the underlying specification. Can new bodies like the Digital Commons European Digital Infrastructure Consortium (EDIC) align government procurement with upstream maintenance?
• [Article] Why science keeps choosing open source - Enterprise IT expects software upgrades every few years, but research labs often pair modern Graphics Processing Unit (GPU) clusters with 15-year-old instruments and validated scripts that cannot change without breaking reproducible results. Highlighting how Linux, containers, and open source outlive commercial vendor roadmaps, how else does source access protect long-term knowledge from planned obsolescence?
• [Blog] Fast, reliable A2UI, with swappable inference formats - Pairing Google’s open Agent-to-User Interface (A2UI) protocol with Genkit for Go, Daniela Petruzalek demonstrates how agents can stream rich generative user interfaces over compact, swappable wire formats without locking frontend layouts to a single model provider. As agent workflows move beyond plain-text chat boxes, how can open UI protocols keep human interfaces fast and inspectable across runtimes?
• [Blog] Testing and Serving A2A Agents from the Terminal with A2A CLI - In a hands-on terminal walkthrough, Mete Atamel shows how the open source Agent2Agent (A2A) command-line interface (CLI) lets developers inspect agent cards, stream multi-turn tasks, and serve local A2A endpoints directly from the command line without spinning up a full web UI. Just as curl made HTTP debugging universal, what terminal primitives do builders need to make multi-agent interoperability easy to test locally?
• [Blog] Behind the scenes, two months later: How we ship Google Agent Skills like products - Treating natural-language SKILL.md packages on GitHub as living software releases rather than static docs, maintainers on Google’s open-source skills repository enforce strict semantic versioning, pre-review CI schema linters, and continuous evaluation suites against a no-skill baseline. When open-source repositories distribute natural-language instructions instead of deterministic code, how must release engineering evolve to prevent silent behavioral regressions?

Spotlight: ATProto Spaces and permissioned data

With a release specification and beta for permissioned spaces on the Authenticated Transfer Protocol (AT Protocol) targeted for late November, what should we be building with shared spaces in mind:

• [Video] FediForum Talk: Introduction to Atproto Spaces & Reintroducing Spaces - Bluesky’s Daniel Holmgren introduces ATProto Spaces as lightweight "mini AT proto networks" built around locality rather than per-record Google+-style Circles (it still lives in our hearts)—proving via "Daniel’s Circles Postulate" why binding each space to one owner and one modality keeps OAuth consent screens legible in two sentences while preserving cross-app remixability for private groups, newsletters, and 100,000-member forums.
• [Blog] Modeling communities on permissioned data & Permissioned Data Diary 5: What’s in a Name? - Rather than cramming forums, chat, and events into one "universal space" that over-grants OAuth read permissions, Holmgren models a community as a single transferable Decentralized Identifier (DID) owning separate modality-specific spaces (at://<space_owner_did>/space/<space_type>/<space_key>/<author_did>/<collection>/<rkey>) so community ownership can change hands without breaking URI backlinks.
• [Blog] Permissioned Data Diary 6: Boring Auth & Permissioned Data Diary 7: Off the Record - Explaining why Spaces passed on User Controlled Authorization Networks (UCAN) capability chains in favor of a "narrow waist" OAuth Space Credential with reader-enforced writes, Holmgren details how space repositories replace Merkle Search Trees (MSTs), asymmetric signatures, and global Relays with LtHash (an ~80-line quantum-resistant lattice multiset hash), deniable Hash-based Message Authentication Code (HMAC) signatures, and direct HTTP/2 pull sync.
• [Forum] STAR format stabilization (space repo archives!) & STAR: settling the details - Because space repositories use order-independent LtHash sets rather than Merkle trees, ATProto Spaces is adopting STreaming ARchives (STAR on Tangled) instead of Content Addressable aRchives (CARs) for repository exports—sparking an active community design discussion around canonical varint strictness, $type Namespace Identifier (NSID) collisions, and truncation checks.
• [Blog] Building on ATProto - Offering a local-first developer counterpoint, Puppet founder Luke Kanies examines the friction of promoting records between private spaces and public broadcast repositories and explains why offline-capable applications still need local working copies alongside remote Personal Data Servers (PDSes). Once open protocols support private and group spaces natively, what kinds of community tools would you want to build first?

Which of these stories will you be chatting about at your next meetup or conference? Let us know! Share with us on our @GoogleOSS X account or our @opensource.google Bluesky account.

Kubernetes Python client gets a modern overhaul for the AI/ML era

by Yu Liao, Haowei Cai, and Federico Bongiovanni, Google Cloud Kubernetes Engineering & SIG API Machinery

When you train a large language model with Kubeflow, orchestrate distributed compute with Ray on Google Kubernetes Engine (GKE), serve inference traffic with KServe, or schedule thousands of ML pipeline pods with Apache Airflow, two technologies almost always meet under the hood: Python and Kubernetes.

Python is the undisputed lingua franca of artificial intelligence and machine learning. Kubernetes is the de facto operating system for AI infrastructure—scheduling GPUs and TPUs, orchestrating distributed training jobs, and scaling model serving endpoints. Connecting these two worlds is the official Kubernetes Python client (kubernetes-client/python).

Second only to Kubernetes's in-tree Go client (client-go) in popularity, the Kubernetes Python client is downloaded more than 73 million times per month on PyPI (~1.7 million times a day) and has earned over 7,500 GitHub stars.

Yet for the past several years, this critical bridge between Python and Kubernetes has operated in low-maintenance mode. As AI/ML workloads have exploded in scale and complexity, the gap between what modern AI infrastructure demands and what the legacy Python client was built to deliver has become impossible to ignore.

Today, we're sharing how Google Cloud engineers are partnering with open source contributors in Kubernetes SIG API Machinery to modernize the official Kubernetes Python client for the AI/ML era.

The historical problem: Legacy machinery meets hyperscale AI

As AI/ML clusters grew from dozens of nodes to 50,000-node hyperscale environments, the limitations of the Python client's aging architecture began surfacing as real-world production bottlenecks:

1. Frozen on a decommissioned code generator: Up through Kubernetes 1.35, the Python client generated its ~400,000 lines of API and model code using OpenAPI Generator v4.3.0 (python-legacy)—a generator version that was deprecated in 2020 and completely removed from the upstream OpenAPI Generator project in May 2022. Staying pinned to v4.3.0 meant the client accumulated DeprecationWarning debt across newer Python releases, struggled with modern dependency resolution alongside PyTorch and TensorFlow, and couldn't easily receive upstream generator bug fixes.
2. Synchronous-only execution in an asyncio world: Modern Python web frameworks, inference servers, and orchestrators have overwhelmingly shifted to asyncio to handle high-concurrency I/O without being bottlenecked by Python's Global Interpreter Lock (GIL). Because the official client lacked native asyncio support from the start, users were forced to turn to community clients like kubernetes-asyncio or third-party clients (kr8s, lightkube).
3. Missing controller primitives (SharedInformer): In Go, controllers use SharedInformer to maintain a local, event-driven cache of cluster resources without repeatedly polling kube-apiserver. Without an equivalent primitive in Python, applications watching thousands of training pods or custom resources often hammered the API server or ran into watch disconnects.
4. Slow model deserialization and HTTP/1.1 transport limits: In large clusters, listing pods or nodes in Python could take 30+ seconds due to excessive model reconfiguration during JSON deserialization (issue #1921). Combined with an underlying urllib3 transport layer restricted to HTTP/1.1, Python workloads missed out on the HTTP/2 multiplexing, flow control, and binary framing that make client-go fast at scale.

A principled approach: Built for AI/ML, not 1:1 parity

When we set out to modernize the Kubernetes Python client, we established two guiding principles to ensure our engineering investments deliver the highest possible return for the community:

1. Target high-impact gaps, not 1:1 client-go parity: client-go is the in-tree Kubernetes client used by the control plane itself (kube-controller-manager, kube-scheduler, and in-tree controllers). Attempting to replicate every long-tail client-go feature in Python would yield diminishing returns. Instead, we focus strictly on the primitives Python developers and operators actually need in production.
2. Prioritize AI/ML workload requirements: Because AI/ML training, inference, and batch frameworks are the primary drivers of Python on Kubernetes today, every architectural improvement—from async concurrency and CRD ergonomics to large-cluster list performance—is prioritized through the lens of AI/ML scale.

How we're modernizing the Kubernetes Python client

Our roadmap focuses on three technical pillars: Machinery, Features, and Performance.

1. Machinery: Upgrading to OpenAPI Generator v7.20+

Every improvement to the Python client starts with its code generation pipeline (kubernetes-client/gen). Over the past few years, multiple community attempts to migrate off the decommissioned v4.3.0 python-legacy generator stalled due to the sheer scale of template and schema changes across hundreds of Kubernetes API models.

We are actively driving the migration to OpenAPI Generator v7.20.0+ and establishing continuous tracking with upstream generator releases. Completing this foundational upgrade:

• Replaces dead python-legacy templates with actively maintained v7+ Python code generation.
• Modernizes type annotations and packaging metadata, easing pip dependency resolution alongside heavy ML frameworks.
• Unlocks the ability to contribute performance and serialization fixes directly to upstream OpenAPI Generator templates.

2. Features: Native asyncio, Shared Informers, and WebSocket v5

To prevent ecosystem fragmentation and give Python developers first-class Kubernetes primitives out of the box, we are bringing three major capabilities to the official client:

• Official asyncio support: Rather than forcing developers to choose between the official synchronous client and third-party async libraries, we are introducing official asyncio support directly into kubernetes-client/python. Async-first ML orchestrators, FastAPI-based model control planes, and notebooks will be able to issue concurrent, non-blocking Kubernetes API calls natively.
• Shared Informers (kubernetes-client/python#2515): We are bringing the SharedInformer pattern to the Python client. With built-in list-watch caching, automatic reconnection, and resource event handlers (on_add, on_update, on_delete), Python controllers and AI job managers can monitor cluster state and Custom Resources (TrainJob, RayCluster, InferenceService) with a fraction of the memory footprint and API server load.
• WebSocket v5 streaming (KEP-4006, kubernetes-client/python#2486): As upstream Kubernetes transitions remote command streaming (exec, attach, port-forward) away from legacy SPDY to standard WebSockets via the v5.channel.k8s.io subprotocol, we are adding native WebSocket v5 channel support so interactive debugging and remote job execution work seamlessly against modern control planes.

3. Performance: Slashing deserialization overhead

For AI/ML platforms operating on multi-thousand-node clusters, client performance is an availability requirement. Our performance track targets the largest bottlenecks in Python client execution:

• Eliminating model reconfiguration overhead: When deserializing large JSON responses (such as listing tens of thousands of Pods across a training cluster), the legacy generated model layer repeatedly instantiates and reconfigures schema validation objects (issue #1921). With the move to OpenAPI Generator v7+, we are revamping model initialization so large cluster queries deserialize in a fraction of the time.

What's next and how to get involved

The intersection of Python and Kubernetes is where modern AI infrastructure is built. By modernizing the code generation machinery, adding native asyncio and SharedInformer primitives, and closing the deserialization performance gap, we aim to give every ML engineer and platform builder a fast, reliable, and Pythonic official client—whether they are running a single notebook experiment or orchestrating a 50,000-node GKE training fleet.

This effort is happening in the open under Kubernetes SIG API Machinery, and we welcome feedback, use cases, and contributions from the community:

• Explore the repository and roadmap: Check out kubernetes-client/python and kubernetes-client/gen on GitHub.
• Join the conversation: Connect with us in the #sig-api-machinery channel on Kubernetes Slack or at the bi-weekly Kubernetes Python client triage meetings.

Scaling AI agents with open standards: Kurtis Van Gent on MCP and Agent Skills joining the AAIF

by Kurtis Van Gent, Google Cloud, and Daryl Ducharme, Google Open Source Programs Office

Building production AI agents requires more than a capable reasoning model. Agents need a reliable way to connect to external systems and data, and they need procedural domain knowledge so they know how to use those tools safely without exhausting their context window.

Over the past year, open source communities have rallied around two complementary open standards to solve these challenges: the Model Context Protocol (MCP) for connecting agents to live tools, and Agent Skills for loading procedural instructions and scripts on demand. Following Anthropic's donation of the Agent Skills specification to the Linux Foundation's Agentic AI Foundation (AAIF) alongside MCP, engineers from Google, Anthropic, OpenAI, and the wider ecosystem are now co-maintaining the standard under vendor-neutral governance.

To explore how open standards prevent ecosystem fragmentation, and why the best solutions don't always have to be homegrown, we sat down with Kurtis Van Gent, co-creator of the open source MCP Toolbox for Databases and a core maintainer on both MCP and Agent Skills.

From the N-by-M database problem to open source collaboration

Daryl Ducharme: How did your work on AI ecosystems for Google Cloud Databases and co-creating the open source MCP Toolbox for Databases lead to your role as a core maintainer on both the Model Context Protocol (MCP) and Agent Skills?

Kurtis Van Gent: When I started my current role around three years ago, it was early in the generative AI cycle. My mission was to make it easy for developers to use cloud databases for their AI applications. As a strong proponent of developer experience, I loved that charter. As model reasoning improved, context and data were clearly the keys to making effective use of it, and there's no better place to store data than a database.

At the time, most database conversations focused on retrieval-augmented generation (RAG) using vector search. However, our team believed that agents and tools held the most interesting potential for large language models (LLMs) going forward. We immediately hit two scaling challenges: Google Cloud supports more than 15 different databases across its portfolio, and new open source agent frameworks (starting with LangChain and LlamaIndex) were emerging every week.

That created a classic N-by-M integration problem between many clients and many data hosts. To solve it, we started GenAI Toolbox for Databases (now MCP Toolbox for Databases) as an open source framework for building and serving tools. We built our own server, clients, and protocol to standardize how agents look up and invoke database tools. Back then, agent terminology wasn't common vernacular yet, so every talk I gave had to start with three to five slides explaining what agents and tools actually were.

When Anthropic announced MCP, it was exciting validation that the broader ecosystem was arriving at the same architectural conclusions we were seeing across our database integrations. Rather than insisting on a homegrown protocol or spinning off a competing specification, we reached out to the MCP co-creators, Justin Spahr-Summers and David Soria Parra, and began meeting regularly. Because I believe strongly in open source communities and shared standards, I advocated for adopting MCP directly. We evolved our project into MCP Toolbox for Databases so it worked out of the box with any MCP client, and I focused on contributing capabilities from our original protocol back into the upstream MCP specification.

Leading the transition to a stateless MCP specification

Kurtis Van Gent: One of my primary upstream focuses was transport scalability. I began leading the MCP Transports Working Group with the goal of evolving the specification toward a stateless, horizontally scalable architecture. At first, it wasn't a crowded room. Our early working group meetings had around five participants, three of whom were from Google.

As MCP adoption accelerated across the industry, however, it became clear that early stateful assumptions around persistent sessions and initialization were holding MCP back at production scale. That effort culminated in a two-day Transports Summit where Google and fellow working group members hosted the MCP core maintainers at our San Francisco offices to work through the scaling bottlenecks and align on a path forward. Shortly afterward, I was invited to become an MCP core maintainer, both in recognition of our work identifying those transport challenges and to keep the Transports Working Group closely aligned with the core specification. The result of that collaboration was the July 28, 2026 MCP specification, which transitioned MCP to a stateless model.

That experience as an MCP core maintainer naturally positioned me to help co-maintain Agent Skills. Having already built working relationships with contributors across Google, Anthropic, and OpenAI, stepping in to help steward Agent Skills inside the AAIF felt like a natural continuation of the same collaborative model.

Why vendor-neutral governance in the AAIF matters for developers

Daryl Ducharme: From your perspective as a core maintainer representing Google, why does bringing Agent Skills into the Linux Foundation's Agentic AI Foundation (AAIF) alongside MCP matter for developers and open source communities?

Kurtis Van Gent: We've seen open source technologies like Kubernetes achieve widespread adoption and sustained cross-company contributions, but organizations are understandably hesitant to build critical workflows on a specification controlled by a single vendor. Just as the Cloud Native Computing Foundation (CNCF) provided a vendor-neutral home for container orchestration, the AAIF provides a neutral forum where organizations and independent maintainers can collaborate on shared agent standards.

Bringing Agent Skills into the AAIF signals how foundational this format has become across the AI ecosystem. Following in the footsteps of MCP, the organizations and open source communities adopting Agent Skills now have a shared seat at the table to shape how the specification evolves. For developers, this means you can author a skill once and trust that it will remain portable across different agents, IDEs, and harnesses without vendor lock-in.

Solving tool bloat with progressive disclosure: how MCP and Agent Skills fit together

Daryl Ducharme: You have spoken about the tension between "tool bloat" and context saturation when building production agents. How should developers think about the division of labor between MCP (connecting agents to live tools and data) and Agent Skills (loading procedural domain knowledge on demand)?

Kurtis Van Gent: One of the most impactful things MCP accomplished was commoditizing tools: it became straightforward for anyone to wrap a set of actions in an MCP server and share them. The unintended consequence was tool and context bloat. As agents grew more capable and connected to dozens of MCP servers, deciding which tool schemas and operational instructions to load into the context window became a major bottleneck.

Agent Skills introduced a remarkably simple, effective pattern for solving that problem through progressive disclosure. By loading only a lightweight YAML frontmatter name and description at startup, and pulling the full SKILL.md instructions, reference files, or scripts into context only when a task requires them, Agent Skills commoditized context the same way MCP commoditized tools.

While some observers initially viewed MCP and Agent Skills as competing approaches, they have always been complementary: Agent Skills package domain expertise into modular chunks that teach an agent how to approach a problem, while MCP provides the live execution interface to carry it out. Today, the broader ecosystem has converged on combining them, including efforts around Agent Plugins and proposals for serving Agent Skills over MCP so platform maintainers can distribute domain instructions and live tools together.

Putting MCP and Agent Skills to work in database and developer workflows

Daryl Ducharme: What is a concrete example of how developers are using Agent Skills and MCP together today—whether in Antigravity, database workflows, or across the broader ecosystem?

Kurtis Van Gent: Both MCP and Agent Skills have become ubiquitous across everyday developer workflows. In my own daily work, I write custom skills whenever I notice an agent struggling to get a repeatable workflow right on the first try. For example, I write skills for how I like to structure GitHub repositories or format commit messages so I never have to re-explain those conventions in a prompt.

At the platform level, our Google Cloud Databases team pairs MCP and Agent Skills together inside our Agent Plugins. When a developer using Antigravity connects to a PostgreSQL database on Cloud SQL or AlloyDB, they can install the corresponding Cloud SQL or AlloyDB plugin. From MCP, the agent gets a list of safe actions it can take against the database. From the bundled Agent Skills, it gets step-by-step instructions on how to use those tools for specific tasks, like provisioning an instance or configuring Identity and Access Management (IAM) database authentication securely—and because both specifications are open standards, the same SKILL.md and MCP pattern works across any open source database or agent harness.

That combination is both faster and safer than pointing an agent at raw documentation written for human readers. In our agent workflow benchmarks, we see developers complete complex database tasks much more quickly and reliably when MCP tools are paired with targeted Agent Skills.

What comes next for the Agent Skills specification

Daryl Ducharme: Working alongside maintainers from Anthropic, OpenAI, and the wider community inside the AAIF, what technical or governance areas are you most focused on next?

Kurtis Van Gent: Two major areas I'm focused on evolving next are packaging and discovery. Today, the Agent Skills specification defines how an individual skill is structured, but it doesn't yet standardize how collections of skills are bundled, how harnesses discover them, or how to resolve naming conflicts across skill sets. Closing those gaps will help address conformance differences across harnesses.

Versioning is another priority. As the Agent Skills specification matures under the AAIF, we need a clear, portable way for skill authors and agent harnesses to declare which version of the specification they support. I'm looking forward to working with the other maintainers and open source communities to standardize packaging, discovery, and versioning in upcoming releases.

How to get involved

Daryl Ducharme: For open source developers and maintainers who want to author portable skills or contribute to the specification and tooling at github.com/agentskills, where should they start?

Kurtis Van Gent: If you want to start authoring portable skills today, the documentation at agentskills.io walks through creating your first SKILL.md package in just a few minutes, and you can explore Google's open source catalog of developer skills at github.com/google/skills (along with our engineering retrospective on how we ship Google Agent Skills like products).

If you want to help shape the specification itself, visit the GitHub organization at github.com/agentskills to review open pull requests, file issues, and join the community Discord server where maintainers and contributors discuss upcoming specification proposals.

GSoC 2026 Mentor Summit: Resilient OSS Communities

by Stephanie Taylor, Google Summer of Code Program Lead

Last weekend, we hosted our annual Google Summer of Code Mentor Summit in Munich, Germany, welcoming 185 attendees representing 133 open source projects across 36 countries. The past year has presented unique challenges for open source communities, particularly with the surge of AI-generated pull requests placing additional strain on maintainers.

Attendees at the GSoC 2026 Mentor Summit in Munich, Germany gathering for the annual group photo.

The 183 open source organizations participating in GSoC 2026 were at the forefront of these shifts. Each organization establishes its own AI guidelines and governance, and many continue to refine their policies as the technology evolves. Throughout the year, we have actively engaged with our communities to better understand these challenges and support them in identifying effective solutions.

Unsurprisingly, the Mentor Summit’s unconference format (where attendees create the schedule) featured numerous sessions on managing AI within both GSoC and the broader open source ecosystem. While many mentors arrived weary after a demanding season, the event fostered a strong sense of shared purpose. Discussions moved beyond common obstacles to highlight notable successes, with several organizations reporting their most impactful GSoC season yet, driven by dedicated contributors who are now transitioning into active maintainer roles.

Organizations shared a variety of strategies to address AI-assisted contributions, specifically targeting automated pull requests and supporting contributors in understanding underlying system architectures alongside AI-generated code.

Resilience emerged as a central theme of this year's summit. Open source communities have navigated dynamic shifts over the past two decades. The continued vitality and importance of open source in 2026 reflects a forward-looking mindset: one grounded in experimentation, adaptation, and continuous improvement.

For our GSoC team, the Mentor Summit underscored the remarkable collaboration across open source. Observing mentors from diverse projects exchange practical tools, workflows, and insights highlights the value of gathering community leaders to strengthen the broader ecosystem.

A huge thanks to all of the GSoC Mentors and Organization Administrators who joined us in Munich, as well as the more than 1,800 mentors worldwide who guided our 2026 contributors. Google Summer of Code wrapped up its 22nd year this week thanks to the dedication and leadership of this global community.

Sandboxing Untrusted AI Agents at Scale: Google Donates Agent Substrate and gVisor to the CNCF

by Mofi Rahman, Developer Relations Engineer, and Brandon Royal, Product Manager, Google Cloud

When Google introduced Kubernetes twelve years ago, the Pod became the default unit of compute for the cloud. The design assumed a straightforward lifecycle: a program boots, binds to a port, serves traffic, and runs until you stop it.

AI agents work fundamentally differently.

An AI agent that’s running on a machine executes untrusted code, commands, and tool calls, and must be isolated from its host and its network resources. At the same time, these agents, whether they’re an interactive coding assistant, an SRE troubleshooter, or a multi-turn evaluation loop, do not run continuously. They execute a step, call a language model, and wait. Most of the time, the agent does nothing at all while it waits for a model to stream tokens or a human to review a pull request. In the same way that Kubernetes was created to address the needs of containerized applications, we introduced Agent Substrate as a new orchestrator for the emerging agentic applications. Secure by default, highly efficient and built for multi-million agent scale.

Agent Substrate was designed from the ground up for AI agent security and density and brings the best parts of Kubernetes together with a new control and data plane for fully-isolated, ultra-low-latency sandboxed compute and storage. The growing Agent Substrate community has been rapidly building core capabilities and stabilizing APIs, culminating in the latest 1.0 release.

This week at KubeCon North America in Salt Lake City, Google Cloud is donating Agent Substrate and gVisor to the Cloud Native Computing Foundation (CNCF) in Sandbox status, alongside OpenRL.

This post explains why traditional approaches struggle with stateful agents, how Agent Substrate solves the problem, how it connects to enterprise governance on Google Kubernetes Engine (GKE), and where to see it in action at KubeCon NA 2026.

Challenges of running AI agents at scale

AI agents introduce two infrastructure bottlenecks that standard Kubernetes was never built to handle: idle resource waste and control plane overload.

1. The idle resource problem

During a typical interactive session, an agent can spend 90% to 95% of its time waiting for model inference, external APIs, or human reviews.

During that wait, the agent consumes zero CPU. However, you cannot simply kill the container. The agent holds critical state in memory and on disk: active language runtimes, local Git repositories, uncommitted file edits, and tool sessions.

With standard Kubernetes, platform engineers face two poor options:

1. Keep a dedicated Pod running all day: The agent responds quickly because it is already warm, but you pay for idle compute around the clock. At ten thousand active users, cluster costs become unsustainable.
2. Scale to zero with serverless containers: You save compute costs while the agent sits idle, but resuming from cold storage forces the container to clone repositories, reinstall packages, and rebuild memory. Wakeup latency climbs past 20 seconds, breaking the interactive experience.

Platform teams need agents that wake up in under 500 milliseconds with full memory and disk state intact—without paying for running Pods while the agent sits idle.

2. Control plane overload

The opposite issue occurs when training or evaluating agents. Reinforcement learning loops and benchmark suites need to run untrusted agent code across thousands of tasks at the exact same time.

If every sandbox requires a full Kubernetes Pod, the control plane quickly grinds to a halt. Scheduling, creating, and destroying thousands of short-lived Pods every minute overwhelms etcd, saturates kube-apiserver, and exhausts subnet IP addresses. Kubernetes was built to manage stable application topologies, not to act as a microsecond sandbox allocator.

How Agent Substrate solves the problem

Agent Substrate adds an actor-based control and data plane built on top of Kubernetes. It solves the idle resource problem by decoupling Actors from Workers:

• Actors hold the state: An Actor represents an individual agent session, complete with its own filesystem, environment variables, memory state, and network rules.
• Workers provide the compute: A Worker is a pre-warmed Kubernetes Pod running in a shared pool (WorkerPool), equipped with container runtimes and sandbox boundaries.

The lifecycle of an agent turn

1. Request parking: An incoming call hits the atenet-router L7 proxy. If the target Actor is suspended, the proxy holds the request in memory and alerts the Substrate controller.
2. Fast placement: The controller assigns the Actor to an available slot in the warm Worker pool.
3. Sub-second restore: The Actor’s memory and disk state restore from tiered storage, the process wakes up, and the proxy delivers the request. The agent resumes in under 500 milliseconds right where it paused.
4. Suspension on idle: When the turn finishes, Substrate snapshots the Actor’s state to tiered storage and frees the Worker slot for other workloads.

Because Substrate manages Actor state directly, thousands of agents can activate, suspend, and resume every second without creating new Pod objects or stressing etcd.

Safe execution with gVisor and microVMs

Agents frequently execute model-generated, untrusted code. Standard Linux containers share the host kernel, which presents an unacceptable security risk on multi-tenant nodes.

Agent Substrate pairs with gVisor (runsc), Google's open source application kernel written in Go. gVisor intercepts system calls in user space, isolating untrusted code from the host kernel. Because gVisor virtualizes its own memory and process tables, Substrate can freeze a running environment, write memory pages to storage, and restore them on another node in under 500 milliseconds.

For workloads requiring hardware virtualization or custom kernel modules, Substrate also supports Cloud Hypervisor microVMs under the same unified API.

Why Google donated Agent Substrate to the CNCF

Over the past two years, engineering teams across the industry have run into the same agent scaling boundaries. Without a shared open standard, every organization ends up building custom schedulers on top of VMs or working around Kubernetes.

Donating Agent Substrate and gVisor to the CNCF gives the cloud-native community a neutral, vendor-independent foundation that works across any conformant Kubernetes cluster.

Together with community projects, they form an open stack for agentic infrastructure:

• Layer 1: Secure Isolation (gVisor): Sandboxes untrusted code execution with user-space kernel isolation and fast memory checkpointing.
• Layer 2: Agent Runtime (Agent Substrate): Multiplexes stateful actors onto warm worker pools with sub-second wakeups.
• Layer 3: Training Orchestration (OpenRL): Coordinates Kubernetes-native reinforcement learning loops and evaluation sandboxes.

Where to find us at KubeCon NA 2026

If you are heading to Salt Lake City for KubeCon + CloudNativeCon North America from November 9 to 12, visit our sessions, workshops, and booth demos:

When	Session or Event	Speakers & Location
Monday, Nov 9	Agent Substrate Day (ATEcon)	Welcome to ATECon, Tim Hockin, Eitan Yarmush, Ron Lev Pleading the Agent: Proof of Agent identity, Greg Castle, Taahir Ahmed Evolving The Substrate Dataplane, Benjamin Elder Truly Sandboxed Networking: Moving beyond MVP, Bowei Du, Lior Lieberman Using Substrate for anything but Agents, Mofi Rahman Agent Substrate Environment, Jaana Dogan, Lior Lieberman Closing Remarks, Tim Hockin, Eitan Yarmush, Ron Lev Salt Palace
Monday, Nov 9	Detonation and Isolation: Hardening Kubernetes Runtimes for Agents Multi-agent orchestration and runtime governance	Syeda Anjum, Kaslin Fields, and Kanchana Rajendran Agentics Day
Monday, Nov 9	GKE Day Announcements and hands-on agent infrastructure labs	Google Cloud GKE Team
Tuesday, Nov 10	Flagship Fireside Chat: Kubernetes Act II Why AI Agents Change Everything Under the Hood	Tim Hockin and Kelsey Hightower Moderated by Savannah Peterson
Wednesday, Nov 11	Hands-on Workshop: Building and Governing Agent Substrate on GKE Hands-on lab deploying warm worker pools, testing snapshot restores, and configuring egress secrets	Mofi Rahman, Drew Brown, Casey West, Kaslin Fields, and Olivier Bourgeois Schedule ID: 1247804
Wednesday, Nov 11	Expo Hall Demo Theater: Inside the Show-Floor Agent Swarm Live fleet multiplexing on GKE	Brandon Royal and Mofi Rahman
Nov 10 to 12	Google Cloud Booth #122 • Agent Swarm demo: See agent substrate in action. • Partner demos with NVIDIA on OpenShell and GPU Actor infrastructure • Filestore Agent Volumes in action	Booth #122 Expo Hall

Get started

Agent Substrate is open source and ready for testing today:

• Documentation: Read the guides and architecture specs at ate.dev.
• Code: Explore the runtime on GitHub at github.com/agent-substrate/substrate.
• Community: Join #substrate-dev #substrate-user on the CNCF Slack.

See you in Salt Lake City!