AI, autonomy, and the future of naval warfare with Captain Jon Haase, United States Navy

Today we're joined by Navy Captain Jon Haase. We've worked with Jon for quite a while on a specific use case involving underwater unmanned vehicles, which we'll talk about. Jon is the program manager for the Navy's Expeditionary Warfare Division, so he has a broad purview into how AI and warfare interact.

First of all, can you tell me about some of the AI applications you've recently been involved with and how they work? I think you're in a domain that a lot of people listening to this podcast wouldn't know much about.

One of the applications at the heart of what we do is automated target recognition. I have to back up a little bit and talk about the hardware where we want these models to run, because that's really important to understand the unique challenges and the way automated target recognition is done.

Automated target recognition runs on unmanned underwater vehicles. These are underwater robotic systems that are preprogrammed to run missions, search the water for mines, and then, based on what they find, either cue autonomous behavior by other vehicles or simply bring that data back and allow human operators to be involved in decision-making about what to do next with those mines and the naval operations that are happening.

The AI component of automated target recognition is an ensemble of deep learners that we've put together over a number of years with a number of third parties. They're able to integrate the models onboard an NVIDIA processor that runs on the unmanned underwater vehicle and deliver inference at runtime in order to cue where we've found targets.

It also runs on laptops, helping human operators who are reviewing all the data generated by the missions to review that data more reliably and quickly and determine where the mines are. It's cueing, targeting, bounding boxes—the sort of thing you might expect.

It also involves bringing the data back from new missions and then fine-tuning all the various components of automated target recognition, figuring out how to weight and ensemble those components, and rapidly redeploy them to the vehicles.

The main application we work on is AI to detect mines on autonomous underwater vehicles. It uses a number of different techniques that work together well when ensembled and are now power-efficient enough, with sufficiently low runtime latency, to be relevant. There's also enough metadata on the vehicles to provide a rich environment for us to extract that metadata along with the generated data.

That's the heart and soul of what we do: automated target recognition for underwater operations to detect mines so that we can conduct operations.

We're also looking at some less mature pilot programs focused on making it easier for sailors to interact with these vehicles. We're looking to replace PDFs and interactive technical manuals with intelligent agents trained on all the relevant specifics that could answer questions, help with field maintenance, and even help plan missions.

Zooming out a little more, as many other people are doing, we're looking at how AI can help the workforce developing these products—generating documents more effectively, understanding our requirements better, and acting as an intelligent assistant in the process.

So we're looking at those 3 things, but the one where we've had the most engagement, involvement, and operational impact is automated target recognition, which allows us to spot mines underwater with those vehicles.

This underwater autonomous vehicle—is that a fancy way of saying a submarine? They look like submarines from my perspective. Can you describe what they are?

In some ways they look like submarines, and in some ways they don't. Think about a cylinder. There's no need for life support, and that's really the big deal about autonomous underwater vehicles: you don't need any of the services a human would need—oxygen purification and generation, atmospheric controls, heating, or discharges from the inside to the outside.

It's just batteries and systems. That allows you to make much smaller systems than you could otherwise build—systems that a human being could never fit into. I have experience with the smaller and medium versions, ranging from about the size of a normal dining room table to roughly 2 tables put together.

They're long cylindrical tubes with 1 propeller at the back to power them, along with a couple of control surfaces and fins. For sensors, we have some that look forward to detect things directly in front of, below, or above the unmanned underwater vehicle. We also have sonars looking downward from the sides that can search the bottom.

We load these vehicles up with sensors and batteries. More recently, we've put onboard compute on them as well. Then we add navigation and autonomy software and preprogram the missions.

One thing that might not be obvious to people is that underwater, it's harder to communicate. You really need total autonomy, right? How much contact do you have with the vehicle?

1. Why underwater operations are harder than people think

I'm glad you mentioned that. It's one of the hardest things for people who haven't had to operate underwater to appreciate. The fluid you're in is about 1,000 times denser than air to start with, so speed, resistance, and control surfaces are all challenging. You also have to adjust for altitude.

You can't use GPS, and communication underwater is really challenging. To communicate between vehicles, you have to use sound waves that travel through the water. There's a lot of background acoustic noise generated by marine life, for example, as well as sound channels created by temperature gradients.

Even delivering sound energy between vehicles becomes challenging. Then you have encryption issues to work through when delivering that information. If just communicating between the vehicles becomes difficult, there are a number of other challenges as well.

Is the underwater autonomy also an AI system, or is it relatively simple because there isn't really anything to crash into underwater? Do you just aim it, or does it also have to navigate and use sensors?

There are a couple of things to unpack there. The first is that there are things to crash into underwater. If the chance isn't 0, then given enough time, all things will happen. We've done it.

There are steep banks and gradients, and when you program missions, you have to maintain relatively close proximity to the bottom in order to generate much of the targeting data—the sensor data—we use. If you have a steep cliff and you're not looking forward while looking down, you can inadvertently run into it. You can absolutely run into things underwater.

The autonomy is preprogrammed and deterministic right now, but it's connected to our AI systems. This is why having AI onboard and being able to perform inference at runtime on the vehicle, with low latency and in a power-efficient way, is important to us.

