A Swarm's Hard Problem Is Authority, Not Autonomy

Task Force 59 was stood up in 2021 to put unmanned systems and AI into daily operations with the Fifth Fleet. Four years on, the interesting question is no longer whether an unmanned surface vessel can cross a stretch of water on its own. That has been demonstrated.

The interesting question is what happens when four of them are working the same piece of water, the link to the operator drops, and something has to decide.

Platform autonomy is a solved demo. Orchestration is the unsolved problem, and the hard part of orchestration is authority.

Autonomy was the easy milestone, and the link breaks first

Teaching one hull to navigate, hold a station, and run a sensor package is an engineering problem with a clear pass mark. You can test it. You can watch it. You can put it in a slide.

A swarm is a different kind of object. Its value comes from behavior that no single platform exhibits: coverage that persists, a formation that redistributes when one node drops out, a picture assembled from partial views. None of that can be tested by watching one boat.

It also changes what failure looks like. A single platform that fails is a lost asset. A swarm that fails can fail quietly, by converging on the same wrong picture, or by doing something coordinated that nobody ordered.

Every architecture for unmanned operations eventually meets the same constraint. In contested water, the link is the first thing an adversary attacks, because it is the cheapest thing to attack. Jam the satellite link, spoof the navigation, and a centrally controlled system becomes expensive debris.

The answer is to push decision-making onto the platforms. Local processing, peer-to-peer coordination, and a mission intent that survives the loss of the link.

That answer creates the next problem. If the platform decides locally, the platform's rules become the rules of the operation. A human on the loop is only meaningful if the loop still exists when the link is down, and at that point the human is not in the loop at all. They are in the intent, written earlier, in a document that the platform is interpreting.

That is a design choice with a legal consequence, and it should be made explicitly rather than discovered during an incident review.

The authority question

Three questions decide whether a swarm is deployable.

Who holds the authority for a coordinated action. A single platform painting a target is one thing. Six platforms converging on it is an operational decision with a shape, and the authority for that shape has to exist before the action does.

What the swarm does when the picture is ambiguous. Two contacts, one of them a fishing vessel. A confidence threshold that is right 95 percent of the time will be wrong on a schedule, and the wrongness is not distributed evenly across the consequences.

What the record shows afterward. If a coordinated action happens, the reviewer needs the intent, the inputs each platform saw, the coordination messages, and the point where a human approval existed or did not. Without that, accountability defaults to whoever was on watch, which is neither fair nor useful.

The Navy's public framing has been human-on-the-loop: people set objectives and boundaries, machines execute inside them. That framing is correct and incomplete. The boundary is only real if it is enforced somewhere other than the model's good behavior, and the objective is only clear if somebody wrote it in a form a machine can refuse.

Interoperability is where the schedule goes

The fleet will not buy one vendor's swarm. It will buy platforms from several, integrate sensors from others, and connect them through a command-and-control layer that was specified before any of the platforms existed.

That makes the interface the critical path. Open architectures, common tasking interfaces, and a data model that survives a vendor being replaced are not procurement preferences. They are the difference between a capability that can be upgraded and one that has to be re-bought.

The pattern is familiar from every integration program. The platform demos well. The interface is discovered late. The schedule absorbs the difference.

There is a specific version of this problem for autonomy. Two platforms that each navigate correctly can still collide if their coordination protocol assumes a shared clock, a shared frame of reference, or a shared definition of "safe distance." Standardization work is unglamorous and it is the difference between a swarm and a crowd.

What to measure instead of autonomy

If autonomy is the wrong metric, what replaces it.

Coverage per platform-hour, because persistence is the capability the Navy is buying. Resilient behavior under link loss, measured by taking the link away in a test rather than assuming it. Decision latency from detection to a coordinated response, including the human approval step. And a record that can be replayed, because a coordinated action nobody can reconstruct is a capability the command cannot authorize twice.

Add one more: the rate at which the swarm produces a picture that is confidently wrong. That number is hard to measure and it is the one that ends programs.

The measure is trust, not cleverness

Unmanned systems are cheap enough to lose and numerous enough to matter. Those two properties are what make them useful, and they are also what make the authority problem urgent. A system you can afford to lose is a system you will send into places where the decision matters.

The platforms will keep improving. The edge compute will get smaller, the models will get better, and the demos will look more convincing every year.

What will not improve on its own is the answer to a simple question: when the link is gone and the swarm acts, who decided, and how would you show it?

That answer is doctrine, interface design, and a record. It is not a model, and it is the part that determines whether any of this is deployable.