My greatest challenge while flight testing collaborative combat aircraft was not troubleshooting errors at high speed in the cockpit. It was when, in a single keystroke, my job shifted from pilot to something like a dog handler — a supervisor of an autonomous agent. As a test pilot, my instinct is to stop for surprise machine behavior, but that met a system where such unexpected behavior could be a good thing. Managing autonomy means accounting for a new phenomenon — machine behavior that is both correct and unexpected.
Historically, aircrews have handled surprises by assuming there’s a malfunction and fixing it, or by honoring prioritized limits. In addition, when traditional aircraft lose contact with a pilot, they follow a fixed set of pre-approved actions. You know in advance what the machine will do on its own. But with agentic systems, which may not follow pre-coded scripts, operators cannot assume that an unexpected behavior is a mistake or a code malfunction. Air Force manuals for commanding agentic systems should therefore endorse a mentality shift: Operators should expect surprises and judge them on their merits.
The Air Force’s Collaborative Combat Aircraft program is part of the Pentagon’s larger commitment to field autonomous collaborative platforms. All variants share an autonomy core, using Government Reference Architecture. This decouples the software from the vehicle hardware, theoretically permitting agents to integrate across different platforms, owned by the different services or by allies, that perform substantially similar missions.
Decisions made now on how to handle autonomous collaborative platforms will be the default for the rest of the portfolio and for U.S. allies standing up their own programs. Existing aircraft manuals have checklists for normal and emergency procedures, informed by system descriptions, and the Pentagon has published policies for proper use of autonomous weapon systems. But these manuals and directives do not teach operators to supervise agents beyond approving or vetoing actions that result from pre-programmed rules. Unless the Air Force finds a way to train its personnel to embrace surprise when operating agentic aircraft, the service risks turning a multi-billion- dollar autonomy program into just another drone.
The missing piece is a hardware-agnostic “agent manual,” organized around the mission of supervising agents rather than around any one airframe. It should classify risk by how hard a task is for the agent, not for the human, and quantify that risk with probability rather than gut instinct. The operator’s available attention — his or her cognitive bandwidth based on the mission or operational conditions — should be one of the equation’s inputs.
An autonomous wingman may save a fighter pilot’s life by distracting an opponent. The same agent may cause a friendly midair collision. The Air Force owes combat operators the guidance to make the right call, tuned to the mission so that it’s applicable across different airframes using the same control software. This guidance should also delineate operators’ responsibility for a system’s behavior under changing conditions. Otherwise, warfighters will have no reason to trust these systems, take responsibility for their actions, and adopt them in earnest.
Sign Up for Our Newsletter
A Manual for the Mission, Not the Airframe
The Air Force needs a manual for operators of agentic systems. Relying on guidance that assumes unexpected behaviors are incorrect by default limits agentic systems’ unique value proposition.
Building early doctrine has become increasingly necessary as the Experimental Operations Unit begins to put collaborative combat aircraft into the hands of operators. For example: Air Force headquarters is changing flying publications to accommodate autonomous collaborative platforms; Air Combat Command has drafted three volumes of collaborative combat aircraft flying operations manuals, reviewed by the author; and Directive 3000.09, which established guidelines for the use of semiautonomous and autonomous systems, technically includes these systems in its scope. But there remains no guidance that teaches operators to judge whether a surprising agent is smart or broken, a prerequisite for command without control.
Three existing approaches to such guidance are tempting, but each would be counterproductive. First, senior leaders could direct units on how to use these systems in combat. But warfighters should define what is valuable, not be told what to integrate. Second, aircraft manuals could be written with open-ended flexibility (“expect the unexpected”). But this guidance is vague enough to defeat the purpose of writing it in a manual. And third, the Pentagon could amend Directive 3000.09. But specifying sub-system boundaries would be too granular for this document. Mission-centric manuals, which authorize risk that aircraft manuals do not, are the path forward.
The Air Force already publishes cross-platform, mission-centric manuals. Flight Test and Aeromedical Evacuation are owned by headquarters, not individual airframes. In a similar way, the service could craft cross-platform guidance for the mission of commanding agents. Unlike previous mission-centric manuals, this would be a guide to supervise systems, not lead people. In the case of agents, this could be done by classifying the tasks they are commanded to do. Categories should align to the risks the agents create. Some sources like Autonomy Levels for Unmanned Systems and Operational Design Domain can help. But combat aircrew should have the final say as technology and adversary environments evolve.
Without guidance tailored to agent command, simple updates become intractable. Consider a routine patrol in combat. Whether commanded from a fighter jet, the ground, or on a tanker, the operator will need it to remain within a geographic area. Say one corner of the area becomes unavailable. To a human, adjusting the patrol route makes little difference. But to an agent, the option space explodes. Instead of flying along the boundary, the agent may cut the corner to cover more ground. Under current guidance, this would trigger either an Air Force-level change, an aircraft manual amendment, or no fix at all. But cross-platform guidance gives the community a common language to diagnose the behavior. Once judged, timely updates can be passed across the fleet. Each fleet’s aircraft manual would not need to be updated to account for agentic software changes.
What My Live Flights Have Taught Me
Last fall, I was there to pilot the jet in the event the agent needed to be overridden. But one day, the agent could be expected to control the aircraft from engine start, during mission execution, and while returning to base, except for target selection and weapon employment. Whether controlled by a pilot, a maintainer, or the agent itself, the challenge of commanding without control will persist.
Simple maneuvers during live flight tests have already revealed the challenges of commanding agents compared to leading humans. The first time the autonomy core was used in a live flight of one of these collaborative platforms, the agent’s task was to fly at an altitude and an airspeed within a defined map area. The system needed to calculate which direction to turn to remain within the designated area. This would be easy for a human or an autopilot to fly because humans can apply common sense and years of training, and an autopilot can follow predictable, pre-coded rules.
With an agent, however, there was a chance an unexpected machine decision could change everything. Accordingly, under these controlled test conditions, there was always a subject matter expert on call. When the aircraft made an inappropriate turn, I stepped in and commanded it to a pre-planned heading so that there was less of a chance it would turn in a direction the team didn’t expect and potentially cause a mid-air collision. Future combat missions, of course, will not have these controlled conditions. Scaling to other mission sets also means efforts need to persist beyond the current cohort of subject matter experts working with collaborative combat aircraft.
Unlike autopilots, missiles, or remotely piloted aircraft, agents are built to find viable solutions the operator may not anticipate. However, for good reason, current procedures assume the opposite. For rules-based software, if the machine isn’t explicitly programmed to do something, it shouldn’t do it. Without guidance on how to command agents, operators will default to their own intuition during the stress of combat and throw out anything they don’t understand.
What Right Looks Like
There are several implications of shifting from a culture of controlling agents to a culture of collaborating with them.
First, classify agents by how hard their tasks are for the agent, not by the mission type. You can’t assume that what’s hard for a human is hard for an agent, as the opposite could just as easily be true. A human qualified in F-16 close air support for 20 years might struggle to switch to the B-2 stealth mission. But to an agent, there is no such thing as close air support or strike. There are just outputs the model produces based on inputs it receives (such as remaining inside a boundary). An agent trained for close air support in a rectangular geographic area may be able to adapt to the strike mission more easily than it can adapt to close air support in a non-rectangular area. Categorizing inputs by tasks, such as airspace boundary avoidance and weapon release timing, is an effective means to understand agent risks across different mission sets. These mission risks need to be understandable to the human overseers. The input the agent is expected to receive during the day should be compared to what it has been trained to do.
Second, mathematics may be more useful than intuition. To an agent, tasks are not “easy” or “difficult.” Once it has all the inputs, the machine will deliver an output. An agent’s behavior can look random, but in reality, it is the output of a trained model working on the data it receives, which means its tendencies can be measured and quantified. The uncertainty the operator faces lives in the inputs and conditions, and in how well the model’s training covers them. Probability can measure that. More importantly, operators should judge the extent to which training conditions are valid for live combat. With a human wingman, operators can say things like “a reasonable person would assume this” or “we train them in the schoolhouse to do that.” But an agent with ten thousand years of perfect training data would still make an error if there’s a bug in the latest software update. Simulators are an important piece of the puzzle and should be used to give operators a heatmap of agent reliability when performing different tasks. But operators need to consider sensor data quality in training versus in live missions. Consolidating these computations into probabilities that agents will act a certain way under given conditions will not be easy. But the reason you pay for an agent is improvisation, and its ability to follow commands without direct control. If we’re unwilling to give collaborative combat aircraft this latitude, then we should just be buying more traditional, remote-controlled drones or air-to-air missiles.
Third, the operator’s bandwidth is part of the agent’s input. Latency, dropout, and noise could occur from the adversary or the environment, but it can also derive from the operator’s availability to give commands. Operators located in a fighter, tanker, or ground-based command and control station may have vastly different limitations. I’m often asked, “How many drones can you fly at once?” If I’m landing the jet with a joystick, the answer is one. If I’m managing patrols in static geographic areas, it’s potentially hundreds. A human in a fighter jet may have to link to his or her accompanying agent-piloted aircraft, but only have the bandwidth to make an inject once every five minutes because they’re flying at maximum speed to intercept an enemy fighter. Therefore, the manual should assess a higher agent difficulty for tasks with low command availability relative to command demand.
Once risk is aligned with the manual’s approvals, instructors will have a common language to teach operators how to make instinctual decisions to command unintuitive systems. The humans will command the agents, and the agents will do what they do best — surprise us.
Build the Culture before the Fleet
The iron is hot for integrating agentic systems into Air Force operations. Senior military leaders have committed to autonomous collaborative platforms as a top modernization priority, and industry is eager to provide solutions. The temptation is to capitalize on this opportunity by pushing these systems out to the field as soon as possible. The collaborative combat aircraft program’s legacy will not be defined by the airframe, or even the autonomy stack. It will be the culture established by the human commanders of these systems that will carry across mission sets.
This is tough to imagine without guidance that changes fast enough to matter. It’s a big ask for each aircraft manual to update at a relevant speed across the Air Force. A hardware-agnostic, agent-centric manual fills that gap. My own flight-test experience leads me to believe that, even with growing practice, operators are still behind the curve as agent tasks get more complex by the day. The strategic investment in autonomy will only pay off if warfighters choose to integrate these systems on their own.
Write for Cogs of War
Maj. Greg Search is a U.S. Air Force test pilot and the first Air Force pilot to operate a Collaborative Combat Aircraft, the YFQ-42A. He currently serves as a staff officer at Headquarters Air Combat Command. Prior to this, he worked as an MQ-9 evaluator pilot and as a Phantom Fellow at the Department of the Air Force-MIT Artificial Intelligence Accelerator. He is a graduate of the U.S. Air Force Academy, Stanford University, and the U.S. Air Force Test Pilot School. The views expressed here are his own and do not represent the Department of the Air Force or any other component of the United States government.
