I have spent the better part of a decade building optical tweezer experiments. First as a PhD student figuring out why my strontium MOT kept losing atoms in ways I could not explain, then as a postdoc watching the field shift rapidly from single-site demonstrations to arrays of tens and then hundreds of qubits. At some point over the last few years it became clear that the central limitation was not the physics. The physics works. The limitation is operational: keeping a 100-qubit neutral-atom system calibrated and running reliably is hard enough that most groups could not use it as a daily tool even if they had access to the hardware.
That observation is why Q-Factor exists.
The problem we kept running into
Here is a specific thing that happened in the lab, more than once: we would spend two days getting a system into a good calibrated state. Gate fidelities would be high, loading would be reliable, everything would look exactly as it should. We would hand it off to a collaborating group to run their circuits. Eighteen hours later, something would drift, fidelity would degrade, and by the time anyone noticed, half the experiment time was wasted on data that could not be used. The next morning: manual recalibration, another two days, repeat.
This is not a Q-Factor-specific problem. Every group running neutral-atom hardware in a research environment lives with some version of it. The systems drift because they are optomechanical instruments operating near their performance limits. Thermal expansion of the optical table shifts beam pointing by fractions of a micron, enough to matter. Air pressure changes affect refractive indices enough to shift laser frequencies. The Rydberg coupling strength varies with atom temperature, and atom temperature varies with how the system was loaded and how long it has been running. None of these effects are large in absolute terms, but together they push the system outside its calibration window over timescales of hours.
The conventional response is to hire more physicists to watch the system and recalibrate when needed. That is fine for an academic lab that has graduate students. It does not scale to a platform that is supposed to give reliable access to external research groups. When a group in another city has scheduled beam time and the instrument is down for recalibration, their scientific program is stalled.
Why we thought automation was tractable
The reason we believed the calibration problem was solvable was not primarily optimism. It was a specific property of the drift dynamics: they are slow, smooth, and correlated. Trap frequency drift in our system happens on a timescale of minutes to hours, not seconds. The drift is usually smooth (it follows the lab temperature, which follows the weather, which changes on predictable timescales). And the drifts in different degrees of freedom are correlated: if the optical table is getting warmer, you can predict which parameters are going to drift and in which direction from the thermal history of the table.
A physical system with slow, smooth, correlated drift is exactly the kind of system where a learned predictive model can do something useful. You do not need to react to drift after it happens; you can predict it and preemptively compensate. The information you need to make that prediction is already available in the sensor data coming off the system: temperatures, pressures, the parametric heating probe signals used to estimate trap frequencies. The challenge was building the right model architecture and integrating it with the control system in a way that was safe to operate unattended.
Arjun brought the hardware physics knowledge: he knew exactly what the dominant drift sources were, which degrees of freedom mattered most, and what the physical coupling between environmental variables and qubit performance looked like. Lena brought the systems engineering: she had built real-time control systems and understood how to design a feedback loop that would not catastrophically destabilize the very system it was trying to stabilize. I had spent years staring at these drift patterns in data and had strong intuitions about which features in the sensor data predicted which calibration failures. Together we had the combination needed to make the approach work. None of us alone would have gotten there.
What the first year actually looked like
We started building in early 2025 in a small lab space we rented in Tel Aviv. The first six months were almost entirely hardware. You cannot train a drift prediction model without data, and you cannot get data without a working system. Building the system meant solving all the engineering problems you expect (vacuum system, laser systems, imaging optics) and several you do not expect until they happen (a specific combination of our AOM driver and the building's power grid produced a resonance that put 50 Hz modulation on our trap depth; we did not figure out what was causing it for three weeks).
The second half of the year was the model and the control integration. We had enough data by month seven to train a first version of the drift prediction model, and the initial results were encouraging: the model correctly predicted the direction of trap frequency drift 73% of the time, and its predictions were significantly better than a naive persistence model (which assumes nothing will change) on all timescales above 15 minutes. We ran the model in shadow mode for two months before trusting it to make actual corrections, comparing its suggested corrections against what we would have done manually.
The first time we ran the system overnight without a human watching it, I stayed awake anyway. The system ran fine. The second time, I went to sleep at a reasonable hour. That was the moment the project felt real.
What we are building toward
The goal is a neutral-atom quantum computing platform that a research group can access remotely and trust to work. Not every day at peak performance, but reliably enough that the instrument is a tool rather than a research project in itself. Research groups studying quantum algorithms, quantum simulation, or quantum error correction should be able to focus on their science, not on debugging why the system drifted at 3 AM.
We are not claiming that we have solved the calibration problem completely. We have demonstrated that the approach works in our lab on our system, and we have early results from the first external research group that used the platform for a week of beam time. But there are open problems. The model does not handle sudden discrete events (laser mode hops, vacuum spikes) and relies on operator intervention for those. The current system has not been tested through a second full year cycle to see how seasonal drift patterns repeat. We do not yet know how the approach generalizes to larger arrays (256 atoms and above) where new physics problems emerge at scale.
These are the problems we are working on now. We are sharing our progress in this blog not because we have all the answers, but because we think the research community benefits from honest accounts of what building this kind of system actually involves. If you are a physicist working in quantum computing, you have probably run into versions of the same calibration headaches we started with. We would like to hear from you.
Three people, a rented lab, and a problem we spent years wishing someone else had already solved. That is where Q-Factor started. This blog is where we document the work of building it into something that actually changes how quantum hardware gets used.
Guy Raz
CEO and Co-Founder, Q-Factor
Tel Aviv, October 2025