Routing and assignment are NP-hard
Which drone flies where, in what order, within range and airspace limits. One failed unit or a new task and the whole plan must be recomputed in seconds.
FSharp.Azure.Quantum · drone-first
Describe the problem. Skip the physics.
Quantum computing that ordinary developers and AI agents can ship. The problem goes in as everyday .NET code, not quantum circuits; the library builds and runs the circuits on a simulator or real quantum hardware and returns the answer. The algorithms and error correction are already done. First application: coordinating drone fleets.
First application · Drone fleet coordination
Coordinating a fleet is a combinatorial problem that grows faster than the fleet.
Quantum tooling is written for physicists
Qiskit, Cirq and Q# expect gates, Hamiltonians and hand-encoded QUBOs. A fleet-software team has none of that vocabulary and no way to hire it.
Hardware arrived without a developer path
Azure Quantum, D-Wave and Braket sell machine time today. Nothing lets an ordinary .NET application describe a business problem and run it there.
Drone-first: what flies today.
Give the swarm its tasks, calculate the routes, re-route on the fly if a unit fails. The hard part is the combinatorics — that is exactly what quantum optimisation is for.
Describe the fleet
Units, their range and capabilities, the tasks to cover and the airspace and altitude limits they fly under.
Give the objective
Shortest total flight time, balanced battery use, guaranteed coverage — expressed as a business goal, not a Hamiltonian.
Solve the assignment
The library turns the model into an optimisation problem and solves it on a simulator, a hybrid path or a real quantum backend.
Re-route on the fly
A unit fails or the mission changes, the swarm is re-planned in place and exported to the flight controllers again.
Four runnable examples in the repository
Fleet path planningWaypoints become a tour, split into range-safe sorties across the fleet, with altitudes checked against the regulatory ceiling.examples/Drones/FleetPathPlanningSwarm task allocationTasks with dependencies and priorities scheduled across drones with capacity limits, minimising mission time.examples/Drones/SwarmTaskAllocationSwarm choreographyFormation transitions solved with QAOA and exported to Crazyflie micro-drones indoors and as ArduPilot missions outdoors.examples/Drones/SwarmChoreographyWildfire air bridgeWater moves as flow along corridors between the lake and the fire sector, capped by fill slots, in-trail spacing and drop slots; the planner decides which corridors to open as the wind turns.examples/Drones/FireAirBridge
Flown in ArduPilot's own simulator (SITL) · ArduPilot 4.7.1 · 29 September 2026
Every example exports ArduPilot missions, and one shared launcher flies them. These flights ran in ArduPilot's software-in-the-loop simulator: the real autopilot firmware on a simulated airframe. Each picture shows the flight in 3-D, with the whole flight playing in 20 seconds. Open it for the plan against the flight, from above and as height over time.
A hundred drones on sixteen qubits · the laptop simulator · 9 October 2026
A swarm's formation change is an assignment of every drone to a slot, n² qubits as one circuit. A hundred drones would need 10,000. The choreography example instead improves the assignment in blocks of four drones, each block a 16-qubit QAOA circuit on the same laptop simulator, until no block moves and every drone keeps its safety distance in flight. No classical solver stands in for the quantum one; the runs grow with the swarm, not with its square. The picture is the show as planned: every drone in the colour its light is set to. Any show works the same way: hand the software the pictures, as points with the colour each light should show, and it plans every flight between them, checks the separation in flight and writes the plan each drone flies.
Where the hardware is
The choreography example runs four drones on sixteen qubits on a laptop simulator, with the quantum solver executing every transition, and a hundred drones on the same sixteen qubits a block at a time. A wider device takes wider blocks: 31 drones per circuit at 1,000 qubits. Cloud QPU and annealer backends sit behind the same API, and the code does not change as the machines grow.
Three layers. Developers touch only the top one.
Layer 1 · Builders
The business vocabulary: routing, scheduling, assignment, knapsack, portfolio, network flow; fraud, churn and workforce builders. Written by developers or AI agents in F# or C#.
Layer 2 · Solvers
QAOA for optimisation; VQE and ADAPT-VQE for chemistry; Grover and amplitude amplification; QFT-based arithmetic and phase estimation.
Layer 3 · Backends
One interface over the local simulator, Azure Quantum (IonQ, Pasqal, Quantinuum, Rigetti), D-Wave annealers, an AWS Braket plugin and a topological simulator for the Majorana era. Circuits arrive as OpenQASM from Qiskit and leave as OpenQASM, QIR or a MAVLink mission.
Write it today. Run it at scale later.
One NuGet package
dotnet add package FSharp.Azure.Quantum — no research stack to assemble.
F# builders, C# fluent API
Written like any other .NET code, reviewable by the whole team.
Quantum-first, honestly
A quantum solver never silently returns a classical answer; the hybrid router says which method produced a result.
Every backend, one interface
Simulator on a laptop today, cloud QPUs and annealers when the problem needs them. OpenQASM 1.0–3.0 in and out, QIR emission, error mitigation and qubit routing, so nothing built here is stranded.
Second act · chemistry
Antibiotics from Western materials.
Most of the world's key antibiotic intermediates come from a single country. The same solver layer runs VQE to compare alternative β-lactam synthesis routes by activation energy, next to binding-affinity and metabolism examples. Regulated drug development is not a market we can demonstrate on our own, so we take it forward with pharma and academic partners who own that path — after the fleets are flying.
How this is sold
We sell the plan. Our partners sell the fleet.
What you buy
Fleet-planning work on an open optimisation library: fixed-scope projects that put a planner into your product or your operation, and supported builds for vendors who ship it. Constraints in, routes, assignments and MAVLink missions out.
Who buys it
Aircraft makers and the vendors who ship ground-control and fleet-operations software, and the operators flying authorised BVLOS corridors — rail, power lines, wind farms.
What the partner gets
A partner bundles coordinated operations into the fleet package and bills it per aircraft per month at their own margin, and we supply the automation evidence behind the pilot-to-aircraft ratio they want to document in the flight manual. Every aircraft they sell is recurring revenue for both of us.
How it starts
A fixed-scope integration or pilot: your product or your fleet, your constraints, a planner in production in twelve weeks, run by remote engineers.
Who owns what
Asset-light by design: the aircraft, the operational authorisation, the pilots and the liability stay with the people who already carry them. Payload is a constraint we model rather than hardware we ship, so every fleet is addressable, and every mission leaves as a file your pilot-in-command inspects before anything flies.
Integration and pilots
Fixed scope, twelve weeks: your fleet or your product, your constraints, a planner in production. Hybrid solver today, quantum backends as an option.
Supported planning SDK
Signed builds, long-term support, an SLA and private builders for vendors who ship the planner inside their own product.
For vendors and operators
Bring us a fleet-planning problem.
The library is public domain and free to use. When you want it inside your product or your operation, we take it on as a fixed-scope project and support the build you ship. Ask for a live demo: four drones, one laptop, a quantum solver, twenty minutes.