The Agent Runtime Is Now a Design Choice

For a developer shipping an agent, model choice is only one design decision. You also need to decide where its code runs, how state survives a pause, and which actions should stay deterministic. Recent product announcements make those boundaries visible.

Two runtime designs

Google’s Nov. 5 Open Source Blog post says Agent Substrate reached version 1.0 and that Google Cloud is donating it, alongside gVisor, to the CNCF Sandbox. The post frames the engineering problem as agent sessions that run a tool, then wait on model inference or a person while their files and process state must remain available. Google presents a fully isolated compute-and-storage runtime as its answer; that is the company’s design rationale, not independent evidence of lower cost or better performance in every deployment. S1

A recent Launch HN post from Rivet’s founders describes a different approach: stateful actors backed by S3, with hibernation while idle, rather than a heavyweight sandbox for each agent. That may fit workloads centered on persistent state and tool calls, but an actor model should not be assumed to offer the same security boundary as a fully isolated sandbox. Y Combinator’s 21st launch page shows another practical layer around the runtime: sandboxed execution, credential proxying, streaming, billing and observability. S2 S3

Keep business sequences deterministic

On Oct. 29, AWS announced that existing Standard and Express Step Functions workflows can be exposed as agent tools through Amazon Bedrock AgentCore Gateway. The agent chooses when to call a workflow and supplies its inputs; Step Functions executes the workflow’s defined steps. S4

That separation is useful when an agent can decide which operation is needed, but a known sequence—such as validation followed by approval and execution—should remain explicit and reviewable. The workflow still needs correct permissions, failure handling and business rules; adding an agent tool does not make those choices safe automatically.

Choose by trust boundary and workload

For arbitrary repository or customer code, prioritize isolation and test network egress and credential access. For sessions that pause often but must retain files or process state, prototype suspend-and-resume or actor-based designs and measure wake latency and state recovery. For fixed multi-step operations, expose a workflow tool and keep authorization checks in the workflow.

Before committing to a runtime, replay representative tasks and record end-to-end p95 completion time, wake-to-first-tool latency, failures and retries, and idle resource cost per completed task. Separate model wait from local execution. Fast resumption, low idle cost and sandbox security are different properties—not one generic measure of “agent speed.”