Daytona funding points to agent cloud scheduling

Daytona's round makes agent infrastructure a scheduling problem

On October 23, 2026, TechCrunch reported that Daytona raised $60 million at a $1 billion valuation for what it calls an agent cloud. The company is positioning around a specific operating model: AI agents that need isolated sandboxes, stateful workspaces, fast startup, network controls, and sometimes GPU access. The investor list matters less to operators than the workload shape. If agent systems move from demos into routine software development, security analysis, data work, customer operations, and internal automation, infrastructure teams will see thousands of short-lived jobs that are not quite batch, not quite interactive notebooks, and not quite traditional CI runners.

That is the change. A GPU estate that was designed around long training jobs, stable inference services, or a handful of notebook users can be fragmented by agents. Each agent may need a clean runtime, a checked-out repository, a browser or toolchain, secrets scoped to one task, temporary network access, logs, a persistent workspace, and a small amount of accelerator time. Some jobs run for 90 seconds. Some run for 20 minutes. Some run CPU-only until a model call, embedding step, computer vision check, or local inference phase needs GPU. The result is not simply higher demand. It is demand that is hard to pack.

For a small or mid-size operator, from a quarter rack to a few racks, this is where economics can move quickly. A hyperscaler can absorb fragmentation through a large regional pool. A smaller GCC, MENA, university, enterprise, or service provider estate cannot assume that spare capacity somewhere else will smooth out scheduling mistakes. If 32 GPUs are divided badly, a useful local cloud becomes a queue. If they are governed well, the same hardware can support research tenants, agent platforms, internal development, and revenue workloads without losing sovereignty or chargeback discipline.

The bottleneck is not only GPU count

Agent jobs stress a cluster in a different way from classic ML training. Training jobs usually reserve large GPU blocks for hours or days. Inference services want steady placement, known latency, and predictable autoscaling. Agent sandboxes are bursty and stateful. They might need many small isolated environments, with a few requiring accelerator slices for brief periods.

That combination creates five infrastructure problems.

First, startup overhead becomes visible. If a sandbox takes 2 minutes to boot and the agent task lasts 4 minutes, one third of the elapsed time is overhead. Operators then overprovision to hide delay, which depresses utilization.

Second, state follows the job. An agent may build an index, clone a repository, create artifacts, cache dependencies, or maintain a browser profile. If the workspace is discarded every time, users wait and storage traffic spikes. If it persists without policy, tenants accumulate unbounded data and create data residency risk.

Third, GPU allocation becomes granular. A whole GPU is too large for many agent phases. A static partition may be too rigid. Time slicing can increase occupancy, but only if fairness, memory pressure, and noisy neighbor behavior are managed.

Fourth, tenancy is not optional. Agents often execute untrusted or semi-trusted code. A shared notebook model is not enough. Operators need namespace isolation, VM or container boundaries where appropriate, network policy, secrets scoping, image provenance, and audit trails.

Fifth, billing units get smaller. A tenant that launches 20,000 agent tasks in a month will not accept a vague share of the cluster bill. The operator needs CPU-hours, GPU-hours or GPU-slice-hours, memory, storage, image pulls, egress, and possibly workspace retention translated into a statement that finance can understand.

This is scheduling fragmentation. The cluster has enough theoretical capacity, but not enough usable capacity at the right isolation level, with the right workspace state, at the right time.

What a quarter rack actually sees

Consider a compact estate with four 8-GPU servers, shared storage, redundant switching, and a management plane. That is 32 GPUs. It may be installed in an enterprise data center in Muscat, Riyadh, Doha, Abu Dhabi, Manama, or Kuwait City, or in a regional hosting facility serving public sector and private tenants. The organization owns the hardware. It cannot move regulated data into a foreign cloud region just because a queue is badly tuned.

The operator starts with a reasonable plan: Kubernetes for containerized workloads, VMs for tenants that require stronger isolation or custom kernels, Ceph for persistent volumes, and metering for chargeback. Then agent workloads arrive. Suddenly there are thousands of pods or sandbox VMs per day. Some need GPU for local model calls or media processing. Many need CPU and storage only. Users complain about cold starts. Finance asks why GPUs are showing low utilization while queues are open. Security asks which agent touched which repository and whether the workspace stayed in country.

A simple batch queue does not solve this because many jobs are interactive and stateful. A simple notebook platform does not solve it because agents are numerous and ephemeral. A simple GPU reservation model does not solve it because whole-device allocation wastes capacity for short bursts.

The answer is an operating model that treats the fleet as one governed substrate, not separate islands for bare metal, Kubernetes, VMs, and storage.

