Talking to Ourselves
Why Tactical Networks Fail at the Edge
I’ve just returned from ten days immersed in a large-scale training exercise simulating combat against a peer adversary. The battlefield was packed with modern technology: drones buzzing overhead, electronic warfare jamming the spectrum, sensors collecting data everywhere. At first glance it looked like a vision of “future war.”
But underneath the surface, things felt old-fashioned. The information those sensors produced wasn’t automatically shared, processed, or actioned. Instead, it was passed around manually: voice over radios, hand-drawn grids on paper maps, even photos of screens.
The Army talks about “data-centric warfare,” “machine-speed kill webs,” and “AI-enabled decision advantage.” What I saw instead were networks that couldn’t reliably move information at the speed of relevance.
The communication barriers faced on the tactical edge fall into three categories: transport, security, and compatibility. Think of the network as a postal service:
· Transport is the trucks and roads that move the mail.
· Security is the envelopes and wax seals that protect messages.
· Compatibility is the shared alphabet that lets the recipient read it once it arrives.
This is a story about how those barriers play out at the company level, where I serve as a Commander leading about 130 Soldiers. My unit fights on the move with limited communications gear and very little bandwidth to “process” information. We are not a headquarters with staff officers and widescreen monitors showing the battlefield. Yet formations like mine represent the bulk of the Army’s fighting power. If our systems fail, we can’t feed information upward to shape the larger fight or pull intelligence down to influence our own.
Transport: Too Many Parts, Too Few Paths
At the edge, radios still rule. Voice is reliable and intuitive, but every piece of data must be turned into words, written down, and plotted by hand. If a platoon spots an enemy, they send me a grid coordinate over the radio. To act on it, I write down the numbers, pull out a map and protractor, and plot it. If it’s dark, I hunch under a poncho with a red-lens flashlight. That’s 20th-century soldiering on a 21st-century battlefield.
We have one digital helper: the End User Device (EUD), a Samsung Galaxy S20 running ATAK, a digital map. Although this works as a stand-alone device, it is most useful when networked- allowing me to see friendly locations, send messages, and even call in artillery or medical evacuation. In theory, it can be connected through our radios. In practice, this connection requires a nine-part kludge of radios, adaptors, cables, cases, and mounts — all strapped to a Soldier’s chest, dragged through mud and rain.
Do the math: if each part has a 90% chance of working, the whole stack only works 39% of the time. Across six key leaders in my company, the chance we all stay connected is 0.34% — about 1 in 300. Raise the reliability to 95% per part, and the odds of all six working is still just 6%.
The alternative? Commercial internet. We’ve been issued MiFi hotspots with funded cell plans. They work well when cell coverage exists, though they introduce detection risks and another battery to manage. The most obvious solution — putting a funded SIM directly in the phone — is prohibited by security rules.
Security: Bureaucratic Denial of Service
I’m not a cyber specialist. But I’ve seen how our security posture often shifts the burden downward by making systems clunkier for Soldiers without necessarily making them safer.
Take ATAK. It’s an open-source tool used by police departments, firefighters, and search-and-rescue groups worldwide. They can download plugins, integrate with Google Maps, and quickly add new devices to the network.
We cannot. While we use the same ATAK app as everyone else, the EUD, an outdated Samsung Galaxy S20, runs a fork of the Android Operating System called Nett Warrior. Stripped of features and blocked from the plugin ecosystem, updates trickle through a long approval process. Bluetooth is disabled. There’s no browser. Connecting to a TAK server requires a custom VPN.
This creates bizarre situations. Many radios and drone controllers ship with ATAK pre-installed — but since they aren’t running the Nett Warrior fork, they can’t connect. Instead of drones feeding their position automatically to the map, operators relay grids over voice. Though commercial solutions allow digital streaming of drone feeds to other networked devices, we’re limited to literally taking a photo of a drone controller’s screen and sending that “screenshot.” Demonstrations of advanced capabilities exist, but are largely staged — possible only in controlled settings with non-organic (borrowed) equipment and contractor support.
This is in part because network control sits not with uniformed signalers but with a single contractor at Division level. This individual supports not just my Company of 130 Soldiers, but over 50 Companies like it. We can’t update software, connect new devices, or troubleshoot beyond what that one person enables.
All of this ensures that our EUDs retain their “Authority To Operate”, a security seal of approval to operate on Department of War networks. However, this means less than you might think. Though maintaining an ATO is mandatory, it is more an exercise in bureaucratic, checklist-based compliance than real cybersecurity. The acting Chief Information Officer of the Department of War recently blasted the process as “archaic” and “stupid.”
Compatibility: Two COPs, Zero Shared Understanding
Even when transport works and security lets us connect, the systems don’t talk to one another.
TAK is the only tool available for Soldiers on the ground.
Maven (built by Palantir) is adopted at battalion and higher headquarters.
Wickr is a secure cloud-based messaging app used across devices by leaders.
That gives us three parallel “chat” channels: TAK, Wickr, and Maven. Worse, we now have two “common operating pictures”: TAK for the people fighting, Maven for the people directing.
The result is chaos. Thousands of Wickr messages fly, including grids, pictures of drone feeds, and status updates. Each has to be manually plotted into TAK. My radio telephone operator can’t help because he isn’t on Wickr. Important information gets buried. Bridges between systems exist, but they’re brittle, limited only to certain data types and channels, and are dependent on one civilian contractor for establishment and maintenance.
One bright spot? An AI agent in Maven that scraped chats for grid coordinates and automatically plotted them on Maven’s map. It showed the promise of near-term AI: turning unstructured text into structured, actionable information.
Prescription: Do Less
The Army doesn’t need more fragile, bespoke systems. It needs simpler, fewer, and cheaper ones.
If a system requires more than four parts to function in the field, kill it. Radio, battery, antenna, handmic — that’s about the limit.
If commercial tools work, use them. Harden where needed, but don’t reinvent. Don’t fork software.
Train signal Soldiers in modern cloud and cyber tools, then give them the permissions they need.
Stop claiming “mission accomplished” after performative demos that never survive rain, mud, and movement.
The war won’t wait for nine-part connectors, VPN handshakes, and redundant apps. If we don’t fix transport, security, and compatibility, we’ll all end up alone on the battlefield — talking to ourselves.
Postscript: A breath of optimism, and what does this all have to do with AI anyway?
In reading this post before publication, I’m realizing that it gives a largely negative view of the world. These problems are critical and deserve urgent attention and solutions. But they’re also symptomatic of growing pains. The Nett Warrior system I pan was a product of an archaic acquisition process that is being reformed. The DoW is rolling out new software approval pathways this fall. Many of the drones that I note are not connected to our system hadn’t even been procured a few months ago. Wickr and Maven were only recently adopted. This post is meant to provide a snapshot of the pain points on the frontlines, so that progress heads in the right direction — and happens quickly.
Also, if you came here for the AI, perhaps via a referral from
’s AI Blogging Fellows, I apologize for the lack of neural nets. Next week I hope to dive into where I see space for AI integration, but I chose to start with the communications problems that will hold AI implementation back. A Samsung Galaxy S20 cannot run AI workloads. Maven can, but it’s cloud-based and only works with a stable internet connection. And any serious AI for command and control or resource optimization will depend on massive amounts of timely and accurate data — data that today can’t move from the front lines to headquarters at anything close to machine speed or scale. Which is all to say: if you didn’t find the AI you were expecting… welcome to the battlefield.
Very neat to see how some of the frontline tech comes together.
Fascinating read.