← Results
AI adoption succeeds when agencies start with real workflows and measurable outcomes—not platforms, pilots or rhetoric
Editor’s note: A different version of this article ran in Real Clear Defense.
There is a moment in almost every AI adoption effort where the room gives itself away.
A leader asks, “What platform should we buy?” Someone answers with a vendor name. Another person says, “We need an enterprise foundation.” A slide appears with the phrase AI Transformation. Heads nod, people relax, and a contract strategy starts to form.
Near the end of the meeting, someone asks the question that should have been first: “What problems are we actually trying to solve?” By then, the decision energy has moved and the capability is already being acquired. The use cases will be figured out later, often without the input of the end-user.
This is not a villainous plot. It is a reflex, the capabilities-first acquisition reflex.
It is the single biggest obstacle to AI adoption in defense, and why top-down urgency doesn’t reliably translate into bottom-up adoption. Secretary Hegseth recently told the Department of War to become AI-first, push capabilities into operators’ hands in days, and measure success by usage and mission impact. It’s a demand signal that raises the pressure, but it doesn’t remove the capabilities-first reflex that turns pressure into misguided procurement.
The capabilities-first reflex follows a five-act structure. If you’ve worked in defense, you’ve seen it.
A big purchase becomes a visible signal that leadership is “doing AI.” It’s tangible, briefs well, and it’s comforting because it lets everyone postpone specificity: defining actual use cases means naming owners, admitting constraints, and agreeing to success metrics. That’s harder than buying a tool.
A portfolio of pilots are chosen for novelty and demo value, not for workflow volume or user desirability. Progress is defined by the number of pilots launched, because that is easy to count, safe to defend, and hard to argue with in a meeting.
Meanwhile, the people doing the work lack solutions. A targeting cell still builds packages by hand because data is split across systems; a maintenance unit fights the same scheduling conflicts because the parts data is stale and the technical manual is a decades-old PDF; and an intelligence analyst still spends two hours cleaning a spreadsheet before they can write a paragraph policymakers will trust.
These are the kind of problems that pilots tend to avoid because they’re not glamorous and require touching real processes and engaging real end-users.
Stakeholders tend to confuse governance with progress. Security reviews, data access constraints, debates about authorities, and training requirements multiply. Each one is reasonable in isolation, but collectively they strangle speed and the organization gets very good at building an approval machine, not an acceleration engine.
The mistake isn’t governance itself. It’s treating governance as proof of adoption – and protecting it because it’s the only thing one can point to.
Users are told to adopt a tool, but their incentives have not changed. They are rewarded for compliance and throughput, not experimentation. A tool that adds friction to their usual processes, even temporarily, is a threat.
Picture an analyst with a stack of requests, a review chain, and a boss who wants the product by the end of the day. A new AI tool promises to help, but requires that they log into a separate environment, tag inputs themselves, format outputs, and provide feedback to improve the model. The future value may be real, but at that moment, it costs time and increases risk – potentially in a very visible way. The analyst uses the tool once or twice, and then reverts to the old way. It’s slower, but it’s trusted and safe.
Finally, adoption stalls. The diagnosis is culture or data readiness, and the remedy is a larger program or a new office. Before long the pattern repeats itself.
The Advanced Battle Management System (ABMS) is the U.S. Air Force’s flagship contribution to Joint All-Domain Command and Control (JADC2). It’s intended to connect sensors, data, and shooters through cloud-based networking and AI, and it was initially showcased through rapid demonstration events.
ABMS is a useful case study not because it was misguided, but because it displayed the capabilities-first acquisition reflex at scale.
ABMS produced experiments, demonstrations, integration work, and genuine learning. But it also revealed the core weakness of capabilities-first thinking: a demonstration can prove connectivity; it cannot prove adoption.
Eventually the hard questions surfaced. What operational workflow changes? Do users really want it? Does it reduce cycle time, error, or manpower hours? Will people keep using it without a champion forcing the issue?
These aren’t innovation questions. They’re adoption questions. Knowing the answers is the difference between a capability that exists and a capability that matters. Programs that think through these points early have a chance; those that postpone them tend to become expensive stories of past pilots.
All transformation efforts have versions of these traps. AI amplifies them.
AI Transformation is a perfectly elastic phrase. It can mean anything, so it commits people to nothing. It enables abstract conversations that never touch the work, and allows leadership to substitute ambition for precision.
That is why many AI efforts drift into the same dead-end: broad access to tools with no discipline around the workflows those tools should change. Then the blame moves to the workforce. They are resistant, do not trust it, and need training.
Sometimes that’s true. But often the workforce is making a rational calculation that changing behavior is costly and the benefit has not been proven.
None of this requires a breakthrough model. It requires changing what we fund, measure, and reward.
Enterprise platforms are often justified with future value. Once everyone is on it, use cases will be discovered. That’s backwards. It quietly treats the platform as though it was the mission.
Platforms should earn their footprint, expanding only when specific workflows are defined, validated, and shown to improve measurable outcomes. Without validated use cases, an organization gets capability in search of a problem, followed by a year of narrative construction to defend sunk costs.
Many defense portfolios are just a list of pilots that aren’t instrumented the same way, can’t be compared, and never graduate to scale.
A real portfolio has investment logic. For example, a small number of thesis areas tied to mission threads (e.g., maintenance readiness, intel production, targeting support, contracting cycle time); risk tiers that separate low-risk workflow automation versus higher-risk decision support; and a standard lifecycle with time boxes, metrics, and kill criteria. Each use case should fit on one page with a hypothesis, expected value, dependencies, and what would kill it. Then run stage gates and a monthly review that is willing to stop efforts that are failing or not ready for more time, energy, and resources.
A healthy portfolio kills more ideas than it scales. That’s not failure. On the contrary, dragging unworthy pilots forward is.
A tool is delivered when the contract line item closes. A tool is adopted when people reorganize work around it and complain loudly if it disappears.
That distinction is where programs go to die quietly.
We need to measure adoption like we mean it. For example, weekly active users in the target role (not total accounts; most of which are inactive); task completion rate (how often it’s actually used for the job); cycle time reduction for the workflow step that matters; rework and error rates; and the drop-back rate (how often users revert to the old method).
If you don’t have adoption metrics, you don’t have capability.
People aren’t irrationally resistant to AI. They’re rationally responsive to incentives: compliance, risk avoidance, and not wanting to own a “failure” that becomes a briefing slide.
We should align incentives to outcomes, and reward leaders for measurable workflow impact (cycle time, error reduction, hours returned), not for pilot counts or training completions. We also should protect controlled experimentation from career penalties, including experimenting with incentives themselves, and making it safer to kill bad ideas than to keep them alive for optics.
If you reward perfect paperwork, you’ll get perfect paperwork. If you reward changed behavior, outcomes, and actual problem-solving, you’ll get adoption.
Defense loves big platforms because they feel orderly: one contract, one dashboard, one sponsor. It makes sense, but adoption rarely scales through one big thing. It scales through small tools embedded in real workflows (triage, routing, reconciliation, summarization, drafting, matching, alerting).
These are boring on purpose. Boring is what people use every day. For example, auto-compare records across systems so analysts stop cleaning data by hand; prioritize queues and route cases with rationale and auditability; and flag anomalies or missing steps before they become rework.
These aren’t AI “moonshots.” They’re friction removal, and that’s the point.
The rule is simple: the tool should fit the routine. It won’t be adopted if it requires users to jump platforms, change formats, or learn a new taxonomy before it pays off.
If you want to demonstrate that your organization can beat the capabilities-first reflex, do not start by writing a new AI strategy. Start by changing one workflow.
Pick something high-volume and unloved.
Start with work that is already rule-bound and repeatable like triaging tickets, reconciling records across systems, drafting routine products, scheduling, or turning recurring briefs into standardized outputs. Avoid anything that requires policy rewrites, new authorities, or a debate about the meaning of AI before you can touch the workflow.
Then get specific. Sit with people who do the work. Watch their workflow and handoffs. Count the rework, trace the data, and define success as a measurable delta (something you can defend without adjectives).
Build the smallest useful tool that moves the metric, put it in the hands of real users, and then measure, iterate, and scale only after it earns the right.
Then repeat. Relentlessly.
This approach is not glamorous, but it’s the only one that compounds. Each successful workflow change builds trust. Trust reduces resistance, and reduced resistance accelerates the next use case. Momentum quickly replaces rhetoric.
Institutional reflexes defend themselves. You will hear familiar objections: “We need an enterprise foundation first,” and “We can’t deploy until governance is complete,” and “We don’t have perfect data.”
Some of these concerns are real. None of them justify postponing the only thing that matters: rapidly proving value in actual workflows.
