Autonomous Vehicle Orchestrator

Prize Challenge Area of Interest

Autonomous Vehicle Orchestrator

Problem

As autonomous systems mature into distributed, multi-domain forces, the Department of War (DoW) lacks an operationally viable Autonomous Vehicle Orchestrator. This orchestrator is the human-machine interaction layer that translates the commander's intent from natural language into machine execution. The quality of this layer directly determines the effectiveness, speed, clarity, and trust with which autonomous formations can be directed in real-world operations.

Desired Solution Attributes

The Department of War (DoW) seeks innovative, market-ready solutions to establish a robust, scalable, and vehicle-agnostic capability for understanding, tasking, and coordinating autonomous systems at the fleet level. This program aims to bridge the critical gap between human intent and platform execution for heterogeneous autonomous platform fleets, without modifying existing platform autonomy stacks or requiring access to vehicle control layers.

The orchestrator performs three core functions:

1. It interprets human intent inputted via voice, text, and a graphical user interface (GUI) and translates that intent into the appropriate option from the autonomous platform’s “playbook.” 
2. It consolidates awareness of what the fleet is doing by aggregating data already provided by platforms through their native systems.
3. It enforces fleet-level constraints by issuing updated intent.

The orchestrator does not change existing craft autonomy structure, command actuators directly, or interfere with platform-level data transfer and communication.

Primary Attributes

• Extension of Command-and-Control

The Orchestrator must allow commanders and operators to issue intent, receive situational understanding, and synchronize autonomous effects.

The Orchestrator must allow humans to work the way they already command: expressing desired effects, constraints, timing, and priorities. It must give autonomy the latitude to carry out those instructions using its own reasoning, while ensuring the human always maintains a clear understanding of what the system is doing and why.

• Intent Translation Into Machine-Executable Tasks

The Orchestrator will require models that convert natural human language into structured autonomous tasking. These agentic models must be aligned specifically for military missions, rules of engagement, authorities, phasing, timing, and domain constraints.

A commander should be able to state commander’s intent (examples below) to existing commands native to the autonomous platforms:

“Place crafts 1-5 in echelon left.”

“Move all USV pods 5 kilometers east.”

“Hold position, conserve battery, and wait for further tasking unless a threat crosses Line Bravo.”

• Data Fusion

To ensure that autonomous systems operate with the fullest possible situational understanding, the Orchestrator must be capable of ingesting intelligence streams, positional data, environmental observations, sensor outputs, partner feeds, and mission context from a wide range of sources. This information must be correlated, interpreted, and used to refine intent translation and situational understanding.

• Reduce Cognitive Burden and Increase Human Understanding

A core objective of the Orchestrator is to reduce the cognitive and operational burden placed on commanders and operators. The Orchestrator must provide plain-language explanations of autonomous behavior: what the system is doing, why it is doing it, what triggered a state change, and what it intends to do next. These explanations must be concise, grounded in operational logic, and immediately useful within the commander’s decision cycle.

While voice and text will serve as the primary modalities for interaction, an informative and intuitive GUI is also essential. The GUI needs to allow for structured capture of commander’s intent as well as display craft and mission information for further analysis and situational understanding.

• Seamless Operation Under Intermittent or Degraded Communications

Because autonomous systems often operate in contested electromagnetic environments, the Orchestrator must be designed to function effectively under intermittent connectivity. The Orchestrator may also eventually need to be run in a disconnected, edge environment without access to the cloud. Commands must be cached, synchronized, and executed whenever link windows open. The system must present operators with realistic representations of communications availability and autonomous behavior, preventing false assumptions of control.

• Ability to Participate in Rapid Iterative Development

If selected, performers must be able to begin Sprint 1 testing within 10 days of selection notification. Companies will be expected to have full-time engineers cleared up to Top Secret deployed to a continental United States location during development sprints. The sum of all sprints is anticipated to take approximately 6 months in total. 

Additional Evaluation Criteria (affirmative statements/details must be provided in proposal):

• Active Facility Clearance (FCL) issued by the Defense Counterintelligence and Security Agency (DCSA) with Secret safeguarding. FCL must be verifiable in the National Industrial Security System. 
• Hardware integration experience
• Large Language Model (LLM) agent implementation experience
• Model size, compute efficiency, and cloud dependence. Proposals should include specifications of your proposed models and environments where they can be run.

No proprietary physical platforms (hardware) should be included in solutions. This development effort is for software and must be vehicle agnostic. 

Additional evaluation criteria may be applied during Sprint 2 and any follow-on sprints in response to changing operational end user needs.

Challenge Series

DIU and the Defense Autonomous Warfare Group (DAWG) intend to run this as one challenge with iterative sprints, tackling increasingly complex portions of the problem. Vendors will only be eligible for selection prior to the first sprint, and, upon successful completion of the previous sprint, can progress to the next sprint. Vendors who are not able to complete the sprint will not move forward.

For each sprint, the intent is for the system to be operated by DoW personnel. 

The unmanned hardware platforms utilized during this effort will be government-furnished equipment. The government will provide the platforms’ application programming interfaces, existing playbooks, and autonomy capabilities to the selected performers under this solicitation to help architect the appropriate translation schemas. The performers will be responsible for building translation barriers to prevent inappropriate or inexecutable commands.

