Skip to main content

Inteldefense

Replicator 2 Is Counter-Drone Work, Not a Software Phase

The program's second line of effort went to countering small drones. The coordination software everyone talks about sits somewhere else.

The program's second line of effort went to countering small drones. The coordination software everyone talks about sits somewhere else.
Contents
  1. What the program actually is
  2. Why the coordination layer is the hard part
  3. Counter-drone work is the other half of the same problem
  4. What a contractor should take from this
  5. The honest read

Replicator was announced in August 2023 with a target of fielding thousands of uncrewed systems within about two years. A former defense official has since put the number fielded in the hundreds (opens in a new tab).

That gap is the most useful fact about the program, and it is not an airframe problem. The airframes exist. The bottleneck is everything required to make a few hundred uncrewed systems operate as one thing: autonomy software, command and control, and the data layer that lets systems from different vendors share a picture.

The second useful fact is that "Replicator 2" does not mean what most of the commentary assumes. It is not the software phase. It is counter-drone work.

What the program actually is

Replicator is a Department of Defense initiative led by the Defense Innovation Unit. Its first line of effort, Replicator 1, is all-domain attritable autonomous systems: cheap enough to lose, numerous enough to matter. The department has confirmed selections including AeroVironment's Switchblade 600, Anduril's Altius-600 and Ghost-X, and Performance Drone Works' C-100, with uncrewed surface and subsurface systems named only in categories.

Replicator 2 was announced in a September 27, 2024 memo by then-Secretary of Defense Lloyd Austin, and its focus is countering small uncrewed aerial systems.

Funding has been modest and episodic: a $300 million FY2023 reprogramming request, $200 million in FY2024 appropriations, and a $500 million request for FY2025. That is not the budget of a program buying thousands of anything. It is the budget of a program trying to prove an acquisition path.

The gap between the target and the count is a software and acquisition problem, and the department has funded it that way: seven companies selected for autonomy and command-and-control software support.

Why the coordination layer is the hard part

An attritable system is a procurement decision. A swarm is an engineering decision, and the engineering is not in the platform.

Cooperative behavior requires that systems from different manufacturers agree on a picture of the world, a tasking model and a fallback when the link drops. That means common message formats, a shared time reference, and a way to arbitrate when two systems claim the same target. None of that is delivered by buying more airframes. All of it has to be specified by the customer, because no vendor has an incentive to make its platform interchangeable with a competitor's.

The Congressional Research Service notes that swarming would likely require further advances in artificial intelligence or networked communications. That is a careful way of saying the software is not solved. It is also where the schedule risk lives, because software integration is the part of a program that cannot be accelerated by adding production capacity.

There is a second constraint that gets less attention. Autonomy at scale needs bandwidth, and the electromagnetic environment over a contested area is the one thing an adversary can attack cheaply. A coordination scheme that assumes a live link is a coordination scheme that fails first.

Counter-drone work is the other half of the same problem

Replicator 2 moving to counter-small-UAS is not a retreat from autonomy. It is the department buying the defense against the capability it is also buying.

The cost-exchange logic that makes attritable systems attractive cuts both ways. A cheap drone that forces an expensive interceptor is a good trade for the attacker. The defender's answer cannot be a missile per drone, so it has to be detection, classification and a cheap defeat mechanism, which is a sensor-fusion and decision-speed problem. The same software stack that coordinates a swarm classifies an incoming one.

That is the reason to read Replicator 2 carefully. A contractor selling autonomy software has a customer in both lines of effort. A contractor selling airframes has a customer in one, and only until the production tranche closes.

What a contractor should take from this

Three things, in order of usefulness.

  1. The software opportunity is in Replicator 1's tranches, not in a phase name. The autonomy and C2 contracts went to seven companies in late 2024. Expect the follow-on work to be integration and testing against government reference implementations, not new platforms.
  2. Interoperability is a requirement, not a differentiator. If your system only talks to your own ground station, you are selling a closed ecosystem to a customer whose stated intent is to mix vendors. Open interfaces are the price of admission, and they are also the thing that gets you replaced by a competitor who does them better.
  3. Assume the link is gone. Design the behavior so a system that loses communication degrades to something safe and predictable. The program office will ask. The answer determines whether your platform is allowed near a formation.

The honest read

Replicator is behind its original target, and the useful question is not whether the department will hit a number. It is whether the acquisition path it is testing survives contact with a program of record.

The software layer is where that gets decided. Platforms are now the commodity in the transaction, and the coordination layer is the part that has to be specified, tested and sustained. Contractors who treat it as an integration afterthought will build something that demos well and fields never.