A machine learning project can fail in a predictable way.
The model performs well in testing. It performs well enough in staging. Then it moves into a real building, with real people, real cameras, real network drops and real hardware that gets bumped, unplugged or misconfigured.
When the system starts producing answers nobody can explain, the postmortem often lands on the model. The team retrains it, tunes it, swaps the architecture or brings in another researcher.
But the model may not be the problem. The surrounding system may not have been built to survive real-world conditions.
Aniruddha Maru has spent years working at that intersection. He is vice president of infrastructure at Standard AI, where he leads the team behind hybrid infrastructure supporting autonomous checkout and computer vision workloads inside retail stores.
His book, The Nervous System of AI: Event-Driven Architecture and the Engineering That Makes Real-World Machine Learning Work, argues that many AI failures are not model failures. They are systems failures.
Debugging the wrong layer
The book begins with a common pattern in AI development: teams treat the model as the product and the surrounding software as secondary plumbing.
That plumbing often gets built late, with less rigor than the model itself. Then the system meets reality. A camera goes offline. A service restarts mid-transaction. Two events arrive out of order. A network connection drops at the wrong moment.
None of those are machine learning problems. No amount of retraining fixes them. But each can produce a wrong answer that looks like a model failure.
Maru’s point is that the industry has built strong practices around model evaluation while paying less attention to the systems that carry a model’s inputs and outputs.
This matters most when AI moves beyond cloud environments and into physical operations. A store backroom does not behave like a data center. The network may be unreliable, the hardware may be constrained and the nearest engineer may be far away.
In that environment, weak architecture becomes visible quickly.
What event-driven design changes
Maru’s proposed answer is architectural.
The book focuses on event-driven design, where components react to things that have happened instead of waiting on each other through tightly linked requests.
That changes what failure looks like. A service interruption can become a backlog rather than a full outage. A spike in traffic can become a queue that drains rather than a cascade. Work that arrives faster than it can be handled can be absorbed instead of dropped.
In a retail AI system, that distinction matters. One unreliable service should not cause the entire checkout experience to lose trust in itself.
Maru is also clear about the trade-offs. Event-driven systems can be harder to reason about than simple request-response systems. Teams have to confront ordering, duplicate delivery and the question of what a system should believe when components disagree.
His argument is that those problems exist either way. Event-driven architecture makes them explicit rather than allowing them to appear later as unexplained failures.
Built from retail infrastructure
The book draws heavily from Maru’s work at Standard AI.
At the company, he worked on infrastructure for autonomous checkout and computer vision systems operating in distributed retail environments. That work required moving beyond demo conditions and building systems that could support stores where hardware, networks and physical layouts vary.
According to the book, Maru helped redesign infrastructure into independently deployable services, moved systems into the cloud and rebuilt deployment paths so engineers could test before shipping.
As Standard AI expanded into store backrooms and edge environments, Maru led work on infrastructure that supports distributed compute clusters across retail sites in multiple countries.
That experience shapes the book’s central argument: AI applications should be treated as disciplined software systems, not specialized black boxes.
Maru’s work also produced a patent covering systems and methods for self-service setup of monitoring operations in an area of real space. The patent addresses a practical problem that appears throughout the book: how to install and monitor AI systems in physical environments without requiring an expert on-site for every configuration.
The part teams often skip
A major portion of the book focuses on what happens after deployment.
Maru argues that a machine learning system without health metrics, observability, rollback paths and clear operating standards is not truly a production system. It is a prototype exposed to customers.
The book emphasizes practical engineering habits: standard interfaces, explicit application specifications, replaceable hardware and systems designed around the assumption that individual nodes will fail.
That perspective is especially relevant as companies move AI into stores, warehouses, clinics and factory floors. These are environments where conditions are messy and tolerance for errors can be low.
The models may be capable enough for many of these use cases. The harder question is whether the system around the model can handle uncertainty, recover from failure and explain what happened when something goes wrong.
A different way to think about AI failure
Maru’s book reframes AI reliability as an infrastructure problem as much as a modeling problem.
It does not argue that models are unimportant. Instead, it argues that model quality is only one part of production readiness. The surrounding architecture determines whether the model can operate safely and consistently outside a controlled environment.
For engineering leaders, that means some AI failures may require fewer retraining cycles and more attention to deployment, monitoring, event flow and system recovery.
The lesson is direct: real-world AI is not just built in notebooks. It is built in the systems that keep working when the network drops, hardware fails and the environment behaves unpredictably.
Click here to download our free news, weather and smart TV apps. And click here to stream Channel 9 Eyewitness News live.
©2026 Cox Media Group
