Introducing QCentroid Missions: From Business Goal to Production Decision

A new goal-driven capability in QCentroid QuantumOps lets teams start with a measurable business objective, evolve their current solver across classical, quantum-inspired and quantum approaches, and return with the evidence needed to decide what belongs in production.

Today at NVIDIA GTC Berlin, we are introducing QCentroid Missions, a new way to run the QuantumOps cycle. A Mission does not start by asking which quantum algorithm you want to try. It starts with a much simpler question: What are you trying to improve? That might mean reducing execution time by 10%, improving a business metric by five points, finding a feasible solution at a scale where the current solver struggles, or lowering computational cost without reducing solution quality.

Once that objective is clear, the team defines the boundaries: how much time and compute can be used, which data and repositories are allowed, which execution backends can be considered, and what evidence must exist before a result can be accepted. From there, the expert AI agents in QuantumOps run the experimentation cycle. They establish the baseline, investigate possible solver evolutions, implement and benchmark them, iterate on the results, validate the evidence and return a recommendation.

That recommendation may involve a better classical solver, a quantum-inspired approach, or a hybrid or quantum implementation. And sometimes the evidence will show that the current classical approach should stay exactly where it is. That is also a successful Mission.

The real bottleneck: turning experiments into production decisions

Enterprise quantum computing has spent years focused on access: access to hardware, algorithms, simulators and specialised expertise. Those things still matter, but they no longer address the hardest question an organisation ultimately has to answer: should we change something that already works?

Before a new solver can move anywhere near production, a team needs much more than a promising experiment. It needs a baseline it trusts, comparable implementations, reproducible benchmarks, clear success criteria, visibility into cost and enough validation for technical, business and risk stakeholders to reach a defensible conclusion. This is where many proofs of concept stall: not because an experiment cannot be run, but because turning an experiment into a decision is a much larger piece of work.

QuantumOps was created to make that process repeatable. In our earlier work on the QuantumOps framework and NVIDIA CUDA-Q, we described a lifecycle in which experiments become versioned, comparable and reusable rather than isolated proofs of concept. We then introduced the harness for expert quantum agents, adding specialised agents to the different stages of that lifecycle while keeping people responsible for initiating each step and approving its output.

With Missions, the unit of work changes again. Instead of asking QuantumOps to perform the next step, you give it the outcome you want to achieve.

What is a Mission?

A Mission combines three things:

A goal: the measurable business or technical outcome that matters

Limits: defining the boundaries within which QuantumOps can operate;

And validation gates: defining what must be checked and where human approval is required.

The limits can include time, compute budget, GPU hours, repositories, dependencies, data restrictions, permitted backends and the number of iterations the agents are allowed to run. The validation gates can require, for example, approval of the problem definition before implementation begins, verification that all candidate solvers have been compared against a fair baseline, reproducible reruns before a claim is accepted, or final human approval before results are published.

Within those boundaries, the expert agents can run the complete experimentation cycle. They examine the existing solver, establish a baseline, investigate relevant approaches and literature, design candidate solutions, implement different solver families, execute benchmarks, diagnose failures, iterate and validate the final comparison. The team still decides the destination and the rules; the agents do the work along the way.

Start from what is already working

A Mission does not start from the assumption that the answer should be quantum. It starts from the solver you have today. That might be an optimisation model that has been running in production for years, a Monte Carlo workflow, a routing heuristic, a machine-learning pipeline or an allocation algorithm. Whatever it is, that existing solution becomes the baseline against which every alternative has to earn its place.

In practice, the journey of a Mission looks like this:

Current solver → business objective → candidate evolutions → controlled experimentation → evidence → production decision.

From there, a Mission can investigate an improved classical approach, quantum-inspired methods, hybrid architectures or quantum implementations. There is no requirement to move through that sequence in a particular direction, or to reach quantum hardware at all. The objective is not to prove quantum advantage. The objective is to find the best computational approach for the business goal under the agreed constraints.

This is the same principle we described when we introduced our enterprise hybrid application engineering approach: start from the classical system, decide explicitly where a new computational component belongs and let the evidence determine the architecture. Missions turn that engineering principle into an executable workflow.

A practical example: improving collateral allocation

