Agent Swarm Lab

A swarm of drones flies at a target and a defender tries to shoot it down. The swarm is organized in one of two ways: central, where one controller drone coordinates everybody, or mesh, where the drones coordinate with each other and nobody is in charge. This page is a simulated Monte Carlo wargame that runs the same fight thousands of times in your browser and counts how often each design gets through.

Every number here is invented. Distances are units, time is ticks, and none of the parameters describes a real aircraft, weapon or defensive system. The point is the shape of the result, not its size.

Every figure on this page is simulated: arithmetic over made-up parameters, computed in this tab from a seed you can see and change. Nothing here is measured.

Loading the simulation…

One fight, both ways

Both panels replay the same trial from the same seed: the same starting positions and the same dice for every shot. Only the swarm’s organization differs. Drones fly left to right toward the target line; the defender fires from the target. The ringed drone is the central swarm’s controller. In the mesh panel the same drone flies the same path and coordinates nothing.

Thin lines are live radio links. Every dot is one message from the engine’s own log for this run — every send, every hop, every delivery — and a red dash is a message lost to jamming; nothing is drawn that the engine did not send, and nothing it sent is left out. The central swarm is a star: every drone talks only to its controller, so when the controller falls every link goes with it. The mesh is a web: every drone talks to every drone in range and passes on what it has heard. A drone ringed in grey is stale — the freshest thing it has heard is older than the staleness limit. Tap or click any drone to see what it knows.

Central — one controller

—

Mesh — peer to peer

—

Tap or click a drone to see what it knows.

flying
holding (lost its controller)
shot down
reached the target
interceptor hit
interceptor miss
live radio link
message
message lost to jamming
stale: has not heard anything fresh enough
sensor range (limited sensor only)
sees the target itself
knows where the target is only from messages

Change the fight

Every change replays one sample run above and reruns 10,000 trials of each design for the histogram below.

With a limited radio or sensor range, any jamming, or the most-connected target, every link is simulated tick by tick, which costs far more. The page then runs 2,000 trials for the histogram and 200 for each chart point, and the size chart samples every 4th swarm size. Each chart says which count it used.

Swarm size 28 drones

Interceptors 32

Hit chance per shot 0.5

Reload time 2 ticks

Success needs 20 drones to arrive (K)

The defender shoots at

Central speed 1.25× mesh speed (default 1.25)

After losing its controller, a central swarm holds for 10 ticks, then carries on as a mesh Never recovers (the default)

Radio range 40 units Unlimited range (the default)

Sensor range: a drone sees the target only within 60 units of it, and otherwise knows where it is only from messages Every drone always sees the target (the default)

Relaying: mesh drones pass on what they heard from others, not only what they saw themselves (on by default)

Jamming: each link is down 0 of the time (default 0)

Staleness limit: a drone keeps acting on information up to 0 ticks old (default 0: it must hear from somebody this tick)

Seed

Sets 28 drones, 32 interceptors, a hit chance of 0.5, a reload time of 2 ticks and K = 20, and leaves everything else as you set it. These values were chosen by measuring a grid of settings for the ones where the recovery curves separate: there, a central swarm that recovers at once beats the mesh, and one that waits a few ticks falls behind it. The page opens at these settings, because at the engine’s defaults two of the charts below are flat. “Sealed defaults (PF-S410)” restores every engine default — the settings the page’s first results and the blind prediction below belong to.

“Relaying matters” sets every control: 36 drones, 24 interceptors, a hit chance of 0.7, a reload time of 3 ticks, K = 25, a sensor range of 80 units, a radio range of 20 units, no jamming, and the rest at the engine’s defaults. At these settings the mesh reaches the target in 66% of runs with relaying and 34% without (2,000 runs each way, the same runs; each figure could be off by about ±2 points). The effect holds from 26 to 36 drones at these settings: at every swarm size in that band, relaying adds at least 5 points. These settings were chosen by measuring a grid of settings for where relaying makes the clearest difference. At many other settings the difference is smaller or absent — with an unlimited radio range, for example, every drone hears whoever sees the target directly, and relaying adds nothing.

How fast must a central swarm recover?