If we think we've seen a mine, we're able to dynamically adjust the mission in a preprogrammed way. We can essentially bring in a branch to the original plan and search that area more extensively while the mission continues.

That avoids having to bring the vehicles to the surface, evaluate the data, reacquire the object of interest, and run an entirely separate mission. So while the autonomy is deterministic and not generated by AI at this point, it does rely on AI and is integrated with it, allowing us to change the autonomy in preprogrammed ways and speed up the mission.

I would naively think that you'd want to put an underwater mine close to the surface. Why does the vehicle run close to the ground?

There are mines on the bottom, mines in the water column, and mines very close to the surface. It depends on the specific design of the mine and how it's designed to function. Some are designed to function very efficiently from the bottom.

Are mines a big problem? Are there lots of mines out there? This is way outside my wheelhouse, but is this a real problem that you need to solve, or is it more of a proof of concept for the technique?

They've been used in the past, and they can shut down fleets in the middle of operations. They are incredibly dangerous when they're out there, and they're fairly low-cost, so they're an asymmetric threat in a lot of ways. They're also very difficult to detect.

This capability is important because it's not a theoretical threat. The Navy has run into mines in the past. We have plenty of case studies about where and how that has happened. It's not a problem until it is, and when it is, it becomes a very big problem.

Going all the way back to the Civil War, in the 1864 Battle of Mobile Bay, Admiral David Farragut was going into Mobile Bay with ironclads and wooden ships together. “Damn the torpedoes, full speed ahead” came from the moment when the lead ship in his formation, the Tecumseh, one of the first ironclads, hit a mine.

2. The real threat of mines and historic Navy examples

It was so disruptive to the operation that the entire fleet stopped. The Battle of Mobile Bay stopped because of the mines. Farragut was on the Hartford, the second ship in the formation. The first ship in the wooden column stopped because they were so afraid of hitting mines, and he ordered his ship ahead at full speed, right into the minefield, and progressed with the fight.

That's where the famous expression came from. “Damn the torpedoes, full speed ahead” was associated with the assault on Mobile Bay in the Civil War in 1864, where mines became a critical factor.

The only reason we survived that attack from the mines we were in the middle of was luck—not because we had conducted mine countermeasures, understood the threat, or avoided or mitigated it sufficiently.

The interesting thing is that, back then, ships cost about $17 million in today's dollars. Today, they cost billions of dollars. It's simply not something we could do again.

So, yes, it's not a theoretical threat. Mines are out there and active.

Would someone put these vehicles in the water ahead of a boat, and would they go out and look for mines? How would they actually be used in practice?

The vehicle would be used to find and clear a minefield. A lot of things would play into how we might suspect that an area needs to be cleared. It could be the geography we're going to navigate, the threats we know about, or a number of other things available to fleet commanders that would indicate, “This is worth investigating. These are risks we need to mitigate further.”

Obviously, the ocean is much too large for us to do this everywhere. It has to be done strategically, at points that matter, at the right time and in the right place, for the right ships to transit through. That's all very situationally dependent.

This seems like a really good example of putting intelligence into objects in a useful way. It's also a good example from a public-relations perspective, because mines seem like a horrible way to kill civilians. It seems incredibly dangerous.

But there seems to be a spectrum of different levels of autonomy that you could give lethal devices. Do you have a framework for thinking about where you would draw the line? You definitely wouldn't want an AI system deciding to launch nuclear weapons. That would be an extreme example that no one in their right mind would support.

But there seems to be a lot of things in between. How do you think about that? Is it possible to hold a standard of never integrating AI into anything offensive?

I appreciate you highlighting that there's a broad spectrum of applications for the Department of Defense to use AI. Our portfolio has been doing this for some time, and as you highlight, this is a great mission for us because it's defensive. It clears threats and obstacles so that not only do U.S. Navy ships avoid hitting them if that becomes an issue, but civilian mariners and others are also protected and kept safe.

It's an easy mission to get behind in that way. There are no ethical questions about using AI to clear these hazards. It's on the protective side, which makes the ethical question you're asking much simpler.

I've never had to wrestle, in terms of my job, policy, or larger issues, with where AI and autonomy could be used for more offensive operations. I haven't had to think through what a program would look like, or the failsafes and other things necessary to do that.

My thoughts are that taking human life is such an incredibly impactful thing that I could not imagine offloading that to AI or autonomous systems in any meaningful way moving forward without humans being directly and specifically involved. All the ethical concerns and considerations would need to be fully met in that regard.

There's a spectrum between gathering information and lethal operations, and it's very use-case-specific. The best way to approach a subject like that is with extreme regard for human life and safety and for explainability.

This is an irreversible thing that could only be done in the most responsible ways, with the best oversight possible, to ensure that no collateral damage occurs and no civilian or innocent lives are lost. We should approach it with that framework and recognize that the tools the military has should allow us to do our mission better, but should never put the ethical high ground that we have so proudly maintained—and still do—at risk.

3. Ethics of AI and autonomy in military defense

