The autonomy stack: how unmanned systems software earns its way into the field

The gap between the demo and the field

Anyone can fly an impressive autonomy demo in 2026. Open-source autopilots, capable simulation environments, and commodity flight controllers have made the highlight reel cheap. What remains expensive — and what federal programs actually pay for — is the distance between a demo and a fielded system: the software that keeps working when positioning drops out, when the environment refuses to match the training data, when three vehicles disagree about who does what, and when a safety official asks for evidence rather than footage. A demo shows what a system can do once. Fielding requires knowing what it will never do.

That distance has a structure. Fielded autonomy is a stack of distinct software layers, each with its own published methods and its own failure modes, wrapped in an assurance and test discipline that public policy now spells out. Understanding the stack — and where the hard residual problems live — is the fastest way to read the current wave of federal investment in uncrewed systems across the air, ground, surface, and undersea domains.

The stack, layer by layer

Layer	Job	Where it breaks
Perception	Turn sensor streams into a usable world model	Distribution shift — weather, clutter, targets that do not resemble training data
State estimation & navigation	Know where the vehicle is and how it is moving	Positioning denial and drift over long missions
Planning & guidance	Decide the next action against mission intent	Uncertainty, dynamic obstacles, replan latency on small compute
Multi-vehicle coordination	Divide work across vehicles without a central node	Degraded communications and disagreeing world views
Run-time assurance	Bound what the complex layers are allowed to do	Monitors that are too loose to protect or too tight to be useful
Human interface	Keep the operator's judgment in the loop at mission tempo	Alert overload and misplaced trust in either direction

No layer is optional in the field, and programs rarely fail at the layer that looked hardest on day one. The perception model that benchmarked well fails quietly on a new sensor; the planner that was flawless in simulation stutters on the actual embedded processor; the coordination scheme that worked on a calm test range degrades when the radio link does. The stack is a system, and the seams between layers are where the engineering lives.

Navigation when positioning goes away

The defining assumption of modern uncrewed systems is that satellite positioning is a convenience, not a guarantee. Contested environments jam it, terrain masks it, and long undersea or indoor missions never had it. The published toolkit for flying without it is mature as research and demanding as engineering: inertial navigation as the backbone, visual and visual-inertial odometry to slow the drift, simultaneous localization and mapping where the environment offers structure, terrain and celestial references where it does not.

The engineering reality is that every one of these techniques is a drift-management strategy, not a drift-elimination strategy. Errors accumulate; the design question is how fast, and what independent reference resets them. Public evaluations in this space increasingly report exactly that — drift per unit distance under realistic motion, robustness across lighting and weather, behavior during aggressive maneuvers — and programs have learned to distrust navigation claims presented without them. It is one of the clearest examples in the field of evaluation methodology being the product.

Planning under uncertainty, on a power budget

Between knowing where the vehicle is and knowing what it should do sits planning — route, trajectory, task sequence, and the continuous replanning that real environments force. The published families are well mapped: sampling-based motion planners, optimization-based trajectory generation, receding-horizon control, and increasingly learned policies for the inner loops where milliseconds matter. The field problem is that all of it must run onboard, on embedded compute, sharing a power budget with sensors and radios, and it must degrade gracefully when the world outruns the plan.

What separates fieldable planning software is rarely the algorithm; it is the honesty of its budget accounting. Replan latency on the actual processor, worst case rather than average. Behavior when no feasible plan exists. The handoff protocol when the planner concludes the mission intent can no longer be met. The public literature calls this graceful degradation; operators call it knowing what the vehicle does when things go wrong, and it is the first question any experienced evaluator asks.

Coordination without a conductor

The force-design logic across the services points the same direction: more vehicles, cheaper vehicles, working together. That makes multi-vehicle coordination a first-class layer of the stack, and the constraint that shapes it is communications. A coordination scheme that assumes a reliable link to a central planner inherits that link as its single point of failure — so the published methods that matter are the decentralized families: consensus protocols, distributed task-allocation schemes, and behavior-based approaches in which useful group behavior emerges from local rules.

