- DK NEJET
Autonomy is architecture, not a feature
We’ve heard and read it many times – “our drone has autonomy.”
The issue, however, is that autonomy isn’t a feature “to be had.” It is the core architecture thing – the drone can be autonomous or it’s not, and an autonomous drone has to be able to make decisions on its own.
Therefore, before we dive deeper, here are a few questions to ask when you want to check if the drone is really autonomous:
- What can the system decide?
- Under what conditions?
- What happens when GPS is unavailable, communications degrade, or the operator cannot monitor every asset?
- And how does a human retain command when the system is acting independently?
- Automation asks: “Can the system perform this task?”
- Autonomy asks: “Can the system still pursue the mission when the environment changes?”
- Human-directed operation: The operator controls the critical actions.
- Automation-assisted operation: The system performs bounded tasks, such as holding a route or maintaining a state.
- Supervised autonomy: The system executes a delegated task while the operator monitors behavior and can intervene.
- Mission-level autonomy: The system coordinates actions across assets and conditions to pursue an operator-defined objective.
- Mission intent: What outcome must be achieved, and what constraints apply?
- Perception and state estimation: What does the system understand about itself, its surroundings, and changing conditions?
- Decision logic: What actions may it take, under what conditions, and within what boundaries?
- Communications and navigation resilience: What happens when GPS, connectivity, or operator oversight is degraded?
- Human-machine interface: How does an operator express intent, monitor behavior, intervene, and regain control?
- Assurance, training, and sustainment: How does a force trust, test, update, and operate the system over time?
- What decisions can the system make?
- What boundaries constrain those decisions?
- How does it behave when communications or navigation degrade?
- How does the operator retain command and intervene?
- How does it coordinate with other systems?
- How is it tested, trained, updated, and sustained?
These questions reveal the real issue: autonomy is not a feature added to an unmanned platform. It is an architectural property of the entire mission system.
Automation Is Not Autonomy
Automation and autonomy are often used interchangeably, and to do that is wrong.
Automation performs a predefined task according to rules set by a human: follow a route, maintain an altitude, trigger a procedure, or return when the battery reaches a certain level. It is valuable because it is repeatable, predictable, and reduces operator workload.
Autonomy is different. It is the ability of a system to pursue an objective within defined boundaries when conditions change. NATO describes autonomy as a system’s ability to function according to programmed parameters and desired goals, based on acquired knowledge and an evolving understanding of the situation.
In simple terms:
An automated system can follow a route. An autonomous system may need to select another route, adapt its behavior when a navigation source is lost, preserve a mission constraint under communications degradation, or recognize that the original plan is no longer viable.
That difference matters because modern operations rarely unfold exactly as planned.
Architecture Versus Automation
Let’s imagine an unmanned system is given a route to an objective.
Automation
The system follows the route, maintains a set altitude, and returns when its battery reaches a predefined threshold.
If the route becomes unavailable, it may stop, circle, or wait for the operator to issue a new instruction.
This is useful automation. It reduces workload and performs a bounded task reliably.
Autonomy
The system is given an objective (or a mission) – reach the assigned area, preserve its ability to communicate, and return safely if the mission constraints can no longer be met.
If its original route becomes unavailable, it evaluates alternatives within its permitted boundaries, adapts its plan, and continues pursuing the operator’s intent.
The autonomous system is not simply executing a longer list of instructions. It is connecting an objective to changing conditions and selecting among possible courses of action. NATO describes autonomy as the ability to understand higher-level intent, perceive the environment, and take appropriate action to achieve a desired state.
The key distinction is this: automation follows a plan; autonomy preserves an objective when the plan breaks.
One Operator, Many Assets
Now imagine one operator responsible for several unmanned systems.
Automation
Each platform can perform a predefined task: hold a position, follow a route, transmit video, or return to a designated point. The operator may still need to monitor and direct each asset individually.
This can improve efficiency, but it does not necessarily solve the scaling problem. As the number of assets grows, the operator’s attention becomes the limiting factor.
Autonomy
The operator defines a mission intent—for example, maintain coverage of an area, prioritize particular tasks, preserve communications, and avoid defined no-go conditions.
The system coordinates tasking and behavior across assets within those boundaries, while the operator monitors progress, changes priorities, and intervenes when necessary.
Here, autonomy is not located in one drone. It exists in the connections between platforms, sensors, communications, decision logic, and the operator’s interface.
This is why autonomy is architectural. A resilient system must allow authority and cognitive functions to be reallocated between the operator and the system as battlefield conditions change. The operator does not disappear; the operator moves from managing every individual action to commanding the mission.
Autonomy Is a Spectrum
Autonomy is not a binary label. A system is not simply “autonomous” or “not autonomous.”
It is more useful to ask: What decisions has the system been delegated, under what conditions, and how can a human direct, monitor, or cancel them?
NATO notes that the functions performed autonomously—and the extent to which human operators can direct, control, or cancel them—are determined by system design trade-offs, mission complexity, environmental conditions, and legal or policy constraints.
This creates a spectrum:
The goal is not to remove the human from the loop. The goal is to allocate authority intelligently.
A human should not spend every second managing routine functions that software can perform reliably. But a human must retain command over intent, priorities, risk, exceptions, and intervention. This is the central design problem of human-machine teaming: humans and semi-autonomous systems cooperate dynamically toward a shared objective.
The Feature Trap
It is tempting to describe autonomy as a feature: “This platform includes autonomy.”
However, autonomy cannot be reduced to an AI module, a route planner, or a set of preprogrammed behaviors. Those may be components of autonomy. They are not autonomy itself.
A truly capable autonomous system requires alignment across the entire architecture:
If these layers are designed separately, the result is not autonomy, but rather a collection of disconnected functions.
Autonomy emerges when the system can connect intent to action: understand a changing situation, select an appropriate course of action, coordinate with other assets where required, and preserve human command throughout. NATO’s own framing emphasizes that autonomy can include reasoning, adaptation, self-direction, and problem-solving—not merely automated execution.
The Operational Test
Instead of “Does the system have AI?” ask “What does the system do when its assumptions fail?”
What happens when the planned route is unavailable? When a communications link weakens? When navigation information becomes unreliable? When the operator cannot manage every asset individually? When conditions change faster than a human can manually direct each platform?
A system that stops functioning the moment one assumption breaks is automated, but not resilient.
A system that can preserve mission intent—within clear boundaries and under human oversight—begins to demonstrate autonomy. It can degrade gracefully rather than fail abruptly. It can continue useful behavior rather than become a liability. And it can give the operator time and space to make decisions that matter.
This is why autonomy is fundamentally an architectural question. It is not about making one platform smarter in isolation. It is about designing a system that remains coherent when the operational environment becomes uncertain.
From Operator to Mission Commander
Autonomy changes the operator’s role. Instead of continuously flying or manually directing every asset, the operator becomes responsible for higher-level decisions: defining intent, setting priorities, managing exceptions, accepting risk, and intervening when the situation requires human judgment.
This shift is essential to scale. One person can control one platform. The more difficult question is what happens when one person must effectively direct many interconnected systems.
DK NEJET’s work on autonomous coordination and swarm intelligence is built around this problem: enabling a single operator to manage multiple interconnected units through software-driven control architectures. The value is not simply that one operator controls more drones. It is that one operator can command a more capable system—one that coordinates, adapts, and executes within the boundaries the operator establishes.
The operator moves from joystick to mission commander.
What This Means for Europe
Europe does not simply need more unmanned platforms. It needs systems that remain effective when platforms, sensors, communications, and human attention are under pressure.
That requires a different approach to capability development. Defense organizations should evaluate autonomy not as a checkbox, but as an architecture:
NATO’s Autonomy Implementation Plan likewise emphasizes interoperable “systems of systems” and the effective management of different levels of autonomy. That is the right frame. Autonomy is not a single technology to procure. It is a capability to design, integrate, assure, and operate.
The future of autonomous defense will not be defined by whether a platform has an autonomy feature. It will be defined by whether the entire system can preserve mission intent, human authority, and operational effectiveness when conditions become difficult.
Autonomy is not a feature. It is an architecture.