That seems like a comfortable position when you don't feel under threat. In Silicon Valley, I think people have often been against any kind of AI military application. But seeing the war in Ukraine reminded a lot of people that there are bad actors out there, and they presumably aren't holding themselves to such a high ethical standard.

We might have enemies who would build autonomous weapons with any degree of autonomy. You might lose a conflict if you weren't willing to be a little more aggressive. Do you think it's possible to hold the standard of never integrating AI into anything offensive?

I wouldn't say never integrate AI into things that are offensive. Certainly, you would need and want to do that. As the pace of conflict advances and adversaries build these capabilities as well, you need to keep pace in front of them.

You also mentioned being aggressive, being victorious, and being warriors who can prevail in the face of conflict. I think it's an “and,” not an “or.” You can be aggressive, you can be warriors, you can prevail in conflict, and you can maintain the moral high ground.

The way you integrate AI, autonomy, and advanced technology into that operational scheme is use-case-specific. But a strategic imperative is that we never want to give up the ethical and moral high ground. We never want to alienate our allies and the people who would come with us into future conflicts.

Those are bedrock principles of the American military and have been for a long time. I don't think you can't enable and integrate AI and autonomy while still maintaining the moral high ground and respect and dignity, with low or no collateral damage to innocent civilians, while prosecuting wars.

Those things are completely synchronous and can be done at the same time. We have incredibly talented people working on those issues, and I'm confident that in the moment when we need to make a decision, we would handle it appropriately.

I'm curious what it's been like for you working with Silicon Valley companies. In the last couple of years, it seems like defense has had a lot more collaboration with Silicon Valley and the U.S. military.

Going back a few years, I remember Google Cloud deciding to stop supporting certain military applications. I remember how badly that made people I knew in military applications feel, and how much animosity it created at the time. Do you feel like that has been worked through and forgotten, or is there still some talking past each other or resentment on the defense side?

On the military side, I don't think there are any issues. We've always wanted the best tools and capabilities so that we could be the strongest military ever and maintain that position of strength.

Whatever the tools are and whoever makes them, we'll gladly use them. We just want to win. That's really the only rule of warfare: win.

However and wherever we do that, we have to account for protection of life, the moral high ground we maintain, and our allies and partners. But the goal is to win. America is amazing at that. We're as good as we've ever been.

You mentioned Google specifically and the transition they've had, along with some of the stories in the press. As I understand it, they now have Impact Level 5 approval for use in government. Where they were versus where they are now, they're offering services to the Department of Defense and complying with some of our security concerns around cloud computing and cloud usage.

They've entered that marketplace with a large contract recently, along with Amazon and Microsoft. They're now one of the offerings available to the government.

More broadly, the fundamental issue is the partnership between technology companies and the military. I think there's actually a great relationship between technology companies and the military, one that's beneficial to everybody.

We're seeing younger companies bringing in a lot of technology and forward-leaning processes, moving aggressively and quickly to develop useful capabilities and challenging the status quo from a technology perspective. We're also seeing venture-backed technology companies entering the defense technology space, as well as more partnerships with larger technology companies.

If you look at what Microsoft is doing with OpenAI and offering some of those connected services, there are examples of major technology companies supporting defense and government in general through partnerships.

What I've seen is that technology companies are trying to understand defense better and trying to serve us as one of their customers. We're grateful to have that technology coming in, giving us more fighting power, and making our military more effective.

There are cultural differences, of course. I've had some exposure to what a technology company is like, how you treat employees, what the demands are, and the technology and talent you recruit. That's obviously a very different culture from the military.

What's important is understanding and communicating between the customer and client. Technology companies need to understand the reliability required to operate in a military environment and be used in conflict and combat. We also need to understand their capabilities and limitations, their financial structures and incentives, and how to make the process of working with the government easier for technology companies.

There's understanding and outreach on both sides, but it's to everybody's benefit. Generally, things have gotten better, and I see a future in which those relationships get stronger.

I think we'll see more defense technology companies founded by technology people who have done successful startups or worked at large companies. That's going to increase over time. There's also a lot of capital going into the space, so I think the marketplace is very rich and robust right now, and that's to our benefit.

One thing you mentioned before we started recording is that people really underestimate the gap between software applied to a civilian use case and software applied to one of your use cases, and how much work goes into hardening the technology to make it work for you.

Could you talk a little about that and tell us some stories from the work you've done? What needs to change? When I zoom out, autonomously operating a car, as we have in San Francisco and as many of our customers do, and autonomously operating a submarine seem somewhat similar. It's sonar instead of lidar, and the cameras don't work as well.

4. Why cyber-hardening turns a 10% problem into a 90% rebuild

Both a submarine and a car can be lethal weapons if you operate them badly. What's the difference when you try to take technology that wasn't designed for you and make it work?

At a very high level, the biggest difference is that I'm not convinced autonomous vehicle companies are considering adversarial attacks. Adversaries are actively looking at those vehicles as attack surfaces, and there are regular, repeated, deliberate attacks designed to disrupt their operation, make them intentionally unsafe, or prevent them from functioning as designed.

