Skip to main content

We offer multiple pathways for your Technology and Talent solutions to impact national security by matching threats with real-world capabilities.

Work With Us - Open Pathways

Find the Right Path to Working With DIU

Pathways through Commercial Solutions Openings (CSO)

If your company has a proven track record of commercial viability with commercial off-the-shelf products and tech, you’re in a great position to work with us. We actively work with companies both in the U.S. and internationally, across allied countries.

You can submit your technical solutions to posted solicitations under our Commercial Solutions Opening (CSO) process and Other Transaction (OT) authority - a fast, flexible way that allows us to competitively solicit proposals for DoD projects, often awarding within 60-90 days.

Open Solicitations —

Sorry, there are no open solications currently.

If you would like to be notified when new solicitations are posted please fill out our interest form here.

For more information on responding to a solicitation, see our Solution Brief best practices guide.

Read the DIU CSO Guidance

Pathways through Challenges or Commercial Acceleration Opportunities

Are you building something innovative, but it’s not yet fully commercialized? If your technology is still in development or you're testing scalability, we’ve designed pathways specifically for you.

We regularly seek proposals from both U.S.- and internationally-based ventures and early-stage companies just like you. Apply through DIU’s Challenges or Commercial Acceleration Opportunities to showcase your potential and get tailored support.

Open Challenges and Commercial Acceleration Opportunities —

Autonomous Vehicle Orchestrator


Responses Due By

2026-01-25 23:59:59 US/Eastern Time

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.

FAQs

1. If we have a Top Secret FCL, does that meet the Secret safeguarding requirement? Or do we need to have a secure facility (ideally we would use Government facilities)?

A: Safeguarding is a separate designation from the facility clearance. A Top Secret FCL does not inherently guarantee safeguarding. With that said, please list what you have as part of your submission, as the lack of safeguarding is not automatically disqualifying.


2. Where will each of the 5 sprints be carried out?

A: All five sprints will occur at the same CONUS location. The location will only be specified to selected companies due to OPSEC. 


3. How will the money be divided across the 5 sprints? How will it be divided among the participants of a given sprint? 

A: That will be decided later by the number of vendors initially selected and then by the number of successful vendors in each sprint. This information will be provided to selected vendors in advance of Sprint 1.


4. What platforms will be used for this? What autonomy stack will they be running?

A: This will only be specified to selected companies due to OPSEC.


5. Are Sprints 1–5 expected to run serially within a single continuous six-month period, or spread over a longer timeline with breaks between sprints?

A: Sprints will run serially within a single continuous six-month period.


6. Is on-site deployment required for the full duration of each sprint, or only during designated integration and demonstration periods (for example, a 7–10 day window)?

A: On-site deployment is expected for the full duration of each sprint.


7. Is a tiered staffing model acceptable, where Secret-cleared personnel support general development and infrastructure, and TS-cleared personnel handle integration and configuration involving TS-level data or scenarios?

A: We expect many individuals will be involved in development. We are just asking for TS-cleared engineers on-site. Tiered staffing is acceptable.


8. Please confirm that the title slide does not count against the 15-slide limit.

A: Solicitations should be 15 pages maximum. That includes all slides (including a title slide).


9. Please confirm whether an intent to establish a classified environment post-award is acceptable at the time of submission, or whether an existing ATO environment is required at submission.

A: Please list what you have as part of your submission, as the lack of safeguarding is not automatically disqualifying. Lack of an approved contractor-owned, contractor-operated classified Information System is not automatically disqualifying.


10. The solicitation states that it is an open call to small businesses and non-traditional defense contractors with other transaction authority. Will other proposers be allowed to submit?

A: This prize challenge is open to all vendors. Other Transaction Authority applies to potential follow-on other transaction agreements resulting from this prize challenge. Any such award must comply with the 'appropriate use of authority' provisions in 10 U.S.C. § 4022(d). Follow-on contracts executed after this prize are not restricted to prototype OTAs.


11. Should ROM pricing be submitted with the proposal for all five sprints?

A: No. As this is a prize challenge, you do not need to submit pricing.


12. Does the Government envision this to replace or be complimentary to the C2? (i.e. is each platforms UI still in play and this is a layer above)

A: Each platform’s native C2 system and UI will remain in-place as a complementary UI and safety layer for live testing in this prize challenge series.


13. Is a prime organization eligible to win who does not have an FCL but has a subcontractor with an FCL?

A: A prime cannot use a subcontractor’s FCL. The prime organization must have an FCL to compete in the challenge. DD254s will be issued to the prime organizations of selected submissions.