Takeaways from Mission-Ready AI: Delivering Decision Advantage in Contested Environments
The models work. That turns out to be the easy part.
Fielding artificial intelligence in the Pacific means fielding it where the link drops without warning, where the grid was never built for the load, and where the site you’re standing on still runs on copper. Earlier this month at Joint Base Pearl Harbor-Hickam, SOSi, AFCEA Hawaii, and Google Public Sector put that problem in front of the people who live with it—DISA Pacific, PACAF, PACOM, Pacific Fleet, and Marine Forces Pacific—and spent the day working through what it will actually take.
Col. Michael “Toby” Hlad, USMC, commander of Defense Information Systems Agency Pacific, set the terms in his opening keynote. The scale and geometry of the theater mean commanders can no longer step outside and see the fight. “You decide through the network, or you don’t decide at all,” he said. “The network isn’t a support function. It’s the primary warfighting platform.”
Enterprise AI and mission AI are different engineering problems
Hlad drew a distinction worth holding onto. Enterprise AI is already fielded and in daily use across the force. It drafts a memo, summarizes a read-ahead, and speeds up staff work. It is genuinely useful, but it is not the same thing as “Mission AI”.
Mission AI runs at the point of need, on infrastructure the force owns, at machine tempo, while actively under attack. Its requirements carry a bill of materials, and most of it isn’t software. As Hlad put it, the Pacific must be an AI-enabled theater, not just an AI-enabled headquarters.
Hlad issued three requirements to industry: survive disconnection, put the stack forward, and secure it while making it coalition-ready at machine speed. He was specific about what the stack means—power, transport, compute, and data, all of which must be positioned forward, and all of which will be targeted. He was equally specific that none of it works on disorganized data. You cannot operationalize chaotic data at the tactical edge. Every session that followed was built to answer one of those requirements.
The failure mode is architectural
The clearest illustration came from a technical session led by SOSi’s Josh Bearden and Kelly Jones of Google Public Sector, which was built around a deliberately unglamorous scenario: a notional Category 4 hurricane crossing the island chain, with landfall in hours rather than days. Reach back degraded. Satellite capacity consumed by life-saving traffic and family communications. The nearest data center 2,500 miles away—and in the storm’s path.
Before the storm, the AI tools worked fine.
“The storm did not defeat the AI,” Bearden said. “The architecture did.”
The answer Bearden and Jones walked through is distillation. Frontier models are generalists trained on effectively everything, and they need racks of GPUs, power, cooling, and data-center-grade infrastructure to run. But you rarely need a generalist at the edge. You need a specialist—in the hurricane scenario, something closer to a meteorologist in a box.
The pattern is a teacher and a student. Train at the core where the compute and data live. Have the teacher model work through scenarios with the student and show its reasoning, not just its answers, so judgment transfers rather than output. Keep the student’s scope narrow. Compress it. What comes out is small enough to run on a device under a folding table at an emergency operations center, on generator power—or in some cases on a phone.
“You don’t deploy the schoolhouse,” Bearden said. “You deploy the graduate.”
Two things about this deserve emphasis. First, the human stays in the loop by design—scorecards, people checking output, judgment applied to consequential results. Second, the economics invert. You cannot build 100 data centers or afford 100 cloud connections for every place AI is needed. But you can copy one stack to 100 sites.
The part nobody demos
Sitting alongside the architecture conversation was a less comfortable one about what’s actually installed across the theater.
Many Pacific sites still run on aging infrastructure and copper transport. It is one thing to talk about cutting-edge capability in the hands of the warfighter; it is another to acknowledge the constraints on conducting day-to-day business at those same locations. The problem compounds with coalition partners who don’t yet have the basics in place—and partners are the theater’s strategic center of gravity, not an afterthought.
Power belongs in the same category, and it may be the hardest of the three. Pacific grids were not built for AI workloads, and inference and training at scale will outrun generation capacity at island sites long before the models become the limiting factor. New fixed generation is a multi-year proposition, and a fixed plant is a coordinate the adversary already has. Which points toward the same answer the compute conversation reached: generation that arrives in weeks rather than years, connects without a land acquisition and permitting cycle, and moves when the mission moves.
None of this is a reason to slow down. It is a reason to engineer for what’s there. But not every tool is viable for every mission. A bandwidth-hungry interface or a compute-hungry model may be entirely appropriate ashore and entirely unusable on a ship, which is where a significant amount of warfighting in this theater will happen. Fielding real capability means designing for a spread of deployment options—from data centers to containerized and palletized stacks down to individual devices—with redundancy and the ability to scale up or down by use case.
Capability nobody knows how to use isn’t capability
The other recurring constraint was people.
Panelists from both government and industry kept returning to training and adoption. A significant investment in technology can produce only marginal improvement across the user population if the people expected to use it were never properly introduced to it. Several government participants asked industry directly for help educating personnel at the operating bases, not just at the headquarters. They said the gap between what a combatant command understands and what an airman at a main operating base has been given to work with was substantial.
Both sides left with homework
The asks from government were specific and consistent: open APIs and open user interfaces, an end to proprietary data silos, government data that stays government data rather than getting locked inside a vendor’s application, and products taken out of the lab and out to the forward edge to be iterated on with warfighters rather than pitched years after development.
Industry’s asks ran back the other way: earlier access to units and exercises, clearer prioritization of gaps, and risk acceptance that lets accreditation move closer to the speed of software.
The warfighter panel described its own approach as failing forward fast—build it, test it, find where it breaks, fix it, and do it again, deliberately, as a method rather than an accident. SOSi CTO Kyle Fox, who moderated that panel, compressed the day’s through-line into five words: “fail forward, but go together.”
That framing is the reason we hosted this. Mission engineering isn’t something industry does to a customer. Scoping the need, mapping the dependencies, and building for the environment that exists requires both sides in the room, early, with the constraints on the table. “Siloed solutions,” as Hlad put it, “are dead on arrival in the Pacific”.
We look forward to continuing this conversation at TechNet Indo-Pacific this fall.