Even worse, the vehicles could be compromised in a way that's unknown to the operators at the time. The fleet of vehicles could become a proxy for someone who isn't supposed to have access to them.

Actually, as you say that, maybe they should consider that. You're right that they probably aren't considering that scenario, but it doesn't seem impossible.

That is a real issue, but it isn't considered by the manufacturers of those vehicles. There's a reason for that: nobody likes cybersecurity.

When you cyber-harden an object, it becomes harder to use, slower to operate, longer to boot up, and more difficult to access from a login perspective. When you go from single sign-on to multifactor authentication, you've made the login process harder.

Now imagine adequately cyber-hardening a vehicle so that all those attack surfaces are mitigated and a dedicated, professional actor couldn't access that vehicle under any conditions. You might have 3 keys to the vehicle. Once you got in, you would need a password. You would need to make it larger and slower because there would be more hardware and software onboard.

The entire communications bus would have to change. Internal messaging would be encrypted. Everything would work worse. That's why people don't like hardening things so that adversaries can't get to them: they're more difficult to use.

This is one of the most significant challenges we've personally had to deal with in our programs. We took a commercial robotic system that worked very well, and we were the first to put these unmanned underwater vehicles through the process of cyber-hardening in accordance with Navy standards.

We thought we were making a 10% change because all we had to do was add a few modules. It turned out to be a 90% change. We quickly realized that we had changed the communications structure, the communications bus, the physical architecture, the software layers, and even the way the vehicle communicated.

To give you an example of the complexity we didn't appreciate before we began, the length of the signals that had to be sent through the underwater acoustic channels increased because the signals were now encrypted.

In addition to the signal, you had to send encryption packets. That required one of the transducers and the digital signal processor to stay open longer to transmit the signal. That applied more voltage for a longer period across the circuit, which caused it to overheat and caused the circuit card to fail.

We were adjusting the physical architecture of the vehicle to account for a communications challenge related to signal processing, all so that we could get the communication packets through. That's just 1 example.

When defense technology companies or others come to my programs with things that work, they never actually work for us. What seems simple turns out to be very complicated.

So, to your initial question about autonomous vehicles—why can't we just do this with underwater vehicles? First, the challenges underwater are significantly harder than operating on the road, even though operating on the road isn't trivial.

Then there's the requirement for reliability and robust cybersecurity. That becomes very challenging. We have to tackle those problems, and we're at the forefront of cyber-hardening robotic systems so that adversaries can't access those attack surfaces.

That has all sorts of technical implications that were difficult to foresee before we did it. Working prototypes that aren't fully hardened and don't meet our requirements turn out to be very difficult to fully harden.

Does your organization do its own AI research, or do you outsource the AI research? What parts do you feel are core—things a company might think it really needs to know how to do itself—and what parts are okay to outsource to third parties who can do them better?

We do some of our own research. The government has technical centers of excellence capable of doing some of this work, and we leverage them.

However, for our particular programs, we also need partnerships with industry. We work through major defense primes that can provide some of the AI services we need. That's on the bespoke side of things, when we need specific capabilities built just for us.

There's no civilian equivalent of automated target recognition that we can access as a commercially available product. The way we think through that process starts with a market survey to see what's available and reaching out to government warfare centers.

The first question is: Has this been done before? Has anyone done this already? Is there information, an architecture, a model, a data repository, or a workflow we could use? Is there even a schema we should use for commonality between our data sources?

We'll do a broad survey. In some cases we'll find things, and in some cases we won't. The next step is to scope the requirement and think through it carefully so that we can go out to industry.

There are a number of ways to do that and find the best available commercial partners to develop the algorithms for us. As the pace of innovation accelerates, with novel models and open-source opportunities becoming available, many of our providers with mission experience can leverage those open-source models.

That's really catapulting and advancing our capabilities. We take what's available in open source, ensure its safety and reliability, bring it into our system, and work on it.

We think about the requirement, what's already been done, what's available, and then a contracting strategy that lets us access the best available workforce to do the work. That's on the bespoke side.

On the other hand, if we have a large language model requirement to perform a function, we'll start with a commercial landscape to understand what's available. If there's a prebuilt solution, we're better off changing our requirement to meet something built at scale than trying to create a bespoke solution to meet our needs, if there's anything even close.

The really important thing for my team is adjusting our expectations to take advantage of what's commercially available and working on policy so that we can use it appropriately within our programs. Given the amount of money invested in training large language models, research, and commercial development, we'd be foolish not to take advantage of what's available and instead modify it ourselves. That would increase our costs exponentially.

I was wondering how you think about competitors. I was excited to hear you say that America is the best in the world at winning—that seems reassuring.

I have competitors who keep me up at night. Do you feel similarly about other countries' militaries? Do you think about whether they're doing something better than us or figuring out things we don't know? Is that something you think about a lot? Are there aspects of what they're doing that you think we could learn from?

There's a lot in there. We can learn from everybody. I learn from my kids, so we can certainly learn from other militaries. There are things we should be watching.

Or do you not even consider other militaries competitors? Is that the wrong analogy?

