Mission-Critical
The Mission-Critical Stack

Public safety software runs to five nines because the alternative could mean life or death. When a 911 call drops, the cost is not measured in churn or downtime. It is measured in seconds that matter. That single reality reshapes every engineering decision, every deploy, and every escalation path. It is also the exact discipline autonomous transport, clinical AI, and the next generation of healthcare platforms must clear before they earn the right to operate at scale.
I spent much of my career building the systems that dispatchers, first responders, and clinicians rely on when the margin for error is zero. The lessons from that world are not just relevant to autonomy. They are the prerequisites. Every argument about whether a robotaxi is "ready" or an AI scribe can be "trusted" traces back to a small set of engineering values that mission-critical SaaS has been quietly enforcing for two decades.
Failure is a product feature
Consumer software degrades gracefully. Mission-critical software fails loudly, deterministically, and with a plan. The system tells the operator exactly what broke, hands the work to a redundant path, and preserves an audit trail that a regulator can read at 3am. Autonomous systems need the same posture. A robotaxi that quietly misinterprets a lane is more dangerous than one that pulls over and escalates. A clinical agent that hallucinates a dose is more dangerous than one that says "I do not know, page the pharmacist."
The five properties that separate mission-critical from everything else
- Deterministic failover. Every dependency has a documented backup path. When primary fails, secondary is already warm, already receiving traffic, and already keeping state. This is table stakes for 911. It is aspirational for most AI.
- Observable at every layer. Not just logs and metrics, cause-and-effect telemetry that lets you replay any incident. In an autonomous system this means sensor state, model inputs, model outputs, and the decision that came out the other side, all reconstructable after the fact.
- Kill-switches by design. Every autonomous action has a documented way to stop it, whether for a single vehicle, a whole fleet, a specific patient, a specific model version. If a kill-switch was not designed in, it does not exist.
- Change control that assumes hostility. Every deployment is reversible in minutes. Every model swap is a traffic-shift, not a cutover. Every config change is auditable. Mission-critical teams do not ship on Fridays for a reason.
- Escalation to a human that actually works. The hand-off path is rehearsed, staffed, and instrumented. The human who receives the escalation has the context to act on it, not just a red icon and a shrug.
What public safety taught me about clinical AI
In dispatch, we learned early that a slow answer is often worse than no answer. A caller in crisis needs a response inside a few seconds or the system has already failed. Clinical AI has an analogous constraint that most teams underestimate: a suggestion that arrives after the clinician has moved on is not a suggestion, it is noise. Latency budgets are not a performance-engineering nicety; they are a safety property.
What public safety taught me about autonomous transport
The 911 network is a lesson in graceful geographic degradation. When a tower goes down, calls reroute. When a PSAP is overwhelmed, overflow rules kick in. When an entire region loses power, mutual aid takes over. Robotaxi fleets need the same doctrine. Every vehicle needs to know what to do when it loses connectivity, when the remote operator is unreachable, and when the map it was expecting no longer matches the road. That is not a nice-to-have. It is the license to operate.
Where spec-driven development changes the math
The reason mission-critical systems used to be so expensive is that every property above had to be built by hand, on top of the implementation, after the fact. Spec-driven development inverts that. When the behavior spec is the source of truth and the evaluation harness is written before the code, failover paths, kill-switches, and escalation contracts move upstream where they belong. AI-native teams can now build mission-critical software at the speed consumer teams used to build features, if they choose to.
The uncomfortable truth for AI startups
Most AI companies are shipping consumer-grade software into mission-critical contexts. Not because they are careless, but because their engineering culture has never operated inside those constraints. The teams that will win the autonomy decade are the ones that adopt public-safety discipline before they need it, not after their first incident makes the news.
The through-line
Autonomy is a promise to take an action on someone's behalf. That promise is only worth what the underlying system will do on the worst day it ever has. The mission-critical stack is not a constraint on autonomy. It is what makes autonomy trustworthy enough to matter.
Continue reading
- Healthcare's Biggest Problem Isn't AI. It's That Hospitals Don't Have an Operating System.
- Agentic AI: The Future of Healthcare Isn't Smarter Software—It's Smarter Workflows
- Is AI Influencing Private Equity's Next Pivot?
- The Age of Autonomy
- Spec-Driven Development
- Evals Are the New Unit Tests
- Buy, Build, or Orchestrate
- Autonomous Transport for Rural Health