A central swarm is only as fragile as its rule for losing the controller. This chart puts the defender on the controller and asks how long the rest of the swarm can take to pick itself up. It plots mission success against the recovery delay, one curve per design, at every other setting you chose. Each point is 2,000 trials, every 2 ticks from 0 to 40 (200 when the settings are linked). The mesh has no controller to lose, so its curve is flat. When the curves cross, the marked line is the break-even delay: the longest delay at which the central swarm still matches or beats the mesh. When they don’t, the chart says so instead of marking the edge of the range.

—

How much jamming can each design take?

Mission success against jamming — the share of links that are down on any given tick — one curve per design, at every other setting you chose. Each point is 200 trials, every 10% from none to every link down. A central follower needs its one link to the controller; a mesh drone needs any one of its links.

—

How big does the swarm need to be?

Mission success probability against swarm size, one curve per design, with every other setting held where you left it. Each point is 2,000 trials, every 2 drones from 2 to 60; the histogram below uses the full 10,000.

Any gap between these two curves comes from the settings above, not from the designs themselves: the central speed you chose, and the recovery rule. At the defaults, a central swarm flies 1.25 times as fast as a mesh and never recovers from losing its controller, and the gap below is what those two assumptions produce.

—

How many get through?

For the current settings: how many trials out of 10,000 ended with each number of drones at the target. The dashed line is K.

—

	Central	Mesh
Mission success	—	—
Average drones arriving	—	—
Shot down, all trials	—	—
Lost coordination, all trials	—	—

A model’s prediction, made blind, then graded

This is the one part of the page with an AI model in the loop. Before any of the four scenarios below had been simulated, claude-opus-5-5 was given a parameter file describing the rules and asked, for each scenario and each design, at what swarm size mission success first reaches 50%. It ran on 27 September 2026 (UTC) in a fresh session with no tools, no files and no network, and its answer was committed before the grading run existed. The simulation then measured each value over 10,000 trials per swarm size, seed 410. The prediction and its grade belong to the page’s original rules, which are today’s defaults: a central swarm that loses its controller never recovers, and central drones fly 1.25 times as fast as mesh drones.

All four scenarios use a hit chance of 0.6, a reload time of 2 ticks and K = 8. The rule, fixed before anything was measured: a prediction within 2 drones of the measured value is a hit, and “never” is a hit only against a measured “never”.

These figures belong to the sealed defaults (PF-S410), not to the settings the page opens at.

8 of 8 predictions were hits; 6 were exact. Every cell is shown, misses included.

Scenario	Interceptors	Aims at controller	Design	Predicted	Measured	Off by	Result
S1	8	off	central	13	13	0	hit
S1	8	off	mesh	13	13	0	hit
S2	8	on	central	never	never	0	hit
S2	8	on	mesh	13	13	0	hit
S3	24	off	central	17	17	0	hit
S3	24	off	mesh	20	19	1	hit
S4	24	on	central	never	never	0	hit
S4	24	on	mesh	20	19	1	hit

Two things limit what this score means. First, the parameter file states every rule of the simulation, so a careful reader can work most of these numbers out with a binomial table: this measures reasoning about a fully described model, not intuition about real swarms. Second, the model that made the predictions is the same model that wrote the simulation. It ran in a fresh session with no tools and saw only the parameter file and the prompt, but it is not an independent party.

What the model said, in its own words

S1: All 8 shots land before any arrival and go at non-controller drones; kills ~Bin(8,0.6), so need N-kills>=8, crossing 50% at N=13 for both.
S2: Priority sends every shot at the controller, which dies with probability ~0.9993 and collapses the swarm; MESH ignores the toggle and matches S1.
S3: CENTRAL: ~14 shots hit other drones before they arrive and the tick-28 shot targets the controller, giving kills ~Bin(14,0.6) and crossing at ~17. MESH is slower, so ~18 shots land on the others plus about 1 on drone 0, crossing at ~20.
S4: The controller is targeted first and dies almost surely, collapsing the swarm; MESH is unaffected by priority and matches S3.

The exact message the model was sent

You are taking part in a blind prediction. Below is a parameter file describing a simple, made-up Monte Carlo model of a drone swarm attacking a target while a defender fires interceptors. It has two coordination architectures, CENTRAL and MESH, and four scenarios.

You have no tools and no other information. Nobody has run these scenarios yet, so there are no results to find. Reason from the rules alone.

For each of the four scenarios and each architecture, predict the measured value described in the parameter file: the smallest swarm size N (from 2 to 60) at which the mission success rate reaches at least 50%, or "never" if no N from 2 to 60 gets there.

