Agent Substrate, gVisor and OpenRL at CNCF: governance and agent platform adoption

An enterprise agent platform must answer questions beyond whether it can execute code: who maintains the runtime, how a session is recovered, who authorizes external actions, and what it would cost to replace the implementation.

On November 5, 2026, Google announced the donation of Agent Substrate, gVisor and OpenRL to the Cloud Native Computing Foundation (CNCF). The announcement describes the projects as working through Sandbox onboarding and also introduces Agent Substrate 1.0 and general availability on Google Kubernetes Engine (GKE). These are related but separate milestones: community governance and the availability of a managed product require different assessments. (cloud.google.com)

This article complements the Agent Substrate, gVisor and OpenRL architecture article. Its focus is turning a governance change into adoption criteria, operational contracts and a testable exit strategy, rather than providing another installation walkthrough.

1. What is confirmed—and what should not be assumed

This analysis uses November 6, 2026 as its reference date. The individual milestones matter:

• gVisor records its application approval on September 28, 2026, followed by its donation announcement on October 2, 2026. Incubation is described as a subsequent objective, not an already completed transition. (gvisor.dev)
• Agent Substrate's application records the signed contribution agreement and creation of its onboarding issue on October 20, 2026. Approval, signing and completion of onboarding are distinct events. (github.com)
• The November 5, 2026 announcement brings the three projects together under the open infrastructure initiative for agents. (cloud.google.com)

CNCF Sandbox is a project-hosting category, not certification that a particular deployment meets your production requirements. My recommendation is therefore to treat foundation participation as one input to due diligence, not as a replacement for technical validation, compliance review or a support agreement. (cncf.io)

2. Three components, three adoption decisions

The projects should not automatically be treated as an indivisible stack.

These responsibilities are described in the projects' applications and documentation. Here, OpenRL specifically means the post-training project associated with CNCF application #518—not an arbitrary reinforcement learning library with a similar name. (github.com)

My recommendation: assess each layer independently. A business may need isolated code execution without operating its own training infrastructure. Another may need post-training without providing persistent interactive sessions to end users.

3. What neutral governance could change

The gVisor donation announcement outlines a transition toward maintainer-based governance, maintainers from outside Google, and changes to build and test infrastructure. These are more useful dependency-assessment signals than a repository simply moving between organizations. (gvisor.dev)

The architectural inference is that public processes and participation from multiple organizations could reduce dependence on one vendor's decisions. They do not automatically establish distributed maintenance, commercial support or identical integration across clouds. Those benefits should be evaluated over time rather than assumed on announcement day. (gvisor.dev)

For an internal review, I would examine five areas:

1. Authority: who approves breaking changes and releases?
2. Continuity: how many organizations can fix, build and publish the project?
3. Security: are coordinated disclosure and supported-version policies documented?
4. Reproducibility: can your organization build and test the artifacts it depends on?
5. Exit: can you migrate your data and operating procedures without relying exclusively on the original supplier?

Capture the answers in an Architecture Decision Record (ADR), preserving the context, alternatives and rationale. The donation is a reason to investigate; operational evidence should determine approval.

4. An adoption architecture: separate product, execution and learning

Rather than repeating the projects' internal architecture, I propose this responsibility flow for an enterprise platform:

Product → authorization and budget → task admission → isolated execution → durable evidence → evaluation

In this proposed design:

• Product defines the requested outcome.
• Authorization and budget determine which tools, data and resources may be used.
• Admission enforces concurrency limits and rejects work the platform cannot safely sustain.
• Execution runs the task within the chosen isolation boundary.
• Durable evidence records results, operation identifiers and external effects.
• Evaluation checks quality and, where an authorized training program exists, provides approved data for that process.

These are recommended platform responsibilities, not invented native APIs for the three projects.

The contract exposed to application teams should describe timeouts, cancellation, retention, identity, resource limits and failure behavior. Avoid turning implementation details of one runtime into permanent requirements of the product interface.

Portability needs an exit test

I recommend three separate demonstrations:

