Standards for Military Autonomy: Avoiding AI Fratricide

A hundred drones in the air isn’t the scary part. The scary part is a hundred drones in the air that can’t speak the same operational language.

That’s the real lesson many defense teams took from Ukraine’s widely discussed “Operation Spiderweb” style of drone employment: operators still planned, tasked, and launched systems, but autonomy handled the coordination work—navigation, timing, and deconfliction—at a scale that would grind a human-only control model into dust. The takeaway isn’t “robots are coming.” It’s that autonomy is already here, and it’s arriving in layers.

In the AI in Defense & National Security series, I keep coming back to a simple idea: mission advantage comes from integration, not novelty. If the Department of Defense doesn’t set a shared standard for autonomy—definitions, interfaces, and operator trust—the force risks building a future where systems are individually impressive and collectively unreliable. In a crisis, that’s not a procurement issue. It’s a survivability issue.

The autonomy problem isn’t “too much AI”—it’s too many meanings

The fastest way to derail an autonomy program is to let every stakeholder use the same word to mean different things.

Right now, “autonomous” can mean anything from a polished operator interface that reduces clicks, to a waypoint-following autopilot, to a system that plans and executes tasks with minimal supervision. Vendors have incentives to stretch the term; program offices have incentives to interpret it in ways that fit a requirement; operators have incentives to distrust it when it’s ambiguous.

A useful way to think: autonomy is layered, not binary

Autonomy in defense systems is rarely an on/off switch. It’s a stack of capabilities that can be introduced incrementally and constrained by mission context. A practical taxonomy tends to separate:

• Perception: sensing, tracking, classification, state estimation
• Decisioning: course-of-action generation, prioritization, deconfliction
• Control: navigation, flight/drive control, formation keeping
• Tasking & coordination: mission assignment, timing, handoffs, teaming
• Safety & constraints: geofencing, rules of engagement logic, abort behaviors

When people argue about autonomy, they’re often arguing about which layer is being automated—and whether the system can explain its behavior at that layer.

A system isn’t “autonomous” in the abstract. It’s autonomous at specific functions under specific constraints.

Why this matters for acquisition and operations

Without shared definitions, the government can’t compare proposals cleanly or build a roadmap that composes capabilities across programs. You end up with:

• Overbuying “autonomy” features that don’t reduce workload in the field
• Underbuying integration work (interfaces, test harnesses, assurance)
• Surprises during joint exercises when systems can’t coordinate

The result is a force that owns autonomy but can’t operate it jointly.

Interoperability is the real battlefield advantage

If autonomy is going to matter in a high-end fight, it has to work across services, across domains, and often across allies.

That’s where interoperability stops being a nice-to-have and becomes the center of gravity. In practical terms, interoperability means systems can exchange data and interpret it the same way quickly enough to matter.

Taiwan Strait scenarios expose the seams

A Taiwan Strait contingency (or any fast-moving crisis in the Indo-Pacific) is a harsh test for autonomy because it forces joint and combined operations in a contested environment. Air, maritime, and land-based unmanned systems may need to share:

• track data and confidence levels
• mission tasking and timing constraints
• deconfliction rules
• communications status and fallbacks

If each service fields autonomy with its own internal language for tasking and reporting, you get the modern equivalent of radios that can’t tune to the same frequency. In the fog of war, the price is missed opportunities at best and fratricide at worst.

“Swarm” outcomes depend on shared messaging

The public fixates on swarms as if the magic is in the number of drones. In reality, the magic is in coordinated behaviors that emerge from:

• consistent tasking formats
• shared state assumptions
• predictable conflict-resolution rules

If one system interprets “hold at waypoint” as “orbit at 200m radius” and another interprets it as “loiter in place,” you don’t have a swarm—you have a midair negotiation with physics.

Pick the right standard layer—or you’ll standardize the wrong thing

Standardization works when it targets a layer that enables interoperability without freezing innovation.

The internet didn’t win because everyone used the same website design. It won because core transport protocols allowed wildly different products and services to communicate. Defense autonomy needs a similar mindset: standardize what must be shared, and keep competition alive everywhere else.

Reference architectures help, but fragmentation still wins by default

Government reference architectures are meant to reduce integration friction. Some efforts focus on payload integration, others on message structures, others on mission-level orchestration. The problem is pace and consistency: when each service adheres to its own framework, joint interoperability becomes an afterthought.

A workable DoD-wide approach should answer one practical question:

What is the minimum set of interfaces that allow any compliant autonomous system to be tasked, to report, and to coordinate safely with others?

What to standardize first: “tasking and messaging” is the best bet

If you standardize hardware too early, you freeze the market. If you standardize algorithms, you slow adaptation. The sweet spot is typically tasking and messaging, because it’s where operators and systems meet.

A solid autonomy messaging standard usually includes:

