Qutwo wants to make quantum an enterprise infrastructure problem

Peter Sarlin is back with a familiar thesis from the Silo AI years before AMD bought the company for $665 million. Build the layer enterprises will need before the underlying hardware is fully ready.

This time, the hardware is quantum.

Sarlin’s new startup, Qutwo, is pitching an operating system for hybrid AI workloads that can move work across standard compute, quantum-inspired methods, and eventually quantum processors. The timing is deliberate. Useful fault-tolerant quantum machines still don't exist. GPU costs and power demands do. Qutwo wants companies designing for that mixed future now rather than waiting for a hardware break that may still be years off.

On paper, that sounds like standard "get ready for quantum" positioning. The reason to take it seriously is simpler: Qutwo already has enterprise design partners, including Zalando and OP Pohjola, and Sarlin says some of those partnerships are worth tens of millions. Enterprises aren't paying for qubits. They're paying to find out whether hybrid optimization can cut latency, reduce energy per result, or improve solution quality on hard search problems.

Why this is landing now

AI infrastructure is getting awkward.

Training is expensive, but inference is squeezing plenty of teams too. Bigger context windows, larger mixture-of-experts systems, retrieval stacks, ranking layers, and agent workflows all add cost. And a lot of enterprise AI work isn't pure matrix multiplication. It's combinatorial search, constrained optimization, scheduling, re-ranking, portfolio balancing, and planning.

That's Qutwo's target.

The pitch is straightforward: some enterprise AI problems can be expressed as QUBO or Ising optimization, run today on classical solvers or quantum-inspired systems, and later shifted toward real quantum hardware if the economics make sense. If that handoff happens through one orchestration layer, developers don't have to rebuild the stack every time the backend changes.

That framing works because it's practical. Qutwo is selling routing.

What Qutwo OS needs to do

Qutwo hasn't published a full technical architecture, but the category is clear enough. If this is meant to be real enterprise infrastructure, the OS has to do four hard things well.

A hardware abstraction layer that actually does the job

A hybrid stack lives or dies on backend integration. That means CPUs, GPUs, digital annealers, and cloud quantum services through providers such as IBM Quantum, AWS Braket, and Azure Quantum.

That sounds manageable until you look at how different these systems are. A GPU job comes with predictable tooling, decent debuggability, and mature orchestration. A QPU job may involve queue times, shot budgets, circuit depth limits, noisy gates, and provider-specific compilation quirks. An orchestration layer that just forwards requests isn't worth much.

The useful part is a routing engine with a live cost model. It has to account for things like:

• queue latency
• expected shot count
• qubit availability
• error rates
• circuit depth
• data locality
• energy pricing
• expected quality of result

At that point you're less in "quantum software" territory and closer to scheduling a very strange distributed system.

A common algorithm layer

Portability matters here, maybe more than raw performance right now.

A serious platform needs to support interfaces like OpenQASM 3, QIR, and probably front ends around Qiskit, Cirq, or tket. It also has to keep classical kernels in play through C++, Python, CUDA, and whatever tensor network or annealing libraries fit the problem.

Without that layer, enterprises get pinned to one provider's gate model or compiler stack. That's a bad position in a market where the hardware is still shifting and benchmarking claims are all over the place.

Hybrid algorithms as first-class workloads

The obvious examples are QAOA and VQE, where a classical optimizer keeps updating parameters and a quantum backend evaluates circuits. That loop gets messy fast in production.

You want caching of measurement results. Warm starts from classical heuristics. Versioning for circuits, hyperparameters, backend configs, and result quality metrics. And yes, you probably want it connected to tools teams already use, whether that's MLflow, Kubeflow, or some internal platform.

This is where the enterprise case gets real. Most quantum tooling still feels built for researchers. Enterprises need observability, audit trails, policy controls, and reproducibility. Boring infrastructure wins deals.

Security that treats cloud QPUs as what they are

If workloads touch a cloud quantum backend, data governance gets awkward quickly.