• Deployment: install the pinned release in another compatible environment.
• State: export artifacts and reconstruct a session from application-controlled data.
• Operations: reproduce policy enforcement, auditing and diagnosis without depending on a supplier-exclusive interface.

Checkpoint/restore is a real gVisor capability with its own requirements and limitations. Its existence does not demonstrate that an arbitrary snapshot can be restored across unrelated versions, configurations and platforms. (gvisor.dev)

Maintain a recovery path based on logical application state: persisted files, authorized history, results and idempotent operations. Treat memory snapshots as an optimization governed by a compatibility matrix, not as the only format in which the business can survive a failure.

5. Enterprise example: agents that prepare fixes

Hypothetical scenario: an organization wants agents to investigate incidents and prepare pull requests. Production changes still require human approval.

Problem: the team must choose an execution foundation without granting sessions administrative cluster access or creating a dependency that cannot realistically be replaced.

Proposed solution: separate task coordination, execution environments and the durable operation ledger. PostgreSQL could hold transactional task state, while object storage could retain artifacts and evidence, subject to organizational requirements.

Suggested implementation:

1. Start with test repositories and synthetic data.
2. Assign a stable identifier to every task and external action.
3. Limit concurrency per team and require approval for destructive operations.
4. Test worker loss, storage unavailability and credential expiration.
5. Retry interrupted tasks and verify that external actions are not duplicated.
6. Export the resulting artifacts to the chosen alternative implementation.

Expected—not measured—outcome: an adoption decision supported by evidence about recovery, isolation and cost. No latency improvement or financial saving should be assumed before the pilot.

6. YAML: an admission budget for the pilot

The following example uses native Kubernetes resources only. It creates an evaluation namespace with an upper bound on declared resources. It does not install Agent Substrate, gVisor or OpenRL, and it does not establish per-Actor quotas. ResourceQuota applies to Kubernetes namespace resources. (kubernetes.io)

apiVersion: v1
kind: Namespace
metadata:
  name: agent-platform-evaluation
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: evaluation-budget
  namespace: agent-platform-evaluation
spec:
  hard:
    requests.cpu: "8"
    requests.memory: 16Gi
    limits.cpu: "16"
    limits.memory: 32Gi
    pods: "30"

requests.* and limits.* constrain declared totals; pods caps non-terminal Pods. The quota can block new admissions, but it neither reserves nodes nor imposes a monetary cloud spending limit. These educational values must be recalculated for the pilot. (kubernetes.io)

As an operational choice, reserve headroom for upgrades and recovery before onboarding additional teams. Do not apply this example indiscriminately to core platform namespaces. Require explicit requests and limits in pilot manifests; if you introduce defaults through a LimitRange, document them rather than leaving sizing implicit. (kubernetes.io)

For multiplexed platforms, the important design rule is: do not use Pod count as a substitute for a session budget. I recommend separate admission controls for active sessions, queue depth, storage and model consumption.

Save the manifest as evaluation-budget.yaml and run:

kubectl apply -f evaluation-budget.yaml
kubectl get resourcequota -n agent-platform-evaluation
kubectl describe resourcequota evaluation-budget -n agent-platform-evaluation

Inspecting quotas and their recorded usage is part of the documented administration workflow for this resource. (kubernetes.io)

7. Production criteria before expansion

The following is a proposed acceptance checklist, not a list of capabilities automatically delivered by the donation.

Availability and recovery

• Require multiple replicas for services that support replication, with capacity distributed across zones.
• Validate readiness, liveness and startup probes for persistent services; avoid restart behavior driven solely by temporarily slow dependencies.
• Test storage outages, worker loss and failures during external actions.
• Define the Recovery Time Objective (RTO), the target recovery time, and Recovery Point Objective (RPO), the acceptable amount of data loss.
• Demonstrate application-data restoration rather than merely checking that snapshots exist.

Use a PodDisruptionBudget where appropriate to constrain voluntary disruptions. It does not replace redundancy or prevent involuntary node failures. (kubernetes.io)

