Agent Sandboxes

[scotwells]

Summary

Introduces a product-level proposal for Agent Sandboxes — a new Datum compute experience purpose-built for AI agents that need their own isolated, ready-to-use environment on demand.

The proposal is here and is intentionally non-technical: it's aimed at product, prospective customers, and the platform team rather than implementers.

What it covers

• What we're building and why the existing Workload shape isn't the right fit for agent use cases.
• Three new resources (Sandbox, SandboxTemplate, SandboxClaim) explained in plain language, plus warm pools as a template-level property.
• How it fits alongside Workload — additive, not a replacement.
• Three user journeys: an agent platform builder (consumer), a Datum platform engineer curating the catalog (operator), and the end user of the agent (incidental).
• Success metrics, open product questions, and explicit out-of-scope items.

This PR is documentation only. A separate technical RFC will follow with the API shape and implementation plan.

Test plan

• Product review of the proposal
• Confirm the user journeys match how we want to talk about the product
• Confirm the success metrics (notably the sub-50 ms claim-to-ready target) are the right bar to set

[zachsmith1]

why not just use upstream sandbox api contracts?

[scotwells]

@zachsmith1 we're building this construct on top of our core instance API which are location aware and have a different interface than native pods (network interfaces).

I do think it's important that we think through how we maintain compatibility with the upstream interface to help with adoption and allow users to build against the upstream API and still work with Datum. I'd look to solve this as a compatibility layer that coverts resources from the upstream API into our representation. Updated the docs with some details around that.