I'm afraid of no one. There's no country that keeps me up at night. We are America, and I'm not afraid of what that means. I work with people who aren't afraid of what that means. I've been in combat, I know what that looks like, and I'm not afraid. The people with me right now aren't afraid of what that means either.

We will go toe-to-toe with anybody, and we fear no one. We respect everyone, though. War is a terrible thing to be part of, and in some ways nobody wins. We should have an attitude of respect for everyone out there. Everyone can put up an amazing fight.

You can look back through history and find examples of great powers struggling with smaller opponents. You can get the stiffest resistance from people you didn't expect it from. You have to respect your adversary in combat.

At the same time, we're not afraid of what that means, and we're not afraid of moving forward to defend our country and our nation. I'm proud of the work we've done in front of me. I've seen people who weren't afraid go into combat and be victorious, and I see the people coming behind me, as I get ready to retire, who are going to take that torch and aren't afraid of what it means either.

We don't fear other countries. We respect them and what it might mean for us to compete with them in the future. We also have to be humble enough to learn from everything that's happening.

Technology has shaped what it means to go into conflict for a long time, and technology is changing more and more rapidly. That's why the relationship you highlighted earlier between technology companies and the Navy—and the military more broadly—is critically important.

5. Why software alone will never win a war

We need to be aware of what's happening and use it as effectively as possible to remain the strongest fighting force the world has ever seen. I'm very proud of what we've done.

Maintaining a technology advantage seems incredibly important for staying safe and winning wars. As technology moves faster and faster, maybe that becomes even more important.

I don't know if that's a technology executive's bias, but the idea of another country having AI technology that's a few years ahead of ours seems scary, especially when you think about the military applications.

Software has never won a war. That's not how wars are fought, and software isn't going to be what decides the next war either.

John Boyd was famous in the Air Force and Marine Corps during his time in and after active duty. Americans with planes that were not as good were able to best Russian pilots in the air because our planes had hydraulics and theirs didn't. We could maneuver faster.

Their planes were technically better and had better performance specifications, but the pilots couldn't operate them as effectively. Because of the human factors involved, our pilots were better in the air because they could make better adjustments in the planes they were using.

It's not just about the technical specifications. I haven't seen a conflict or combat situation where software was the deciding advantage. It's an enabler, but nothing will replace the fighting spirit of the people who use those tools.

It might be terrifying to see the technological battle go back and forth and to see who has the advantage at any particular moment, but I don't think that will ever be the deciding factor. There's a margin, and as long as you're within that margin and can still compete with the necessary technology, there's something magical about America.

Anyone who tries to test that is going to be very disappointed with the outcome. Technology is going to be an important part of that, and we're going to use it as effectively as we can.

I'm pushing back a little because it seems like software could make a huge difference.

It's just not how we win wars. Software isn't going to march into the capital of another country and declare victory. That's not how it's ever been done, and I would be shocked if it were ever done that way.

Autonomy is going to be important, and AI is going to be important, but they're just components of how we operate. They're not the only components.

You could look at energetics in explosives, for example. If one country has better energetics and a higher energy-per-pound of explosives delivered than another, wouldn't that mean it would win? That's 1 factor, but so much goes into warfare that, at its heart, warfare has always been about people.

I think we have the best warriors the world has ever seen and the strongest military ever. We've stitched all these capabilities together in an incredibly impressive way. Software is part of that, but it isn't the only part.

As the defense technology community rallies behind and partners with the military, it's important to realize that technology isn't the only part of the equation.

Software could also play a role in training and selecting people. If people are the most important thing, that seems like a good place to try to use more software.

Absolutely. AR/VR, any way you can make the humans involved in military activities more effective is important. This is where automated target recognition becomes so important, and where enabling decision advantage becomes so important.

How do you lift the cognitive burden from people so they can focus on the right thing at the right time? How do you keep them from being overwhelmed by irrelevant information while allowing them to clearly see the signal through the noise?

They need to make the right decision about combat operations at the right moment and move forward as effectively as possible with the most important things that need to be done.

You can look back through the history of warfare and find all sorts of examples. In World War II, Nimitz sent a message to 2 famous admirals. Nimitz meant for Halsey to attack a Japanese battle group that was passing through a vulnerable position.

Halsey received the message and thought it meant “be ready to attack,” so he never attacked. We had better technology, better intelligence, better positioning, and the element of surprise, but it didn't matter.

6. The future of warfare: faster, unmanned, more autonomous

That's an example of how many factors go into these operations. You have to cut through all of that and get to the best decision-making, the best situational awareness, and the best capability. All those factors have to come together in a kind of magic moment.

What do you think changes in the next 5 to 10 years as these AI applications explode? It seems like what we think of as war will look very different, with a lot more unmanned things operating. In the news from Ukraine, you see many more drones and similar systems. Am I off on that, or what's your view?

I don't think you're off. That's a trend that certainly won't go away. I don't think we've yet seen a nation-state put all its resources behind conflict operations with the technological scope and background that America has right now, so we don't know what that would fully mean.

That will be 1 factor among many. Technology will play a big role, and unmanned systems will play a big role. The future of warfare will be increasingly enabled by technology.