Answer with a single JSON object and nothing after it, in exactly this shape:

{"predictions": [
  {"scenario": "S1", "central": <integer or "never">, "mesh": <integer or "never">, "rationale": "<one or two sentences>"},
  {"scenario": "S2", ...},
  {"scenario": "S3", ...},
  {"scenario": "S4", ...}
]}

You may think before the JSON, but the JSON object must be the last thing in your answer.

--- parameter file (params.json) follows ---
{
  "title": "Agent Swarm Lab — blind prediction parameter file",
  "note": "Every number here is invented and abstract. Distances are units, time is ticks. Nothing is calibrated against any real system.",
  "model": {
    "swarm": "A red swarm of N drones, numbered 0 to N-1, flies straight at a target. Drone 0 is the controller in the CENTRAL architecture; in the MESH architecture drone 0 flies exactly the same path and coordinates nothing.",
    "startDistance": "Drone 0 starts 150 units from the target. Every other drone starts 100 + J units away, where J is a whole number drawn uniformly from 0 to 40 inclusive, independently per drone.",
    "speed": "CENTRAL drones move 5 units per tick. MESH drones move 4 units per tick (peer-to-peer coordination costs time). A drone starting D units away arrives at tick ceil(D / speed).",
    "defender": "The blue defender fires one interceptor at tick 0, then one every R ticks (ticks 0, R, 2R, ...), until it has no interceptors left or nothing to shoot at.",
    "targetable": "A drone is a target while it has not been shot down and has not arrived. A drone that arrives at tick t cannot be shot at tick t or later.",
    "targeting": "Each shot goes at the nearest target (ties: lowest drone number). If the priority toggle is ON and the swarm is CENTRAL, the shot goes at the controller instead, whenever the controller is still a target. In MESH the toggle has no effect.",
    "hit": "Each shot hits with probability p, independently. A hit shoots the target down.",
    "centralCollapse": "CENTRAL only: if the controller is shot down, every drone that has not yet arrived stops where it is and never arrives. The defender keeps shooting the stopped drones, nearest first, until it runs out of interceptors or the controller's own planned arrival tick has passed. Stopped drones never reach the target.",
    "mesh": "MESH: nothing collapses. Any drone that is not shot down arrives.",
    "success": "A trial is a mission success for red when at least K drones reach the target."
  },
  "common": {
    "p": 0.6,
    "R": 2,
    "K": 8
  },
  "scenarios": [
    {"id": "S1", "interceptors": 8, "priority": false},
    {"id": "S2", "interceptors": 8, "priority": true},
    {"id": "S3", "interceptors": 24, "priority": false},
    {"id": "S4", "interceptors": 24, "priority": true}
  ],
  "measurement": "For each scenario and each architecture, the swarm size N is swept from 2 to 60 in steps of 1, with 10,000 independent trials at each N. The measured value is the smallest N at which the mission success rate is at least 50%. If no N from 2 to 60 reaches 50%, the measured value is \"never\".",
  "grading": "Locked before any measurement exists. A prediction is a HIT when it is within 2 drones of the measured value (|predicted - measured| <= 2). When the measured value is \"never\", only a prediction of \"never\" is a hit; when the prediction is \"never\" and the measured value is a number, it is a miss. Every cell is published, hits and misses alike."
}

How this works

