Complexity masquerades as flexibility— but it often creates the very fragility it claims to prevent.
No one likes high fragmentation and complexity. Many small vendors lead to inefficient purchasing decisions, and someone needs to train you on all these new machines and vendors. You could start releasing design documents on usage patterns. Or perhaps there is a quasi standard or best-practice — a lot of guns look and handle the same; your software applications and websites have similar usage patterns.
I bristle when I hear of overlays or aggregation. I totally get the desire for automation in a growing complexity of defense, resilience, and battlefield tech — state your objective and rules of engagements (ROEs) and let the AIs take care of it. That’s actually a really hard problem, for a couple of reasons. And few think through second- and third-order effects of such layers.
Venture capital and government innovation units should fund substrate-deep, interoperable-at-the-hardware-level, resilience-first defense systems—not coordination middleware that degrades under pressure.
The Fragility of Precision
Here is what we lose when we optimize the wrong things: Layers create attention, they reduce effectiveness, they create attack surfaces, they struggle with AI, they reduce accountability and conviction, they increase complexity, and they break under field constraints.
Layers create attention.
Adversaries might find that compromising the AI guidance system of three to four 155 howitzers is not really worth the trouble of spending the compute and manpower on. But a consolidated platform, and the potential of disabling 80% of all howitzers if the overlay is compromised, might suddenly draw attention.
Layers reduce efectiveness
Abstraction layers might increases efficiency, but they also regress performance to the mean. In theory, individual systems can have special strengths or advantages in corner cases, and should hence advertise such capabilities and be able to use those. I often find it more ingenious to advertise a system’s capabilities and let well-trained warfighters decide how to use that system creatively for maximum effect under given circumstances. I’m sure neither command nor vendor thought of the many ingenious and creative solutions I’ve seen in the field. Noone could have foreseen these scenarios.
Layers create attack surface.
Someone has to write specifications of these layers, and someone will have to document them. Vendors have to talk to each other. Operatives have to give feedback on interactions with other systems and thus disclose their existence, vendors, configurations. Any additional communications protocol will increase an attack surface. And not all overlay systems and their comms get selected by the best solution, but perhaps by money available, cost of system, existing relationships, time-to-integration, or some swing state vendor in an election year.
Layers Struggle with AI.
AI regress to the mean. More training model data will make AI predictable. Larger models and more participants and more systems will discover lots of new use cases and approaches, very creatively, but ironically most AI models regress to the mean by design: fall back and use what works.
More worrisome is the fact that LLM-based AIs have model drift. Good prompt design is really hard, and unless you know the prompt, you can create unwanted side effects and LLMs starting to lie to you or simply ignore instructions if they do not let them achieve their goal. the overlay AI or system might also be unaware of manipulations or errors the underlying AIs are prone to.
Adversaries might be able to inject data, or let sensors “see” data that are crafted to distort models, as I wrote earlier in Cognitive Breach: Defense of Cognitive Infrastructure.
Layers reduce accountability and conviction.
When second- or third-order side effects cannot be seen, and operators are removed from underlying decisions and hardship (who diverted the surveillance drones? why is there no air support? we are blind, who moved that satellite?) they make decisions without accountability — how could they be accountable for the AI or Layer or underlying system diverting resources?! As always, that will slow down learning, it will slow down feedback loops, it will slow down operational improvement and innovation. We all know that when we try to figure out why we got charged extra on our phone bills, or how to get the referral to the right doctor, or somehow your account got locked out… “the system won’t let me” or “I just follow our policies” is often the answer.
What’s even worse, layers usually decrease conviction. In Writing The Check Isn’t Just An Act Of Confidence — It’s A Signal Of Ethical Clarity I wrote about the difference between beliefs and conviction. Ironically, one would believe that simplification or summary of a complex scenario increases conviction – after all, you have the “real gist of things” now, right? But when you dive into behavioral economics and psychology, the risk of losing touch with ground facts and narratives around those facts actually reduce the internalization of truth. When lives are on the line, or when you’re defending your country, this one is probably the worst. It will destroy people and divide a country.
“How fast do you think you were going?!” — “Officer, I believe I was going the speed limit.” yes. but did you actually act on that believe?
Layers create complexity.
Once layers are in place, they have to be maintained. There will be code debt. But worse, it will become someone’s job. And that will create careers, org structures, budgets, divisions, offices, phone systems, … rigidity and complexity. We probably know a few divisions where we wonder how they got so big, and wonder even more about what they are actually doing with all that man power now that the world changed, and why that is even necessary….
Layers break under field constraints.
Field constraints like denied environments, degraded power, and zero-connectivity ops make APIs irrelevant in practice. And if you reduce “layers” back to “command and intent”, perhaps with some “Rules of Engagement”, then we’re back where we started. We have that already.
Resilient Substrate Design
resilient substrate design requires tight coupling of mission-critical code and hardware with local operability and survivability. Resilient systems must be substrate-integrated, locally operable, and low-dependence—not layered abstractions that invite brittleness and centralization. Examples would be drone units with embedded autonomy vs. cloud-coordinated swarms; or radiation-hardened chips with mission-specific firmware vs. general-purpose processors relying on runtime abstraction.
| Dimension | Overlay System | Integrated Substrate Systems |
|---|---|---|
| Survivability | Fragile in degraded or disconnected environments; layers fail independently | High survivability; minimal dependencies; can run in denied conditions |
| Agility (Real) | Apparent agility in peacetime; constrained by interlayer dependencies in war | Built-in agility at unit level; fewer moving parts, fewer coordination needs |
| System Complexity | Emergent complexity over time; high integration debt | Lower long-term complexity; testable, verifiable, maintainable |
| Security / Attack Surface | Expanded with each abstraction layer; often opaque | Tighter security boundary; fewer privileged components |
| Vendor Dependence | API transparency masks operational opacity; vendors dominate updates | Local control over design and lifecycle; easier to audit, modify, replace |
| Failure Modes | Cascading; often non-local and hard to diagnose | Contained and observable; easier to simulate and mitigate |
| Adaptability in Field | Requires central coordination or updates; brittle without backend | Field-updatable; mission-configurable without new dependencies |
Ironically, we have those guidelines already:
NATO Review – “Resilience: the First Line of Defence” (2019)
- CONTEXT: NATO’s Article 3 mandates that all members maintain and develop their individual and collective capacity to resist attack, including civil preparedness. Focus is on continuity of government and essential services, even under multi-domain hybrid threats (cyber, EMP, infrastructure attacks). The emphasis is not on “agile overlays” but on redundancy, local operability, and survivability of core systems.
- IMPLICATION: Civil preparedness must be built to operate autonomously under stress, not via abstracted dependencies that assume connectivity or centralized orchestration.
SOCOM / DoD Edge Compute Requirements
- CONTEXT: edge nodes (drones, comms, sensors, analytics) must operate without GPS, without connectivity, under intermittent power, with zero trust of cloud or central systems. The emphasis is on tightly-coupled, resilient compute with localized autonomy—not API-based overlays or coordination layers.
- IMPLICATIONS: Systems deployed in austere or denied environments must degrade gracefully and function independently, which is incompatible with complex software-defined overlays or orchestration middleware.
US Army Mission Command Doctrine
as described, for example, in FM 6-0 Commander and Staff Organization and Operations (2022) or the Military Review article on Commander’s Intent and Concept of Operations (2013)
- CONTEXT: “Mission command” is the Army’s philosophy of decentralized execution. it is based on trust, commander’s intent, and disciplined initiative. It requires that subordinate units are able to act independently without further direction or data calls. Excessive reliance on layered C2 systems is viewed as antithetical to mission command.
- IMPLICATIONS: The greater the dependency on software abstraction or central coordination, the less capable a unit is of acting on intent alone — violating the very basis of mission command.
Is there *any* positive takeaway?!
Yes. If you can attack one or more of the shortcoming above across infrastructure generations you’ll have a billion-dollar company. But aspiration and tech alone is not enough to do so. You have to be exceptionally different — some groundbreaking scientific discovery paired with exceptional productization and execution. And perhaps some luck with the macro environment ….