Sampler vs Estimator vs Executor: choose the result your workflow needs.

Qiskit Runtime primitives provide task-oriented interfaces to IBM Quantum hardware. SamplerV2 samples output registers. EstimatorV2 estimates expectation values of observables. The newer Executor interface, currently beta, accepts a directed quantum program and exposes lower-level control over how circuit variants are generated and executed.

These interfaces are not three quality levels. Estimator is not automatically more scientific than Sampler, and Executor is not automatically better because it offers more control. The correct interface is the one whose inputs and outputs match the predeclared question and whose assumptions the team can review.

Sampler executes one or more circuits and returns shot-based measurement data for their output registers. It is a natural fit for Bell correlations, Grover-style outcome distributions, bitstring constraints, and other experiments where the measured samples themselves support the analysis.

A Sampler PUB contains a circuit, optional parameter values, and optional shots. Review must cover classical-register mapping, shot count, parameter broadcasting, circuit metadata, and any post-processing that turns samples into probabilities or summary statistics. Sampler is not a general request for the full quantum state, and a histogram alone is not a complete experiment record.

Estimator combines a circuit, one or more observables, optional parameter values, and an optional target precision. It returns expectation-value estimates and associated uncertainty information. This model fits cost functions, energy estimates, and parameter sweeps where an observable—not a displayed bitstring distribution—is the scientific quantity of interest.

Observable layout matters. After transpilation, observables must correspond to the circuit’s physical layout. Commuting observables should be grouped deliberately when the workflow intends to estimate them from the same measurement basis. IBM also notes that measurement instructions in an Estimator input circuit are ignored, so a visually measured circuit cannot be assumed to define Estimator output semantics.

Executor is part of IBM’s directed execution model and remains beta in the current documentation. It samples output registers like Sampler, but follows client-provided directives for generating and binding circuit variants. IBM describes it as a lower-level interface that makes execution choices more visible and controllable.

Executor does not include built-in error suppression or mitigation that silently selects a strategy. The workflow must express its design intent through the supported program and directive structures, then retain those inputs with the result. Because the interface is beta and Qiskit does not yet define a base Executor primitive class, code and claims should be reviewed against the live documentation before release.

Current Runtime guidance uses the V2 primitive interfaces. V1 Sampler and Estimator were deprecated and their support was removed in August 2024. V2 represents inputs as PUBs so a circuit can be combined efficiently with observables, parameter arrays, shots, or target precision according to the primitive contract.

Before hardware execution, circuits and observables must be prepared for the target instruction set. The circuit must use supported operations and respect connectivity constraints, while observables need the corresponding layout where applicable. Preserve the abstract source and the ISA-transformed artifact; they answer different review questions.

Estimator exposes error-suppression and mitigation controls such as dynamical decoupling, twirling, measurement mitigation, zero-noise extrapolation, and probabilistic methods where supported. These choices can change circuit ensembles, shot requirements, cost, uncertainty, and interpretation. IBM explicitly notes that zero-noise extrapolation often improves results but does not guarantee an unbiased answer.

Result metadata can vary by primitive implementation and option set; base primitives do not guarantee every metadata key. An evidence layer should therefore preserve the raw result object, primitive and package versions, explicit options, shots or precision, PUB-level metadata, and any transformation performed after retrieval rather than extracting only a preferred number.

QFlow Studio’s visual canvas and generated-code view can help a learner or reviewer connect circuit intent to Qiskit and OpenQASM artifacts. For Runtime work, teams should attach the selected primitive, PUB inputs, options, route, returned result, and review rule as supplemental evidence; the public generated-code documentation does not claim that all of those fields are captured automatically.

This guide does not claim that every Qiskit Runtime primitive—especially beta Executor—is callable from QFlow. Live submission support must be verified against QFlow’s dated integration matrix and tested with the user’s independent provider account. Where a path is not implemented, QFlow should present the primitive as ecosystem context or an exported-code destination, not as an available run button.