Manus funding changes the demand signal
On October 8, 2026, TechCrunch reported that Manus raised more than $500 million in its first funding round after splitting from Meta. The report matters less because of the brand name and more because of what the capital is underwriting: agentic systems that can run long, tool-using workflows rather than single prompt and response inference calls.
That distinction changes infrastructure planning. A chatbot request is often a short compute event. An agent session may plan, call tools, read documents, write files, execute code, inspect results, retry, and keep state for minutes or hours. It may need intermittent GPU acceleration, sustained CPU, local storage, object storage, network access, and a durable audit trail. It may also fail in ways that are operationally expensive: orphaned pods, idle GPU allocations, runaway browser sessions, or persistent volumes that nobody charges back to a tenant.
For operators who own a quarter rack to a few racks, this is the practical issue behind the funding news. Demand for agents can arrive before the estate has hyperscaler-style controls. The bottleneck is not simply whether there are enough accelerators. It is whether the platform can admit work fairly, preempt or resize GPU allocations, preserve session state, meter the full workflow, and keep tenants separated while utilization stays high.
ClastIQ is built for that operating model: real hardware, owned by the operator, with bare-metal provisioning, Kubernetes and VM tenancy on the same fleet, GPU partitioning, Ceph storage, per-tenant metering, quota engineering, and support for air-gapped or sovereign deployments. The question raised by Manus is not whether every regional operator should build an agent company. It is whether their GPU estate can host agent workloads without turning into a manual scheduling desk.
Why agent sessions do not behave like normal inference
Traditional inference capacity planning starts with tokens per second, concurrency, model size, and latency targets. Agent workloads add a control loop. The model is not always generating text. It may be waiting on a web fetch, a database query, a Python execution step, a vector search, or a human approval. During those waits, the workload may still hold memory, credentials, files, and a reservation on expensive compute.
That creates a utilization trap. If every agent session gets a full GPU until it completes, utilization appears allocated but not productive. If the scheduler releases the GPU too aggressively, session latency rises, state handling becomes complex, and users experience failures during resume. If the operator has no per-workflow metering, the platform cannot distinguish a valuable four-hour research workflow from an abandoned job that kept a GPU slice attached overnight.
The load profile is also bursty. A team may launch 80 agents at 9:00 a.m. local time to inspect tenders, invoices, code repositories, or industrial telemetry. Another team may schedule long document processing runs after midnight. The same fleet may also serve notebook users, fine-tuning jobs, retrieval pipelines, virtual machines, and customer demos. A small estate cannot hide behind regional oversupply. A few bad admission decisions can block an entire rack.
For a China-focused agent system, the same principles apply at scale. For GCC and MENA operators, the lesson is immediate. Ministries, banks, industrial groups, universities, and service providers may want agent workflows while also requiring data residency, local support, and predictable chargeback. Buying hardware is the easy part. Running it as a governed regional capacity pool is the harder part.
The bottleneck for a quarter rack
Consider a quarter-rack deployment with 8 GPU servers, each with 4 accelerators, for 32 physical GPUs. Add 12 CPU-heavy nodes for tool execution, vector indexing, CI tasks, and shared services. Attach Ceph across NVMe and HDD tiers for persistent volumes, object buckets, logs, and tenant datasets. This is not a hyperscaler region, but it is enough hardware to support meaningful agent services if scheduled correctly.
The first bottleneck is admission control. Agent sessions are unpredictable. Some finish in 8 minutes. Some run for 3 hours. Some call a model 200 times but use the GPU for only 30 percent of wall-clock time. A first-in, first-out queue is simple, but it lets large or noisy tenants dominate the fleet. A purely interactive priority class improves responsiveness, but it can starve batch work and reduce revenue.
The second bottleneck is GPU fragmentation. One agent runtime may need a whole GPU for a planning model. Another may need only a partition for a lightweight model server. Another may run CPU tools most of the time and request GPU bursts. Hardware-agnostic partitioning matters here. On supported hardware, operators may use mechanisms such as MIG-style partitioning, time-slicing, or device plugin level sharing. On other accelerators, the policy may be expressed through different partitioning and scheduling primitives. The operational goal is the same: put smaller jobs on smaller slices without pretending that all GPUs behave identically.
The third bottleneck is state. Agent workloads need durable scratch space, logs, artifacts, vector indexes, and sometimes encrypted tenant repositories. If state lives only in the pod, preemption is dangerous. If every workflow writes to unmanaged disks, chargeback and cleanup fail. Persistent volumes, object storage, lifecycle policies, and namespace-level quotas are part of the scheduler, not an afterthought.
The fourth bottleneck is metering. A GPU estate that cannot calculate cost per workflow cannot run fair internal chargeback or external billing. Token counts alone are not enough. Operators need GPU-hours, partition-hours, CPU-hours, RAM-hours, storage GB-months, egress, and retained artifacts by tenant and workflow.
A worked capacity and chargeback example
Use the quarter-rack example: 32 physical GPUs available 24 hours per day. That is 768 physical GPU-hours per day.
Assume the operator partitions half the fleet into smaller slices for agent inference and tool-augmented workflows. The remaining half stays available as full GPUs for fine-tuning, larger inference, and priority jobs.
If 16 GPUs are configured as 4 equal slices each, that creates 64 slice slots. If each slice is charged internally at 0.30 of a full GPU-hour to account for overhead and memory constraints, then 64 slice slots available for 24 hours represent 1,536 slice-hours, equivalent to 460.8 billable full GPU-hours per day. The other 16 full GPUs represent 384 full GPU-hours per day. Total billable capacity is 844.8 GPU-hour equivalents per day, but physical energy and thermal limits remain those of 32 GPUs plus servers.
Now assume measured utilization is:
| Pool | Daily capacity | Utilization | Billable use |
|---|---|---|---|
| Full GPU pool | 384 GPU-hours | 62% | 238.1 GPU-hours |
| Agent slice pool | 460.8 GPU-hour equivalents | 71% | 327.2 GPU-hour equivalents |
| Total | 844.8 GPU-hour equivalents | 66.9% blended | 565.3 GPU-hour equivalents |
If the operator sets an internal chargeback price of 3.20 dollars per GPU-hour equivalent, daily compute revenue or cost recovery is 565.3 × 3.20 = 1,808.96 dollars. Monthly, using 30 days, that is 54,268.80 dollars.
Power changes the view. Suppose the quarter rack draws 22 kW average including servers, storage, switching, and cooling allocation. Monthly energy is 22 kW × 24 × 30 = 15,840 kWh. If all-in facility power costs 0.12 dollars per kWh, monthly energy cost is 1,900.80 dollars. This is not total cost, because depreciation, support, facilities, software operations, and financing also matter. But it shows why utilization and chargeback matter more than headline GPU count.
Revenue per MW can be normalized from the same numbers. Monthly chargeback of 54,268.80 dollars at 0.022 MW average equals 2,466,763.64 dollars per MW-month. Annualized, that is 29,601,163.68 dollars per MW-year. If poor scheduling drops blended utilization from 66.9 percent to 42 percent at the same price, monthly chargeback falls to about 34,070 dollars, and annualized revenue per MW falls to about 18.6 million dollars. The operator did not lose hardware. The operator lost schedulable, metered utilization.
This is where agent workloads become an economic issue. The difference between a governed agent pool and an unmanaged one can be the difference between a recoverable rack investment and a queue full of idle reservations.
How ClastIQ maps the problem to controls
A small or mid-size GPU estate needs the same control surfaces as a larger region, but with less staffing and less spare capacity. A system like ClastIQ addresses the problem in layers.
Bare-metal provisioning comes first. MAAS and Juju-based workflows let the operator enroll machines, install operating systems, model services, and rebuild nodes consistently. This matters when the fleet is mixed: different GPU vendors, CPU-only tool nodes, storage nodes, and networking profiles. Agent platforms should not depend on a single hardware bill of materials.
The tenancy layer comes next. Kubernetes should serve containerized model endpoints, agent workers, tool sandboxes, observability stacks, and batch jobs. VMs should still be available for tenants that need stronger isolation, custom kernels, licensed software, or legacy environments. Running Kubernetes and VM tenancy on the same fleet lets the operator avoid stranded capacity.
GPU partitioning is the third layer. Some workloads need a full accelerator. Some can run on smaller partitions. Some benefit from time-slicing because they are latency tolerant or bursty. The policy should be explicit: which tenant can use which partition type, how many concurrent sessions are allowed, whether preemption is permitted, and what happens to state when preemption occurs.
Storage is the fourth layer. Ceph gives the operator a common substrate for block volumes, object storage, and file-style access patterns depending on configuration. Agent workloads need this because they generate artifacts. A research agent may create PDFs, embeddings, notebooks, logs, and intermediate datasets. A coding agent may create repositories, build outputs, and test logs. Without storage quotas and lifecycle rules, abandoned state becomes a hidden bill.
Metering and quotas are the fifth layer. Each namespace, VM project, workflow ID, or tenant account should have measurable consumption. Chargeback should include accelerators, CPU, memory, storage, and network where relevant. Quotas should be designed around business commitments, not just technical limits. For example, a tenant may have 10 full GPU-hours per day for priority work, 80 slice-hours for agent sessions, and 2 TB of retained artifacts.
Sovereignty and air-gap support are the sixth layer. Agent systems often touch sensitive data: procurement records, customer files, industrial logs, source code, and regulated documents. GCC and MENA operators may face national data residency requirements, sector-specific rules, or internal policies that prohibit sending prompts and artifacts to an overseas cloud service. For operators in Oman, Saudi Arabia, the UAE, Qatar, Kuwait, Bahrain, and the wider region, running agent infrastructure on owned hardware can align capacity planning with governance, provided the platform enforces tenancy, auditability, and local control.
Scheduling policy for long-running agents
The key scheduling design is to separate workflow lifetime from accelerator attachment. An agent session may last two hours, but it should not always hold a GPU for two hours. The agent controller can checkpoint state to persistent storage, release the GPU while waiting on tools, and reacquire a slice or full device when the next model step is ready.
At platform level, this requires clear classes of service. For example:
| Class | Intended use | Preemption | Metering unit |
|---|---|---|---|
| interactive-agent | human waiting on result | limited | GPU slice-minute plus CPU-minute |
| batch-agent | scheduled workflow | allowed at checkpoint | GPU slice-minute plus storage |
| full-gpu | large model or fine-tune | restricted | physical GPU-hour |
| cpu-tooling | browsers, code, ETL | allowed | vCPU-hour and RAM-hour |
A simple Kubernetes policy fragment can make the operational intent visible. This is illustrative, not a universal template:
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: interactive-agent
value: 8000
globalDefault: false
description: Short human-facing agent steps, limited preemption
---
apiVersion: v1
kind: ResourceQuota
metadata:
name: tenant-agent-quota
namespace: tenant-a
spec:
hard:
requests.cpu: 320
requests.memory: 1Ti
persistentvolumeclaims: 80
requests.storage: 20Ti
limits.example.com/gpu-slice: 24
The exact resource name depends on the device plugin and partitioning model. The important point is that agent capacity is expressed as a quota-controlled resource, not as an informal promise. Operators should also enforce maximum workflow duration, idle timeout, artifact retention, and per-tenant concurrent session limits.
For VMs, the same idea applies through flavors and placement policies. A tenant may get a GPU-backed VM for a secure development environment, while bursty agent workers run in Kubernetes. ClastIQ's value is in coordinating both modes on the same estate so that utilization is managed across the whole fleet.
Observability for agent infrastructure
Agent observability is not only application tracing. Operators need to see where capacity is being consumed and where it is being wasted. The minimum useful view connects workflow ID, tenant, namespace, GPU allocation, CPU use, memory, storage growth, queue time, run time, failure reason, and cost.
Queue time is especially important. A tenant may complain that agents are slow, while GPU utilization looks low. The cause may be storage throttling, CPU tool saturation, image pulls, DNS failures, or license servers. Conversely, the GPU pool may be saturated because sessions keep devices attached while waiting for external APIs. Without cross-layer observability, the operator will add GPUs when the real bottleneck is state management or queue policy.
A practical dashboard for a small GPU estate should answer five questions:
- Which tenants are using the most GPU-hour equivalents today?
- Which workflows are holding accelerators while doing little GPU work?
- Which queues have rising wait time?
- Which storage pools are growing fastest by tenant?
- Which nodes are power or thermal constrained?
Power deserves inclusion because agent workloads can hide inefficiency. A rack may draw near steady power while delivering low billable GPU-hours if devices remain allocated but underused. Operators should compare watts, GPU utilization, and chargeback in the same review. Revenue per megawatt is not a finance-only metric. It is an infrastructure health metric.
China signal, regional implication
The Manus funding report is a China-focused demand signal for agentic systems. Capital is moving toward software that performs work across tools, not only chat interfaces. Infrastructure demand will follow, but it will not arrive as neat, stable inference traffic.
For GCC and MENA operators, the implication is not to copy China's market structure. It is to prepare local capacity for similar workload shapes under regional constraints. A university AI center may need project-level quotas. A government agency may need air-gapped deployment and audit logs. A bank may need VM isolation for sensitive datasets and Kubernetes for scalable agent workers. An industrial operator may need agents close to plant data because moving logs offshore is not acceptable.
The operator with 32 to 128 GPUs cannot solve this by overprovisioning. The better path is to make every accelerator schedulable, every workflow stateful but preemptable where possible, every tenant metered, and every policy visible. That is how a small estate starts to behave like a governed region rather than a shared lab.
ClastIQ, a product of Cognition AI and Technology Innovation SPC registered in Oman, is designed around that operating reality. It is hardware-agnostic across NVIDIA, AMD, and mixed CPU and GPU estates. It focuses on the controls that matter when the operator owns the hardware: provisioning, tenancy, partitioning, storage, metering, quotas, policy, sovereignty, and local human support.
What to do this week
- Inventory agent-like workloads already running on the estate, including notebooks, scripts, tool workers, browser automation, and long inference chains.
- Define at least three service classes: interactive agent, batch agent, and full GPU. Assign preemption, timeout, and quota rules to each.
- Add workflow-level metering fields now: tenant, workflow ID, GPU allocation type, wall time, GPU active time, CPU-hours, storage used, and exit status.
- Test checkpoint and resume for one representative agent workload. Confirm that state survives pod eviction, node drain, and queue delay.
- Review storage lifecycle rules. Set retention limits for logs, artifacts, embeddings, and abandoned persistent volumes by tenant.
- Calculate current revenue or cost recovery per MW using real utilization and chargeback numbers, then model the effect of a 10 percentage point utilization gain.
ClastIQ runs this on the operator's own hardware, from a quarter rack to a few racks. request a demo