I am Kingsley Crane, a technology analyst here. I have had the privilege of getting to know the Horizon Quantum team a little bit better over the past couple of months. We have Dr. Joe Fitzsimons, CEO and Founder, here with us today. Welcome back. You joined our symposium in May. A lot has happened since then. You have a Quantum Machines collaboration, a testbed expansion, your second quarter as a public company. Just, I guess, for those that have not met you co-invented universal blind quantum computing, before founding Horizon in 2018. Maybe if you just start out with what you saw in your research and maybe the gap you saw in the market that led you to founding Horizon. Sure. I have been working in quantum computing quite a long time now. I got into the field back in 2004 when I thought quantum computers were just around the corner, which shows a little bit of youthful naivety. But, I have been working in the field since then. I did my PhD at Oxford. I worked as a fellow in Merton, doing research into quantum computing and applications of quantum computing, as well as architectures, like how you build a scalable system that is error-corrected and so on. I have been working on that for many years. I moved over to Singapore in 2010, built up a research group over there. But around 2015, 2016, with the release of the IBM Quantum Experience, when they put the first. I was about to say when they put the first quantum computer on the cloud, but actually University of Bristol had a linear optic system that they put on the internet just before then. Two systems went online pretty soon, or close together around that time. You also had a lot of results where the error rates were getting much better. Around the time I got into quantum computing, the chance of you having an error, if you tried to do a logic gate in a quantum computer, was about three in 10. Zero nines of fidelity. It had increased to the point where it was maybe one in 100. That was really interesting because it was close to where we thought error correction might become a possibility. Now it has taken a bit longer, and it turns out that systems have had to become a little bit better than was expected in order to really see error correction start to work. But around that time, it was becoming increasingly clear that progress was going to be made more in industry than it was in academia. Maybe this is something like the current situation with AI, where all of the frontier labs are now in industry. The same is true of quantum computing. Pretty much all of the frontier systems, nearly all of the frontier systems, are built in industry rather than academia. I decided it was time to jump ship and move into industry. I went out, started interviewing at a bunch of quantum computing companies, then decided that I did not really agree with anyone's view of what was needed. I better go do it myself. In 2018, I registered the company on paper, went out to raise some money, and quit my academic job. I think I was the first person with a tenured professorship to actually quit to move into a quantum computing startup. What we have been focused on is really closing what we see as one of the really fundamental gaps in quantum computing. A really important part of quantum computing is, can you build hardware that can process information quantum mechanically? That is what many of the companies you will hear from today do. It is what IQM do, it is what many others do. There is another part of that. How do you harness these systems to do useful work? The reality is they work in a fundamentally different way than conventional computers. Taking code written for conventional computers and trying to run it on a quantum computer does not help you at all. Instead, we need to reinvent essentially 80 years of computer science, 80 years of computer software, for the quantum era. That is what we have been trying to do at Horizon. We have been trying to speed run the history of computer software or computer software engineering from the 1940s, 1950s, up to the present day. We have been doing that by building programming languages to make the systems more accessible, to expose more capabilities. We have been building the compilers and the runtime environment to be able to execute that on hardware. As we have started to do that, we have started to have to develop essentially system software as well. At the moment, most quantum programs that are run today are what are called circuits. That is just a list of operations, one after the next, that are implemented and then finished with measurements. If you want to do general computation, you need to think of general control flow. You need to be able to do things like loops and subroutine calls and things like this. That is trivial on conventional computers. It is how they all work. In quantum computing, we are only just at the forefront of that. As we are just dipping into that in quantum computing, it opens up the whole domain of operating systems. Not the way many of the companies you will hear from use the term operating system, where they are talking about orchestrating workloads. What I mean is fundamentally the kernel that runs on your laptop, on your server, that is exposing different system services, dynamic memory allocation, input and output, so communications with other systems over network. All of these kind of low-level operations that are needed during the execution of complex programs. We have started having to build into that direction. Essentially now we have become the first software company to start operating our own hardware. We have a first testbed system that is pieced together from a Rigetti QPU and control systems from Quantum Machines. We have a new system coming next year from IonQ that will be a very capable system. We are looking forward to getting our hands on that. And you've alluded to this, I think when investors hear quantum software, it can mean a lot of different things. I think that part of the space has been underdeveloped for quite some time, and many of these software offerings are Python libraries stitching together certain circuits. But in the case of Beryllium, which is one of your premier software offerings, what can you do today, or what can a customer do today with Beryllium that they would not be able to do with a competitive SDK or a similar type of offering? There's different levels at which things are different. I should say it's fundamentally different from most methods of programming quantum computers. The first thing that's important to understand is that the programming languages we build target ideal quantum computers. So we say, "What does a perfect quantum computer look like?" Not the systems we have today, but what does a perfect ideal quantum computer look like, and how do we program that system? Then what we need to do is build up the compiler capabilities, the execution capabilities to take that code written for an ideal system and execute it on the kinds of more limited systems that we have available today. That's important to understand because many of the systems that are currently available are not capable of doing things like control flow. They can't do something as simple as making a measurement in the middle of a computation and then using the result of that to decide what happens next. Some can, but there's a lot of constraints around this. If you think about what a mature quantum computer should be able to do, first of all, it needs to be able to make a general decision based on any measurements that it has at that point in time. So that means you need to be able to do classical computation on the results of measurements from a quantum computation, and then use them to influence that ongoing quantum computation before it has all collapsed, before the quantumness has been washed out by decoherence. So we have been building an execution environment that enables this, and necessarily, this allows you to express things in our programming languages that are just not expressible in many other programming frameworks for quantum computers. Now, that's true of all of our programming languages, from Hydrogen, which you can think of as an assembly language, through Helium, which is essentially a basic programming language, to Beryllium, which is our first object-oriented programming language. The reason we have built up these layers of abstraction up to an object-oriented quantum programming language is so that you can start to abstract away the quantumness. Essentially, what we're trying to do as a company is get to a point where developers can write conventional code and have it automatically accelerated on quantum computers. Beryllium is essentially the third step of four for us on this path. What we're doing with that is allowing developers who are expert in quantum computing to build up classes to represent objects that are combinations of quantum and classical data, together with the various algorithms to manipulate those kinds of data. But then to allow those to be exposed to other developers who may not be experts in quantum computing. So it allows you to add this layer of abstraction where each incremental developer can create higher levels of abstraction and start removing the quantum mechanics. It starts to get you to a place where developers can write code that is able to express anything a quantum computer can possibly do, but in such a way that they don't need to be experts in quantum computing themselves. I think that's really important. So part of it is that a user or developer can write conventional code and benefit from quantum speed-ups. It also seems like when I've spoken to you in the past, that you believe that basically the total addressable market for quantum computing, it could be much larger, it could address traditional applications. It seems like something that you aspire to help with. But I guess on both of those domains, how far along do you feel like we are, and just how much conviction do you have? Yeah. So fundamentally, the promise of quantum computing is to be better computers. Quantum computers are computers with an extra trick, or at least that's what they're supposed to be. They're supposed to be able to do general computation, plus take advantage of quantum interference between possible branches of a computation. Now, the reality of that is that today's systems tend to be much more limited than that and so tend to be worse computers. But if you can overcome that gap, and a lot of that is, well, some of that's hardware, but a lot of that's software as well. If you can start to bridge that gap to get to the point where quantum computers are really better computers with an extra trick, then you can turn them to a much wider variety of problems than you would see if, for example, you just look at the BCG reports on quantum computing, where you see, oh, optimization, simulation, machine learning, and cryptography as the four application domains. I don't think this is generally true. So the approach we've been pursuing to get to a point where we can automatically accelerate general code is a very general approach. We try to look at a program structure. We try to break apart the loops and the recursive function calls that dominate the runtime for that program. We try to break them apart to give us simpler and simpler elements that we can then recognize and replace with more efficient means of doing the same thing that exploit quantum processing. That turns out to be a very general process. My expectation is that we can turn this to a very wide variety of problems. Even if we look at where we see inbound interest, it is not confined to those four domains I mentioned. You also see it for things like large inverse problems that show up in the oil and gas sector, for example. There is a lot of different applications that maybe have not yet been fully thought through, where quantum computing stands to really be an accelerant. We have to get to the point where the quantum computers are actually able to solve these problems, and we are still a little bit away from that. The current state of quantum computing as it stands today, no one is really using quantum computers in production to solve hard problems that impact their bottom line. We need to get across that line to the point where it is the case that software running on quantum computers is generating real value for the end users of that software. Software layer, hardware agnostic, you have an Ember One testbed, and have hardware capabilities from a number of different providers, including IonQ in short order. What does that offer you strategically that you would not be able to achieve with cloud access? Yeah. I should say we do use cloud access to a really wide variety of systems at the moment, so we are able to compile our programs to run on a wide variety of hardware and extend the capabilities of those hardware systems to enable things like loops and recursion that are not natively supported on those systems. Having access to on-prem systems, so Ember One being a superconducting system that we have set up in our Singapore headquarters, it allows us to deeply integrate directly with the control systems. We are building code that runs directly on the control systems. We are not going through other software stacks on the way down, which tend to screen out capabilities of the hardware. Just because it is hard to think through how you safely expose all of the potential capabilities of hardware in a way that cannot damage the system and so on. Having access to that is really useful. The other thing that you cannot get around over the cloud, and there are attempts to do this with co-locating classical systems and so on, is latency. You just need to have processing very close to your quantum computer if you want to be able to do that kind of concurrent classical processing that I alluded to earlier, where you are taking the results of measurements, for example, that have happened during your quantum program, and you are then running some classical function to decide what to do next based on those results. If you want to be able to do that, particularly with superconducting systems, you need to have everything very close together because every foot they are apart is an extra nanosecond, in terms of the timing. You just cannot do that sat internet scale, you have to physically co-locate the hardware. You had a Quantum Machines collaboration recently, which helps with embedded calibration. Maybe not the most glamorous or obvious problem, but still an existential one. How important is that, could something like that become a way for you to productize another part of your platform? Well, you are right that it is not very glamorous, but it is a really important problem. The issue you have at the moment is that quantum computers need to be recalibrated all the time, and to do that, you end up essentially taking them offline or making them unavailable to users so that you can do all your calibration runs, all of your measurements to try to figure out how the frequencies have drifted and all of the little tweaks to the calibration that you need to do to get optimal performance out of them. That means your quantum computer has a lot of downtime. They are pretty valuable resources. The other side of it, there is just not very many of them. If we get to a world where there's a real quantum advantage where JPMorgan or whoever is running jobs all the time on the quantum computer that are important to its business, are they really going to accept the idea that like, "Oh, no, we have to bring the system down for a few hours. It's completely unavailable to you until tomorrow because actually we were trying to calibrate it and we noticed something weird, and we're looking into it." I don't think that's a great state of things, right? A much better place to get to is where we can maintain the calibration in an ongoing way so that you're essentially using the results that you have running the system continuously to keep it always up to date in terms of calibration. Because then you don't have to have these long sustained downtimes and so on, you always get the best performance out of the system, which is really important because none of the systems behave as performantly as I would like them to. So the more performant we can make them, the better. So it's really important. It's really important from an OpEx perspective if we want to get to real production use of quantum computers. Yeah, the way we think about this is we're not really breaking off separate products at the moment. The way we think of things is we see Triple Alpha essentially as the way to code, compile and deploy your quantum applications. But that means we need to make sure that everything needed to make them execute, in a timely fashion, in as performed a fashion as possible, in as reliable a fashion as possible, we need to do. We need to be right at the forefront of quantum computing in that respect. Looking out on the horizon of computing and thinking about that second system had hinted that it could solve some uniquely challenging problems. More color on the ambition there and what class of problems that could include. Sure. The second test bed system we have coming, which is due to be installed in Dublin in Ireland next year, is a 256-qubit trapped ion system from IonQ. There is a nice diagram that a researcher in Waterloo put together of all of the different areas in which quantum computing applications are known to exist, where there is a quantum advantage and where there is not. If you look at the qubit count for that system, and you look at roughly where the fidelity of the one and two qubit operations and measurements for that system are expected to land, if it lives up to spec, that should put it right on the cusp of an advantage for certain chemistry problems. We will not know until we have the system, whether we will actually show a real advantage or not. Depends on a lot of things, but it does get us very close to that cusp of where a real advantage may be possible. Within your Ember One test bed, you have multiple modalities. Have you learned anything interesting by observing different modalities from your software layer? Well, Ember One is what we call the superconducting system we have. We will have another name for the trapped ion system when it arrives. At the moment, we are only operating one system on-prem, so we do not have the trapped ion system up and running yet. But we do run on a wide variety of different hardware, and there are very clear trade-offs between different kinds of hardware. Historically, trapped ions have been the most accurate systems. Their error rates are lower, their coherence times are longer, but their gate times are slower compared to superconducting systems. So superconducting systems are really fast. In some sense, trapped ion systems are at least an order of magnitude slower. And that means for some kinds of problems where you need to generate a very large number of shots, it is just much more cost-effective to do it on a superconducting system than on a trapped ion system. But when you are trying to push the frontier in terms of error correction, things like this, then trapped ions can really show an advantage. All of this has been kind of upset a little bit by the coming of age of neutral atom systems, which are very slow if you have to physically move around the atoms, but at the same time are fully reconfigurable that they are really a super interesting technology. So each different system has its own quirks. At least for me, I have been working on this, as I say, 22 years at this point, I cannot pick a winner. I do not know which hardware platform is going to win. So when you listen to people telling you that they know for sure, if they have not been doing this a very long time, I would probably take that with a pinch of salt. Sounds like you would like a neutral atom test bed as well. Yeah. If anyone wants to send me one in the post. Would you like to take a moment as well, if anyone in the audience would like to ask a question? Sounds good. We can circle back. How about just the developer adoption strategy? How aggressive are you in building that mind share at this stage in the market? Yeah. We have gone a different way than many others. A lot of what has been done to date has certainly pushed developer adoption, with things like Qiskit and so on. For us, our approach has mostly been focused on the hardware companies to date. We will start broadening access to our system over time, of course, but at least the strategy we have been taking is to work as closely with hardware manufacturers as we can to try to get to a point where we can deliver a real advantage before we really start trying to push things towards enterprise. Because at least for us, it is very clear that until there is a real advantage to running software on the quantum computer, until running software on the quantum computer is generating real value for the end user of that software, it is kind of premature to really start trying to drive enterprise adoption because it is only POCs. It is only going to be POCs that do not really convert into production deployments until there is a real advantage. Our focus is really on working with the hardware companies who care most about getting to a real advantage. The other side of our strategy has been to stand up an internal applications team, and that has been news for us in the last, well, I guess, since the earnings call. We have put together an internal team, focused on three high-value problems across three different industries. The reason for this is because if you think of the current dynamic in quantum computing and adoption of quantum computing and enterprise at the moment, as I say, at the moment, it is mostly proof of concept. Engagements, various enterprise are dipping their toe in the water, but not yet solving hard problems. Any kind of short-term engagement like that is unlikely to get to a very high-value application in quantum computing. Instead, we decide, okay, if the way you get there is not by going out and doing POCs with enterprise, how do you get there? From my perspective, the way we do it is we focus on, we pick the problems we think are achievable and that are high value, and we focus on them internally. That is what we are doing at the moment. Of course, we will start to open up our system to more users, but for the moment, our real focus has been on gaining traction with hardware providers and with pushing towards real advantage. Yeah, just to highlight, early in revenue, but incredibly efficient business compared to some other quantum companies that are more capital-intensive right now. Just any thoughts or reminders there and thoughts on capital allocation and then maybe parting words as we wrap up on time? Sure. Actually, I will be even stronger than what you said in the sense that we deliberately stay pre-revenue. The reason we do this is because any revenue that you would derive in a company like ours, pre-advantage is somewhat misleading. It ends up coming from professional services bundled with system access and stuff like that. It is not at all representative of the step change we believe comes with real advantage. So it is like saying, when you have GPT-1 or GPT-2, talking about like, okay, now we are rolling it out to enterprise, because the reality is, okay, maybe some will adopt it and so on, but it does not really work yet. But by the time you get to GPT-5, by the time you get to Sol or something, it really is working. So at least for us, it's very clear there's a step change there and it's important for us, I think, to set the expectations with the market that actually that is really when we believe there's the real step change and we are focused on getting there as soon as possible. In terms of how we think about OpEx and so on, look, if we were able to live up to our highest ambitions, ultimately what we're doing is we're trying to follow a roadmap that mimics what Microsoft did in the sense of programming languages and interpreters were kind of the first aspect of Microsoft, and then the next division was system software and then desktop applications. We're kind of following that same path. If everything went very swimmingly for us and we lived up to our highest goal, well, obviously our OpEx isn't going to be static if we have billions of users, but that's a long way off, right? For the moment, while we're still staying pre-revenue, pre-advantage, from my perspective, it's not something we're expecting to grow without bound. We'll keep a pretty tight control on that. Ultimately, we're a software business, so our economics just look totally different from many of the hardware companies. Exciting times. Thank you so much for joining and sharing the story. Thanks very much.