How Clastiq would structure the fleet

Clastiq is designed for operators who own real hardware and need hyperscaler-like governance without becoming a hyperscaler. In this workload class, the key is to expose several tenancy shapes on the same estate.

Bare-metal provisioning establishes the hardware baseline. With MAAS and Juju based automation, servers can be commissioned, reprovisioned, placed into Kubernetes clusters, assigned to VM capacity, or reserved for dedicated tenants. This matters when the estate is small because every stranded server is material.

Kubernetes handles high-churn agent workers, API services, queue consumers, and GPU-slice workloads. VM tenancy handles customers or departments that need a stronger boundary, custom images, licensed software, or stable workspaces. Both should draw from the same physical fleet under policy, rather than becoming separate purchasing plans.

GPU partitioning should be selected by workload, not by vendor slogan. On NVIDIA estates, MIG can provide hard partitions on supported GPUs. Time slicing can improve throughput when jobs are latency tolerant and memory footprints are modest. On AMD or mixed estates, the exact mechanisms differ, but the requirement is the same: define consumable accelerator classes, expose them to schedulers, meter them, and prevent one tenant from consuming the cluster by accident.

Ceph provides the persistent layer. Agent workspaces, caches, artifacts, container registries, logs, and tenant volumes should not be glued to individual nodes. A sandbox can terminate while its workspace remains governed by quota, retention, and data residency policy. For GCC and MENA operators, that is not a minor feature. It is often the difference between offering an agent platform locally and telling users to export data to a larger foreign region.

Metering and chargeback close the loop. If a tenant creates many small jobs, they should see the cost of CPU, GPU slices, storage retained, and possibly premium sandbox startup classes. If a platform team wants warm pools for faster startup, those warm pools should be charged to the service owner, not hidden in the general infrastructure budget.

A worked example: fragmentation versus governed slicing

Assume the 32-GPU estate has 23,040 available GPU-hours in a 30-day month:

32 GPUs x 24 hours x 30 days = 23,040 GPU-hours.

The monthly platform cost includes capital recovery on servers and GPU nodes of $13,333, facility power of $3,326, and shared operations, networking, and software support of $5,000. Total monthly cost is $21,659. The cost per available GPU-hour is:

$21,659 / 23,040 = $0.94 per available GPU-hour.

Now compare two operating modes.

In the first mode, agent jobs reserve whole GPUs, and cold starts are frequent. Short jobs leave gaps. Some tenants hold GPUs idle while state is copied back and forth. Effective billable utilization is 25 percent. The operator sells or charges back:

23,040 x 25 percent = 5,760 billable GPU-hours.

The cost per billable GPU-hour becomes:

$21,659 / 5,760 = $3.76.

If the internal or external charge is $2.40 per GPU-hour, the estate under-recovers cost. Revenue or chargeback is:

5,760 x $2.40 = $13,824 per month.

In the second mode, the operator uses a mix of GPU slices, time sharing for eligible agent phases, warm sandbox pools, and persistent Ceph workspaces. Not every job becomes efficient, but effective billable utilization rises to 60 percent:

23,040 x 60 percent = 13,824 billable GPU-hours.

Cost per billable GPU-hour becomes:

$21,659 / 13,824 = $1.57.

At the same $2.40 charge, monthly chargeback is:

13,824 x $2.40 = $33,178.

The physical power profile also becomes clearer. Suppose the 32 GPUs draw 22.4 kW at rated GPU power, with CPU, memory, networking, and storage adding 10.6 kW. IT load is 33 kW. At a PUE of 1.4, facility load is 46.2 kW, or 0.0462 MW. Annualized chargeback in the second mode is $398,136. Revenue per facility MW-year is:

$398,136 / 0.0462 = $8.62 million per MW-year.

In the fragmented mode, annualized chargeback is $165,888, or $3.59 million per MW-year. The hardware did not change. The scheduling, tenancy, and metering model changed.

These figures are illustrative, but the direction is the operator lesson. For compact estates, utilization is not an abstract dashboard metric. It determines whether local sovereign capacity can compete with imported cloud consumption.

Control points for agent workloads

A practical design should make the following decisions explicit.

The table is deliberately operational. It avoids the common trap of treating agents as just another deployment target. Agents are a pressure test for the whole platform: identity, isolation, storage, scheduler behavior, and accounting.

Quotas should be written before the platform is popular

Operators often add quotas after the first incident. With agent workloads, that is late. A single team can create thousands of sandboxes because their orchestration layer is doing exactly what it was designed to do. Quotas should be part of tenant onboarding.

