Where Flying the Aircraft Ends and Achieving the Objective Begins

Consider a hypothetical: an aircraft is dispatched to deliver urgently needed supplies. En route, weather closes the planned destination.

In this scenario, the aircraft itself might not be the limiting factor. Automation could, in principle, help the aircraft hold a safe path and respond to the disruption. But a different question remains: What should the operation attempt to accomplish now?

Wait for conditions to improve? Divert to another airfield? Select a different delivery point? Preserve fuel for a return? Ask a human to decide? Determine that the objective can no longer be achieved safely at all?

Those are not purely flying questions. Holding, diverting, and rerouting all require the aircraft to fly safely, but choosing among them may also require a decision about the objective. An aircraft capable of executing any of those actions would not necessarily be authorized, or equipped, to decide which outcome the operation should pursue. What the operation still requires, in other words, is judgment.

That distinction, between flying the aircraft and determining how to pursue the objective, is where conversations about aviation autonomy often lose precision. The boundary is not impermeable, but it’s important.

Two Different Responsibilities, Not Two Settings on the Same Dial

Flight autonomy concerns the functions required to operate the aircraft safely, including flight control, navigation, communication, and response to defined contingencies. The expanded Aviate, Navigate, Communicate, Operate framework that Merlin CTO Tim Burns described in Fortune helps explain how those responsibilities interact.

Mission autonomy emerges within “Operate,” where aircraft crews manage the systems, information, plans, and decisions required to accomplish an objective. It may involve re-tasking, managing sensors and payload, or reconsidering a plan as circumstances change.

Put simply: flight autonomy answers how the aircraft can execute an action safely. Mission autonomy helps determine where action best serves the objective within defined constraints. The two layers interact, but they are designed and evaluated against different requirements.

Merlin describes this broader capability as Artificial Airmanship. In a July 2026 post, Burns wrote that Merlin is working to build systems that carries that disciplined judgement across all of it, with the aim of reducing workload, extending mission capacity, and improving safety. In a separate post, he described assured autonomy as learning how experienced pilots think, bounding and assuring system behavior, and maintaining human accountability.

Two Common Lenses, and What Each Leaves Out

Public discussions of aviation autonomy often rely on one of two lenses.

The first adapts the levels-based model familiar from the automotive industry: a linear progression from human operation toward full autonomy. Some aviation frameworks use five or six levels that resemble SAE’s Level 0-to-Level 5 scale for driving automation, as discussed in Air & Space Forces Magazine. But a single scale has limitations in aviation. A commercial jet on autopilot at cruise may use mature automation to control its flight path while having little or no authority to make mission-level decisions. One dial can’t describe an aircraft that’s highly automated in one dimension and largely human-directed in another.

The second framing appears frequently in defense discussions, where "mission autonomy" is often presented in the context of uncrewed aircraft, human-machine teaming, and coordinated operations across multiple platforms. That work has helped make the term more visible, but it represents only part of the concept. The distinction between flying an aircraft and pursuing an operational objective is relevant to tankers, cargo aircraft, ISR platforms, and commercial operations involving the movement of fuel, cargo, supplies, people, or information. In these settings, the central question is how an aircraft and its human operators respond when weather, airspace constraints, aircraft status, or operational priorities require the original plan to change.

Why the Split Is More Than Semantics

Flight and mission autonomy have different primary responsibilities, but failures in either layer can affect the broader operation. A flight-autonomy fault may directly affect control or safe operation of the aircraft. A mission-autonomy fault may first affect task selection, planning, or the objective, but its consequences can propagate to aircraft and crew safety if the surrounding architecture does not contain them.

That difference shapes how each function must be assured. Software that directly affects aircraft control generally faces airworthiness and safety requirements appropriate to that role. Mission-level software may be evaluated against additional criteria, including whether it interprets objectives correctly, respects delegated authority, and behaves predictably when information is incomplete. The applicable scrutiny ultimately depends on what the function does and the consequences if it fails.

The human role can differ as well. The appropriate level of involvement depends on the decision being made, the authority delegated to the system, and the conditions under which it is operating. Asking only “how much autonomy” obscures those more consequential questions.

What the Split Looks Like in Practice

Northrop Grumman's Talon IQ testbed, formerly known as Beacon, offers a public example of flight and mission autonomy being developed as distinct but integrated layers. Using Scaled Composites' Model 437, the program provides an aircraft and flight-autonomy foundation on which participating companies can integrate and evaluate mission-autonomy software. Under Merlin’s agreement with Northrop Grumman, the company reported it would provide the Merlin Pilot for critical testing and validation activities, including engineering integration for software-in-the-loop testing and flight-test operations. Northrop Grumman has also reported flight demonstrations involving its Prism software and Shield AI’s Hivemind on the same test aircraft. These efforts illustrate a modular architectural approach in which different mission-autonomy systems can be integrated with a common flight-autonomy platform, although each integration still requires appropriate testing and validation.

The Question Worth Asking

The wrong question is “How autonomous is this aircraft?” That assumes autonomy can be captured by a single measure.

A more useful question is, “Which responsibility is being automated?” Is the system operating the aircraft, or is it helping determine how the operation should respond as conditions change? Those functions interact, but they’re developed, assured, and evaluated against different requirements.

As Burns wrote, aviation technology has long helped crews “stay ahead of the aircraft rather than constantly reacting to it.” Extending that advantage requires precision about what a system is designed and authorized to do. Flight autonomy and mission autonomy are not two points on the same scale, they are complementary layers, and understanding the boundary between them is essential to building, evaluating, and deploying autonomy responsibly.

Cautionary Statement Regarding Forward-Looking Statements

This post contains forward-looking statements within the meaning of the Private Securities Litigation Reform Act of 1995; actual results may differ materially from those anticipated, and readers are cautioned not to place undue reliance on such statements, which speak only as of the date of this post and are subject to the risks and uncertainties described under "Risk Factors" in our filings with the Securities and Exchange Commission, including our Prospectus dated May 13, 2026, filed with the SEC on May 13, 2026, and our subsequently filed Quarterly Reports on Form 10-Q, which are available from the SEC. Except as required by applicable law, we undertake no obligation to update any of these forward-looking statements after the date of this post.