In Part 1, I argued that the architecture we built for the last decade of AI, centralized compute, GPUs, and CNNs processing everything at full power, was never designed for the physical world. The physical world is sparse, event-driven, and unforgiving of wasted energy.
The natural question is: what does the right architecture actually look like when it ships as a product?
At Sensors Converge, I got that answer. Not from slides or theoretical discussions, but from production deployments. Real constraints, real outcomes, real commercial stakes. All pointing to the same conclusion: the sensor edge demands architectures that conventional GPU and CNN approaches cannot serve.
Something else struck me. A year ago, the conversations at events like this were still theoretical. This year, they were real. Applications showcased real-world use cases. More deployed products were on the show floor, not just demos. The shift from “can we do this?” to “here is what we have built” happened faster than most people expected. The market is not waiting, and this is exactly where the next wave of value is getting created.
The architecture that matches the physical world.
The last decade of AI ran on a clear formula. More parameters, more compute, more accuracy. GPUs made that formula work. CNNs and ANNs became the default architecture for almost everything. The results were extraordinary in the domains they were designed for.
Sensor data is not one of those domains.
In Part 1, I covered why CNNs are the wrong fit for sensor signals. The short version: they were built for images, not for the one-dimensional time series and spatiotemporal signals that real-world sensors produce. That mismatch does not get solved by scaling. It gets solved by rethinking the architecture entirely.
The second problem is power and latency. GPUs and CNNs process everything at full power regardless of whether anything meaningful is happening. This impacts latency, too. For a sensor node that must run for years on a battery and respond in milliseconds when something changes, that is not a tradeoff. It is a disqualification.
Neuromorphic architectures solve both problems. They are event-driven by design, consuming energy proportional to the information content of the signal rather than proportional to time. When the environment is silent, they are silent. When something meaningful happens, they respond immediately. At Innatera, we built Pulsar the world’s first neuromorphic microcontroller, and it is already in production, designed from the ground up for the physics of the sensor world. That is not a roadmap claim. It is a shipping product.
What this looks like in production.
The panel discussion and the demonstrations at Sensors Converge spanned industrial, medtech, consumer, wearables and drone applications. What connected all of them was not model sophistication. It was the same discipline applied consistently: define the constraint first, then design the intelligence around it.
At Innatera, we showcased three applications on Pulsar. A radar-based presence detection system delivering privacy-first, ultra-low power human presence monitoring with no camera and no microphone. A baby cry monitor built with our partner Joya Design, an end product that detects and classifies why a baby is crying, running entirely on the device. And audio scene classification use case enabling hearing aids and hearables to understand and adapt to the ambient environment automatically, without user intervention.
On the panel, I described two further applications. The first builds on the same Pulsar and radar-based human detection technology we showcased. Fall detection for elderly care. The place you need it most is the bathroom: cameras cannot go there, and wearables come off before a shower. Radar detects a fall without capturing any identifiable data. Privacy is not a feature. It is the architecture. The second was material classification on a robotic finger and hand (sensor fusion of a multimodal sensor). A deployment previously running an 80-million-parameter model on GPUs now achieves equivalent accuracy on Pulsar in the kiloparameter range at sub-milliwatt power levels. The result is immediate, reflex-based action on the robotic arm without a cloud round-trip. That is not an incremental improvement. It is a different order of magnitude across power, size, cost, and latency at the same time.
The other panellists brought equally specific examples. Syntiant Corp. demonstrated smart glasses isolating voice through skull vibration sensing rather than microphones, with no cloud dependency. EMASS described a multimodal factory health monitor running local inference across IMU, barometric, temperature, and acoustic sensors, and an always-on drone inference system that improved flight efficiency. Himax Technologies, Inc. talked about an endoscopic capsule on a 3mm by 5mm chip capturing eight hours of internal patient data, and a wildlife monitoring camera running for ten years on a single battery. BrainChip described smart glasses for epilepsy patients predicting seizures before they occur, and on-device last-layer customization enabling deployed models to improve in the field without retraining.
Every one of these products exists because the team started with the constraint, not the model.
Developers: start with the constraint, not the model.
Most developers start with a model. Find a benchmark, hit an accuracy target, then figure out deployment. That sequence is backwards for embodied systems and it is why so many edge AI projects stall between prototype and product.
The use cases worth building for share at least one of these properties. The decision must happen with the speed of a reflex, faster than any cloud round trip allows. The device runs on a battery for years, or powers a more hungry processor that must stay in deep sleep until something meaningful wakes it. The raw data is continuous, too noisy, too sensitive, or too large to transmit, and the system must capture, understand, and act reliably with no connectivity. Or there is clear economic value in detecting an event earlier or automating a response faster.
If none of those are true, you probably need a better cloud pipeline, not edge intelligence.
If any of them are true, follow this sequence. Start with the constraint. Then go deep on the sensor signal that lives within it. Understand its statistical nature, when events occur, and what they look like. Design or select an architecture that matches that structure natively. Then train. The model that emerges will be smaller, faster, and more accurate in deployment than anything arrived at by compressing a large pretrained network downward.
That last point is worth mentioning. Even when developers identify the right constraint, the next instinct is to take a pretrained model and compress it. Quantize it, prune it, distill it, and hope it fits. Compression reduces size. It does not fix the fundamental mismatch between a frame-based model and a time series signal, or between a model trained to process everything and a deployment where almost nothing is happening most of the time.
The material classification example I described on the panel makes this concrete. From 80 million parameters on GPUs to kiloparameter range on Pulsar with equivalent accuracy. That result was not achieved by compression. It was achieved by starting from the right constraint, understanding the signal, and selecting the right architecture for the problem.
Constraint first. Sensor signal second. Architecture third. Model last. The companies that follow that sequence are shipping. The rest are still benchmarking or, even worse, not able to conceptualize a product.
This shift from brute force to elegant architecture is where the next decade of value is built. In Part 3 and final part I will make the investor case for where that value accrues and what to look for in the companies building it.
