How QCentroid QuantumOps uses expert AI agents and NVIDIA CUDA-Q to start from proven classical baselines, design evidence-driven hybrid experiments, and recommend where —and whether— quantum computing should become part of an enterprise application.
Beyond algorithm selection
For years, much of the conversation around enterprise quantum computing has focused on algorithms: find a relevant business problem, identify a quantum algorithm that could address it, run it on a simulator or quantum processor, and compare the results.
That is an important first step, but it is not how most enterprise applications are actually built. Real applications are heterogeneous systems. They combine data processing, machine learning, optimization, simulation and business logic, already running across CPUs, GPUs and distributed infrastructure. Introducing quantum computing into those systems is therefore rarely a question of replacing an entire classical application with a quantum one.
The more useful question is where, if anywhere, should quantum computing sit inside an application that already works? This shifts the focus from quantum algorithm selection to hybrid application engineering. The objective is no longer simply to demonstrate that a quantum algorithm can solve a problem. It is to determine experimentally whether a quantum component contributes value, where it should be introduced, how much of the application should become quantum, and which computational resource should execute it.
In many cases, particularly in the near term, the resulting architecture will probably be hybrid. In others, continued experimentation may be justified while waiting for more capable quantum hardware. And sometimes the evidence will simply say keep it classical for now. All of these are valid outcomes.
This is the next stage of the QuantumOps approach described in our previous article. Once a classical baseline and a candidate computational problem exist, the challenge becomes engineering the boundary between classical and quantum computing—and accumulating enough evidence to make that boundary defensible.

Start from what already works
Hybrid quantum engineering should begin with a classical baseline, not with a quantum algorithm. The baseline establishes what an alternative architecture must compete with in terms of output quality, computational cost, execution time, scalability and operational requirements. More importantly, it provides a working application that can be progressively modified.
Rather than asking how to build a quantum version of an application, the engineering team can ask which parts of the existing application are actually worth changing. This distinction becomes particularly relevant outside optimization, where there may not be a single obvious solver or computational component to replace.
The QATALIZE project, currently being implemented by QCentroid and Gradiant using CESGA’s HPC and quantum infrastructure, provides a useful example. One of its objectives is to explore a generative AI approach to materials discovery using a conditional Generative Adversarial Network, or cGAN.
Materials discovery involves searching extremely large chemical spaces. In the catalyst use case, candidate materials can ultimately be evaluated using Density Functional Theory (DFT), but those calculations are computationally expensive. The generative model acts as a pre-screening mechanism: it learns from existing data, generates promising new candidates, and reserves expensive downstream evaluation for a much smaller subset. The same architecture can also target materials for CO₂ capture by changing the training data, chemical representation and conditioning targets.
The interesting question for hybrid computing is therefore not simply whether this GAN can be made “quantum”. It is where quantum computation should intervene inside it.
Hybrid engineering creates three levels of decision
What initially looks like a single decision—whether to use quantum computing—quickly separates into several architectural questions. In practice, there are at least three levels that must be navigated systematically.
Level 1 — Which application component?
The first decision is where quantum computing could plausibly contribute to the overall application. An industrial workflow may include data preparation, optimization, simulation, machine learning, inference and post-processing, while only a subset of those components may justify quantum experimentation.
In the QATALIZE materials-discovery example, the candidate component is the generative model used to navigate the chemical search space. Identifying that component, however, does not define the hybrid architecture.
Level 2 — Where inside that component?
Finding a promising component still does not tell us where its classical–quantum boundary should be. A GAN contains a Generator and a Discriminator, each composed of multiple transformations and layers. In the architecture being explored in this project, quantum experimentation is focused on the Generator. The Generator is the initial focus because it directly controls the learned representation used to explore the candidate space, making changes in its latent transformation measurable through downstream candidate-quality metrics.
The engineering question becomes much more granular: at which point inside the Generator should a quantum transformation be introduced? A parametrized quantum circuit (PQC) could operate close to the latent input, after an initial classical transformation, inside a compressed bottleneck, later in the network, or potentially at several points.
The architecture is therefore no longer simply classical versus quantum. It becomes a spectrum of possible hybrid designs.
Level 3 — On which computational resource?
Once a hybrid architecture has been defined, a third decision remains. The quantum component may initially run through GPU-accelerated simulation, then under simulated noise, and eventually—if the evidence justifies it—on a QPU. Different QPUs may themselves become alternative experimental targets.
These three decisions are related, but they are not interchangeable. Together, they define an increasingly large design space:
What to make quantum → where to make it quantum → where to execute it.
Hybrid application engineering therefore quickly stops being a single quantum experiment and becomes an experiment management and decision problem.