Made-up parameters. Nothing is calibrated against a real system. Distances are units and time is ticks.
Seeded and reproducible. The same seed and settings give the same result every time, on any machine. Each trial has its own random stream, and both designs share it, so they face the same dice.
What one trial does. Drones start 100 to 140 units out; the controller starts at 150, behind everyone. Mesh drones move 4 units a tick, and central drones move that times the speed setting. The defender fires one interceptor at tick 0 and then once per reload, at the nearest drone — or, with the toggle on, at the central controller. If the central controller is shot down, every drone that has not arrived stops, and the recovery setting decides what happens next. A trial succeeds when at least K drones reach the target.
Central speed is an assumption. It assumes that following one controller is faster than agreeing among peers, by exactly the factor you set: at the default of 1.25, a central drone covers 1.25 times the mesh’s 4 units a tick.
Recovery is an assumption. It assumes that when the controller falls, the other drones stop where they are, wait the delay you set, and then fly on as a mesh at mesh speed; the default, “never”, assumes they never regroup at all.
Radio range is an assumption. It assumes two drones can talk only while they are closer than the range you set, measured along the approach; by default every pair is in range. A drone that cannot reach the drones it needs holds where it is until it can.
Sensor range is an assumption. It assumes a drone sees the target only while it is closer than the range you set, and otherwise knows where the target is only from what it was told; one that knows nothing keeps searching toward the target area at half speed. By default every drone always sees it.
Jamming is an assumption. It assumes every link fails on its own, independently, with the chance you set, and comes back the next tick with the same chance. Which links fail is drawn from the seed, so a run is reproducible and both designs lose the same links.
What a message carries. Each piece of information names who created it, the tick it was created, the target position its creator believed and the order it held. Every tick the controller creates orders, each follower creates a report for the controller, and every mesh drone creates its own observation. Every drone sends one message over every live link it has each tick; a message crosses one link per tick and a jammed link drops it. The counts under each panel are the engine’s log, and they always add up.
How relaying works. A star relays nothing: a follower takes orders only from the controller, so one out of the controller’s range never gets them, however close another follower is. A web relays everything: a mesh drone’s message carries the freshest thing it has heard from every other drone, so news reaches a drone with no direct link to its source one hop a tick, a tick older for every extra hop. Relaying never changes whether a drone moves: everybody creates something new every tick, so a drone that hears anything at all hears a neighbor’s own fresh information first. With an unlimited sensor it changes nothing else either, since every drone sees the target itself. With a limited sensor range it carries where the target is, which decides how fast a drone flies. With a sensor range of 60 units, at the Near the cliff settings the mesh reaches the target in 5.2% with relaying against 1.5% without at a radio range of 20 units; 5.7% with relaying against 3.9% without at a radio range of 30 units; 6.0% either way with an unlimited radio range (2,000 runs each).
Drones decide only from what they received. A drone steers toward the target position it has been told, acts on the orders it holds, and moves only while the freshest information it has received from another drone is recent enough. It never reads another drone’s state or the defender’s, and the only thing it learns without a message is the target itself, when it is within sensor range. A central follower acts only on the controller’s orders even then: its report tells the controller, whose next orders carry the sighting back. One exception is kept from before: a mesh drone or the controller that is the last one left in the air flies on alone, with nobody left to hear from.
The staleness rule. The staleness limit is how many ticks old a drone’s freshest received information may be before it stops acting in concert and holds. At the default of 0 it must hear from somebody every tick, which is exactly the rule this page used before messages carried anything. Raise it and a drone rides out a few jammed ticks on the last orders it heard.
Most-connected targeting. It has the defender shoot whichever drone has the most live links, on both designs: against a star that is the controller, against a web it is the best-connected relay. It is the fair version of “aim at the controller”. Against the mesh, shooting the best-connected drone instead of the nearest one makes almost no difference, even at radio ranges short enough to turn some drones into relays: at the Near the cliff settings the mesh succeeds in 20.6% against 20.8% at a range of 10 units, 32.6% against 32.6% at a range of 20 units, 32.6% against 32.6% at a range of 40 units (2,000 runs each) — because each hit still removes exactly one drone, and losing one relay rarely cuts anybody else off.
One option is one-sided. Only the central swarm has a controller, so “the central controller first” changes only the central fight; against the mesh that option shoots the nearest drone. Most-connected targeting applies to both.
What the model saw. Only the parameter file and the prompt shown above. It had no tools and no access to this code or to any result.
Where it runs. The simulation is Go compiled to WebAssembly, running in a background worker in your browser. Nothing is sent anywhere.

The same trade-off in software

Swarms of AI agents are often built the central way: one “swarm controller” hands out the work and every other agent talks only to it. That is a star network, and a star has one point of failure: lose the controller and every link goes with it, which is what the left panel shows the moment the defender hits the ringed drone. A peer-to-peer design is a web, and losing one agent only thins it. The communication layer matters as much as the shape. A message bus that drops messages degrades agents the same way jamming degrades these drones: each lost message is a moment an agent cannot act on what the others know, and a star feels it at every follower while a web can often get the message through another way. Whether the central design is worth it depends on how much its controller saves, how quickly the rest can carry on without it, and how reliable the links are — the settings on this page.