The exact resource names will depend on the GPU vendor, device plugin, and partitioning mode, but the pattern is simple: define tenant classes, cap accelerator slices, cap CPU and memory, and limit persistent volume growth.

kubectl create namespace tenant-research
kubectl label namespace tenant-research tenant=research data-class=internal
kubectl apply -n tenant-research -f - <<'EOF'
apiVersion: v1
kind: ResourceQuota
metadata:
  name: agent-sandbox-quota
spec:
  hard:
    requests.cpu: '160'
    requests.memory: 640Gi
    requests.storage: 20Ti
    persistentvolumeclaims: '200'
    example.com/gpu-slice: '16'
    pods: '1000'
EOF

This is not a complete policy, but it shows the operator stance. The agent platform can scale inside a defined envelope. If the tenant needs more, the request becomes a capacity and budget conversation, not a 2 a.m. outage.

Isolation choices: container, VM, or bare metal

Not every agent sandbox deserves the same boundary. Low-risk internal automation may run as containers with tight Kubernetes policy. Agents that execute customer code, handle regulated data, or install arbitrary packages may belong in VMs. Dedicated bare metal may be appropriate for tenants with strict isolation, licensed stacks, or performance-sensitive GPU jobs that do not tolerate sharing.

The important point is that these choices should coexist. If Kubernetes and VM platforms are built as separate silos, the operator loses pooling. If everything is forced into containers, security exceptions multiply. A Clastiq-style estate keeps bare metal provisioning, Kubernetes tenancy, VM tenancy, storage, GPU partitioning, and chargeback in one operating model.

For GCC and MENA organizations, this also supports procurement reality. A ministry, bank, university, AI lab, or regional service provider may need local support, Arabic and English operating procedures, air-gap installation options, and sovereign data handling. Agent infrastructure does not remove those requirements. It increases them, because agents touch more systems and generate more artifacts than a single inference endpoint.

Storage is part of utilization

GPU utilization often fails because storage was treated as a secondary issue. Agent workloads amplify that mistake. A sandbox may need to restore a repository, dependency cache, vector index, browser profile, or intermediate dataset before it can use the GPU. If every run pulls from the internet or rebuilds from scratch, accelerator capacity waits on storage and network paths.

A Ceph-backed design lets the operator create workspace classes. For example, scratch workspaces expire after 24 hours. Project workspaces retain for 30 days. Regulated workspaces are encrypted, backed up, and pinned to a defined location. High-performance caches can be placed close to GPU nodes, while durable artifacts remain on replicated pools.

The metering model should include retained storage. Otherwise tenants will optimize for compute cost by leaving every workspace alive forever. A simple chargeback line such as $0.03 per GB-month for standard workspace storage and a higher rate for protected retention can change behavior without a policy battle.

Power and capacity planning

Agent workloads can make power planning less intuitive. Whole-GPU training often produces sustained draw. Agent bursts produce peaks, idle gaps, and rapid transitions. Time slicing may increase average utilization, which is economically good, but it can also raise sustained power and cooling demand. Operators should watch facility load, rack density, and power capping as part of the scheduler design.

The right question is not only how many GPUs fit in the rack. It is how many governed GPU-hours the estate can deliver per kilowatt, under the required isolation and storage policy. Revenue per megawatt, or internal value per megawatt, is a useful executive metric because it connects technical fragmentation to data center economics.

A small estate can be financially healthy with fewer GPUs if it packs them well, meters them accurately, and avoids uncontrolled state growth. A larger estate can still lose money if sandboxes wait on cold starts, tenants hoard slices, or chargeback ignores storage and idle reservations.

What to do this week

1. Measure sandbox startup time. Separate image pull, VM boot, workspace attach, dependency restore, and scheduler wait.
2. Classify agent jobs into CPU-only, GPU burst, steady GPU, and high-risk execution. Do not use one queue for all four.
3. Define tenant quotas before broader rollout. Include pods or VMs, CPU, memory, GPU slices, persistent volumes, and retained storage.
4. Test GPU partitioning modes with real agent traces. Compare whole GPU, hardware partitioning where available, and time slicing for throughput, latency, and interference.
5. Put workspaces on governed storage. Set retention classes, backup policy, and data residency rules before users create thousands of artifacts.
6. Build a chargeback statement that shows CPU-hours, GPU-hours or slice-hours, GB-months, and warm pool reservations by tenant.

Clastiq runs this operating model on the operator's own hardware. request a demo

Sources

TechCrunch, Agent cloud startup Daytona hits $1B valuation backed by FirstMark and angels