Oracle and Classiq Bring Quantum AI Agen
Introduction
Quantum software developers need an efficient way to build applications and the computing capacity to test them at scale. In a recent proof of concept, Oracle and Classiq connected those two pieces. Classiq used its quantum expert AI agent as the starting point for generating a quantum portfolio optimization application, and Oracle GPU infrastructure provided the compute capacity for a demanding 36-qubit simulation.
The goal was to demonstrate a practical end-to-end quantum software engineering workflow: start from a simple AI prompt, generate a structured Jupyter notebook, synthesize a nontrivial quantum circuit, and execute the simulation on NVIDIA GPUs via Oracle Cloud Infrastructure (OCI). With only light parameter tuning, the workflow produced a feasible portfolio allocation with a strong modeled objective value and a clear path for further refinement.
Why OCI matters for quantum simulation
Simulation is a critical part of quantum application development. It enables teams to validate models, debug circuits, compare algorithm choices, and prepare workloads before running on quantum hardware. But compute requirements grow quickly as circuits become larger and deeper, making high-performance classical infrastructure an important part of the quantum stack.
The Classiq platform supports quantum simulations with as many as 29 qubits in its standard flow. In this proof of concept, Oracle and Classiq pushed the workflow to 36 qubits by routing Classiq-generated circuits to an NVIDIA DGXA100 node hosted on OCI. The simulation ran across the node’s eight A100 GPUs and took about five hours.
The memory footprint shows why this kind of infrastructure matters. A 36-qubit state vector contains 68.7 billion complex amplitudes. Assuming single precision, where each complex amplitude is stored as two 32-bit floating-point numbers, the raw statevector alone requires about 512 GiB of GPU device memory before simulator overhead. That scale requires a distributed multi-GPU setup with enough aggregate GPU memory to hold the state vector and support the simulator runtime.
From AI prompt to a working notebook in under 15 minutes
The workflow began with a natural-language prompt to Classiq’s expert AI agent. The agent, informed by context from Classiq’s library of algorithms and industry applications, generated an end-to-end Jupyter notebook for a discrete portfolio optimization problem, including problem setup, hybrid classical-quantum workflow, classical benchmark, and result analysis. This was the full prompt passed to the AI agent:
Create a Classiq quantum portfolio optimization application designed to run on Oracle's GPU supercomputing nodes:
- Build a realistic 12-asset portfolio optimization problem following the Markowitz model.
- Include expected returns, risks/covariances, allocation units, and a total budget constraint.
- Allow each asset to receive an integer allocation from 0 to 7 chunks, inclusive.
- Set the total portfolio budget to 15 chunks, meaning the allocation variables must sum to 15.
- Optimize a discrete mean-variance objective with a configurable risk-aversion parameter, converting chunk allocations to portfolio percentages before computing risk and return.
The notebook was AI-generated, but the workflow still benefited from technical review. The Classiq team inspected the generated notebook, adjusted tunable parameters, and validated execution before running the large-scale simulation. A major value was speed: a coherent prototype was created in under 15 minutes from a simple prompt, reducing boilerplate and helping the team focus on integration and modeling preferences.
A 36-qubit workflow for portfolio optimization
The application used a discrete version of a Markowitz-style portfolio optimization problem. The notebook modeled 12 correlated assets across a diversified set of sectors. Each asset could receive an integer allocation from zero to seven chunks, and the total portfolio budget was fixed at 15 chunks.
This creates eight choices for each of 12 assets, or 68.7 billion possible raw allocation combinations before applying the budget requirement. Classical optimizers can exploit structure in this kind of problem, but the search space is large enough to make it a useful demonstration for a quantum optimization workflow.
The Quantum Approximate Optimization Algorithm (QAOA) is a hybrid method: a quantum circuit samples candidate solutions, and a classical optimizer updates the circuit parameters to improve the samples. In this notebook, measured bit strings were decoded back into portfolio allocations.
The 36-qubit circuit size came directly from the encoding: each of the 12 assets had eight possible allocation levels, which required three qubits per asset. The notebook used three QAOA layers. The Classiq synthesis engine searched the problem space and implemented a 36-qubit circuit with a depth of 730. Because the notebook used Classiq’s high-level algorithmic constructs, the quantum program remained readable and easy to adapt without requiring developers to work at the gate level.
Connecting Classiq circuits to Oracle GPU infrastructure
For this proof of concept, the workflow used a single NVIDIA DGX A100 node on OCI as the remote execution target, accessed over SSH. The integration used a lightweight execution-adaptation layer to submit generated circuits directly to OCI, outside the standard Classiq backend execution flow.
The adapted flow exported the Classiq circuit, bound the current QAOA parameters, uploaded the OpenQASM file and helper scripts to the OCI host, and launched the NVIDIA cuQuantum Appliance remotely inside Docker. The simulation used mpirun to distribute execution across all eight A100 GPUs.
On the Oracle side, a mounted work directory acted as a simple job store. Each job had its own inputs, scripts, logs, execution state, and result artifacts. On the Classiq side, the notebook polled the remote directory through periodic SSH commands, retrieved the result file when ready, parsed the samples, and continued the QAOA loop. From the developer perspective, the notebook remained the primary interface while Oracle infrastructure handled the compute-heavy simulation work.
What the run showed
The full 36-qubit noiseless hybrid simulation took approximately five hours, including the GPU-backed sampling calls used in the QAOA loop. The run used 16,384 shots per sampling call and 15 outer iterations of the COBYLA optimizer. The executed notebook compared the best quantum-sampled feasible allocation with a classical benchmark generated from 200,000 random feasible allocations.
We found the quantum result was a strong portfolio allocation under the modeled objective. While there was a 4.63% objective gap relative to the classical reference, the more important result was the workflow itself: Oracle GPU infrastructure enabled a simulation beyond the scale available in standard quantum development environments, while Classiq simplified the path from natural-language intent to a synthesized, executable quantum program. This combination allows organizations to scale their quantum activity and achieve meaningful results today, maintaining model portability as hardware continues to scale.
Conclusion
For aspiring quantum developers, this proof of concept demonstrates a turning point. Quantum Software Engineering is now accessible and practical. The combination of AI-assisted development (Classiq) and powerful, scalable simulation infrastructure (OCI and NVIDIA GPUs) removes significant barriers. Classiq’s Quantum Software Engineering platform offers an enterprise-grade workflow from a natural-language idea to a synthesized, complex 36-qubit circuit, while OCI provides the compute necessary to test and validate large-scale hybrid quantum-classical workflows today. This approach is an invitation for researchers and developers to inspect, extend, and accelerate their advanced quantum optimization efforts now.
Introduction
Quantum software developers need an efficient way to build applications and the computing capacity to test them at scale. In a recent proof of concept, Oracle and Classiq connected those two pieces. Classiq used its quantum expert AI agent as the starting point for generating a quantum portfolio optimization application, and Oracle GPU infrastructure provided the compute capacity for a demanding 36-qubit simulation.
The goal was to demonstrate a practical end-to-end quantum software engineering workflow: start from a simple AI prompt, generate a structured Jupyter notebook, synthesize a nontrivial quantum circuit, and execute the simulation on NVIDIA GPUs via Oracle Cloud Infrastructure (OCI). With only light parameter tuning, the workflow produced a feasible portfolio allocation with a strong modeled objective value and a clear path for further refinement.
Why OCI matters for quantum simulation
Simulation is a critical part of quantum application development. It enables teams to validate models, debug circuits, compare algorithm choices, and prepare workloads before running on quantum hardware. But compute requirements grow quickly as circuits become larger and deeper, making high-performance classical infrastructure an important part of the quantum stack.
The Classiq platform supports quantum simulations with as many as 29 qubits in its standard flow. In this proof of concept, Oracle and Classiq pushed the workflow to 36 qubits by routing Classiq-generated circuits to an NVIDIA DGXA100 node hosted on OCI. The simulation ran across the node’s eight A100 GPUs and took about five hours.
The memory footprint shows why this kind of infrastructure matters. A 36-qubit state vector contains 68.7 billion complex amplitudes. Assuming single precision, where each complex amplitude is stored as two 32-bit floating-point numbers, the raw statevector alone requires about 512 GiB of GPU device memory before simulator overhead. That scale requires a distributed multi-GPU setup with enough aggregate GPU memory to hold the state vector and support the simulator runtime.
From AI prompt to a working notebook in under 15 minutes
The workflow began with a natural-language prompt to Classiq’s expert AI agent. The agent, informed by context from Classiq’s library of algorithms and industry applications, generated an end-to-end Jupyter notebook for a discrete portfolio optimization problem, including problem setup, hybrid classical-quantum workflow, classical benchmark, and result analysis. This was the full prompt passed to the AI agent:
Create a Classiq quantum portfolio optimization application designed to run on Oracle's GPU supercomputing nodes:
- Build a realistic 12-asset portfolio optimization problem following the Markowitz model.
- Include expected returns, risks/covariances, allocation units, and a total budget constraint.
- Allow each asset to receive an integer allocation from 0 to 7 chunks, inclusive.
- Set the total portfolio budget to 15 chunks, meaning the allocation variables must sum to 15.
- Optimize a discrete mean-variance objective with a configurable risk-aversion parameter, converting chunk allocations to portfolio percentages before computing risk and return.
The notebook was AI-generated, but the workflow still benefited from technical review. The Classiq team inspected the generated notebook, adjusted tunable parameters, and validated execution before running the large-scale simulation. A major value was speed: a coherent prototype was created in under 15 minutes from a simple prompt, reducing boilerplate and helping the team focus on integration and modeling preferences.
A 36-qubit workflow for portfolio optimization
The application used a discrete version of a Markowitz-style portfolio optimization problem. The notebook modeled 12 correlated assets across a diversified set of sectors. Each asset could receive an integer allocation from zero to seven chunks, and the total portfolio budget was fixed at 15 chunks.
This creates eight choices for each of 12 assets, or 68.7 billion possible raw allocation combinations before applying the budget requirement. Classical optimizers can exploit structure in this kind of problem, but the search space is large enough to make it a useful demonstration for a quantum optimization workflow.
The Quantum Approximate Optimization Algorithm (QAOA) is a hybrid method: a quantum circuit samples candidate solutions, and a classical optimizer updates the circuit parameters to improve the samples. In this notebook, measured bit strings were decoded back into portfolio allocations.
The 36-qubit circuit size came directly from the encoding: each of the 12 assets had eight possible allocation levels, which required three qubits per asset. The notebook used three QAOA layers. The Classiq synthesis engine searched the problem space and implemented a 36-qubit circuit with a depth of 730. Because the notebook used Classiq’s high-level algorithmic constructs, the quantum program remained readable and easy to adapt without requiring developers to work at the gate level.
Connecting Classiq circuits to Oracle GPU infrastructure
For this proof of concept, the workflow used a single NVIDIA DGX A100 node on OCI as the remote execution target, accessed over SSH. The integration used a lightweight execution-adaptation layer to submit generated circuits directly to OCI, outside the standard Classiq backend execution flow.
The adapted flow exported the Classiq circuit, bound the current QAOA parameters, uploaded the OpenQASM file and helper scripts to the OCI host, and launched the NVIDIA cuQuantum Appliance remotely inside Docker. The simulation used mpirun to distribute execution across all eight A100 GPUs.
On the Oracle side, a mounted work directory acted as a simple job store. Each job had its own inputs, scripts, logs, execution state, and result artifacts. On the Classiq side, the notebook polled the remote directory through periodic SSH commands, retrieved the result file when ready, parsed the samples, and continued the QAOA loop. From the developer perspective, the notebook remained the primary interface while Oracle infrastructure handled the compute-heavy simulation work.
What the run showed
The full 36-qubit noiseless hybrid simulation took approximately five hours, including the GPU-backed sampling calls used in the QAOA loop. The run used 16,384 shots per sampling call and 15 outer iterations of the COBYLA optimizer. The executed notebook compared the best quantum-sampled feasible allocation with a classical benchmark generated from 200,000 random feasible allocations.
We found the quantum result was a strong portfolio allocation under the modeled objective. While there was a 4.63% objective gap relative to the classical reference, the more important result was the workflow itself: Oracle GPU infrastructure enabled a simulation beyond the scale available in standard quantum development environments, while Classiq simplified the path from natural-language intent to a synthesized, executable quantum program. This combination allows organizations to scale their quantum activity and achieve meaningful results today, maintaining model portability as hardware continues to scale.
Conclusion
For aspiring quantum developers, this proof of concept demonstrates a turning point. Quantum Software Engineering is now accessible and practical. The combination of AI-assisted development (Classiq) and powerful, scalable simulation infrastructure (OCI and NVIDIA GPUs) removes significant barriers. Classiq’s Quantum Software Engineering platform offers an enterprise-grade workflow from a natural-language idea to a synthesized, complex 36-qubit circuit, while OCI provides the compute necessary to test and validate large-scale hybrid quantum-classical workflows today. This approach is an invitation for researchers and developers to inspect, extend, and accelerate their advanced quantum optimization efforts now.