Proposal: Agent Substrate as a delegated isolation backend under RFC 12

Lee primero RFC 12 y el issue #3361; después, inspecciona SandboxConfirmEvidence::validate, GetCapabilities y BoundaryLoopbackConnector. Revisa cómo encajan el transporte delegado y el contrato de ciclo de vida con las interfaces existentes. Se considerará terminado cuando exista un plan de implementación acordado, validado con un despliegue real de GKE, y se hayan aportado escenarios de topologías delegadas a openshell-conformance.

Proposal: Agent Substrate as a delegated isolation backend

We're planning to implement RFC 12 for Agent Substrate, and Drew offered on #2048 to work through a proposal, so here is one. It's concrete about what we'd build and about the three places the contract would need to move first.

What Substrate is, briefly

An open-source system that runs agent workloads on Kubernetes by multiplexing many "actors" onto a smaller pool of ready worker pods. Agents are idle most of the time, so actors are checkpointed to storage when idle and restored on demand, which is where the density comes from. Isolation is gVisor. There's a control plane and a per-node agent; the node agent is what owns a sandbox's lifecycle.

The topology it lands as

Delegated, in the RFC's sense. Substrate is a separately deployed control plane, so the backend would be a thin in-process implementation of the interface that carries its own transport to the node agent, with delegation staying topology-private. That's the pattern the RFC already describes, in the alternatives section and again in non-goals, rather than anything new.

Three things in the contract

1. A transport surface for the delegated link. The alternatives section says a transport-bearing surface "is not precluded: it is versioned contract surface, added when a concrete delegated backend requires it." We'd be that backend, so this is us supplying the trigger rather than reopening the decision. What we'd want to agree is the shape: which operations cross the link, and what the versioning story is when the two halves are deployed separately and can skew.

2. Confirmation evidence as properties rather than mechanisms. SandboxConfirmEvidence::validate currently requires a specific set of seccomp user-notification facts plus landlock_abi >= 3. A gVisor boundary provides neither, because the sentry implements the syscall interception itself, so no backend on it can reach Ready regardless of the isolation it actually provides. The merged RFC doesn't ask for either mechanism, and its kernel-relationship table already contemplates a userspace application kernel, so I read this as a gap between the text and the crate. Written up properly in #3361 rather than here, with the measured probe output and a proposed shape.

3. A memory-preserving lifecycle verb, plus a capability bit. Today's lifecycle is cold: Stop and Start by design. Substrate suspends an actor with its memory intact and resumes it, which is the property the density model depends on, and there's no way to express it through the current verbs. GetCapabilities already negotiates gateway_manages_lifecycle, so negotiating lifecycle semantics per backend is an established pattern here, and a backend that doesn't implement the verb would simply not advertise it.

One thing I'd rather ask than assume: does BoundaryLoopbackConnector cover port forwarding into a delegated topology, or is that still open?

What we'd do

Build it, against a real deployment rather than a mock. We have Substrate running on GKE today with gVisor actors suspending and resuming with memory and filesystem state both intact, so the backend has something to sit on from day one.

We'd also be glad to contribute the delegated-topology scenarios to openshell-conformance as part of the work. A backend that's out of process is the awkward case for a suite, and it seems better for us to write those than to hand you a backend and leave the testing to someone else.

Happy to break any of the three out into its own issue if that's easier to review than one thread.