Finding the classical–quantum boundary inside a GAN
The QGAN experiment makes this design problem particularly visible. The classical baseline can be represented as a conventional Generator that transforms noise and conditioning information into a candidate material, while a classical Discriminator evaluates generated samples during training.
The conditioning signals describe what the researcher is looking for—for example, a target adsorbate and an adsorption-energy range—while the Generator learns to propose candidates consistent with those conditions.
Starting from that baseline, several alternative Generator architectures can be explored. A quantum transformation close to the latent space introduces a PQC early in the Generator, allowing the quantum component to operate on an initial representation of the latent variables. A quantum bottleneck first uses classical layers to transform or compress that representation, passes the resulting compact state through a PQC, and then expands it again through classical layers. A later quantum transformation allows classical computation to build a richer intermediate representation before applying the quantum transformation. More complex designs can introduce several quantum layers at different positions.
The architecture has deliberately been designed to support this flexibility: classical and quantum layers can be interleaved, while the number, depth and position of quantum components remain configurable.
Each architectural alternative then introduces further experimental parameters, including the number of qubits, circuit depth, encoding strategy, parametrized ansatz, training configuration and execution backend. The search space cannot be expanded arbitrarily: increasing qubit count or circuit depth may introduce trainability, gradient-estimation and sampling costs that must themselves become part of the experimental evidence. Hybrid application engineering becomes a search problem of its own. The question is no longer simply which quantum algorithm to use, but where quantum computation belongs within the application architecture.
To make these comparisons meaningful, the experimental design must also control for factors that could otherwise confound the results. Classical and hybrid architectures should be evaluated using consistent datasets, conditioning targets, training budgets and evaluation procedures, with repeated runs across controlled random seeds to account for training variability. Where architectures differ in model capacity, factors such as trainable parameter count, circuit evaluations and computational resources should also be tracked. The objective is not simply to find the best-performing configuration, but to determine whether an observed improvement can reasonably be attributed to the architectural change being tested.

Why systematic experimentation matters
Even a deliberately simplified experiment already creates multiple evaluation paths:
| Generator architecture | Classical/GPU training | GPU quantum simulation | Noise-aware simulation | QPU experiment |
| Classical baseline | ✓ | — | — | — |
| Early quantum layer | ✓ | ✓ | ✓ | Selected |
| Quantum bottleneck | ✓ | ✓ | ✓ | Selected |
| Late quantum layer | ✓ | ✓ | ✓ | Selected |
| Multiple PQCs | ✓ | ✓ | ✓ | Selected |
Legend: ✓ indicates a normal evaluation stage for that architecture; — means that the stage does not apply to the classical baseline; “Selected” means that QPU execution is not performed automatically for every configuration. Only architectures that produce sufficient evidence in earlier simulation and benchmarking stages are shortlisted for hardware validation.
And this matrix is still highly simplified. A single row may contain multiple circuit configurations, training parameters, random seeds, problem sizes and dataset variants. Experiments may need to be repeated to measure training variability, while each execution target introduces additional constraints and measurements.
The challenge is therefore not merely running a quantum circuit. It is maintaining enough structure across all those experiments to determine whether moving the PQC improved the generated candidates, whether that improvement remains under more realistic execution conditions, what additional computational cost it introduces, whether the result is reproducible and whether the architecture remains technically feasible as the problem scales.
Without systematic experimentation, it is relatively easy to produce an interesting quantum result while still lacking enough evidence to support an application decision.

CUDA-Q makes the execution target an experimental variable
This is where NVIDIA CUDA-Q becomes an important enabling technology. CUDA-Q provides a unified programming model for hybrid applications in which CPUs, GPUs and QPUs work together, and its backend model includes CPU and GPU simulators as well as supported quantum hardware targets.
For hybrid neural-network workloads, CUDA-Q also provides an integration pattern with PyTorch, allowing classical neural processing and quantum components to coexist inside the same workflow. The architectural consequence is more important than any individual API: changing the computational target does not necessarily require redesigning the overall application architecture.
Without a common execution layer, moving an experiment from one target to another can easily become an integration exercise involving different SDKs, interfaces and infrastructure. That friction makes systematic comparison harder because part of the engineering effort is spent changing technology rather than testing the hypothesis.
With CUDA-Q, a promising hybrid Generator can instead be evaluated progressively across GPU-accelerated quantum simulation, noise-aware experimentation and selected QPU execution, with evidence from each stage feeding back into architecture and circuit design, while preserving the same underlying application hypothesis. CUDA-Q provides GPU-based noisy simulation capabilities as well as multiple simulation strategies designed for different circuit characteristics and scales.
Different backends do not become equivalent. Hardware constraints, topology, noise, circuit characteristics and execution behavior still matter and need to be measured. The important difference is that these characteristics can become experimental variables rather than architectural barriers.
The less engineering effort a team spends switching execution technologies, the more effort it can spend determining whether the alternative architecture is actually better.

