Paper deep dive
SQD-Agent: LLM-driven agentic framework for Quantum Chemistry workflows
Kislaya Tiwari, Anupama Ray
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 92%
Last extracted: 10/1/2026, 7:09:17 AM
Summary
The paper introduces SQD-Agent, an LLM-driven multi-agent framework designed to automate quantum chemistry workflows using Sample-Based Quantum Diagonalization (SQD). It translates natural language user intent into executable hybrid quantum-classical workflows, managing tasks such as circuit construction, hardware execution, error mitigation, and result analysis. The system aims to lower the barrier to entry for researchers by handling complex configuration, transpilation, and resource optimization automatically.
Entities (9)
Relation Signals (8)
Kislaya Tiwari â authored â SQD-Agent
confidence 95% ¡ SQD-Agent: LLM-driven agentic framework for Quantum Chemistry workflows Kislaya Tiwari
Anupama Ray â authored â SQD-Agent
confidence 95% ¡ Anupama Ray IBM Quantum, IBM Research
SQD-Agent â implements â Sample-Based Quantum Diagonalization
confidence 95% ¡ workflows for Quantum Chemistry applications where algorithms from the Sample-Based Quantum Diagonalization (SQD) family are used
SQD-Agent â uses â LLM
confidence 95% ¡ SQD Agent, an LLM-based agentic framework that translates natural-language user intent
SQD-Agent â integrates â Qiskit
confidence 90% ¡ The execution layer is built on PySCF, Qiskit, ffsim, and qiskit-addon-sqd
SQD-Agent â integrates â PySCF
confidence 90% ¡ The execution layer is built on PySCF, Qiskit, ffsim, and qiskit-addon-sqd
SQD-Agent â supports â IBM Quantum
confidence 88% ¡ Support to IBM Quantum devices is the current hardware path
SQD-Agent â provides â error mitigation
confidence 85% ¡ Key features include ... error mitigation on real quantum hardware
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Quantum algorithms and quantum hardware are advancing towards a promising paradigm for scientific applications. However, translating domain-specific problems into executable hybrid quantum-classical workflows remains a significant barrier for application researchers due to the required expertise in quantum algorithms, nuances in quantum programming, and hardware-aware system integration. At the same time, AI and primarily LLM based agents are increasingly capable of interpreting natural-language intent, reasoning over complex workflows, and translating high-level objectives into executable code and building computational pipelines. In this work, we introduce SQD Agent, an LLM-based agentic framework that translates natural-language user intent into executable workflows for Quantum Chemistry applications where algorithms from the Sample-Based Quantum Diagonalization (SQD) family are used. By automating this translation, SQD Agent reduces the level of human expertise and configuration overhead required, thereby simplifying experimentation in hybrid quantum-classical settings for application researchers new to quantum. SQD Agent adopts a modular and extensible architecture that supports seamless integration of heterogeneous quantum backends, classical solvers, and workflow components, ensuring adaptability to rapidly evolving quantum ecosystems. The framework further incorporates interactive capabilities for on-demand profiling, bottleneck analysis, resource optimization, intelligent result caching, and convergence visualization. Key features include quantum chemistry experiments, error mitigation on real quantum hardware, together with analysis of candidate mitigation schemes in terms of their potential error-recovery behavior and computational budget, helping users understand their practical trade-offs and decide which strategies to explore in subsequent experiments.
Tags
Links
- Source: https://arxiv.org/abs/2609.39302v1
- Canonical: https://arxiv.org/abs/2609.39302v1
Trouble viewing inline? Open PDF directly â
Full Text
55,746 characters extracted from source content.
Expand or collapse full text
SQD-Agent: LLM-driven agentic framework for Quantum Chemistry workflows Kislaya Tiwari Indian Institute of Technology Delhi kislayatiwari@gmail.com Anupama Ray IBM Quantum, IBM Research anupamar@in.ibm.com AbstractâAdvances in quantum hardware and algorithms are positioning quantum-centric supercomputing as a promising paradigm for scientific applications. However, translating domain- specific problems into executable hybrid quantum-classical work- flows remains a significant barrier for application researchers due to the required expertise in quantum algorithms, nuances in quan- tum programming, and hardware-aware system integration. At the same time, artificial intelligence has evolved into a transformative tool for scientific computing. Large language models (LLMs) are increasingly capable of interpreting natural-language intent, reasoning over complex workflows, and translating high-level ob- jectives into executable code and building computational pipelines. In this work, we introduce SQD Agent, an LLM-based agentic framework that translates natural-language user intent into executable workflows for Quantum Chemistry applications where algorithms from the Sample-Based Quantum Diagonalization (SQD) family are used. By automating this translation, SQD Agent reduces the level of human expertise and configuration overhead required, thereby simplifying experimentation in hybrid quantum- classical settings for application researchers new to quantum. SQD Agent adopts a modular and extensible architecture that supports seamless integration of heterogeneous quantum backends, classical solvers, and workflow components, ensuring adaptability to rapidly evolving quantum ecosystems. The framework further incorporates interactive capabilities for on-demand profiling, bottleneck analysis, resource optimization, intelligent result caching, and convergence visualization. Key features include natural-language-driven quantum chemistry experiments, support for error mitigation on real quantum hardware, together with analysis of candidate mitigation schemes in terms of their potential error-recovery behavior and computational budget, helping users understand their practical trade-offs and decide which strategies to explore in subsequent experiments. This agentic system focuses on these key features, as these are common painpoints across domain experts, and such systems can advance quantum applications to a useful scale. Keywords: AI for Quantum, LLM-based agent, computational quantum chemistry automation, sampling-based subspace itera- tion methods. I. INTRODUCTION Recent advances in hybrid quantumâclassical algorithms, to- gether with their use of heterogeneous computational platforms spanning quantum processors and classical CPU/GPU/HPC resources, have enabled quantum chemistry studies of molec- ular systems that were previously difficult to simulate using purely classical or purely quantum approaches. Computational chemistry is central to applications such as catalyst design, materials discovery, and drug development; however, accurate electronic-structure calculations remain challenging because the dimension of the many-electron Hilbert space grows rapidly with the number of active orbitals. Classical methods such as coupled cluster, complete active-space approaches, and selected configuration interaction provide powerful approximations, yet their computational cost and configuration complexity motivate hybrid quantum-classical approaches for near-term devices. Sample-based subspace iteration methods have emerged as a promising family of algorithms for quantum chemistry on noisy quantum hardware through quantum-centric supercomputing platforms. Sampling-based quantum diagonalization (SQD) uses a quantum circuit to generate measurement samples, constructs a selected configuration subspace from those samples, and performs classical diagonalization of the projected Hamilto- nian. This structure makes SQD attractive for near-term systems because the quantum processor is used primarily as a sampler, while the expensive eigenvalue problem is delegated to classical resources. Recent work has demonstrated the potential of SQD- style workflows for molecular systems beyond the scale of exact diagonalization [1] and even for protein complexes spanning 12,635 atoms [2]. This progress has further motivated several extensions of subspace-iteration-based SQD, including Krylov- enhanced, randomized, and randomized SQD variants [3]â[5]. Despite this algorithmic progress, executing computational chemistry experiments remains difficult for many application researchers because of the steep learning curve. Users must possess expert knowledge of computational chemistry protocols, quantum algorithms, hardware and software usage, and coding across the full stack. A complete workflow requires selecting a molecular geometry and basis set, choosing an active space, identifying a suitable algorithm, constructing the corresponding quantum circuits, benchmarking on simulators when possi- ble, efficiently transpiling circuits for execution on quantum hardware, and performing classical diagonalization and con- figuration recovery on classical infrastructure. Furthermore, when executing on quantum devices, users must understand shot budgets, apply and compare different error-mitigation strategies, interpret convergence behavior, and explain the resulting metrics. These steps require expertise across quantum chemistry, quantum programming, hardware execution, and classical post-processing. Existing software libraries such as PySCF, Qiskit,ffsim, andqiskit-addon-sqdprovide the necessary computational building blocks, but users must still manually assemble them into a reproducible and hardware- aware workflow [6], [7]. arXiv:2609.39302v1 [quant-ph] 30 Sep 2026 Fig. 1. Schematic representation of the SQD Agent workflow. A natural-language user request is interpreted by the lead orchestrator, which identifies the task, resolves missing parameters, and routes the request to specialized agents for chemistry setup, SQD-family execution, hardware submission, mitigation comparison, profiling, debugging, and reporting. The agents interact with a shared resource and data layer that stores molecular inputs, tool interfaces, cached artifacts, logs, and external-service connections. User supervision, guided by domain-specific knowledge, is maintained throughout the process. With the recent success of LLMs and agentic systems, several research efforts have explored their use in computational chemistry and scientific discovery, including ChemCrow [8], Coscientist [9], SciAgents [10], and El Agente Q [11]. Most of these systems aim to support scientific literature understanding and the investigation of new scientific hypotheses through plan- ning, tool calling, and coordination across different software tools and databases. However, they primarily target classical chemistry workflows or general scientific tool use, and do not directly address the quantum-native requirements of quantum computational chemistry workflows. In this paper, we present a multi-agent framework for quantum chemistry experiments that leverages LLMs for decision making and tool calling across the software stack, together with specialized quantum agents that manage sampling- based subspace iteration methods and other quantumâclassical research steps. We call this the SQD Agent, since SQD was the first sampling-based subspace iteration method to demonstrate quantum-chemistry calculations beyond the scale of exact diagonalization. This LLM-based agentic framework orchestrates quantum-chemistry workflows on simulators and near-term quantum hardware for different versions of SQD and related subspace-iteration methods. The framework sep- arates language-level planning from deterministic execution and is explained in detail in Figure 1. A lead orchestrator interprets the userâs natural-language request and dispatches it to the appropriate specialized agent. At present, the frame- work includes specialized agents for SQD-family execution on simulators, hardware execution, mitigation comparison, profiling, debugging, and reporting. These agents construct validated task-specific specifications that are passed to a modular execution layer built on PySCF, Qiskit, ffsim, and qiskit-addon-sqd. The execution layer then performs electronic-structure preparation, circuit construction, sampling, SQD post-processing, subspace diagonalization, artifact storage, and report generation. The main contributions of this paper are as follows: ⢠We present a multi-agent system for advancing scientific discovery in quantum chemistry by agent-driven experiment orchestration, thereby accelerating experimentation across diverse levels of user expertise through natural-language inputs. â˘The framework is implemented in a modular manner, enabling the integration of additional algorithms (currently from the SQD family such as extended SQD [12], and SQdrift [4]) as well as tools (such as Fulqrum [13], [14]) and other tools for profiling, logging, benchmarking, etc. â˘We develop a hardware agent that supports quantum- native circuit optimization, quantum execution, job retrieval, mitigation-strategy suggestion, and post-run comparison of observed accuracy-cost trade-offs, where cost includes shots, QPU jobs, runtime, and classical post-processing. â˘We evaluate the framework through experiments on six molecular systems using both simulators and IBM quantum systems, demonstrating end-to-end agent-mediated workflow execution and detailed result dashboards. Rather than coordinating only classical chemistry packages as in as El Agente Q [11], SQD-Agent targets a quantum- native workflow in which the agent manages quantum circuit generation, transpiling strategies for quantum hardware, effi- cient sampling from quantum devices, various error mitigation policies while optimizing recovery and budget, SQD diagonal- ization, and performance-aware reporting. The framework is therefore positioned as an agentic execution and analysis layer for near-term quantum-centric chemistry experiments, and not as a replacement for the underlying SQD family of algorithms. I. ARCHITECTURE AND WORKFLOW A. Agent-Callable SQD Execution Engine The algorithmic core of SQD Agent is implemented as a modular Python execution engine with an agent-facing control interface. The execution routines can be invoked either by the mid-level SQD agent or directly through the command-line interface, enabling the system to support both conversational use and reproducible scripted execution. The role of the core execution engine is to receive a validated workflow request, execute an SQD-family quantum-chemistry calculation, and return numerical outputs, diagnostic traces, and metadata for reproducibility. The numerical outputs and diagnostics support energy analysis, convergence inspection, resource comparison, profiling, and hardware-aware interpretation, while the metadata preserves the configuration needed to reproduce or retrieve a run. This design separates language-level planning from deterministic numerical execution, that is, the LLM- based agent chooses, validates, and explains the workflow configuration, while electronic-structure calculations, circuit construction, quantum sampling, subspace diagonalization, and post-processing are performed by fixed library-backed routines. Since the engine is organized through modular interfaces for chemistry preparation, ansätz construction, backend execution, subspace solving, mitigation, profiling, and reporting; new features and parameters can be added as improved libraries, solvers, backend services, and SQD-family components become available. To make the separation between agent planning and opera- tional execution, the SQD-execution specialist communicates with the execution layer through a structured run contract, denoted here asSQDRunSpec. This contract is specific to SQD execution tasks and does not represent the full reasoning capacity of the agentic framework. It records the information needed to perform a reproducible SQD run, including the molecular geometry, basis set, charge and spin, active-space policy, ansätz family, backend target, shot count, SQD iteration count, batching mode, transpilation profile, error-mitigation policy, profiling flag, and cache policy. The execution layer returns an execution-specificSQDRunResultcontaining the total energy, available classical reference energies, circuit metrics, convergence trace, timing breakdown, artifact paths, and, for hardware runs, a mitigation report. Other specialists, such as the performance, hardware, debugging, and reporting agents, may consume or extend these artifacts according to their own task-specific policies. By requiring all agent decisions to pass through this structured contract, the framework prevents free-form code execution and makes every run auditable. a) Electronic-structure and active-space preparation: The workflow begins with electronic-structure preparation using PySCF. Given a molecular specification, the chemistry layer constructs a HartreeâFock reference and forms the one- and two- electron integrals in the molecular-orbital basis together with the core energy. When requested, MP2, CCSD, CASCI, or FCI reference values are computed when feasible and stored for later comparison. For reduced active-space calculations, the active- space module selects a chemically relevant orbital window using one of the implemented policies: a HOMOâLUMO window, a natural-occupation criterion, or a CCSD-amplitude- based orbital score. A capacity-preserving refit ensures that the selected active space can accommodate the active electrons, avoiding silent electron loss during truncation. The ansätz layer constructs the quantum state-preparation circuit under a JordanâWigner mapping. The current imple- mentation supports a HartreeâFock reference circuit, a Unitary Cluster Jastrow (UCJ) circuit initialized from CCSD amplitudes throughffsim, a localized UCJ proxy that restricts excitation locality to reduce two-qubit gate count, and a fixed hardware- efficient circuit. The ansätz interface is modular: additional ansätz families, initialization rules, locality constraints, or hardware-adapted circuit templates can be added as new construction modules and exposed to the user through the agent interface. Thus, a user may request an existing ansätz, compare multiple ansätze, or, when supported by the codebase, invoke newly added ansätz variants through the same natural- language workflow. By default, each constructed circuit is saved with ansätz-related metadata such as logical qubit count, pre- and post-transpilation depth, two-qubit gate count, and total gate count. Additional ansätz diagnostics, circuit summaries, or comparative plots can also be generated by the agent on demand from the stored artifacts. b) SQD execution loop: The SQD loop follows the sample-based diagonalization workflow: the prepared circuit is sampled on the selected backend, measured bitstrings are fil- tered or recovered to enforce the target electron number, config- urations are batched into selected subspaces, and the molecular Hamiltonian is projected and diagonalized in those subspaces. The implementation reuses the qiskit-addon-sqd primi- tives for configuration recovery and projected diagonalization rather than reimplementing the SQD solver itself. The con- figuration pool can be handled in single-batch, merged-batch, or independent-batch mode. Merged batches are deduplicated and pooled before diagonalization, increasing the subspace dimension and may improve accuracy, while independent batches reduce the size of each diagonalization and expose parallelism. The per-iteration best energy, subspace size, and occupancy information are recorded as convergence diagnostics. The current diagonalization path delegates the selected- configuration problem tosolve_fermion, which constructs and solves the projected Hamiltonian using sparse classical linear algebra. However, this solver is not an architectural constraint. The execution layer treats the diagonalizer as a replaceable solver component: future selected-CI solvers, GPU- accelerated eigensolvers, distributed sparse diagonalizers, or SQD-family variants can be added behind the same interface, provided they consume the selected configurations and molec- ular integrals and return the projected ground-state estimate and associated diagnostics. c) Backend and hardware abstraction: The execution engine separates SQD logic from backend-specific execution. Simulator runs are currently supported through Qiskit Aer backends such as statevector, matrix-product-state, and GPU- enabled simulation when available. Hardware runs use Qiskit Runtime and IBM Quantum backends, with transpilation profiles controlling the trade-off between compilation time and circuit quality. After sampling, both simulator and hardware results are converted into the same bitstring-count interface, allowing the SQD post-processing loop to remain backend independent. This backend abstraction is important for extensibility. Support to IBM Quantum devices is the current hardware path, but the architecture does not assume IBM-specific hardware at the SQD level. Additional quantum processors or cloud providers can be integrated through backend adapters that implement the same operations: circuit submission, job monitoring, result retrieval, metadata recording, and conversion of measurement outcomes into the common sampling format. Thus, new backends can be added without changing the agent- orchestration logic or the SQD diagonalization pipeline. d) Error Mitigation for hardware execution: For physical- device runs, the execution layer exposes error mitigation as a configurable policy object rather than as a hard-coded option. If the user does not specify a mitigation strategy, or explicitly asks for guidance, the hardware agent can suggest compatible strategies before execution using the backend capabilities, circuit depth, two-qubit gate count, shot count, and user objective. The objective may be to minimize runtime, improve robustness, or obtain a comparative mitigation study. The agent may then run an unmitigated baseline, execute one selected mitigation strategy, or sweep over multiple supported strategies. When multiple strategies are executed, the system records for each case the backend, transpilation profile, shot count, QPU time, classical diagonalization time, recovered SQD energy, and deviation from the selected reference where available. These entries are collected into aMitigationReport, which compares the observed timeâaccuracy trade-off across mitigation choices. The recommendation is therefore context- dependent: before execution it is based on compatibility and expected overhead, while after execution it is based on the measured behavior for the present molecule, ansätz, backend, and shot budget. The framework does not assume that one mitigation method is universally optimal across all SQD workloads. e) Resource logging, profiling, and artifact management: The execution layer records the resource information needed to interpret each SQD run. On the quantum side, the saved metadata includes the number of logical qubits, transpiled circuit depth, two-qubit gate count, total gate count, shot count, backend name, and QPU runtime when available. On the classical side, the framework records the wall-clock time of major stages such as circuit sampling, SQD post- processing, subspace diagonalization, and result serialization. These measurements are not intended to replace a full low- level performance model; rather, they provide a lightweight, reproducible timing breakdown that allows the user to perform further analyses on the fly. When requested, the agent can invoke an optional profiling mode that generates a more detailed timing report for the same workflow. The current design therefore supports two levels of performance analysis: default resource logging for every saved run, and on-demand profiling for deeper inspection before optimization or demonstration experiments. The resulting timing summaries, convergence traces, circuit metrics, and run metadata are stored with the output artifacts so that the reporting agent can later generate tables, plots, and qualitative bottleneck summaries without rerunning the calculation. All data-producing actions write timestamped artifacts under the benchmark archive. Before launching a new computation, the agent constructs a run signature from the molecule, basis, charge, spin, ansätz, active-space policy, backend, shot count, SQD settings, mitigation policy, random seed when available, and software environment. If a compatible result already exists, the cache-first policy reuses the stored artifact rather than recomputing it. For hardware jobs, saved job identifiers allow interrupted runs to be retrieved after completion. The same artifact store supplies convergence plots, benchmark tables, mitigation summaries, and reproducibility metadata to the reporting agent. Overall, the execution layer provides the deterministic substrate on which the agentic framework operates. It com- bines established quantum-chemistry and quantum-computing libraries with structured workflow control, backend abstraction, mitigation suggestion, profiling, and artifact management. This makes SQD Agent extensible to new SQD-family algorithms, new classical solvers, and new quantum hardware backends while preserving the reproducibility and safety constraints required for near-term quantum-centric experiments. B. Agentic Orchestration and Workflow Control The automation layer connects the deterministic SQD execution engine of Section I-B to a natural-language interface. Rather than allowing the language model to directly generate and execute arbitrary code, SQD Agent uses the LLM as a workflow planner that produces a validated, task-dependent execution specification. A user request is first interpreted by a lead orchestrator, which identifies the intended taskâfor example simulator execution, hardware execution, profiling, debugging, mitigation comparison, or report generationâand dispatches the request to the appropriate specialist agent. The specialist then constructs the corresponding structured request. For SQD energy-estimation tasks, this request is represented as anSQDRunSpec, whose fields are populated according to the task requested by the user. For example, a simulator benchmark may require molecule, basis, ansätz family, active-space policy, shot count, batching mode, and profiling options, whereas a hardware run additionally requires backend selection, transpi- lation profile, job policy, and error-mitigation settings. The execution layer accepts only such validated structured requests and returns task-specific artifacts, such as anSQDRunResult containing the estimated energy, reference energies where available, circuit metrics, convergence trace, timing breakdown, and artifact paths, or a hardware-specific mitigation report when mitigation strategies are executed or compared. This separation between language-level planning and deter- ministic execution is central to the reliability of the framework. The lead orchestrator does not perform quantum-chemistry computation; it routes tasks, resolves missing information, and dispatches the request to the appropriate specialist. The execution specialist handles simulator-based energy estima- tion and multi-ansätz benchmarking. The hardware specialist manages backend selection, transpilation, job submission, job retrieval, mitigation strategy selection, and post-processing of hardware results. The performance specialist invokes profiling and bottleneck-analysis routines, while the reporting specialist generates tables, convergence plots, and accuracyâcost sum- maries from stored artifacts. Here, cost refers to practical execution resources such as shot count, number of hardware jobs, QPU runtime, queue or retrieval overhead, classical post- processing time, and diagonalization time. Each specialist is restricted to a narrow operational scope, which makes the workflow auditable and prevents a single agent from silently changing scientific or hardware parameters. The framework uses human-in-the-loop validation for choices that affect scientific integrity or quantum-resource consumption. This validation is designed to rely on the userâs domain expertise rather than on low-level technical knowledge of quantum software or hardware execution. For instance, if the user provides a complete molecular geometry, it is used directly. If only a molecular name is supplied, the agent first searches the local molecule registry and otherwise retrieves a candidate structure from an external chemistry source. The selected geometry is then shown to the user for confirmation before the run proceeds, allowing the user to judge whether the structure is scientifically appropriate while the agent handles the technical conversion into executable input. Similarly, hardware execution requires explicit confirmation of the backend, ansätz, shot count, and mitigation strategy before a QPU job is submitted. This design keeps scientific oversight with the researcher while delegating command construction, software configuration, data movement, hardware interaction, and post-processing to the agent. SQD Agent also follows a cache-first execution policy. Be- fore launching a new computation or analysis task, the specialist agent constructs a task-dependent signature from the parameters relevant to that request. For an SQD-family execution task, this signature includes the molecule, basis, charge, spin, ansätz, active-space selection, backend, shot count, SQD settings, mitigation policy, random seed when available, and software environment. For profiling and bottleneck analysis, the signature additionally records system-dependent information such as processor and memory configuration, available GPU support, operating system, Python environment, library versions, and linear-algebra thread settings, since performance measurements are meaningful only relative to the machine on which they were obtained. For reporting tasks, the specification instead points to stored result artifacts, convergence traces, circuit metrics, and mitigation tables from which plots or summaries should be generated. If a compatible artifact already exists for the requested task, the result is summarized and reused rather than recomputed. For interrupted hardware tasks, stored job identifiers are used to retrieve completed results from the backend. This policy reduces redundant simulator and QPU cost while preserving traceability through timestamped metadata, saved commands, convergence traces, circuit metrics, profiling records, and generated reports. Because the execution-layer extensibility is handled through the modular interfaces described in SectionII-A, the agent layer does not need to change when new ansätze, SQD- family variants, solvers, or hardware backends are added. The specialist agents only need to expose the new option through the corresponding task-specific specification and validation policy. This distinguishes SQD Agent from general chemistry agents such as El Agente Q. While those systems demonstrate the usefulness of LLM agents for coordinating classical quantum- chemistry software, SQD Agent targets a quantum-native workflow in which the agent must manage quantum sampling, hardware-aware transpilation, shot budgets, mitigation policies, classical subspace diagonalization, and quantumâclassical performance trade-offs. The contribution is therefore not a general-purpose chemistry chatbot, but an agentic control layer for reproducible and performance-aware SQD-family workflows on near-term quantum-centric systems which can be supervised by the userâs domain-specific knowledge. Table I summarizes the workflow layers of SQD Agent. The table emphasizes the main distinction from general chemistry agents such as El Agente Q: SQD Agent is designed around quantum-native SQD execution, hardware submission, mitigation comparison, and quantumâclassical performance reporting. I. EXPERIMENTAL EVALUATION OF AGENTIC SQD WORKFLOWS This section presents the experimental evaluation of SQD Agent as an end-to-end agentic workflow system, performed with OpenCode [15]. The experiments are organized to demon- strate how the framework translates user intent into reproducible SQD-family executions, exposes quantumâclassical resource costs, reuses stored artifacts, generates convergence and timing TABLE I WORKFLOW LAYERS OF SQD AGENT AND THEIR DISTINCTION FROM GENERAL CHEMISTRY AGENTS. LayerDescription Lead orchestratorInterprets natural-language intent using the LLM, plans a workflow and routes the task to a specialist. SQD-family algorithm exe- cution agent Converts energy-estimation requests into validated SQD-family execution specifications, enabling sim- ulator runs and ansätz comparisons without manual quantum-workflow configuration. Hardware execution agentManages backend selection, transpilation, QPU sub- mission, job retrieval, and hardware-result processing, extending agentic chemistry workflows from classical software to real quantum devices. Mitigation advisor Suggests compatible mitigation strategies before exe- cution and compares observed accuracyâcost trade- offs after mitigation sweeps, where cost includes shots, QPU jobs, runtime, and post-processing time. Performance agentProduces resource and timing summaries for quantumâ classical SQD workflows, exposing the cost split between sampling, post-processing, and subspace diagonalization. Reporting agent Generates convergence plots, benchmark tables, and mitigation summaries from stored artifacts, enabling SQD experiments to be studied across sessions. Debugging agentAssists with dependency, API, command, and ex- ecution failures while preserving the validated run specification and artifact provenance. SQD execution layerProvides the deterministic quantum-native sub- strate built on PySCF, Qiskit,ffsim, and qiskit-addon-sqd, separating SQD computa- tion from LLM planning and remaining extensible to new solvers, ansätze, and backends. reports, and compares mitigation strategies on a real quantum backend. We structure the evaluation around five questions: â˘Q1: Can a natural-language prompt be converted into a valid SQD-family workflow? â˘Q2: Do the generated workflows recover reference energies on simulator benchmarks? ⢠Q3: Does the framework expose quantum and classical resource costs? ⢠Q4: Can cached artifacts, convergence traces, and timing summaries support reproducible reporting? ⢠Q5: Can the hardware agent execute and compare mitigation strategies on a real QPU? A. Evaluation Protocol and Setup The core software stack consists of PySCF for electronic- structure preparation, Qiskit and Qiskit Aer for circuit construc- tion and simulation,ffsimfor fermionic state preparation, andqiskit-addon-sqdfor sample-based diagonalization. Hardware execution used Qiskit Runtime on the 156-qubit IBM Quantum backendibm_kingston. For each saved run, SQD Agent records the task specification, command-line invocation or agent-generated task request, software environment, linear- algebra thread settings, circuit metrics, convergence trace, timing summary, and output artifacts. Hardware runs addi- tionally store backend metadata, mitigation configuration, and job identifiers so that interrupted executions can be retrieved rather than resubmitted. The simulator benchmarks use the STO-3G basis and com- pare the ansätz families available in the current implementation: HartreeâFock (HF), Unitary Cluster Jastrow (UCJ), localized UCJ (LUCJ), and a fixed hardware-efficient ansätz (HE). Unless otherwise stated, simulator benchmarks use300.000shots per circuit, samples-per-batch=100,000, max_iters=8, seeded MPS seed_simulator=42. Reference energies are computed using classical methods when feasible, including RHF, MP2, CCSD, CASCI, and FCI. The hardware experiment is performed with the N 2 /LUCJ workflow to test backend submission, result retrieval, SQD post-processing, and mitigation comparison on a physical quantum processor. B. Natural-Language to SQD Workflow Validation To test whether user intent can be converted into an executable SQD-family workflow, we used the prompt: âRun SQD energy estimation for formaldehyde in the STO-3G basis and compare ansätze.â The lead orchestrator identified the task as simulator-based SQD benchmarking and dispatched it to the SQD-family algorithm execution agent. The specialist agent resolved the molecule, selected the STO-3G basis, generated a benchmark- style execution specification, and invoked the execution layer for the available ansätz families. The resulting artifacts included an ansätz-comparison table, circuit metrics, convergence traces, and saved (see Table VIII). On request, the reporting agent used the same artifact directory to generate convergence plots and summary tables without requiring the user to manually reconstruct the command-line invocation. This example demonstrates the intended division of labor. The user supplies the scientific objective in natural language, while the agent handles workflow construction, parameter resolution, execution, artifact storage, and report generation. The same run remains reproducible because the generated execution specification and artifacts are saved with the result. C. Simulator Accuracy and Resource Metrics Table I summarizes the simulator benchmarks. The goal of these experiments is to validate that SQD Agent correctly orchestrates SQD-family workflows and records the accuracy and resource information needed for comparison. Across the tested molecules, the correlated UCJ/LUCJ-style ansätze recover reference energies with small deviations in the full- space calculations, while active-space runs expose the expected truncation error when the active window omits correlation- relevant orbitals. The recorded metrics include logical qubit count, transpiled depth, two-qubit gate count, total gate count, shot count, wall- clock runtime, and SQD convergence traces. These measure- ments allow the reporting agent to compare ansätze not only by final energy but also by execution cost. For example, UCJ and LUCJ provide chemically accurate or near-chemical-accuracy estimates in the tested full-space cases, while the hardware- efficient circuit has lower structural complexity but does not TABLE I SUMMARY OF SQD AGENT BENCHMARKS IN STO-3G BASIS PERFORMED ON QISKIT QUANTUM SIMULATOR. DETAILED RESULTS ARE IN APPENDIX A MoleculeBest SQD ansätzError vs. FCI LiHUCJ/LUCJ+1.161 mHa H 2 OLUCJ+0.000 mHa N 2 UCJ+0.418 mHa consistently provide the same accuracy across molecules. Such comparisons are useful for application researchers because they expose the practical trade-off between circuit cost and energy recovery. D. Profiling, Caching, and Convergence Reporting The execution layer described in SectionII-Arecords the resource and timing information needed to interpret each saved SQD run. A default set of metadata is stored for every execution, including the molecule, basis, ansätz, backend name, shot count, qubit count, total circuit depth, two-qubit gate count, total gate count, convergence trace, and total runtime. Additional details are recorded depending on the user request and task type. For example, a hardware run stores backend metadata, error mitigation configuration, QPU runtime, and job identifiers, while a profiling request records a more detailed timing breakdown for stages such as sampling, SQD post-processing, subspace diagonalization, and result serialization. These timing reports are interpreted relative to the recorded system configuration, since profiling can depend on the processor, memory, operating system, Python environment, library versions, and linear-algebra thread settings. The cache-first policy was evaluated by repeating previously saved simulator and hardware tasks. Before execution, the agent constructs a task-dependent signature from the molecule, basis, ansätz, backend, shot count, SQD settings, mitigation policy, and software environment. If a compatible artifact exists, the agent summarizes the stored result rather than recomputing the workflow. For hardware tasks, saved job identifiers allow completed jobs to be retrieved after interruptions. This is par- ticularly important for QPU experiments, where resubmission can consume additional queue time, shots, and backend access. Convergence reporting is generated from the per-iteration SQD traces saved by the execution layer. The reporting agent can use these traces to produce energy-versus-iteration plots, subspace-size summaries, and ansätz-comparison tables. This supports the abstract-level claim that the framework provides convergence visualization and interactive reporting from stored artifacts rather than requiring the user to manually inspect raw output files. E. Hardware Execution and Mitigation Comparison To validate execution on a physical quantum device, the N 2 /LUCJ workflow was executed on the 156-qubit IBM Quantum backendibm_kingstonusing100 000shots per job. The experiment used the full-space LUCJ ansätz, which cor- responds to a 20-qubit logical circuit. The circuit was transpiled TABLE I HARDWARE ERROR-MITIGATION COMPARISON FOR N 2 WITH LUCJ ANSĂTZ ON IBM_KINGSTON . ENERGIES ARE COMPARED AGAINST FCI AS A REFERENCE. QPU+DIAG (S) IS THE TOTAL TIME OR OBSERVED QPU-JOB EXECUTION/WALL TIME(INCLUDING QUEUE TIME ON QUANTUM DEVICE, ACTUAL QUANTUM TIME PLUS CLASSICAL SQD DIAGONALIZATION TIME, IN SECONDS. NOTE: ONLY FIRST JOB HAD QUEUE TIME OF 142 SEC INCLUDED, WHICH IS NOT THERE IN ANY OTHER JOBS. MitigationE SQD (Ha) |â| vs FCI (mHa)QPU+Diag (s) None â107.6541030.01947697149.4050 s D â107.65412060.00180379448.606 s Twirling â107.65399220.13024604249.4789 s Twirling + D â107.65400090.12157614150.1549 s using a VF2 calibration-aware layout withopt_level=3, resulting in a hardware circuit on 156 physical qubits with post-transpilation total depth210(which includes both single qubit gates and 2-qubit gates), the actual 2-qubit gate depth is42. We ran for multiple seeds and then pick the lowest depth quantum circuit for hardware execution. Also the post- transpilation 2qubit gates = 298. The hardware runner submitted one IBM Runtime job per supported mitigation setting, retrieved the measurement results, applied the same SQD post-processing used in simulator runs, and generated the mitigation comparison reported in Table I. The saved artifacts include the CSV/XLSX comparison table, metadata JSON, pre- and post-transpilation circuit statistics, strategy-wise recovered energies, observed job- wall-time plus SQD-diagonalization time, and job identifiers for retrieving interrupted or previously submitted hardware jobs. Here, cost refers to the number of QPU jobs, shot count, QPU runtime, retrieval overhead, and classical post-processing time. For this molecule, backend, ansätz, and shot count, all tested mitigation settings recover the FCI reference to within 10 â3 mHa, while the unmitigated baseline has the lowest observed runtime. We do not interpret this as evidence that unmitigated execution is generally optimal, nor that the same mitigation ranking will hold for larger molecules, deeper circuits, or different backend calibration states. Instead, the result validates the frameworkâs ability to produce a context- dependent mitigation report that makes the observed accuracyâ cost trade-off explicit. The hardware experiments and its results not only confirm to the simulator results or the state-of-art results one can generate by directly running SQD, but also support the main systems claims of SQD Agent: natural-language requests can be translated into SQD-family workflows; the same execution layer supports simulator and hardware paths; resource metrics and convergence traces are saved by default; cached artifacts can be reused; and mitigation strategies can be suggested or compared through hardware-specific reports. The simulator benchmarks use small molecules in a minimal basis where FCI or CASCI references remain available. The hardware experiment uses one molecule, one ansätz, and one backend, namely N 2 /LUCJ onibm_kingston. Therefore, Fig. 2. Benchmarking ansatz across accuracy, runtime and two-qubit gate counts for H 2 O molecule Fig. 3. Benchmarking ansatz across accuracy, runtime and two-qubit gate counts for LiH molecule the hardware results should be read as validation of the agentic capabilities,including hardware execution rather than as a broad chemistry benchmark. Profiling results are also machine-dependent and are reported as lightweight timing summaries rather than a complete low-level performance model. Finally, the agent is autonomous in workflow orchestration, but safety-critical choices such as fetched geometries, hardware submission, shot count, and mitigation strategy remain human- confirmed by design. IV. DISCUSSIONS AND FUTURE SCOPE In this work, we present an LLM-powered multi-agent system that dynamically generates and executes quantum chemistry workflows, thereby increasing the accessibility of quantum chemistry experiments. In the current work, we focused on the electronic structure prediction problem using the SQD algorithm. The agent can understand natural-language text instructions, generate the workflows accordingly, and, as per the userâs request, run on a simulator or on real hardware. In hardware runs, it can additionally set up and compare error- mitigation strategies and report the associated accuracy and runtime costs. We evaluated it onN 2 , andCH 2 Oagainst Fig. 4. Benchmarking ansatz across accuracy, runtime and two-qubit gate counts for N 2 molecule Fig. 5. Benchmarking ansatz across accuracy, runtime and two-qubit gate counts for CH 2 O molecule CASCI and CCSD references on simulator and validated execution ofN 2 on a 156-qubit IBM Quantum processor, where the SQD energy reproduced the exact (FCI) result to well within chemical accuracy as shown in detail. We emphasize that the present work does not claim quantum advantage or introduce a new SQD algorithm; rather, its contribution is an orchestration framework that integrates established SQD- family algorithms, chemistry tools, classical post-processing, and quantum hardware into reproducible quantumâclassical workflow. Beyond a single application, SQD Agent is built from modular Python components (runner.py,chemistry.py, active_space.py) that extend to new molecular systems through additional molecular data and workflow specifications. Reproducibility is supported by a cache-first execution policy and timestamped artifacts containing commands, metadata, traces, metrics, and outputs. The framework builds on the broader move toward LLM- driven scientific agents, and carries it from the coordination of classical chemistry software into the quantum-native setting, where the agent manages circuit execution and error mitigation on real devices as well as on simulators. Its modular design Fig. 6. Benchmarking Error mitigation across accuracy, runtime forN 2 energy estimation with LUCJ ansatz is intended to scale from the small molecules studied here toward larger, chemically richer targets such as transition-metal clusters ([F e 2 S 2 ],[F e 4 S 4 ]), catalytic centers, and biomolecular systems, which is the next step we are working towards. Such scaling reflects the portability of the orchestration framework and should not be interpreted as a claim that SQD Agent changes the computational scaling or accuracy properties of the underlying SQD algorithms. We expect agent-based frameworks of this kind to play a growing role in quantum-classical co-design, hardware-aware algorithm selection, and adaptive sampling on near-term quantum devices. The present study is bounded by available computational resources, so both the simulator and hardware experiments detailed in results section are restricted to small molecules in a minimal (STO-3G) basis, where full-space FCI remains computable as a reference. The hardware demonstration is a single molecule (N 2 /LUCJ) on one backend (ibm_kingston) and is included to validate the execution path. Reported energies come from single runs with an unseeded sampler, so we quote no run-to-run error bars, and reproducibility is provided through cached artifacts rather than bitwise-identical recomputation. Finally, the agent layer is an orchestration and policy framework rather than an autonomous reasoner. Its reliability depends on the underlying LLM, and safety-critical steps such as hardware submission and the use of fetched geometries are gated by explicit human confirmation by design. As future work, we plan to strengthen guardrails around LLM-based decision making to retain flexibility and creativity while reducing hallucinations and unsafe or scientifically inconsistent actions. The current framework records convergence traces, resource and timing information, profiling outputs, and mitigation reports that can inform subsequent workflow changes; however, reconfiguration is presently human-supervised rather than operating as an automatic closed-loop feedback system. We plan to develop such a closed-loop mechanism in which validated execution feedback can guide subsequent choices of ansatz, sampling parameters, backend configuration, and error-mitigation strategies. We are working on features such as adaptive error mitigation tailored to execution on physical quantum hardware, and a recommendation of which error mitigation schemes can be applied, what could be the range of typical error recovery with them, and the budget (compute time) they would need so that users can understand what algorithms they can explore while using this framework. Agent efficiency will also be improved through token-optimization techniques. For example, a representative current LiH workflow required seven LLM calls and five tool calls, corresponding to 67,978 processed tokens; future versions will investigate more compact context management, selective retrieval, and ML- based methods for token-efficient planning and error-mitigation recommendation. Finally, the present work should be viewed as a proof-of-concept systems evaluation: preliminary use with a small expert user set was encouraging, but is insufficient for statistically meaningful conclusions about workflow-efficiency gains. We therefore plan a dedicated pilot user study measuring task-completion time, intervention frequency, success rate, usability, and workflow smoothness relative to direct/manual SQD execution. The current framework should be treated as a first version of multi-agent Quantum CoScientist and currently has only one algorithm family (SQD) for only one task molecular ground state estimation, but will be extended to several tasks with more algorithmic support as well as algorithm discovery in subsequent work. DATA AVAILABILITY All source code, demonstrations, simulators, and quantum hardware results supporting the findings of this study are main- tained in a GitHub repository, whose link will be added after acceptance. The repository will be made publicly accessible upon publication. ACKNOWLEDGEMENTS OpenCode [15] with Gemini 2.5 Flash [16] was used for AI- assisted code/command support while processing and testing theagent.mdworkflow files. All AI-assisted text, code, commands, and outputs were constantly reviewed and verified by the authors. REFERENCES [1]Robledo-Moreno et al., âChemistry beyond exact solutions on a quantum-centric supercomputer,â Science Advances, 2025, preprint at arXiv:2405.05068. [Online]. Available: https://arxiv.org/abs/2405.05068 [2]K. M. Merz et al., âCrossing the 12,000-atom barrier with heterogeneous quantum-classical supercomputing: quantum chemistry of protein-ligand complexes,â 2026. [Online]. Available: https://arxiv.org/abs/2605.01138 [3]J. Yu, J. Robledo-Moreno, J. T. Iosue et al., âQuantum-centric algorithm for sample-based krylov diagonalization,â arXiv preprint arXiv:2501.09702, 2025. [Online]. Available: https://arxiv.org/abs/2501. 09702 [4]S. Piccinelli, A. Baiardi, M. Rossmannek et al., âQuantum chemistry with provable convergence via randomized sample-based quantum diagonalization,â arXiv preprint arXiv:2508.02578, 2025. [Online]. Available: https://arxiv.org/abs/2508.02578 [5]V. Graves, A. Rattew et al., âResource-efficient quantum algorithms for selected hamiltonian subspace diagonalization,â arXiv preprint arXiv:2603.13160, 2026. [Online]. Available: https://arxiv.org/abs/2603. 13160 [6]Q. Sun, T. C. Berkelbach, N. S. Blunt et al., âPyscf: The python-based simulations of chemistry framework,â WIREs Computational Molecular Science, vol. 8, no. 1, p. e1340, 2018. [7]Qiskit Nature Developers and Contributors, âQiskit nature,â Zenodo, 2023. [Online]. Available: https://doi.org/10.5281/zenodo.7828767 [8]A. M. Bran, et al., âAugmenting large language models with chemistry tools,â Nature Machine Intelligence, vol. 6, p. 525â 535, 2024, preprint at arXiv:2304.05376. [Online]. Available: https: //doi.org/10.1038/s42256-024-00832-8 [9]D. A. Boiko, R. MacKnight, B. Kline, and G. Gomes, âAutonomous chemical research with large language models,â Nature, vol. 624, p. 570â578, 2023. [Online]. Available: https://doi.org/10.1038/ s41586-023-06792-0 [10]A. Ghafarollahi and M. J. Buehler, âSciagents: Automating scientific discovery through multi-agent intelligent graph reasoning,â Advanced Materials, vol. 37, p. 2413523, 2025, preprint at arXiv:2409.05556. [11]Y. Zou et al., âEl agente: An autonomous agent for quantum chemistry,â Matter, vol. 8, p. 102263, 2025, preprint at arXiv:2505.02484. [12]S. Barison, J. Robledo Moreno, and M. Motta, âQuantum-centric computation of molecular excited states with extended sample-based quantum diagonalization,â Quantum Science and Technology, vol. 10, no. 2, p. 025034, 2025. [13] P. D. Nation, A. A. Saki, and H. Kang, âA generalized framework for quantum subspace diagonalization,â 2026. [14]Qiskit Community, âFulqrum: A generalized framework for quantum subspace eigensolving,â https://github.com/qiskit-community/fulqrum, 2026, software repository. [15] Anomaly, âOpenCode: The open-source AI coding agent,â 2026, aI coding agent used for code/command support. [Online]. Available: https://github.com/anomalyco/opencode [16] Google, âGemini,â 2026, gemini 2.5 Flash used with OpenCode. [Online]. Available: https://gemini.google.com/ APPENDIX A ADDITIONAL BENCHMARK RESULTS This appendix reports supplementary SQD Agent bench- marks, including energies, runtimes, and circuit-size metrics for the molecular systems used in the evaluation. Energies are given in Hartree (Ha), deviations are reported relative to the full-space FCI reference in millihartree (mHa), and runtimes are given in seconds. For SQD results, âfullâ denotes the full orbital space, while âactiveâ denotes the selected active-space window. Reported circuit metrics include qubit count, pre- and post-transpilation depth, two-qubit gate count, and total gate count; a dash indicates that the quantity is either not applicable or was not recorded. TABLE IV H 2 O BENCHMARK RESULTS USING FULL-SPACE AND ACTIVE-SPACE SQD VARIANTS. ACTIVE-SPACE WINDOW: n core = 2, n cas = 5, n elecas = (3, 3). MethodEnergy (Ha)â vs FCI (mHa)Runtime (s)#Qubits2Q (post) RHF-74.96294666+49.4910.237â MP2-74.99844949+13.9881.702â CCSD-75.01232107+0.1160.127â CASCI (full)-75.01243743+0.0000.085â FCI (full)-75.01243743+0.000ââ SQD (full) [UCJ]-75.01229993+0.1380.966143536 SQD (active) [UCJ]-74.99663647+15.8010.416101096 SQD (full) [LUCJ]-75.01229944+0.1380.846143516 SQD (active) [LUCJ]-74.99667086+15.7670.405101096 SQD (full) [HE]-75.01243743+0.0004.6271428 SQD (active) [HE]-74.99667929+15.7580.5711020 SQD (full) [HF]-74.96294666+49.4910.665140 SQD (active) [HF]-74.96294666+49.4910.443100 CASCI (active)-74.99667929+15.7580.013â TABLE V LIH BENCHMARK RESULTS USING FULL-SPACE AND ACTIVE-SPACE SQD VARIANTS. FOR THIS MOLECULE, THE SELECTED ACTIVE SPACE SPANS THE FULL SIX-ORBITAL SPACE. MethodEnergy (Ha)â vs FCI (mHa)Runtime (s)#QubitsDepth (pre)Depth (post)2Q (pre)2Q (post)Total (pre)Total (post) RHF-7.86186477+20.4600.210â MP2-7.87476887+7.5561.233â CCSD-7.88231382+0.0110.149â CASCI (full)-7.88232438+0.0000.056â FCI (full)-7.88232438+0.000ââ SQD (full) [UCJ]-7.88229363+0.0310.5601236460201223538 SQD (active) [UCJ]-7.88224839+0.0760.4851236460201223538 SQD (full) [LUCJ]-7.88229363+0.0310.4871235780185623354 SQD (active) [LUCJ]-7.88230837+0.0160.4691235780185623354 SQD (full) [HE]-7.88232438+0.0001.25012282724244948 SQD (active) [HE]-7.88232438+0.0001.51012282724244948 SQD (full) [HF]-7.86186477+20.4602.18612220014 SQD (active) [HF]-7.86186477+20.4600.64812220014 CASCI (active)-7.88232438+0.0000.035â TABLE VI N 2 BENCHMARK RESULTS USING FULL-SPACE AND ACTIVE-SPACE SQD VARIANTS. ACTIVE-SPACE WINDOW: n core = 4, n cas = 6, n elecas = (3, 3). MethodEnergy (Ha)â vs FCI (mHa)Runtime (s)#QubitsDepth (pre)Depth (post)2Q (pre)2Q (post)Total (pre)Total (post) RHF-107.49650051+157.6220.220â MP2-107.65142137+2.7012.526â CCSD-107.65019741+3.9250.185â CASCI (full)-107.65412245+0.0000.229â FCI (full)-107.65412245+0.000ââ SQD (full) [UCJ]-107.65326614+0.85628.0742032788015240227524 SQD (active) [UCJ]-107.62308076+31.0420.5221238180258424176 SQD (full) [LUCJ]-107.65218217+1.94025.9552032695014712226468 SQD (active) [LUCJ]-107.62291478+31.2080.5751238160264824274 SQD (full) [HE]-107.64268871+11.43417.60120444340408180 SQD (active) [HE]-107.62310177+31.0211.32912282724244948 SQD (full) [HF]-107.49650051+157.6221.105202200114 SQD (active) [HF]-107.49650051+157.6220.65812220016 CASCI (active)-107.62310177+31.0210.148â TABLE VII O 2 BENCHMARK RESULTS USING FULL-SPACE AND ACTIVE-SPACE SQD VARIANTS. ACTIVE-SPACE WINDOW: n core = 5, n cas = 5, n elecas = (3, 3). MethodEnergy (Ha)â vs FCI (mHa)Runtime (s)#QubitsDepth (pre)Depth (post)2Q (pre)2Q (post)Total (pre)Total (post) RHF-147.55124893+193.5400.176â MP2-147.67710818+67.6811.217â CCSD-147.69625405+48.5350.204â CASCI (full)-147.74478939+0.0000.109â FCI (full)-147.74478939+0.000ââ SQD (full) [UCJ]-147.74398371+0.80619.9822032025010940219952 SQD (active) [UCJ]-147.67684337+67.9460.3771034360109621856 SQD (full) [LUCJ]-147.73582544+8.96418.3452031970010496219208 SQD (active) [LUCJ]-147.67684337+67.9460.3441034340109621852 SQD (full) [HE]-147.74478136+0.00820.98820444340408180 SQD (active) [HE]-147.67684337+67.9460.68310242320204140 SQD (full) [HF]-147.55124893+193.5401.193202200116 SQD (active) [HF]-147.55124893+193.5400.53910220016 CASCI (active)-147.67751641+67.2730.012â Note: The full-space CASCI/FCI/SQD recover the triplet ground state (â¨S 2 âŠ=2), whereas the active-space results are singlet-restricted. TABLE VIII CH 2 O BENCHMARK RESULTS USING THE SQD AGENT. MethodEnergy (Ha)â vs FCI (mHa)Runtime (s)#QubitsDepth (pre)Depth (post)2Q (pre)2Q (post)Total (pre)Total (post) RHF-112.34795500+139.0170.193â MP2-112.45997198+27.0001.506â CCSD-112.48475257+2.2190.255â CASCI (full)-112.48697170+0.0002.075â FCI (full)-112.48697170+0.000ââ SQD (full) [UCJ]-112.48580783+1.1641128.7702435444035280263304 SQD (full) [LUCJ]-112.48308521+3.8861125.5132435040033612261786 SQD (full) [HE]-112.47995370+7.01874.46024525148489796 SQD (full) [HF]-112.34795500+139.0171.775242200116 SQD (active) [HF]-112.34795500+139.0171.09512220016