I do think we'll see more robotic systems on the battlefield. How they interact with each other, how they generate information, and how humans process and use that information on the battlefield will change significantly.

There are a lot of tailwinds from technology development in the commercial sector. I think humans will be enabled to conduct more operations in more locations remotely. We'll have better information and more real-time information.

We'll see a more connected battlefield, where information flows between robotic systems, humans, and AI agents that help with decision-making. The pace of operations will speed up more and more.

The other thing I know is that every time we've entered a conflict in history where technology played a decisive role—whether it was the advent of aviation, rifling introduced into firearms, gunpowder, or whatever it was—we were always surprised by it on the battlefield.

There will be surprises that nobody is anticipating. It's reasonable to project current trends into the future, but leave about 30% for something we don't see yet.

What about large language models? We've mostly been talking about autonomy, but I was excited when we spoke earlier and you mentioned using Gemini in your daily job and your wife using Cursor as a developer. That seems pretty modern and exciting. What LLM applications are you seeing right now?

The Department of Defense is really trying to figure this out. They know it's important. The Air Force has done some great work, and it's a policy issue for us right now.

We've never had to bring intelligent agents into the Department of Defense before, so we have to think about what that means for information protection, policy compliance, ethical considerations, and all those other issues. We're taking a measured, cautious, and diligent approach.

There are some limited instances starting to be piloted. Gemini is one example. Anthropic has recently come out with some applications with the Air Force that can access its systems, and Microsoft is making some of these available at different impact levels.

7. How LLMs like Gemini are entering defense

As people gain access to these systems, they'll gain access to LLMs. We can expect things to move more rapidly, higher quality on the first attempt, intelligent assistance with reviews, and complicated processes becoming easier to understand and navigate. Cycle times can be increased, and developers can become more productive.

It's an exciting time to onboard this capability. There's also an incredible opportunity because some of what's happening with LLMs inside the Department of Defense will be unique to what's happening outside it.

There may be a space that's not being adequately served: how an LLM could be specifically tailored to meet the needs of the Department of Defense.

Could you be a little more specific about what would be different? At a high level, it's all humans trying to solve problems, right?

There are guardrails on large language models around things you can query and policy areas that you generally wouldn't want people to discuss or talk about. Those issues would be part and parcel of being in the Department of Defense and conducting combat operations.

Somehow, we need to enable people doing mission planning, studying warfare, making plans, viewing plans, processing battlefield data, and dealing with casualties and combat operations. Those activities might trigger policies and guardrails that generate a response saying, “This violates our policy, and we can't serve this at inference.”

There's a requirement for more interaction around lethal operations—what the Department of Defense does, what we want to plan for, and how to process that information.

We haven't had to do this at scale during combat operations yet, but I foresee policy issues both in our ability to use large language models and among the people creating them. You wouldn't want ordinary people talking about how to conduct an assault on a position, but within the Department of Defense, those are things we're planning for and would want to enable.

There's something there to figure out. We haven't yet seen what those policy issues and problems will be, but the Department of Defense would have more limited applications if they're not addressed.

Right now, we're trying to use LLMs and AI agents to do the day-to-day job: paperwork, low-threat processes, awards, and HR tasks. But when we get into the core business of the military and consider whether to use these systems more in the future, there needs to be a closer partnership around the policy guardrails associated with LLMs.

One concern people have with LLMs is that an individual could learn how to create a biological weapon and then build it, or learn how to create lethal weapons and cause serious problems. Is that something you think about? Does it change the way you think about security?

It creates some new problems, but they aren't entirely new. That information can be found in various places. If you look back at events that have happened, that's the genesis of where people have found this information. The information is already there; LLMs make it a little easier to access.

The Department of Defense doesn't control what companies are able to serve, how their policies allow people to interface with or jailbreak systems, or how they restrict information. We also don't know how these models were trained, so we don't have the data provenance to know what they were exposed to, what they know, or what they could figure out.

If you have more and more intelligent agents, could you have one part of the planning process in one chat window and then stitch together a number of chat windows? These are questions I don't have answers to, but they're things I think the trust-and-safety teams at technology companies need to take seriously.

I'm encouraged to see many companies thinking about trust and safety and establishing policy guardrails to try to prevent this. They need to continue monitoring these systems and taking an active role to ensure that intelligent agents don't put people needlessly at risk because of policy problems or guardrails that weren't put in place.

One thing that affected my world, and the stock market quite a bit, was the surprising launch of DeepSeek R1 and R10. Did you notice that, and did it change your views about LLMs or how they might work?

We certainly noticed it. That was obviously a major development that captured everybody's collective attention, and it still does. It was a big surprise and hard not to notice.

I'm less concerned about the military application and what it might mean for the work we're doing. We're still trying to figure out and process policy issues, use cases, and applications for existing U.S. AI systems that are already being onboarded into the Department of Defense to help us do our mission more effectively.

There's so much to work out there. It's a bit like running a race. Do you focus on running your race, hitting your marks, finishing on time, and pacing yourself? Or are you looking at your competition the whole time?

