Agent sandboxes will strain small GPU estates

The news: agent infrastructure is becoming its own tier

Dealroom’s August 2026 notes put three AI infrastructure financings in the same frame. Daytona raised a $48.3 million Series B, with a related $60 million offering disclosed via the SEC, to build secure cloud sandboxes where AI agents can run code and use tools. Naïve raised a $28.5 million Series A for infrastructure intended to let AI agents handle the operational work of setting up and running companies. Keenable emerged from stealth with a $26 million seed round to build independent web-search and retrieval infrastructure for AI labs and inference providers.

Read together, these are not just application stories. They describe a new operating pattern for compute estates. Agents do not only call a model endpoint. They open workspaces, run code, fetch documents, search the web, write intermediate files, invoke tools, and sometimes need GPUs for short bursts. Retrieval is no longer a sidecar to inference; it is a bandwidth, storage and policy plane. Sandboxes are no longer developer convenience; they are tenant execution environments with untrusted code.

For a hyperscaler, the answer is usually another managed service boundary. For an operator with a quarter rack, one rack or a few racks of owned hardware, the answer has to be more deliberate. The same fleet may need to host Kubernetes tenants, virtual machines, model-serving jobs, CPU-heavy agent sandboxes, GPU-partitioned notebooks, Ceph-backed datasets, and a retrieval layer that is noisy on network and storage. The bottleneck will arrive before the estate is physically full.

The practical question is: can a modest GPU estate keep utilisation high while giving each tenant enough isolation, quota, accounting and data control to run agent workloads safely?

The real bottleneck is agentic multi-tenancy

A traditional small GPU cluster is often planned around a simple unit: a whole GPU allocated to a job for a period of time. That works for training, fine-tuning and some inference. Agent infrastructure changes the shape of demand.

A single agent workflow may have five distinct resource profiles:

This is why the Daytona, Naïve and Keenable pattern matters to infrastructure operators. The scarce item is not always the accelerator. A tenant may reserve GPUs but spend much of the wall-clock time in retrieval, package installation, browser automation, document parsing or code execution. Another tenant may need thousands of short GPU bursts rather than a stable eight-GPU allocation. A third may be legally required to keep retrieval indexes, prompts and generated artefacts inside national or organisational boundaries.

Without orchestration, these demands collide. Whole GPUs are stranded behind CPU queues. Retrieval workloads saturate Ceph or top-of-rack links. Developers ask for SSH access because the platform does not provide controlled sandboxes. Finance sees a power bill but cannot map it to tenant activity. Security teams block useful agent tools because there is no per-tenant egress policy.

Small and mid-size operators feel this more sharply than very large clouds because they cannot hide inefficiency inside regional scale. A few wasted GPUs can materially change unit economics.

What this means for a quarter rack to a few racks

Consider an operator with eight GPU servers in a single room or colocation cage: 32 accelerators in total, plus CPU, NVMe, Ceph storage nodes and redundant networking. The estate serves internal AI teams, a few external tenants, or government and enterprise workloads. This is a common shape for a sovereign or local AI platform in the GCC/MENA market: large enough to matter, too small to waste capacity, and often subject to strict data residency expectations.

Agent workloads introduce several failure modes.

First, scheduling becomes mixed-mode. Some users need Kubernetes pods for agent runtimes. Others need VMs because their tools require a stronger boundary or a full operating-system image. Some want bare metal for performance testing. If the estate is split manually into separate pools, each pool becomes underutilised. The Kubernetes pool runs out of CPU while the VM pool has idle GPUs. The bare-metal pool holds machines for weeks because reprovisioning is painful.

Second, GPU partitioning becomes necessary. A full high-memory accelerator is wasteful for many agent steps. Retrieval-augmented generation, evaluation, embedding refreshes and interactive notebooks may need fractions of a GPU or time-sliced access. On NVIDIA estates that may mean MIG where available, time-slicing where suitable, or full GPU allocation for latency-sensitive work. On AMD estates it means using the relevant device plugin and partitioning model available for the hardware. In mixed estates, the scheduler needs to understand classes of capacity, not assume one vendor or one accelerator type.

Third, storage and retrieval become first-class. Keenable’s positioning around independent web-search and retrieval infrastructure is a reminder that model quality depends on context supply. But retrieval is not free. Indexes consume memory and disk. Crawlers and connectors create ingress and egress traffic. Vector stores, document stores and object stores need backup and policy. If retrieval is run as an afterthought on the same nodes as GPU serving, the GPUs wait on storage.

Fourth, metering must move below the invoice level. Charging only by allocated GPU is not enough for agents. The operator needs GPU-hours, GPU-slice-hours, vCPU-hours, memory-hours, storage GB-months, retrieval API calls, egress allowances and possibly power allocation by tenant or namespace. This is not only for external billing. Internal chargeback changes behaviour: teams stop hoarding whole GPUs when they can see the cost of idle allocations.

