Your AI Agent Program Is a System of Systems — And the Navy Has Been Solving This Since 1994

The U.S. Navy has been solving the AI agent coordination problem since 1994. The framework is called MOSA: Modular Open Systems Approach. It was formalized across defense acquisitions to handle exactly the problem AI teams are rediscovering this quarter: how do you coordinate independent systems — each with its own state, its own update cycle, its own failure modes — into a single mission capability.

A widely-circulated NAVAIR post on system-of-systems engineering this month defined it cleanly. A system of systems is an engineering approach where independent systems operate together as a single mission capability. MOSA is DoD's framework for making that approach actually work — interface contracts between subsystems, independent upgrade paths, mission-level reliability, verifiable interfaces.

The same week, Herdr crossed 8,100 GitHub stars and 57 Hacker News points by giving developers exactly what MOSA gives defense programs: a way to run multiple independent agent processes side-by-side with visible state. And Codex Issue #2847 — the August 2025 request for a way to exclude sensitive files from agent scope — hit 87 comments and is still unresolved, because no agent has a defined interface contract for what it cannot read.

The pattern is the same in every domain. The AI agent industry is reinventing system-of-systems engineering without knowing the vocabulary exists.

The number that matters

The number is 32 years. MOSA's foundational documents trace back to 1994. The AI agent era is 24 months old. We are solving a coordination problem the defense community has been running in production for three decades.

When a TPM in 2026 sits down to figure out how to let Claude Code, Codex, and an internal agent work on the same codebase without stepping on each other, they are doing mini system-of-systems engineering. The vocabulary is missing. The framework is not.

The framework

The defense acquisition community did not invent MOSA for fun. They invented it because the alternative was systems that could not be upgraded, could not be tested, and could not be trusted. The AI agent era is about to learn the same lessons, faster and with less margin for error.

Four patterns from MOSA translate directly to multi-agent AI programs.

1. Interface contracts are the first deliverable, not the last. MOSA starts every program by specifying the interfaces between subsystems before any subsystem is built. The interface is a contract: what inputs does this subsystem accept, what outputs does it produce, what is the failure mode when the contract is violated. AI agent programs usually do the opposite — build the agent, then discover the interfaces when something breaks. Move the interface definition to the program definition. You will save the postmortem.

2. Independent upgrade paths are non-negotiable. MOSA requires that any subsystem can be replaced or upgraded without taking down the mission capability. The AI agent equivalent: any agent in your multi-agent program should be swappable without rewiring the rest of the chain. If you cannot swap Claude Code for the next model release without a six-week integration project, your program is not modular. It is monolithically dependent on a vendor's release cadence.

3. Single points of failure get named, then mitigated. A MOSA review walks through the system architecture and explicitly identifies every subsystem whose failure takes down the mission. The AI agent equivalent: which agent in your program is the linchpin? When that agent is unavailable, what happens? TPMs running multi-agent programs who cannot answer this question in 30 seconds have a system-of-systems problem they have not acknowledged yet.

4. Independent verifiability beats joint test events. MOSA requires that each subsystem be testable on its own, with documented test procedures and pass criteria. The joint test is the last step, not the first. AI agent programs that only validate the whole chain end-to-end are running joint test events as their primary QA. Move the verification upstream. Each agent should have a stand-alone test that proves it works in isolation before it touches the others.

What this does not solve

Three honest caveats.

MOSA is a vocabulary, not a solution. Adopting the framework does not eliminate the coordination work. It makes the coordination work visible and structured. TPMs who adopt MOSA-style interface contracts still have to negotiate those contracts with engineering, security, and the domain owners. The framework gives you a place to have the conversation; it does not have the conversation for you.

The defense context is not the AI agent context. MOSA was built for hardware systems with multi-decade lifecycles, formal acquisition gates, and regulatory scrutiny. AI agents have weekly release cycles, no acquisition gate, and most programs do not yet have a compliance review. Borrowing the vocabulary is high-leverage; copying the process wholesale will slow you down. Take the structural patterns, leave the bureaucratic ones.

You cannot MOSA your way out of a single-vendor strategy. If your entire AI agent program runs on one vendor's platform, you do not have a system-of-systems problem. You have a vendor relationship problem. The framework applies when you have heterogeneous subsystems that need to interoperate. Single-vendor programs should be evaluated on vendor durability directly, not on system-of-systems metrics.

The signal that matters most

The signal is the gap between the maturity of the framework and the immaturity of the adoption. The defense acquisition community spent 32 years building and refining MOSA because the coordination problem does not go away when you ignore it — it goes away when you solve it. The AI agent era is at the "ignore it" stage, where every team is reinventing coordination primitives in isolation.

TPMs who bring MOSA's vocabulary to the conversation skip a decade of rediscovering what the Navy already knows. The next time you sit down to plan a multi-agent program, start with the interface contract. Name the single points of failure. Document the upgrade paths. Verify each agent in isolation. The pattern is older than the problem, and it still works.

If you are running a multi-agent AI program in 2026, the audit is the work to schedule this week, not the work to schedule after the first incident. Run the interface contract review. Identify the single points of failure. Map the upgrade paths. And write the verification procedures before you need them.

---

*Send me your current multi-agent interface map (anonymized is fine, even a one-page sketch). I am collecting working interface maps into a public TPM coordination playbook for AI agents. Five interface maps from production multi-agent programs would let me ship it next month. DM me on LinkedIn (Doron Katz).*