In this case, there's so much work to be done and so much value to be gained from the technology that exists in the U.S. sector right now. We're focusing on the opportunities we have and what we can do, rather than on things outside our control.

Again, the best LLM will never replace a good soldier, sailor, airman, or Marine. Having brave and courageous people willing to go out and be part of a team is much more important than a 10% or 20% competitive advantage between large language models.

We're best off focusing on what we have and making the most of it. There's so much ground to gain by doing that that we don't need to be overly concerned about the capabilities of other countries right now.

8. Leadership behaviors that drive AI adoption inside the military

I don't think anyone has fully and completely captured the value available from technology like this yet. The people who will do best are the ones who integrate it best, train with it best, and teach people to use it best—not the ones with a 20% performance improvement on an ARC benchmark.

You mentioned earlier that you wrote a white paper about getting people to use AI better. We didn't find it in our research, but that sounds really interesting. Could you describe what it was, and is there a pointer we could put in the show notes if it's publicly available?

It's a paper that's currently under review for an academic publication. I like doing academic publications with colleagues in the Navy, so that work is still in progress. That's probably why you didn't find it.

I did have a publication in Technologies about using AI metrics for continuous improvement and assessing where we are so that we can make progress. There's also an upcoming publication in IEEE about agility readiness levels, using AI and contracting approaches, and organizational agility to select the correct contracting approach.

The one you're referring to is the paper I'm most excited about. It's about leadership behaviors that enable organizations to adopt AI and technology more effectively.

It came about because we started bringing early pilot programs into our team, and adoption was initially slow. My teammates were concerned that they would be perceived negatively if they used AI to do their jobs better.

I had seen research showing something like a 25% improvement among consultants using AI tools. These are highly trained, very intelligent people getting a double-digit boost in productivity, so I knew it was important for us to do.

I started asking myself, as a leader, what I could do to improve AI adoption throughout my organization. I like to work with people one-on-one or in groups, in my office or over Teams. If a question came up or there was something I didn't know, I used to ask people in the office, “What is this?” We'd talk about it, and they'd bring me up to speed.

I started asking our AI assistant instead. I wouldn't obscure the fact that I was asking these questions of my AI tutor or assistant. I'd turn the screen toward my team during the meeting and type in the question. Sometimes, while the conversation was still happening, I'd generate the response and say, “There are these things we hadn't considered.”

They'd read it with me, and within 1 or 2 weeks of starting this very simple behavior, other senior leaders in those meetings began doing the same thing with their teams. They started sending me products that were better organized, better structured, and had better review and thought behind them.

I'd ask them about it, and they'd say, “We just started using the same tools you did.” They realized that instead of looking down on them negatively for using AI, I was encouraging them to use it and wanted to see the output.

They're responsible for their work and can use the tools as they see fit, but they still have to cover all the relevant policy issues. That led me to start unpacking the leadership tools and behaviors we could use to demonstrate to our teams that they had psychological safety and our backing to adopt these tools.

One of the AI researchers I'm working with is at Georgetown and AWS, and we're coauthoring a paper that we hope to present in Switzerland. It's currently under review, and when it's published, we'll send you a link. Hopefully, it's accepted.

The paper is really about the human aspects of adopting AI in teams and incentivizing people to do that while keeping them accountable. We're continuing to explore behaviors such as training sessions so that everyone understands the capabilities, rolling out new tools, expressing excitement and enthusiasm about them, demonstrating leadership by using the tools ourselves, and encouraging our teams to see us using them.

We're also integrating them into existing workflows. This may seem silly because most people are probably already doing it, but I started asking everyone to make a transcript of every Teams call so we could download the text.

Now we have natural-language processing. My thought was that if we ever needed to build a repository and perform retrieval-augmented generation, we wouldn't have to download all our program documents. We could pull our transcripts, which would contain our conversations, and perhaps the system would know us.

Then we could interact with agents that had access to everything we'd said in those transcripts, which we controlled. The compression of information is amazing when you go from spoken language and video to a text transcript.

This is another leadership behavior. We'd ask, “Where's the transcript? Where did it go into the repository? How do we structure our file folders so we can access these and so that an agent can understand which program we're discussing based simply on where we put the transcript?”

Those are all things I started unpacking with the team, and I've seen positive responses. If you have best practices in this area, maybe we can partner on the paper in the future.

It sounds like I could learn from you. That's fantastic and really interesting. It's also cool that you have the space both to innovate in your leadership that way and to publish research so other people can learn from it.

I'm fortunate to have a medical component in my portfolio. Some PhDs in physiology are part of my team, and 1 of them was very interested in AI. When I started talking about publishing in a peer-reviewed journal, his eyes lit up.

We come up with topics, submit them for publication, partner with academic institutions, and put them through the review process the Navy requires. I've actually published more academic papers—and I'm about to publish in IEEE, which I'm thrilled about—now, 20 years out of graduate school, than I did while getting my master's degree.

That's really cool. It's amazing to see the breadth of topics, from LLMs and leadership to contracting. I think we also found a paper on underwater mine finding, right?

Absolutely. I love this job because it has such a broad range of applications. We get to look at so many things.