How Clastiq fits the operating model

Clastiq is designed for operators who own the hardware: from a quarter rack to a few racks, not a hyperscale region. The relevant design point is control of a mixed fleet. Bare-metal provisioning through MAAS and Juju, Kubernetes and VM tenancy on the same physical estate, GPU partitioning through MIG or time-slicing where supported, Ceph storage, per-tenant metering, quota and policy engineering, and deployment patterns for air-gapped or sovereign sites.

For agent infrastructure, the important part is not one feature in isolation. It is the combination.

Bare-metal provisioning keeps the estate rebuildable. If a node used for VM tenancy needs to become part of a Kubernetes pool, the operator should not be reinstalling by hand. If a tenant needs a clean GPU host for a controlled benchmark, that should be a governed provisioning workflow rather than an exception.

Kubernetes and VMs on the same fleet allow different sandbox boundaries. Lightweight agent execution can run in Kubernetes namespaces with quotas, network policies and storage classes. Higher-risk workloads can run in VMs with stricter isolation. Long-lived platform services such as retrieval gateways, vector databases or tenant control planes can be placed deliberately, rather than competing with transient jobs.

GPU partitioning reduces fragmentation. Full GPUs should be reserved for workloads that need full memory, bandwidth or predictable latency. Smaller agent tasks can use slices or scheduled time access. The point is not to oversell accelerators blindly; it is to match the allocation unit to the job.

Ceph gives a common storage substrate for object, block and file use cases, with placement and replication policies that can be aligned to the size of the estate. Retrieval indexes, tenant artefacts, VM volumes and model repositories should not sprawl across unmanaged disks.

Metering and chargeback connect engineering to economics. If a tenant uses CPU sandboxes heavily but only occasional GPU inference, the bill or internal allocation should show that. If another tenant occupies a full accelerator while spending 70 percent of time waiting for a crawler, the platform should make that visible.

Quota and policy engineering are what keep agent systems governable. Agents are designed to take actions. Infrastructure must define which actions are allowed: what networks they may reach, which secrets they can mount, which storage buckets they can read, how many concurrent sandboxes they can launch, and what happens when a monthly GPU-hour budget is exhausted.

A worked utilisation and chargeback example

Assume a 32-GPU estate. Each GPU is available for 720 hours in a 30-day month, so the theoretical monthly capacity is:

32 GPUs × 720 hours = 23,040 GPU-hours

Before introducing better orchestration, the operator averages 32 percent productive GPU utilisation because whole GPUs are reserved for mixed agent workflows and sit idle during retrieval or CPU-heavy tool use.

23,040 × 0.32 = 7,373 productive GPU-hours per month

Assume the facility draw for the small estate is 54 kW IT load including GPU servers, CPU nodes, storage and networking. With a PUE of 1.3, facility power is 70.2 kW. Monthly energy is:

70.2 kW × 720 hours = 50,544 kWh

At $0.11 per kWh, power costs $5,560 per month. Add $27,222 per month for hardware amortisation on a $980,000 estate over 36 months, plus $6,000 for colocation, support and connectivity. Total monthly cost is $38,782.

At 32 percent productive utilisation, infrastructure cost per productive GPU-hour is:

$38,782 ÷ 7,373 = $5.26 per productive GPU-hour

Now assume the operator uses a Clastiq-style model: tenant quotas, GPU slices for smaller jobs, VM isolation for riskier sandboxes, Kubernetes namespaces for routine agent workers, and metering that discourages idle reservations. Productive GPU utilisation rises to 65 percent without adding hardware:

23,040 × 0.65 = 14,976 productive GPU-hours per month

The same monthly cost divided by the higher productive usage is:

$38,782 ÷ 14,976 = $2.59 per productive GPU-hour

The power bill has not disappeared. The servers are not magic. The gain comes from reducing stranded capacity and charging the right resource at the right granularity.

For revenue or internal recovery, suppose the operator bills the month as follows:

• 10,000 full-GPU-equivalent hours at $4.00 = $40,000
• 24,000 GPU-slice-hours at $0.70 = $16,800
• 80,000 vCPU sandbox-hours at $0.03 = $2,400
• 20 TB of managed retrieval and artefact storage at $25 per TB-month = $500

Total monthly recovery is $59,700. Annualised, that is $716,400. On a 70.2 kW facility footprint, revenue per MW-year is:

$716,400 ÷ 0.0702 MW = $10.2 million per MW-year

At the earlier utilisation level, billing only 7,373 GPU-hours at $4.00 would produce $29,492 per month, or $353,904 per year. That is about $5.0 million per MW-year. The difference is not a claim about any particular deployment; it is the arithmetic of utilisation and metering in a small estate.

The control points operators should implement

Agent platforms need a resource contract. The contract should be visible to tenants and enforceable by the scheduler.

A simple Kubernetes quota for an agent namespace might look like this. The GPU resource name will vary by device plugin and partitioning mode; the example uses a MIG-style resource only to show the pattern.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: agent-team-quota
  namespace: agent-team-a
