The fighter designation marks an ambition—and a test program
On March 3, 2025, the Air Force designated General Atomics' prototype YFQ-42A and Anduril's prototype YFQ-44A. Both received the fighter designation: Y identifies a prototype, F the fighter mission, and Q an uncrewed aircraft. The Air Force described them as a new generation intended for autonomous capabilities and crewed-uncrewed teaming. Air Force designation announcement.
The operational attraction is clear. Distributing sensors, weapons, and other payloads across additional aircraft can complicate an adversary's targeting and reduce the need to place a pilot aboard every platform entering a dangerous area. The appropriate division of labor depends on the mission, the platform's capabilities, and command authorities. An uncrewed aircraft does not become expendable simply because it has no cockpit, and a fighter designation alone does not establish combat readiness.
That distinction matters when reading industrial announcements. Production work at Anduril's Arsenal-1 began in March 2026. In a later July 27 update, JobsOhio reported that the first Ohio-built Fury had rolled off the line. Starting factory work, receiving a government production contract, completing an aircraft, and fielding a combat-ready unit are separate milestones. JobsOhio production update.
Weapons integration and autonomy answer different questions
The Air Force's February 23, 2026 announcement described captive-carry testing with inert weapons. That work evaluates carriage, structural and aerodynamic behavior, safety, and compatibility before live employment. It is one stage in weapons integration, rather than a declaration that every engagement function has been validated. Air Force weapons-testing announcement.
Mission autonomy introduces another set of questions. Shield AI announced on February 13 that Hivemind had been selected as a mission-autonomy provider for CCA technology maturation and risk reduction, with integration on the YFQ-44A. This did not give one supplier exclusive ownership of the aircraft's future behavior. Shield AI announcement.
In its February 26 release, Anduril reported a flight in which the same YFQ-44A completed test points under Hivemind and then switched to Lattice for Mission Autonomy to perform the same test points. The company attributed the integration to early use of the Autonomy Government Reference Architecture, or A-GRA. This is a supplier-reported demonstration of modular mission software, with further mission, weapons, multi-aircraft, and crewed-fighter testing still ahead at that point. Anduril release reproduced by Joint Forces.
Three layers should remain distinct in a technical review:
- Flight control and platform autonomy keep the aircraft within its flight and safety envelope.
- Mission autonomy interprets assigned objectives and selects permitted actions within that envelope.
- Command and weapons authority define what the system and its human operators are allowed to do.
A successful software handover demonstrates something valuable about integration. It cannot, by itself, prove correct threat classification, safe behavior in every disconnected condition, or operational effectiveness against an adversary.
Later developments: production and testing continue
On June 17, 2026, the Air Force described aircraft production contracts for General Atomics and Anduril, alongside a separate mission-autonomy contracting approach. Its six-vendor software pool preserves competition beyond the airframe decision, with initial competitive production options for Anduril, RTX Collins, and Shield AI and a planned primary software selection in summer 2027. Air Force June 17 announcement.
On July 15, the Air Force reported that a YFQ-44A had fired an AIM-120 at a digital target during controlled testing over the Mojave Desert. That advances the weapons-integration record beyond inert carriage, while remaining a developmental test rather than an operational combat claim. The Air Force also states that CCA will not employ weapons autonomously: the human operator exclusively decides whether to release a weapon. Air Force live-fire announcement.
For a buyer, separate hardware and software competition creates more options. Making those options usable requires documented interfaces, suitable technical-data and licensing rights, access to test environments, and a repeatable path for accepting a new software release. Modularity reduces a dependency only when the next supplier can actually integrate and demonstrate its work.
The F-47 belongs to the same operational picture
The Air Force awarded Boeing the F-47 engineering and manufacturing development contract on March 21, 2025. The public announcement described the aircraft as the cornerstone of the Next Generation Air Dominance family, with development and test aircraft preceding possible low-rate production. Air Force F-47 announcement.
The “drone quarterback” analogy is useful for explaining coordination, but it should not hide the workload problem. Directing several aircraft requires a clear display of their status, uncertainty, remaining resources, and permitted actions. A pilot cannot be expected to repair ambiguous mission instructions or supervise every low-level maneuver while managing the crewed aircraft's own mission.
Training and simulation should therefore test the team as a whole: which decisions remain with the human, which are delegated, when an aircraft asks for clarification, and how the team recovers after losing a member or a communication path. Detailed public evidence does not establish every proposed F-47 cockpit function or a universal training arrangement across today's fighter fleet.
Design for the interval when the link is unavailable
Time-critical onboard functions need enough local sensing and computing to remain useful when reachback is unavailable. That does not eliminate ground-based training, fleet analysis, or mission planning; it determines which decisions cannot depend on them during flight.
Consider a mission whose route becomes unsafe. The engineering challenge is to distinguish what the aircraft has observed from what it has inferred, compare the observation against its assigned constraints, and choose an authorized response. A hold, return, reroute, or request for direction may each be appropriate under different conditions. The system should not improvise new authority because the connection has failed.
An acceptance plan should answer five practical questions:
- What remains valid after link loss? Define mission boundaries, time limits, and conditions requiring a change of behavior.
- How does uncertainty reach the operator? Preserve confidence, source age, and conflicting observations instead of presenting one unexplained answer.
- What changes when software is replaced? Repeat relevant flight, mission, weapons-interface, and cybersecurity tests for the new configuration.
- Can the human manage several aircraft? Measure workload, misunderstood commands, delayed interventions, and recovery behavior.
- Can the event be reconstructed? Retain configuration, observations, commands, and decisions sufficient to understand a failed test and verify the fix.
CCA progress is substantial because these questions are being confronted in aircraft and acquisition decisions. Sustained advantage will depend on keeping that evidence current as platforms, software, threats, and tactics evolve.
Portability has a commercial side
The ability to demonstrate two software suites on one aircraft is important, but a customer also needs an executable path to a supported replacement. That path depends on the rights, documentation, tools, and cooperation available under its agreements. Technical compatibility and practical purchasing freedom are related achievements, not identical ones.
Before treating a supplier change as an available option, the acquisition team should establish who performs integration, who supplies relevant evidence, and which organization supports the resulting configuration. It should also identify any recurring licenses or services that remain necessary after the change. Otherwise a nominally interchangeable component can carry dependencies that make substitution more difficult than expected.
The appropriate rights package need not transfer ownership of every proprietary element. It should provide the access and permissions the government needs for its intended integration, assessment, and support activities. The agreement should make the limits visible so the buyer can assess their consequences before relying on future competition.
A demonstration should leave the next team with usable records
The people conducting an early event often know details that never reach a later support team. A configuration may depend on a particular tool version, an unresolved interface condition, or specialist assistance supplied for the event. Those details belong in the handoff record if the next organization is expected to reproduce the supported result.
A practical procurement review can organize the evidence around four questions:
- What was actually demonstrated? Identify the configuration and scope of the event, while keeping proposed capabilities separate.
- What accompanied the result? Record the support personnel, tools, and services needed to obtain it.
- What will the customer receive? Connect the deliverable, relevant rights, documentation, and continuing support to the demonstrated configuration.
- What decision remains open? Identify unresolved acceptance work and the official responsible for the next step.
These questions concern acquisition accountability. They do not prescribe flight behavior, operational tactics, or an automatic acceptance standard for a weapon system.
The review may support a limited initial delivery while a broader configuration remains under assessment. It may instead show that an unresolved dependency prevents useful acceptance. Both are credible outcomes when the evidence is clear. What the program should avoid is allowing the language of modularity to stand in for a completed integration and support decision.
The next supplier discussion should therefore include the people who will accept and sustain the release, not only those who can demonstrate it. That is how the promise of interchangeable mission software becomes a choice the customer can actually exercise.
Sources and further reading
- Air Force: YFQ-42A and YFQ-44A designations
- Air Force: inert weapons integration
- Shield AI: mission-autonomy selection
- Anduril: two software suites in one flight, reproduced release
- Air Force: June 2026 contracts
- Air Force: July 2026 live-fire test
- JobsOhio: Arsenal-1 production milestone
- Air Force: F-47 development contract
Spartan X's autonomy, AI, and engineering work connects software architecture to mission requirements and the evidence needed to trust a release. That connection is central to turning interchangeable autonomy into a capability operators can use with confidence.