I swim in this every day, so I understand how it works in the government to put things on contract, test them, structure a contract, award modifications and options, and work with the Defense Innovation Unit to evaluate commercial solutions. I think, “Of course, everybody knows this.”

I want to learn the technology side of it, so I turned out to be more technical than most program managers. When I talk to technical people, they're surprised that I understand how the process works.

9. Why multi-agent autonomy is the future of battlefield AI

I'm in this great space where I can bring in experts from different domains and contribute to academic work or advance technology within the system. I let my creativity guide me and find interested partners who are willing to put in the work with me.

It scratches a lot of itches. One of the things that makes me most nervous about retirement is that I won't have such a broad breadth of interests or be able to explore things as freely as I do now, because I love it.

It sounds like you could spin out a company that uses AI to help contract with the government. I think that would be wildly successful. You could count me as your first customer.

I'm ready when you are, Lukas.

As a final question, are there other topics in AI that you're interested in exploring? Is there research percolating in your mind that you'd like to talk about, or applications you think are coming that you haven't had a chance to publish on?

Multi-agent collaborative autonomy is a fascinating and underserved topic. I'd love to look at how information interchangeability and interoperability could work with robotic systems on the battlefield.

I think about all the robots that are going to arrive, all the sensors in different file formats, and all the streams of information that we're generally not paying attention to. How do you sift through that information, find the signal in the noise, and build the right agents at the right levels to perform the right functions?

How do you get interoperability between the agents and data interoperability as well? I'm fascinated by this idea because I picture a 4-person team on a boat using these vehicles to run a mission.

They have to plan the mission, which is currently done by hand by entering a set of data points. It's preprogrammed, and then it runs. But what if data generated dynamically during the mission allowed an AI agent to help the human re-task and replan the mission more effectively?

That data could then flow up to the next level in the chain of command, where people are making decisions about missions across many ships. Data interoperability would allow it to flow seamlessly, be compressed appropriately, and let the agents communicate with one another.

The next agent would understand what's happening at the individual missions and what that means for the larger operation. That process could continue upward, with agents communicating and interoperating with one another and tuned to the appropriate level of the chain of command.

The agent trying to determine whether the thing you're looking at is a mine or a rock would share the same data but perform a different function from the agent deciding where to place all the ships across the entire battlefield.

I think it's fascinating to look at multi-agent collaborative autonomy, where agents have interoperable data, perform different tasks, and feed into each other's decision-making processes in a dynamic, real-time, connected way. It would be amazing to explore, understand, and develop.

The second area would be an LLM specifically designed to support use cases within these operations and tailored to do exactly that.

Consider the example of Nimitz's message to Halsey. The words were improperly written or improperly understood, so the mission never happened. Imagine if that could never happen again because intelligent assistants were perfectly tuned to the mission.

The person receiving the message could ask exactly what was happening of the agent, and that could be the same agent that wrote the mission on the other end. The data compression would happen at the agent level, rather than in the communication of the words themselves.

Those 2 things are on my mind right now, and I'd love to explore them further.

You bring an interesting lens to that. You're oriented toward the way humans collaborate and work together, and you view that as more important than the technology. But then you're applying that focus on communication to technology—getting agents to collaborate and work together as a team, and focusing on message-passing with clarity.

It seems like that's a real thread.

It's like the von Clausewitz thing: the fog of war is difficult to get through. You're tired and exhausted, adrenaline is pumping, messages are broken, data is sparse, and you're trying to make sense of everything on the battlefield.

Imagine how much progress we could make by solving that problem. At the end of the day, everything is a human problem.

That's why technology is meant to enable and empower humans, not replace us—particularly on the battlefield, no matter how good it gets. Making things more efficient, faster, and easier is extremely interesting to me, and the returns from doing that could be completely outsized.

The benefits are outsized when you compare them with making some marginal improvement to an airplane. It's not even close.

I have to ask you about something. A lot of my entrepreneur and CEO friends who have never been near a battlefield and don't know anything about it love a quote—I think it's attributed to a general—that amateurs talk strategy and professionals talk logistics.

Is that a real quote? Is that something you think rings true in your field?

It's used all the time. Whether it's an actual quote or not, it's a truism that's used constantly. That's absolutely the case.

In my world, I develop capability and field it to the Navy. The analogy I use is that amateurs get excited about working prototypes.

They say, “We found this thing that works.” But everything works at some point. It may not work well enough for us, it may not be hardened, and it may not be ready. That's 5% of the problem: getting something to work.

That is absolutely true. Amateurs get excited about a prototype, while professionals ask how to resupply an army and get enough food so that nobody starves. Those are questions you wouldn't think about if you're focused only on the tactical part.

The way that translates into my world is that technology that might work might not work for us. Understanding that difference is a huge gap, and developing the skills to close it is very difficult. It takes a lot of time, energy, and effort.

Professionals ask about sustainment, fielding, cybersecurity, and policy compliance—not just how effective the system is. An effective system is table stakes, but it doesn't get you all the way there.

That's a great one to end on. Thanks, Jon. That was fantastic. I really appreciate it.