A real heterogeneous environment: HPC and QPU
The QATALIZE infrastructure provides a natural environment in which to apply this methodology. CESGA operates conventional HPC capabilities alongside Qmio, a quantum-computing research environment that includes a 32-qubit superconducting QPU and HPC resources connected to the quantum infrastructure.
This matters because hybrid applications are inherently heterogeneous. Dataset preparation, classical neural-network training and large experimental campaigns remain natural HPC/GPU workloads. Quantum components can be simulated on accelerated classical infrastructure and, where the evidence justifies doing so, selected configurations can advance to quantum hardware.
The objective is not to migrate the workload from HPC to quantum computing. It is to determine how classical, accelerated and quantum resources should cooperate within the same application. That is a fundamentally different adoption model.
From execution to evidence: the role of QuantumOps
CUDA-Q reduces the friction involved in constructing and executing heterogeneous experiments, but easier execution creates another challenge: more architectures and configurations are now feasible to explore.
As circuit parameters, datasets, Generator designs and execution targets multiply, the engineering team needs to preserve the relationship between the hypothesis being tested, the configuration executed and the evidence produced. This is the role of QCentroid QuantumOps.
QuantumOps structures the experimentation cycle around the computational infrastructure, managing alternative configurations, executions, results and benchmarking information so that experiments become comparable rather than isolated runs. Expert AI agents operate over this experimental context to assist particularly across execution, benchmarking and recommendation. Their role is not to make the architectural decision autonomously, but to help teams navigate the design space, identify meaningful comparisons, detect weak experimental branches, interpret accumulated evidence and suggest which configurations deserve further investigation. The final decision remains with the user.
In this sense, CUDA-Q and QuantumOps address different but complementary layers of the problem: NVIDIA CUDA-Q makes heterogeneous computing programmable, QCentroid QuantumOps makes heterogeneous architectures experimentally comparable and evidence-driven.

From experimental evidence to architectural recommendation
For the QGAN experiment, infrastructure metrics such as runtime and resource consumption are necessary but not sufficient. The central question is whether modifying the Generator improves its ability to propose useful material candidates.
Because the exact project evaluation framework will evolve with the implementation, a practical starting point is to focus on three complementary metric families that are widely aligned with evaluation practices in generative chemistry and materials discovery.
The first is candidate validity rate: the percentage of generated outputs that satisfy the chemical and structural constraints required by the representation. Validity is a standard dimension in generative molecular benchmarks, where the objective is to distinguish models that generate syntactically or chemically meaningful candidates from those producing unusable outputs. For QATALIZE, the exact validity rules can be adapted to the catalyst or MOF representation being generated.
The second is novelty and diversity. A generative model that repeatedly reproduces known candidates may achieve high validity while contributing little to materials discovery. Novelty measures whether generated candidates differ from the training set, while diversity or uniqueness captures whether the model is exploring different regions of the design space rather than repeatedly generating near-identical candidates. These dimensions are also commonly included in molecular generation benchmarks.
The third—and ultimately the most application-oriented—is a DFT-validated target hit rate: among the candidates selected for downstream validation, what proportion actually satisfies the target physical criteria, such as falling within the desired adsorption-energy window? Materials-generation research increasingly evaluates generated structures against target properties and validates promising candidates using first-principles calculations or experimental measurements rather than relying exclusively on ML-level metrics. For this use case, improving that hit rate would directly support the original objective: reducing the number of expensive evaluations required to find promising materials.
These three measures should be interpreted together with engineering evidence such as training stability, execution time, computational cost, required qubits, circuit depth and sensitivity to noise. A hybrid Generator that produces a marginal improvement in candidate quality at dramatically higher computational cost may not justify its complexity, while a configuration that is promising under ideal simulation but highly noise-sensitive may be better classified as a future candidate than as an architecture ready for QPU execution today. For an enterprise architecture, experimental performance must ultimately be evaluated alongside operational criteria such as integration complexity, reproducibility, reliability, security, deployment constraints and total computational cost.
At the end of the cycle, QuantumOps and its expert agents can help consolidate the experimental evidence into an architectural recommendation. The evidence may show that the classical Generator remains the best option; identify a particular quantum bottleneck as promising enough for continued simulation; show that an architecture has potential but should wait for more capable or lower-noise hardware; or justify advancing a specific configuration to QPU validation.
The important point is that none of these outcomes is predetermined. The purpose of the process is not to find quantum advantage. It is to find the right computational architecture. In that context, keep it classical for now is not a failed quantum experiment but an evidence-based engineering decision.
When quantum does become part of the recommended architecture, the team should be able to explain not merely that a quantum experiment worked, but why that component was selected, why the classical–quantum boundary was placed there, what alternatives were evaluated, what evidence supports the decision and which computational resources are appropriate for executing it.
Engineering the boundary
Enterprise quantum adoption is unlikely to happen through a sudden transition from classical applications to quantum applications. It is more likely to emerge progressively inside heterogeneous systems, with CPUs, GPUs and QPUs performing the parts of a workload for which they are best suited.
The real engineering challenge is therefore not choosing between classical and quantum computing. It is finding the right computational boundary between them.
The QGAN materials-discovery project illustrates that challenge particularly well. Even after identifying the Generator as the candidate for quantum experimentation, multiple architectural questions remain: where to introduce the PQC, how much of the network to make quantum, how to configure it, how to execute it and how to determine whether the change produced meaningful value.
NVIDIA CUDA-Q provides the heterogeneous programming and execution foundation that makes this type of exploration practical. QCentroid QuantumOps provides the experimental framework around it: structured execution, benchmarking, evidence accumulation and AI-assisted recommendations.
Together, these capabilities shift the conversation beyond the quantum algorithm: from asking “Can we run this problem on a quantum computer?” to asking “Where should quantum computing participate in this application—and what evidence supports putting it there?”




























