COFE Tech turns agents into infrastructure demand
COFE Tech, founded in Kuwait and focused on the Gulf, closed a pre-IPO round at a reported $178 million valuation on 2 September 2026. The company said the raise would support its work as an operator of agentic AI enterprises and as a provider of AI-powered procurement and commerce infrastructure to more than 1,000 Gulf businesses.
That is not just a retail or marketplace story. For GPU cluster operators in the GCC, it is a signal about workload shape. Commerce platforms that used to call a recommendation model or a chatbot now want persistent agents: agents that watch catalogues, check supplier terms, draft purchase orders, reconcile invoices, answer customer messages, and escalate exceptions. A single enterprise account can turn into hundreds or thousands of small inference sessions tied to SKUs, suppliers, branches, and users.
The infrastructure problem is not whether a hyperscaler can absorb that pattern. It can. The problem is what happens when the operator is not a hyperscaler: a university commercialisation unit, a telecom edge facility, a sovereign cloud operator, a systems integrator, a retail group, or an AI service provider with a quarter rack to a few racks of real hardware in Kuwait, Saudi Arabia, the UAE, Qatar, Bahrain, Oman, or elsewhere in MENA.
At that scale, the hard part is not buying GPUs. It is keeping them busy without losing control. Agentic commerce workloads need fine-grained GPU sharing, tenant separation, storage locality, policy enforcement, and billing records that a finance team can defend. A small estate cannot afford stranded GPUs, hand-written spreadsheets, or a single noisy tenant that turns a shared cluster into an incident.
ClastIQ is built for that operating model: hardware-agnostic GPU and CPU orchestration on the operator’s own fleet, spanning bare metal, Kubernetes, VM tenancy, GPU partitioning, Ceph-backed storage, quotas, metering, chargeback, air-gap deployment, and local human support. The point is to make a small or mid-size GPU estate governable enough to sell or allocate as infrastructure, not just powerful enough to run a demo.
The bottleneck is many small claims on expensive devices
Agent workloads are different from classic batch training. A training job may reserve eight GPUs for several days. It is visible, scheduled, and relatively easy to attribute. Commerce agents are messier. They may use a small language model for routine classification, a larger model for exception handling, an embedding model for catalogue search, and a vision model for product images or receipt capture. Many calls are short. Some are latency-sensitive. Some run inside business hours. Some run at night against procurement backlogs.
In a GCC commerce platform serving more than 1,000 businesses, the tenant map can be layered. The platform is one customer of the GPU operator. Under it are merchants, suppliers, branches, and business functions. If the operator only meters at the cluster or node level, the platform still has no clean way to allocate cost internally. If the operator meters only monthly GPU allocation, short inference bursts get averaged into a number nobody trusts.
This becomes acute in small estates because the slack is limited. A rack with 16 or 32 GPUs is large enough to carry meaningful revenue, but small enough that two bad scheduling decisions matter. Reserving whole GPUs for low-duty-cycle agents wastes capacity. Overcommitting them without controls causes latency spikes. Mixing VM tenants, Kubernetes tenants, and bare-metal jobs without a single policy layer makes incident response slow.
The applied bottleneck has five parts:
- Partitioning: splitting GPUs safely across many small inference services where supported, using mechanisms such as MIG, time-slicing, or vendor-equivalent partitioning.
- Tenancy: giving each customer or internal business unit a bounded environment, whether that is Kubernetes, VMs, or bare metal.
- Metering: recording GPU-hours, partition-hours, CPU, memory, storage, and network usage at the tenant and workload level.
- Quotas: preventing one tenant from consuming the whole fleet during a campaign, catalogue rebuild, or runaway agent loop.
- Sovereignty: keeping data, logs, models, and billing records inside the operator’s chosen jurisdiction and operating model.
COFE Tech’s funding event matters because it shows that AI commerce infrastructure in the Gulf is moving from pilots to operating platforms. When the application layer matures, the cluster layer has to mature with it.
Why quarter-rack economics are unforgiving
Consider a small operator with 16 accelerators in a quarter-rack deployment. The estate is hardware-agnostic in principle: the same operating questions apply whether the fleet is NVIDIA, AMD, or mixed CPU and GPU nodes. Assume each accelerator is available 24 hours a day for 30 days.
Total monthly GPU-hour capacity is:
16 GPUs × 24 hours × 30 days = 11,520 GPU-hours
Now assume the operator’s all-in monthly cost for the cluster is $55,000. That figure includes depreciation or lease cost, facility allocation, power, cooling, support, spares, software operations, and staff time. The cost per available GPU-hour is:
$55,000 ÷ 11,520 = $4.77 per available GPU-hour
But available hours are not the same as billable or allocated hours. If the cluster is run manually and achieves only 22% billable utilisation, it sells or allocates:
11,520 × 22% = 2,534 GPU-hours
The effective cost per billable GPU-hour becomes:
$55,000 ÷ 2,534 = $21.70
That number is difficult to recover from commerce inference tenants. Many agent tasks are small and intermittent; they will not accept pricing built around idle hardware. If the operator uses partitioning, scheduling policy, and tenant-level metering to reach 62% billable utilisation, the same cluster produces:
11,520 × 62% = 7,142 GPU-hours
The effective cost per billable GPU-hour falls to:
$55,000 ÷ 7,142 = $7.70
If the internal or external chargeback rate is $11 per metered GPU-hour equivalent, monthly chargeback is:
7,142 × $11 = $78,562
That leaves $23,562 above the assumed monthly cost before corporate overhead and taxes. On a facility allocation of 22 kW for the quarter-rack footprint, the planning revenue per megawatt is:
$78,562 × 12 ÷ 0.022 MW = $42.85 million per MW-year
This is not a benchmark and not a promise. It is the arithmetic that operators should force themselves to do. Revenue per megawatt is not improved by buying more hardware and leaving it idle. It improves when the estate can safely host more paying work per watt, with records that tenants and finance teams can reconcile.
| Operating mode | Billable utilisation | Billable GPU-hours/month | Effective cost per billable GPU-hour | Chargeback at $11/GPU-hour |
|---|---|---|---|---|
| Manual allocation | 22% | 2,534 | $21.70 | $27,874 |
| Orchestrated sharing | 62% | 7,142 | $7.70 | $78,562 |
For GCC operators, this calculation also has a sovereignty dimension. If the data must remain in-country or within a defined sovereign operating boundary, the answer cannot simply be to burst every workload to an overseas region. The local estate has to carry more utilisation without giving up policy control.
What ClastIQ changes in the operating model
ClastIQ is not a model layer. It is an orchestration and operating layer for people who own the hardware. The platform combines bare-metal provisioning through MAAS and Juju, Kubernetes and VM tenancy on the same fleet, GPU partitioning, Ceph storage, metering, quota engineering, and air-gap capable deployment. For an operator serving agentic commerce workloads, this changes the estate from a collection of servers into a governed supply of compute.
The first change is reproducible provisioning. Small clusters often start with heroic manual work: a few nodes installed by hand, one Kubernetes cluster, some scripts, and a GPU operator added later. That may be acceptable for a proof of concept. It is not acceptable when tenants expect onboarding, isolation, upgrades, and incident recovery. Bare-metal provisioning gives the operator a known baseline for firmware, OS images, network roles, and node classes.
The second change is mixed tenancy. Agentic commerce platforms may not all arrive as containers. Some teams want Kubernetes namespaces and service accounts. Some want VMs for legacy procurement systems, databases, or controlled middleware. Some need bare-metal access for model serving stacks with strict performance requirements. A small estate should not split into three disconnected islands. The operator needs one view of capacity and policy across those tenancy types.
The third change is GPU sharing. Where hardware supports hard partitioning, a GPU can be divided into smaller slices suitable for inference. Where time-slicing is the better fit, workloads can share a device under policy. Hardware-agnostic operation matters because GCC and MENA estates are often mixed: nodes may be bought across procurement cycles, sourced from different vendors, or repurposed from earlier AI initiatives. The operator should expose capacity classes rather than force every tenant to understand the physical inventory.
A simplified policy might look like this:
# Example intent, not a universal command set
clastiq quota set tenant-cofe-procurement \
--gpu-class inference-small=48-partition-hours/day \
--gpu-class inference-large=8-gpu-hours/day \
--cpu=320-vcpu-hours/day \
--storage=12TiB \
--max-burst=150% \
--chargeback-code=GCC-COMMERCE-AI
clastiq meter export \
--tenant tenant-cofe-procurement \
--from 2026-09-01 \
--to 2026-09-30 \
--format csv
The exact interface is less important than the operating principle: quota and metering must be first-class objects. If agent workloads are allowed to run without bounded resource claims, the operator will eventually discover usage through a power bill, a latency incident, or a finance dispute.
Metering has to follow the business shape
For commerce infrastructure, the tenant is not always the legal customer. An AI procurement platform may want usage split by merchant, supplier network, country, feature, or cost centre. The GPU operator does not have to understand every commercial contract, but it must emit accurate enough records for the platform owner to map usage downstream.
A practical metering record should include tenant ID, namespace or VM, workload identity, accelerator class, partition size where applicable, start time, stop time, average utilisation, memory allocation, storage volume, and chargeback tag. For time-sliced devices, the operator needs a defensible equivalent unit, such as partition-hours or weighted GPU-hour equivalents. For persistent agents, idle reservations should also be visible. A tenant that reserves capacity all day but uses it for 40 minutes still consumes an opportunity cost.
This is where small estates often leak money. They measure node uptime and monthly invoices, but not the unit economics between them. The cluster appears busy because dashboards show pods and GPU memory allocations. Finance sees poor recovery because usage cannot be converted into accountable chargeback. Tenants complain because they cannot see why one month costs more than another.
A governed platform fixes this by making metering operational, not retrospective. Quotas stop runaway consumption before it becomes a dispute. Policy defines which tenants can burst and which cannot. Metering exports feed invoices, internal allocation, or showback dashboards. The same records support capacity planning: if small inference partitions are saturated while large training devices sit idle, the next procurement round should reflect that.
Storage and data locality are part of the GPU service
Agentic commerce workloads are not only GPU calls. They carry catalogues, embeddings, product images, invoices, supplier documents, chat transcripts, audit logs, and model artefacts. In the GCC, some of this data may be subject to internal sovereignty policy, sector rules, customer commitments, or government procurement requirements. Even when a workload is not legally restricted, customers may prefer in-country operation for latency, governance, or procurement reasons.
Ceph-backed storage is useful in this context because it gives the operator a way to provide shared, resilient storage services across tenants without tying each workload to local disks on a single node. A Kubernetes inference service may need access to model weights and vector indexes. A VM tenant may need block storage for a procurement database. A batch job may need object-style storage for document processing. The storage layer must be quota-controlled and metered alongside compute.
This also affects incident handling. If a GPU node fails, the operator needs to know whether workloads can be rescheduled and whether data is available elsewhere. If an upgrade is required, tenants need maintenance windows and migration paths. Small clusters do not have infinite redundancy, so the orchestration layer must be explicit about failure domains, storage placement, and tenant priority.
Power is a product constraint, not a facilities footnote
In Gulf data centres, power and cooling are strategic inputs. AI demand is rising while operators also face facility limits, procurement lead times, and national efficiency goals. For a quarter rack to a few racks, the binding constraint may be the power envelope before it is the floor space.
Agentic inference can help if scheduled correctly. Many commerce tasks are elastic. Catalogue enrichment, supplier matching, invoice extraction, and report generation can move away from peak hours. Customer-facing agents and checkout-related services cannot. The operator should classify workloads by latency requirement and schedule accordingly.
That classification allows a small estate to run closer to its economic limit without running blind. Latency-sensitive services get protected quota. Background agents use lower-priority queues or cheaper partitions. Training or fine-tuning jobs run when power and interactive demand allow. If the operator has tenant-level metering, it can show customers the cost difference between reserved capacity, burst capacity, and best-effort processing.
This is where revenue per megawatt becomes operational. It is not a slogan. It is the result of policy: which jobs run, when they run, how they are partitioned, and whether tenants pay for the capacity they reserve.
GCC relevance: sovereign commerce clouds will be smaller than hyperscalers
The GCC is not a single infrastructure market, but the pattern is common across the region. Governments and large enterprises want AI capability near their data. Local platforms want procurement in local currency, local support, and contracts aligned with regional business practice. Operators want to monetise facilities without waiting to become hyperscalers.
Recent regional funding across AI, fintech, tax automation, and commerce points to more application teams building AI-native workflows. COFE Tech’s pre-IPO round is one example. HeyBreez, Fasset, Cobi, and Tax Star point to a broader pipeline of startups and scaleups that will consume inference, embeddings, document processing, and automation. Not all of them will buy dedicated clusters. Many will need governed access to local compute.
That creates an opening for small and mid-size GPU operators, but only if they can present themselves as infrastructure, not as a pile of accelerators. A tenant should be able to ask for a sovereign inference environment, a quota, a storage allocation, a support path, and a monthly usage report. The operator should be able to answer without rebuilding the estate each time.
ClastIQ’s role is to make that repeatable on the operator’s own hardware. It does not require the operator to standardise on one accelerator vendor or one tenancy model. It gives the estate a control plane for provisioning, partitioning, tenancy, metering, quotas, storage, and deployment constraints, including air-gapped or sovereign environments where required.
What to do this week
- Build a tenant map for agent workloads. List platforms, merchants, departments, namespaces, VMs, and chargeback codes before new inference services arrive.
- Calculate current billable utilisation. Use available GPU-hours, allocated GPU-hours, and paid or internally charged GPU-hours. Do not rely only on dashboard activity.
- Define GPU capacity classes. Separate small inference partitions, full-device inference, batch processing, and training so tenants stop requesting raw hardware by hostname.
- Put quotas in writing. Set daily or monthly limits, burst rules, and priority classes for each tenant before onboarding commerce agents.
- Connect metering to finance. Export usage by tenant, workload, accelerator class, and storage allocation, then test whether finance can reproduce the invoice.
- Review sovereignty and recovery. Confirm where data, logs, model artefacts, and metering records live, and test rescheduling for at least one failed GPU node.
ClastIQ runs this on the operator’s own hardware — request a demo.