A credible system needs tight control over what leaves the VPC, connectors to enterprise data stores and policy engines, and a clear story for logging and residency. It also makes sense to think ahead on post-quantum cryptography, especially for transport and storage. Schemes like Kyber and Dilithium have moved out of the theoretical bucket for large enterprises. They're already on security roadmaps.

None of that is glamorous. It's still where enterprise platform deals get decided.

The near-term value is quantum-inspired methods

This is the grounded part of Qutwo's story.

The practical near-term case isn't that a QPU suddenly outperforms tuned classical systems across an enterprise recommendation stack. It probably won't. The immediate value is in quantum-inspired optimization, running on classical hardware today and helping with hard search and constraint problems.

Think:

• simulated annealing for QUBO-like formulations
• tensor network methods for structured optimization and simulation
• digital annealers for combinatorial search
• approximations for problems such as max-cut, vehicle routing, or constrained re-ranking

That makes the Zalando and OP Pohjola pilots more interesting than they might sound at first.

At Zalando, "lifestyle agents" is a fuzzy label, but the problem underneath it isn't. Personalization at retail scale is full of competing objectives. Relevance matters. Margin matters. Inventory and size availability matter. Sustainability constraints may matter. Long-term engagement definitely matters. A classical ranking model gets you most of the way there. A QUBO-style re-ranking stage could help sort through the ugly constraints at the end.

At OP Pohjola, portfolio construction and risk-constrained optimization are even more obvious fits. Finance has spent years turning ugly objective functions into forms that can be approximated, bounded, or sampled more efficiently. Quantum-inspired solvers fit that world far better than the old fantasy of running transformers on a QPU.

The hard limits still matter

Amdahl's Law still applies.

If only a small slice of a pipeline benefits from a quantum or quantum-inspired solver, the system-level gains are capped. Hybrid orchestration also adds overhead. Data movement, queueing, compilation, retries, and result validation all take a bite out of any improvement.

Latency is another problem. If a QPU call adds 200 milliseconds, that may be acceptable for a nightly portfolio run or asynchronous batch re-ranking. It's a lot less acceptable in an in-session recommendation flow where every extra hop shows up in conversion metrics.

Cost is its own mess. Public QPU pricing is often shot-based, so sloppy experimentation gets expensive quickly. Teams will need aggressive caching, surrogate models, shot budgeting, and a hard threshold for when a "better" answer is actually worth paying for.

Portability is rough too. Providers expose different gate sets, connectivity maps, compiler optimizations, and noise profiles. The same logical circuit can behave differently enough across backends to make benchmarking slippery. Any OS claiming backend neutrality needs serious normalization work, or it needs to be honest about the caveats.

That's why Qutwo's AI-first posture matters. If the company stays disciplined, it can judge success by metrics engineers actually care about: quality of result, latency, throughput, energy per solution, and total cost. If it drifts into hardware evangelism, the value proposition gets vague fast.

What technical teams should watch

The question is whether hybrid orchestration becomes a normal layer in enterprise AI platforms before fault-tolerant quantum machines arrive.

That's plausible.

We already run mixed infrastructure across CPUs, GPUs, and domain-specific accelerators. Adding digital annealers and occasional QPU calls isn't conceptually strange. Operationally, it's ugly. That ugliness creates room for platform companies.

If you run AI infrastructure or applied ML teams, the sensible move is to look for narrow problem classes where search and constraint handling dominate cost or quality:

• re-ranking under many business constraints
• routing and scheduling
• portfolio and risk optimization
• resource allocation
• planning inside agent systems

Those are the places where a hybrid stack might actually earn its keep.

The strategic play is obvious enough. Qutwo is trying to define the control plane before the hardware market settles. If that works, it could end up in a strong position. Enterprises rarely want to bet directly on a raw hardware winner when tooling and standards are still moving. They'd rather buy insulation.

That doesn't make the quantum timeline any shorter. It could make adoption less painful once there's finally something worth adopting.