Signal
Issue 15 · October 20, 2026 · 7 min read
Drone Swarm Technology: How Swarms Agree With No Leader
How drone swarms work and communicate, why the graph Laplacian decides whether a leaderless swarm agrees, and a graded project that predicts mission success.
"...not by clicking through menus or programming behaviors." - Lt. Gen. Frank Donovan, on how troops should command drone swarms
Ukraine fielded more than a million drones last year. Most of them still needed a human pilot each.
This week we're talking about drone swarm technology, and specifically how a swarm agrees on anything when nobody is in charge, and yes, this can get you a very comfortable job.
Here's the idea: drone swarm technology is software that lets many drones act as one system by coordinating with each other instead of with a pilot. The hard part is decentralized control. Every drone only hears its neighbors over a lossy radio link, yet the whole group still has to agree on a heading, a formation or a target.
The Pentagon has learned how hard that last part is. Replicator set out to field thousands of cheap autonomous drones by August 2025; the Congressional Research Service says it delivered hundreds, and one of the missing pieces was software able to orchestrate large swarms of different drones. The program was folded into the new Defense Autonomous Warfare Group, and in January the Defense Innovation Unit put up to $100 million on the table in the Orchestrator Prize Challenge for exactly that software. Meanwhile Ukraine's Swarmer, which reports more than 100,000 combat missions and one operator controlling 20 or more drones, went public in March.
The math underneath all of it is older than any of these companies. In 2014 a Harvard team got 1,024 tiny Kilobot robots to assemble themselves into shapes using only local rules. The rule that matters most for a swarm is the simplest one: move a little toward your neighbors.
How does a drone swarm work?
Each drone runs the same local rule and reads only the drones within radio range. To agree on a value such as a heading, drone i nudges its own value toward its neighbors' values at every step. Stack every drone's value into a vector x and the whole swarm update is one line of linear algebra: L is the graph Laplacian of the communication network (degree matrix minus adjacency matrix) and epsilon is the gain. Three facts fall out of that line, and they are the whole job:
- The sum of the values never changes, so a connected swarm converges to the exact average of where it started.
- How fast it gets there is set by the second-smallest eigenvalue of L, called the algebraic connectivity (lambda 2). A disconnected swarm has lambda 2 = 0 and never agrees.
- It is only stable when epsilon is smaller than 2 divided by the largest eigenvalue of L. Turn the gain up past that and the swarm oscillates and blows apart, however good the radios are.
How do drone swarms communicate?
Over a mesh network. Each drone talks to the drones in radio range and relays what it hears, so there is no hub to jam or shoot down. The catch is that the graph keeps changing: drones move, links drop, and a jammer can cut a swarm into pieces. Packet loss does not usually break consensus, it slows it down, because every lost message is a step where that link contributed nothing.
Is swarm consensus the same as blockchain consensus?
No. Raft, Paxos and PBFT make a set of servers agree exactly on a discrete log of decisions, with guarantees even when some servers fail. Swarm consensus averages continuous values over a moving, lossy network and only converges asymptotically. Same word, different mathematics, and a common interview trap.
| Centralized swarm control | Decentralized swarm control | |
|---|---|---|
| Who decides | A ground station or leader drone | Every drone, from its neighbors |
| Single point of failure | Yes | No |
| Communication | Every drone to the hub | Neighbor to neighbor over a mesh |
| Under jamming | Freezes when the hub link drops | Degrades gracefully and slows down |
| What limits scale | Hub bandwidth and latency | How fast agreement spreads (lambda 2) |
| Hardest engineering problem | Keeping the link alive | Proving the group converges |
Now I'm going to explain what this means for you:
The Skill Employers EXPECT
Learn graphs as matrices. Autonomy and multi-agent teams assume you can:
- Build the adjacency matrix and Laplacian of a communication graph from agent positions and a radio range
- Compute its eigenvalues in NumPy and say what the smallest nonzero one and the largest one each tell you
- Simulate a consensus or flocking rule in Python for a few dozen agents and plot disagreement over time
- Explain why the swarm converges to the average and not to some other value
- Tell swarm consensus apart from distributed-systems consensus (Raft, Paxos) without hesitating
If you cannot say why a swarm with twice the gain might never converge, you are guessing at the tuning.
The Skill That Separates You
Learn to predict whether a swarm will work before it flies.
Flight tests are expensive and battlefields are not labs. The engineers who stand out can look at a configuration and call it. You should know how to:
- Check the stability condition from the largest Laplacian eigenvalue before choosing a gain, and know why packet loss can hide a bad gain: a thinned graph has a smaller largest eigenvalue, so a lossy swarm can survive a setting that would wreck a perfect one
- Estimate time to agreement from lambda 2, the gain and the packet loss rate
- Raise lambda 2 cheaply by adding a few long-range links, the small-world trick
- Keep consensus honest when one drone is compromised and broadcasts bad values (resilient consensus, trimmed updates)
- Turn those physics quantities into features and show a model with them beats a model without them
The Project To Learn These Skills This Week
Certify a leaderless drone swarm before it launches. This is a graded Pro project on GRADuateML: Swarm Consensus: Certify a Leaderless Drone Swarm Before Launch. Every one of the 20,000 training missions was actually simulated: drones on a random radio graph, links dropping packets every step, each drone running the consensus update above. The hidden test fleet is bigger and denser than anything in training, so a model has to learn the physics rather than memorize ranges. The punchline: boosted trees on the raw columns reach a ROC-AUC of 0.950 on the new fleet and miss the bar. Add the spectral features and the same kind of model reaches 0.987. Not on Pro? The free challenge below is the consensus update, by hand.
Requirements (each one is a graded milestone):
- Read the flight logs: the success rate, and how missions fail (split apart, too slow, or diverged).
- Find the stability limit: no mission with gain times the largest eigenvalue below 2 ever diverged. Explain why only about half of those above it did, and fix the rule for packet loss.
- Show that lambda 2 separates connected swarms from split ones perfectly, while the tempting rule "no drone is isolated" does not.
- Fly a six-drone ring by hand and match the closed-form eigenvalue solution.
- Measure what packet loss costs: at 40 to 50% loss, agreement takes 1.75x longer, almost exactly what the 1 / (1 - p) prediction says.
- Predict mission success on the new, larger fleet: ROC-AUC of at least 0.965 and balanced accuracy of at least 0.90.
- Build a pre-flight go/no-go check with precision of at least 0.93 and recall of at least 0.80 that runs in under 2 seconds, then write the certification note.
This project teaches a practical lesson for production ML:
When you know the physics, put it in the features. The model will thank you with fewer examples and fewer surprises.
If you want to sharpen your machine learning skills even more, I also selected a free challenge problem for you this week. It is the consensus update from above, run by hand on a small graph:
If you learned something from this newsletter, make sure to forward it to a friend.
GRADuateML
The full swarm consensus build, graded against a hidden test set, is part of GRADuateML Pro.