Consider a treasury team allocating collateral inventory across counterparty margin calls. The organisation already has a solver, so the useful question is not “Can we formulate collateral allocation as a quantum optimisation problem?” The useful question is: can we improve the current solver at the scale we care about, within the constraints under which the business actually operates?

For one of our initial Missions, the target was a collateral-allocation problem with 150 assets and 20 counterparties. The Mission started from the existing problem definition and business constraints and established a common evaluation framework so that every candidate solution would be judged on the same basis.

From there, the agents developed and compared several solver paths, including an exact optimisation approach, quantum-inspired annealing and a QAOA-based approach, alongside the classical baseline. The important point was not simply that multiple solvers were executed. The Mission benchmarked them across problem sizes, identified performance and dependency issues, modified the implementations and reran the experiments over several iterations.

At the largest problem size, the time-limited exact solver had not produced a feasible incumbent, while the quantum-inspired and QAOA approaches both produced feasible allocations with objective values within 0.05% of one another.

That result does not mean “quantum won.” It means something much more useful: the team now has evidence about how different solver paths behave at the scale that matters and can decide which of them deserves further investment or production consideration.

That is what a Mission is designed to produce.

Evidence matters more than good news

Running more experiments faster only creates value if the evidence behind them can be trusted. That is why validation is part of a Mission itself rather than something added after the experiment has finished.

In another Mission, focused on long-term risk modelling, one of the strongest initially reported improvements turned out to be overstated. The validation layer challenged the result, independently recomputed the comparison and revised the reported improvement downward. The corrected result, 6.2× sampling efficiency at equal error for the quantum-inspired sampling method, is the number we use.

We consider that behaviour fundamental to the product. A system that only produces favourable results cannot support serious technology decisions. A system designed to challenge its own evidence can. The purpose of a Mission is not to make quantum look good; it is to make the resulting decision defensible.

Human control is part of the architecture

Goal-driven does not mean unconstrained. Before a Mission runs, the team defines what it is allowed to do. A Mission might have a maximum compute budget, a fixed number of GPU hours, access only to specific repositories, permission to use synthetic but not production data, or a requirement to remain simulation-only unless a later gate explicitly authorises QPU execution.

The team also decides where human approval is required. A Mission may stop after the initial problem definition so the team can confirm what is actually being optimised. It can stop again before implementation so the proposed solver strategy can be reviewed. Final results can remain pending until the validation and publication gates have been cleared.

This creates a different relationship between people and agents. People no longer need to manually drive every individual experiment, but they retain control over what is being attempted, what resources can be consumed and what counts as proof.

NVIDIA CUDA-Q: The compute layer behind a Mission

Once a Mission reaches experimentation, compute becomes part of the decision. For circuit-based approaches, QuantumOps uses NVIDIA accelerated computing and NVIDIA CUDA-Q for accelerated simulation through QCentroid Launchpad. As we described when we first introduced CUDA-Q into the QuantumOps experimentation lifecycle, the aim is not simply to make an individual circuit run faster, but to make accelerated quantum simulation part of a repeatable hybrid experimentation process.

Missions extend that idea by placing GPU-simulated quantum approaches inside the same lifecycle used for classical and quantum-inspired methods, with common benchmarking, provenance and cost tracking. When the evidence justifies execution on quantum hardware, a Mission can include a gated QPU step, while QuantumOps remains QPU-agnostic across the providers connected to the platform.

The architectural principle is simple: classical computing, GPU simulation, quantum-inspired methods and quantum hardware should not live in separate experimentation silos. They are different computational resources available to the same application engineering process. A Mission determines when each is worth using.

From more experiments to better decisions

Quantum teams are typically small, while the queue of questions coming from the business is not. The answer cannot be to turn every promising use case into another bespoke proof of concept that a specialist team has to manually drive from beginning to end.

A risk team should be able to ask whether its current sampling workflow can be improved. A treasury team should be able to ask whether a different optimisation approach performs better at the scale it cares about. A logistics team should be able to ask whether route computation time can be reduced without sacrificing solution quality. None of those teams should need to decide in advance whether the answer is classical, quantum-inspired or quantum.

They should define the outcome. QuantumOps should investigate the alternatives. And the evidence should decide.

A Mission does not end with an experiment. It ends with a decision.

That is QCentroid Missions: from business goal to production decision.