A weekend of coding left Riyaz Somani with a question about his own profession. Using AI to build things was becoming easier. What, then, should product management become? He took the question into conversations with other founders. Later, describing work with his technical colleagues at Kubex, he offered a small translation of executive language: “working with” is CEO speak for trying to keep up.
It is an unusually useful joke. A chief executive can make a great many things sound deliberate after they happen. Here was one admitting that the people around him were moving quickly enough to require effort. The remark brings a person into focus behind a business concerned with a rather impersonal subject: the allocation of computing resources.
Somani is Kubex’s co-founder and CEO, based in Toronto. His career reaches back beyond the current enthusiasm for AI agents, through the company’s earlier identities as Densify and Cirba. Following that career means following a question that has survived several changes of technological wardrobe. How much useful work can a business get from the infrastructure it already pays for?
Before the cloud had a bill
Before Densify, Somani was co-founder and CEO of Opensoft. The firm developed large, mission-critical systems for Fortune 1000 companies. His education at the University of Waterloo included engineering and computer science. Enterprise software was already his territory before Kubernetes acquired its place in the corporate vocabulary.
In 1999, he and Andrew Hillier co-founded Cirba. By 2006, its software was examining server consolidation and virtualization. A version called CiRBA 3.1 could detect virtual machines, distinguish physical from virtual software inventories and identify configuration differences. The customer list included Bell Mobility and Rogers Wireless. These were practical concerns for businesses with complicated estates of machines.
The product’s world sounds almost quaint now: Solaris, HP-UX, AIX, Windows, databases and management interfaces. Yet the underlying task is recognizable. Inventory the environment. Understand how its parts behave. Work out where resources can be used more effectively. Before a company can become efficient, it has to discover what it is actually running.
Even the old name had an engineer’s density. CiRBA stood for configuration item request broker architecture. It was a name with enough syllables to require its own capacity plan. The business would eventually adopt shorter names, but the complexity it was trying to manage would keep growing.
The new name arrived after the engineering
Cirba became Densify in June 2017. By the following year, the company was expanding its UK and Ireland channel through distributor DataSolutions, taking its machine-learning cloud optimization service to that market. The change of name accompanied a business addressing public cloud use, where an infrastructure decision also becomes a recurring expense.
For Somani, the institutional history contains a long stretch of operating responsibility. As Densify’s co-founder and president, he set strategic direction and oversaw overall operations, taking responsibility for both the company’s course and its day-to-day business. Today he is CEO. Hillier remains the technical co-founder beside him. The relationship connects the company’s original chapter with its present one.
On December 31, 2025, Somani published the announcement that Densify would become Kubex the following day. He explained that the platform rebuild had begun eighteen months earlier. It encompassed Kubernetes nodes, pods and containers, together with GPU and AI workloads and the infrastructure supporting them.
The rebuilt architecture included an automation controller, an agentic AI framework and a conversational interface. Kubex had first been introduced as the product brand for this work. The company then adopted the product’s name. That sequence links a visible announcement to a longer period of technical work, rather than assigning the whole transformation to New Year’s Day. The announcement preserved continuity of ownership, legal structure and customer support. The sign changed after the engineering had established the direction.
The expensive question beneath AI
Somani’s current argument about AI begins below the layer that gets most of the attention. Models improve; applications gain new abilities; hardware gets faster. He asks how effectively those applications use the expensive equipment underneath. The purchase of a GPU and the productive use of a GPU are separate events, however closely they appear on a presentation slide.
Somani has distinguished model training, which can sustain high GPU demand, from inference, where utilization can be much lower. He described shared environments involving GPUs, CPUs and memory, and argued that allocation needs active management. His warning about utilization below 20 percent was his characterization of poorly managed inference environments, rather than a measured average for every enterprise.
That distinction matters to the story. Somani is making a commercial and technical argument about an opportunity for optimization. Treating his figure as a universal industry measurement would make the argument tidier and less accurate. The practical question remains worthwhile without turning every company’s infrastructure into the same case.
The purchase of a GPU and the productive use of a GPU are separate events.
An observation at the center of this profile
His company’s partnerships show where that argument is being taken. In January 2026, Tangoe and Kubex announced an integration bringing optimization capabilities into Tangoe One Cloud. In April, Kubex described its partnership with Rafay, connecting Rafay’s orchestration and workflow management with Kubex’s resource optimization.
Somani said the team had seen Rafay’s platform in customer environments and wanted customers to be able to extend those capabilities with Kubex. It is a concrete expression of the business’s direction: resource efficiency working inside the systems enterprises already use to run their infrastructure.
Permission belongs in the machinery
There is an awkward human problem inside any offer to tune infrastructure automatically. Someone remains responsible for the application. A suggested saving can look attractive while the person responsible for availability has perfectly sensible reasons to hesitate. For a business selling automation, confidence in how a change happens is part of the product.
Kubex’s architecture describes a sequence of observing workloads, analyzing demand, deciding on optimization, acting and matching workloads to infrastructure. The company combines a deterministic machine-learning engine with automation and infrastructure matching. The scope runs from application workloads through Kubernetes components to CPU and GPU resources.
The automation engine makes the boundaries more specific. Policies determine where changes apply. Checks cover quotas, available node capacity and workload availability. In-place resizing is available on supported Kubernetes configurations; other changes can require an allowed eviction. Rollback monitoring depends on a matching rollback policy being configured. Those details put conditions around the promise of autonomy.
- Read demandObserve workload behavior
- Check policyRespect the operator’s boundaries
- Apply and monitorAct with configured safeguards
Its AI agent introduces another division of labor. The company describes language models explaining and summarizing, while the deterministic engine makes optimization decisions. People can ask questions in ordinary language and connect their preferred agent environments. The interface may become conversational; the responsibility to make a defensible resource decision still sits underneath it.
Read together, these choices explain the ambition Somani is leading. Engineers define the rules and the software takes on more routine tuning. The operator’s judgment becomes part of the system’s boundaries. For a founder whose earlier business served large enterprise systems, that is a recognizable setting for a new generation of tools.
The agent platform also describes what-if analysis and simulations, along with specialized agents for container sizing, predictive scaling, node optimization and GPU efficiency. Those are different tasks with different consequences. A conversation about them is useful only if it reaches the relevant workload and its behavior. The company’s emphasis on contextual recommendations reflects that requirement. For Somani’s business, making infrastructure easier to discuss and making it easier to operate have to develop together. Otherwise a friendlier interface merely gives a complicated system better manners.
Compatibility is another part of the proposition. Kubex describes working alongside established Kubernetes components, including Prometheus, HPA, VPA, KEDA and Karpenter, as well as GPU infrastructure tools. Its company page places trust in automation beside the goal of reducing manual tuning. This gives the business a demanding brief. It has to fit into an environment that already has its own rules, tools and people. The founder’s task is therefore partly one of continuity: introduce a different way to manage resources while respecting the systems customers have already assembled around them.
A second company, and room to learn
Kubex is one part of Somani’s working life. He is also co-founder and board chair of GoodLabs Studio, where his involvement has included investor and advisor roles. The current team includes people working across AI engineering, fraud prevention and analytics. His role places him alongside another organization concerned with building applied technology.
It also broadens the picture beyond a single executive title. There is a software company he led before Cirba, the infrastructure business that developed through several names, and a separate founding and board role. These are concrete connections between businesses and people, rather than a neat ladder in which each appointment erases the one before it.
The coding weekend is a fitting place to return. A founder can spend years helping other people manage complexity and still find his own methods changing. Somani’s public interest in new tools sits beside his long operating history. The combination gives this chapter its tension: experience with enterprise systems, and an appetite to revisit how software gets made.
The machines have changed since 1999. The vocabulary has acquired pods, agents and GPU fractions. Somani is still working close to the relationship between resources and results. It is a field in which buying more can be quite straightforward. Getting the existing machinery to earn its keep requires a longer conversation.