Each family trades differently. Centralized planning is optimal and fragile; consensus methods are robust and slow to converge; behavior-based schemes are fast and hard to bound formally. The open research problems are exactly the ones a field deployment surfaces: coordinating when different vehicles hold different world models, keeping group behavior predictable as membership changes mid-mission, and proving anything at all about emergent behavior to a test authority. Programs across several services are funding precisely this seam, and the firms doing well in it publish their degradation behavior, not just their best-case sortie.

Run-time assurance: the layer that makes the rest certifiable

The most consequential quiet development in autonomy engineering is the maturing of run-time assurance as a formal practice. The premise is disarming: if a complex or learned function cannot be exhaustively verified at design time — and modern perception and planning functions cannot — then wrap it in a simpler, verifiable monitor that watches the system's actual behavior and intervenes when it approaches a defined boundary. The complex function flies the mission; the simple function guarantees the envelope.

This is now written down as industry standard. ASTM F3269, developed by the unmanned-aircraft standards community, defines the architectural practice for safely bounding the behavior of aircraft systems containing complex functions through a run-time assurance architecture — explicitly as an alternative path where traditional design-assurance methods are impractical for functions built on machine learning. For firms building learned autonomy, the practical meaning is direct: the assurance architecture is not compliance overhead added at the end, it is the design decision that determines whether the interesting software is allowed to fly at all.

The policy floor: human judgment, by directive

Autonomy in weapon systems has an explicit federal policy frame. DoD Directive 3000.09, updated January 25, 2023 in its first major revision since 2012, requires that systems be designed to allow commanders and operators to exercise appropriate levels of human judgment over the use of force, and it requires that covered systems be tested and evaluated to perform as anticipated in realistic operational environments against adaptive adversaries. Two engineering consequences follow for anyone building in this space.

First, the human interface is a load-bearing layer of the stack, not a dashboard bolted on later — "appropriate human judgment" is exercised through whatever the software surfaces, at whatever tempo the mission imposes. Second, the test bar is written into policy: realistic environments, adaptive opposition. A test program built around scripted scenarios does not meet the sentence as written, and test authorities read the sentence as written.

Test and evaluation: the long pole

Every experienced autonomy program says a version of the same thing: the vehicle is the short pole, the evidence is the long pole. Simulation carries most of the load — thousands of scenario variations, systematic parameter sweeps, injected failures — but simulation fidelity is itself a claim that needs validation, and the sim-to-real gap is a permanent tax. Field testing then anchors the simulation claims, stressing the specific seams simulation renders poorly: real sensor noise, real link degradation, real weather.

The discipline that has emerged in the public record is scenario-coverage thinking, borrowed in part from the autonomous-vehicle industry: define the operational design domain explicitly, enumerate the conditions the system claims to handle, measure coverage against that enumeration, and treat the discovered edge case as a first-order deliverable rather than an embarrassment. Programs increasingly ask for the scenario library and the coverage argument alongside the flight logs — which is to say, the test infrastructure is part of the product, and small firms that arrive with it stand out immediately.

Where small firms fit

The stack decomposes, and federal innovation programs across the Army, Navy, Air Force, special-operations, and missile-defense communities are funding it seam by seam: a navigation module with honest drift accounting, a coordination layer with published degradation behavior, an assurance monitor designed to a recognized standard, a scenario-generation and coverage harness a test authority can audit. Small teams win in this space the same way in every domain — by picking one seam, building against public benchmarks and standards first, and showing evidence discipline that survives contact with an evaluator. The vehicles are increasingly commodity. The software between the layers is not.

Bottom line

Uncrewed systems are the visible face of a software problem. The stack is known — perception, navigation, planning, coordination, assurance, interface — and the public record now specifies both the engineering standards and the policy expectations that fielded systems must meet. The distance between demo and deployment is measured in evidence: drift budgets, degradation behavior, bounded envelopes, scenario coverage. That is where the current wave of federal investment is pointed, and it is the most durable place for a software firm to build.

Frequently asked questions