Demonstrations at the event will occur in all relevant conditions and all submissions will be tested and operated by a designated team of DoW end users to the maximum extent possible.

Sprint 1: Software-Only Integration and Intent Translation

Sprint 1 will be purely software-based. The focus is on validating the intent translation and ensuring that commands, inputted via voice, text, and graphical user interface, can be interpreted and translated into platform-executable actions. During this sprint, the system will demonstrate:

• Correct mapping of voice input into a universal message format
• Correct mapping of input to a valid and applicable command in platform playbook
• Correct logging and traceability for validation

Sprint 2: Homogeneous Pod Control

Sprint 2 will introduce live platforms, operating as a homogeneous pod. The goal is to validate that commands can be used to execute fundamental tasks such as:

• Formation control
• Loiter behavior
• Transit configuration
• Platform diagnostics

Sprint 3: Heterogeneous Pod Control

Sprint 3 will introduce two different platform types. The goal is to prove that identical commands can be used to coordinate the behavior of heterogeneous platforms. Tasks will mirror those from Sprint 2 and will demonstrate that the system can function across different platform autonomy implementations.

Sprint 4: Terminal Environment Behaviors

Sprint 4 will focus on intent sequencing, constraint management, and ensuring that more sophisticated fleet-level coordination can occur through command intent.

This sprint introduces more complex operational scenarios, such as:

• Phased actions
• Deconfliction between pods
• Target-related awareness and sharing

Sprint 5: Full Mission Profiles 

Sprint 5 will demonstrate that full mission profiles can be executed from launch to termination using the orchestrator. While text and manual controls will remain available as a backup, all three input pathways will be evaluated. Mission profiles will involve multiple, integrated tasks across the fleet, and the system will demonstrate the ability to handle complete operational workflows.

Additional Information

Up to $100,000,000 in awards are available for this effort to be allocated across the sprints. The government anticipates multiple awards. Companies will be evaluated at the conclusion of each sprint to determine whether they are invited to subsequent sprints. Companies that make it through all five sprints will be eligible to be selected as recipients of procurement contracts and other agreements.

Proposals must demonstrate an ability to address the entirety of the problem. Prime/subcontractor solutions are acceptable, and subcontractors may change in composition throughout the challenge (as long as the prime vendor remains the same).

Proposal Submission Requirements:

Teams will submit a proposal outlining their solution that addresses the desired solution attributes, primary attributes and additional evaluation criteria above. Proposals should meet the following format requirements:

• Sized 16:9 (1920x1080 pixels)

• Horizontal presentation

• PDF file

• Maximum 15 slides

There is no guarantee that submissions will be selected. If invited, companies may incur costs not covered by the Prize Award and should be willing and able to do so.

Intellectual Property Considerations:

Applicants retain ownership of existing Intellectual Property (IP) submitted under this Challenge and agree that their submissions are their original work. Applicants are presumed to have sufficient rights to submit the submission. For any submission made to the Challenge, you grant DIU a limited license to use this IP for testing and evaluation for efforts specifically related to the Challenge. DIU will negotiate with individual competitors in the event additional usage, integration, or development is contemplated. 

About the Defense Innovation Unit

The Defense Innovation Unit (DIU) strengthens national security by accelerating the adoption of commercial technology in the Department of War and bolstering our allied and national security innovation bases. DIU partners with organizations across the DoW to rapidly prototype and field dual-use capabilities that solve operational challenges at speed and scale. With offices in Silicon Valley, Boston, Austin, Chicago and Washington, DC, DIU is the Department’s gateway to leading technology companies across the country.

Other Transaction Authority:

This DIU Challenge public announcement is an open call to small businesses and non-traditional defense contractors seeking innovative, commercial technologies proposed to create new DoD solutions or potential new capabilities fulfilling requirements, closing capability gaps, or providing potential technological advancements, technologies fueled by commercial or strategic investment, but also concept demonstrations, pilots, and agile development activities improving commercial technologies, existing Government-owned capabilities, or concepts for broad Defense application(s). As such, the Government reserves the right to award a contract or an Other Transaction agreement for any purpose, to include a prototype or research, under this public announcement. The Federal Government is not responsible for any monies expended by the applicant before award and is under no obligation to pursue such transactions.

Satisfying Competition Requirements:

This DIU Challenge Open Call Announcement is considered to have potential for further efforts that may be accomplished via FAR-based contracting instruments, Other Transaction Authority (OTA) for Prototype Projects 10 USC 4022 and Research 10 USC 4021, Prizes for advanced technology achievements 10 USC 4025, and/or Prize Competitions 15 USC 3719. The public open call announcement made on the DIU website is considered to satisfy the reasonable effort to obtain competition in accordance with 10 USC 4025(b), 15 USC 3719 (e) and 10 USC 4022 (b)(2). Accordingly, FAR-based actions will follow announcement procedures per FAR 5.201(b). DIU reserves the right to cancel, suspend, and/or modify the Challenge, or any part of it, for any reason, at DIU’s sole discretion.