The AI Antagonist

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. A contract strategy starts to form. 

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. The timing matters. 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, not PowerPoint. That kind of demand signal 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 have worked in defense, you have seen it. 

Act II: Pilots as progress. A portfolio of pilots emerges. Many are chosen for novelty and briefability, not for workflow volume. 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. 

Act III: Governance as gravity. Security reviews, data access constraints, debates about authorities, and training requirements multiply. Each is individually reasonable; collectively, they strangle speed. What began as Move Fast becomes Wait for Approval. 

Act IV: Incentives as sabotage. Users are told to adopt, 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 treated as a threat. 

Act V: Disillusionment and escalation. Adoption stalls. The diagnosis becomes culture or data readiness. The remedy becomes a larger program, a new office, and another platform. Before long the pattern repeats itself.

ABMS (the Advanced Battle Management System) is the U.S. Air Force’s flagship contribution to Joint All-Domain Command and Control, intended to connect sensors, data, and shooters through cloud-based networking and AI – and it was initially showcased through rapid demonstration events. It's a useful case study not because it was misguided, but because it displayed the capabilities-first acquisition reflex at scale. ABMS produced motion: 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? Does it reduce cycle time, error, or manpower hours? Will people keep using it without a champion forcing the issue? 

Knowing the answers to these questions is the difference between a capability that exists and a capability that matters. AI programs that think through these points early have a chance. AI programs that postpone them tend to become expensive stories of past pilots.

These kinds of challenges exist in all transformation efforts, but they’re more pronounced with AI. That’s because AI is gasoline on the capabilities-first reflex. AI Transformation is a perfectly elastic phrase. It is easier to describe than operationalize. It can mean anything and therefore commits you to nothing. It enables abstract conversations that never touch the work. It allows leadership to substitute ambition for precision. 

That is why so 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; they do not trust it; and they need training. 

Sometimes they do. But often the workforce is making a rational calculation: changing behavior is costly, and the benefit has not been proven.

None of this requires a breakthrough model. It requires changing what we fund, what we measure, and what we reward.

First, require use cases before expanding platforms. Enterprise platforms are often justified with future value: once everyone is on it, we’ll find the use cases. 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. Expand without validated use cases and you get a capability in search of a problem, followed by a year of narrative construction to defend sunk costs.

Second, build a use case portfolio, not a pilot petting zoo. The former has discipline. The latter has vibes. Many defense portfolios are just lists of pilots that aren’t instrumented the same way, can’t be compared, and never graduate to scale. A portfolio has investment logic: (1) a small number of thesis areas tied to mission threads (e.g., maintenance readiness, intel production, targeting support, contracting cycle time); (2) risk tiers (low-risk workflow automation versus higher-risk decision support); and (3) a standard lifecycle with time boxes, metrics, and kill criteria. Each use case should fit on one page: hypothesis, expected value, dependencies, and what would kill it. Then run stage gates and a monthly review that is willing to say stop.

Third, define adoption as behavior change, not delivery. 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. So measure adoption like you mean it: weekly active users in the target role (not total accounts); 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 a capability. You have a demo with a help desk.

Fourth, bake incentives into the process. If the safest career move is to avoid being the first, you will not get adoption. People aren’t irrationally resistant to AI. They’re rationally responsive to incentives: compliance, risk avoidance, and not owning a failure that becomes a briefing slide. Align incentives to outcomes. Reward leaders for measurable workflow impact (cycle time, error reduction, hours returned), not for pilot counts or training completions. Protect controlled experimentation from career penalties, including experimentation with incentives themselves. Make it safer to kill bad ideas than to keep them alive for optics. Reward perfect paperwork and you’ll get perfect paperwork. Reward changed outcomes and you’ll get adoption.

Fifth, win with small tools, not big platforms. Defense loves big platforms because they feel orderly: one contract, one dashboard, one sponsor. 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. Auto-compare records across systems so analysts stop cleaning data by hand. Prioritize queues and route cases with rationale and auditability. Flag anomalies or missing steps before they become rework. The rule is simple: the tool must fit the routine. If it requires users to jump platforms, change formats, or learn a new taxonomy before it pays off, it won’t be adopted.

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: 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. Focus on the kind of work people complain about but assume will never change. Map it, identify the friction, and define success as a measurable delta. Build the smallest useful tool that moves the metric, deploy it to 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. Reduced resistance accelerates the next use case. Momentum replaces rhetoric. 

The capabilities-first reflex thrives on abstraction. Your counter is specificity.

Institutional reflexes defend themselves. You will hear familiar objections: We need an enterprise foundation first; we can’t deploy until governance is complete; we don’t have perfect data; we need to train everyone before we start.

Some of these concerns are real. None of them justify postponing the only thing that matters: proving value in actual workflows. 

You do not earn permission to move fast by waiting. You earn it by demonstrating controlled success and building the evidence that reduces risk. It requires discipline and leadership willing to trade a little short-term comfort for long-term operational leverage.

Brian Miller is President at BMNT, leading federal acquisition and go-to-market strategy across business development, product, and government affairs. He is a former national security advisor and professional staff member for the Senate Select Committee on Intelligence.