spec:
  hard:
    requests.cpu: '400'
    limits.cpu: '800'
    requests.memory: 2Ti
    requests.nvidia.com/mig-1g.10gb: '16'
    requests.storage: 20Ti
    count/pods: '250'

The quota is only one layer. A production design also needs network policy, image provenance, secrets boundaries, storage classes, runtime controls and metering. For VM tenants, the same intent should be expressed through project quotas, image controls, volume limits and GPU attachment rules.

For retrieval-heavy workloads, isolate the data path. Retrieval gateways should have explicit egress policy and caching. Index builders should run in CPU and storage pools where possible. GPU nodes should not become the default place to parse PDFs, crawl websites or run long ETL jobs unless there is a measured reason.

For sandboxes, define lifetimes. Agent workspaces that live forever become unmanaged servers. A sandbox should have an owner, a maximum runtime, a storage retention policy, and a budget. If the tenant needs persistence, promote the artefact into governed storage rather than leaving it on ephemeral disks.

For chargeback, do not wait for perfect billing. Start with a small set of defensible meters: allocated GPU-hours, GPU-slice-hours, vCPU-hours, RAM-hours, storage GB-months, and network egress. Add retrieval-specific units later if needed. The goal is to make waste visible quickly.

GCC/MENA relevance: sovereignty and revenue per megawatt

Although the Daytona, Naïve and Keenable financings are global AI infrastructure signals, the implications are especially concrete in GCC/MENA markets. Many operators in the region are building national, sectoral or enterprise AI capacity without handing all data and workload control to an offshore hyperscaler. They may serve banks, public-sector entities, universities, Arabic-language AI teams, energy companies or local software firms. Data residency, procurement control, air-gap options and human-led local support are not optional details.

Agent infrastructure raises the sovereignty bar. A model endpoint can be isolated relatively cleanly. An agent workflow is harder: it may search, browse, execute code, call tools, store intermediate files and generate audit logs. If those retrieval paths leave the country or cross an unapproved provider boundary, the operator has a governance problem even if the GPU inference stayed local.

This is why independent retrieval layers matter. Operators need to decide which indexes are local, which external search APIs are allowed, which tenants can reach the open internet, and what content is cached or logged. For some workloads, the correct design is a fully air-gapped retrieval corpus. For others, it is a controlled egress gateway with policy and audit.

Power economics also matter in the region. GPU estates are increasingly judged by revenue or useful work per megawatt, not just nameplate accelerator count. A few racks that run at poor utilisation can consume scarce power allocation while delivering little tenant value. Better partitioning, scheduling and chargeback directly affect the business case for expanding the site.

Design principle: separate trust, scheduling and data planes

The safest pattern is to avoid treating “agent platform” as one flat cluster. Separate three concerns.

The trust plane defines who may run what. This includes tenant identity, VM versus container boundaries, approved images, secrets access and egress controls.

The scheduling plane decides where workloads land. It needs to understand whole GPUs, slices, CPU pools, storage locality, maintenance windows and tenant quotas. It should avoid placing retrieval ETL on expensive GPU hosts when CPU nodes will do.

The data plane moves prompts, documents, embeddings, indexes, artefacts and logs. It needs Ceph placement, backup policy, retention rules and, where applicable, sovereign or air-gapped routing.

Clastiq’s role is to integrate these planes on hardware the operator already owns or plans to buy. It is hardware-agnostic across NVIDIA, AMD and mixed CPU/GPU estates. The value is not pretending a small cluster is a hyperscaler. The value is giving a small or mid-size estate the operating discipline of one: provisioning, tenancy, partitioning, storage, metering, quotas and policy.

What to do this week

1. Inventory agent-shaped demand separately from training and inference. Count sandboxes, vCPU-hours, storage, retrieval traffic and GPU bursts, not only GPUs.
2. Define tenant classes: Kubernetes namespace, VM tenant, bare-metal reservation, and restricted or air-gapped tenant. Map each to isolation and quota rules.
3. Introduce GPU allocation tiers. Reserve whole accelerators for jobs that need them; use partitioning or time-slicing for smaller agent and notebook workloads where the hardware supports it.
4. Put retrieval on a governed data path. Decide what is local, what may egress, what is cached, and how indexes are stored and backed up.
5. Start chargeback with five meters: GPU-hours, GPU-slice-hours, vCPU-hours, storage GB-months and egress. Publish reports even before pricing is final.
6. Review power and revenue per MW monthly. If utilisation gains do not show up in the power-normalised economics, the scheduling and quota model is not yet working.

Clastiq runs this on the operator’s own hardware: request a demo.

Sources

• Daytona lands $48.3M Series B for AI agent sandbox platform
• Naïve raises $28.5M Series A to let AI agents run companies
• Keenable emerges from stealth with $26 million seed round
• Oxide Computer raises $445M Series D