Security and identity

The gVisor security model addresses workload containment. It should not be interpreted as business authorization for actions performed through permissions already granted to the code. Evaluate isolation and access permissions as complementary controls. (gvisor.dev)

I recommend the following requirements:

• Separate control-plane, worker and consuming-application identities.
• Apply Role-Based Access Control (RBAC) with only the permissions each identity requires.
• Use dedicated ServiceAccounts and avoid automatic token mounting where it is unnecessary. (kubernetes.io)
• Do not provide execution environments with administrative credentials or shared Secrets.
• Require short-lived credentials, rotation, Transport Layer Security (TLS), encrypted storage and destination-specific authorization.
• Treat snapshots as sensitive data and test credential renewal after a session resumes.

Connectivity deserves a separate assessment; see networking for agent sandboxes on Kubernetes.

Upgrades and rollback

I recommend pinning releases and image digests, managing configuration through GitOps, and promoting changes only after compatibility testing. Canary with tasks that have no external side effects, and validate restoration before upgrading the entire pool.

The rollback plan must answer a concrete question: can the previous release consume data written by the new release? If that has not been demonstrated, prefer draining sessions and reconstructing them from logical application state. Reverting an image alone is not evidence of complete recovery.

8. Task-oriented observability and FinOps

For the pilot, I recommend instrumenting four perspectives:

Define Service Level Indicators (SLIs) and Service Level Objectives (SLOs) around the task as experienced by the user. Pod availability alone should not be the success criterion.

I recommend correlating logs and traces through task identifiers while keeping high-cardinality identifiers out of metric labels. Do not log prompts, authentication tokens or repository contents by default.

For initial capacity planning, use average concurrency ≈ arrival rate × average active duration, then validate it against measurements. In a purely hypothetical example, 2 tasks per second with 5 active seconds each imply an average of 10 concurrent executions. This does not size the peak or account for failure headroom, waiting and uneven workload distribution.

A proposed financial model is:

cost per valid task = attributed period costs / tasks completed and approved during that period

Include idle warm capacity, snapshots, cross-zone traffic, load balancers, telemetry, model calls and human operations. Consider Spot capacity for restartable tasks; prioritize predictable capacity for the control plane and the minimum resources needed to meet the SLO. Do not assume that suspending execution automatically creates net savings.

9. Hypothesis-driven troubleshooting

The procedures below are proposed investigations for the pilot. Quota commands inspect native resources, not the projects' internal sessions. (kubernetes.io)

Increasing a quota is not a universal remedy. If recovery cannot fit within physical capacity, a higher admission ceiling merely moves the bottleneck.

10. Development, alternatives and decision criteria

For development, I would accept one environment, low traffic and simplified observability when data is disposable and limitations are explicit. Production approval should require demonstrated restoration, alerting, redundancy, access policy and rollback.

This table is a decision framework, not an implementation benchmark.

Avoid adopting all three layers at once for a small problem. Also reject hardcoded credentials, missing requests, permanent services without health probes, infrastructure without backups, unnecessary public exposure and expansion without an operational owner.

Practical summary

• Distinguish announcements, institutional approval, onboarding and operational readiness.
• Evaluate lifecycle management, isolation and training independently.
• Require recovery and exit demonstrations, not just a successful execution demo.
• Combine Kubernetes resource budgets with session and external-consumption controls.
• Measure reliability and cost per valid task.
• Approve production only when support, security and rollback have both accountable owners and evidence.

Conclusion

The strategic opportunity is to make agent infrastructure a dependency that can be more openly reviewed, audited and maintained across organizations. That is an architectural interpretation of the governance change, not a guarantee of portability or uniform maturity.

For DevOps, SRE and Platform Engineering teams, the next step should not be a platform-wide migration driven by an announcement. It should be a pilot with explicit contracts, acceptance criteria, failure tests and an alternative execution path. An open foundation can improve the decision context; engineering must still demonstrate that the platform is secure, recoverable and economically sustainable.