1. Task specification: what to do, priorities, timing, constraints
2. Status reporting: where it is, what it’s doing, confidence, comms health
3. Event reporting: detections, engagements, aborts, anomalies
4. Deconfliction primitives: right-of-way, separation minima, keep-out zones
5. Identity & trust signals: authentication, authorization, integrity checks

This layer also shapes acquisition: if a program office can buy “any autonomy module that speaks the standard,” the vendor ecosystem competes on performance and reliability instead of proprietary lock-in.

A practical analogy procurement teams understand

Think about why USB spread so fast: it made devices interoperable for end users and made the market bigger for manufacturers. A well-chosen autonomy standard does the same thing:

• operators get predictable behaviors and faster onboarding
• integrators reduce custom glue code
• vendors focus on capability instead of bespoke interfaces

And yes—legacy solutions that can’t adapt will get squeezed out. That’s a feature, not a bug.

Trust is an operational requirement, not a training slide

Operators don’t distrust autonomy because they dislike technology. They distrust it because they’ve been burned by systems that behave differently than advertised, fail silently, or require heroic troubleshooting under stress.

Calibrated trust is the goal: not blind faith, not reflexive skepticism—confidence that matches reality.

Trust grows from observable behavior

If you want autonomy that’s used in contested environments, the system must provide ways for operators to understand what’s happening without turning them into software debuggers.

Three capabilities consistently move the needle:

• Explainable state at the right level: not “here are neural net weights,” but “tracking target A with 0.82 confidence; lost GPS; switching to visual odometry; expected position error 15m.”
• Diagnostics and rehearsal tools: the ability to run “what happened?” reviews, trend anomalies, and test mission profiles before deployment.
• Graceful degradation: clear, predictable behavior when comms drop, sensors degrade, or navigation becomes uncertain.

The human-in-the-loop question needs a mission answer

Programs like loitering munitions and low-altitude strike systems highlight a hard truth: autonomy can do a lot—track, follow, time, avoid—but policy and operational design often keep target selection and engagement authorization in human hands.

That’s not a weakness. It’s a design choice. But it requires precision in how requirements are written.

Instead of saying “autonomous targeting,” a better requirement might be:

• Autonomous track and maintain custody of a moving target for 10 minutes
• Autonomous deconfliction with friendly systems within defined volumes
• Human-confirmed engagement within a defined time window
• Post-action reporting with sensor snapshots and confidence metadata

This kind of clarity protects operators, keeps vendors honest, and makes test and evaluation measurable.

The policy imperative: stop letting marketing define autonomy

If the Pentagon doesn’t define autonomy clearly, industry marketing will. And marketing language doesn’t survive first contact with a joint task force.

A department-wide autonomy standard should do four things quickly:

1) Publish a shared autonomy taxonomy

Not a 200-page document that nobody uses. A short, enforceable vocabulary that program offices must reference in solicitations and test plans.

2) Mandate a common messaging/tasking layer for new starts

Treat it like a baseline requirement for interoperability—especially for systems expected to team, swarm, or operate in proximity.

3) Fund integration and test infrastructure as “first-class” work

Most autonomy failures aren’t algorithm failures. They’re integration failures: timing, message semantics, edge cases, and mismatched assumptions. Build test harnesses, digital twins, and joint exercise instrumentation that expose those seams early.

4) Make operator trust measurable

If trust is essential, measure the inputs:

• workload reduction (time-on-task)
• operator intervention rate
• false alarm rate and missed detection rate
• mission success under degraded conditions
• recovery time from faults

When these metrics are tracked, trust becomes something you can engineer—not something you hope for.

What defense leaders can do in the next 90 days

Most companies and program teams wait for a perfect standard and then wonder why nothing interoperates. There’s a better way: start by making today’s efforts composable.

Here’s a practical checklist I’ve found effective for autonomy programs and AI in national security deployments:

1. Write requirements in outcomes, not buzzwords. Specify measurable behaviors, constraints, and reporting.
2. Demand interface clarity. If a vendor can’t show tasking formats and status semantics, they’re not ready for joint integration.
3. Run a “mixed fleet” demo early. Put at least two vendors’ systems in the same scenario and force deconfliction and handoffs.
4. Bake in cyber and identity controls. Autonomy messaging is a high-value target; authenticate and authorize everything.
5. Train operators with the real UI and real failure modes. Trust comes from seeing edge cases before they happen in combat.

These steps don’t require a moonshot. They require discipline.

Where this fits in AI in Defense & National Security

Autonomy is one of the most visible faces of AI in defense, but it’s not separate from the rest of the stack. The same forces show up in surveillance analytics, ISR fusion, cybersecurity, and mission planning: if you can’t standardize how systems share meaning, you can’t scale operational advantage.

A future joint force will be measured less by how many autonomous platforms it owns and more by how well it can task, trust, and coordinate those platforms under stress. Standards are how you get there.

If your team is building or buying autonomy now, the highest-value question isn’t “how advanced is the AI?” It’s this: Can it interoperate, and can an operator trust it when the plan breaks?