Navigating Constraints In AI: Mubin Pagarkar

An automotive ECU may allocate under 1MB of RAM to security processing. Threat-detection windows can close in under 50 milliseconds. Cloud connectivity disappears without warning. And in a moving vehicle, a false positive is not merely inconvenient — it can compromise the operation of the system itself. These are the engineering realities that define connected-vehicle infrastructure.

Mubin Pagarkar spent two formative stretches of his career building products under exactly these conditions: first as Principal Product Manager at Symantec, working on connected-vehicle cybersecurity, and later at Amazon, helping architect voice and physical-access systems for automobiles. The engineering discipline forged in those constrained environments now shapes how he approaches AI system design at much larger scales.

At Symantec: Learning what the cloud can’t do

The connected-vehicle security work at Symantec centered on a difficult operational reality: vehicles cannot depend entirely on the cloud for protection. Connectivity is intermittent, attack surfaces evolve in real time, and many high-risk decisions must occur locally before a cloud response could ever arrive.

Pagarkar worked on localized AI-driven threat suppression systems designed to detect anomalous behavior directly within constrained vehicular environments. The work involved contextual data traces, on-device anomaly isolation, and lightweight inference models capable of functioning under severe hardware limitations.

“Actions that are time-sensitive or high-stakes need to be resolved locally,” Pagarkar explains. “You cannot assume the cloud will always arrive in time.”

The hardware restrictions forced architectural decisions that ultimately improved system reliability. Instead of building heavy centralized detection systems, he focused on lean edge-based intelligence capable of functioning independently during connectivity interruptions. This work later informed a U.S. Patent Application on  “Intrusion Detection for Connected Vehicles,” which outlines techniques for isolating malicious network anomalies locally without exhausting finite vehicle compute resources.

“The hardware constraints on automotive ECUs—under 1MB of RAM, sub-50ms detection windows, and no guaranteed cloud connectivity—meant we simply could not build the system we originally sketched out,” Pagarkar notes. “The limitation forced a cleaner separation of concerns than we would have built if we had unlimited resources.”

What began as embedded cybersecurity work ultimately taught Pagarkar something broader about engineering itself: systems designed under constraint often become more resilient than systems designed under abundance.

At Amazon, voice: When latency is the product

At Amazon, the constraint shifted from security to interaction latency. Voice interfaces inside moving vehicles introduced a different engineering challenge: a delay that feels negligible on a smartphone becomes dangerous when it competes for a driver’s attention. In this environment, latency itself becomes part of the product experience.

Pagarkar contributed to the product architecture of the open-source Alexa Auto SDK, helping shape the split between on-device inference for common interactions and cloud-based processing for more complex requests. Frequently used functions — climate adjustments, media control, navigation prompts, and recurring voice commands — were designed to resolve locally whenever possible. Cloud interactions remained available, but only when necessary.

“Building in-car experiences taught us that friction kills,” Pagarkar explains. “A voice interaction that resolves instantly disappears into the driving experience. One that pauses to think becomes a distraction.”

The architectural philosophy mirrored lessons learned at Symantec. Rather than depending entirely on centralized compute infrastructure, the system prioritized localized execution paths capable of operating seamlessly under real-world variability. OEM integrations across manufacturers, including GM, Ford, and Volvo, demonstrated how hybrid edge-cloud architectures could support consumer-scale deployment without sacrificing responsiveness.

“The common interactions needed to resolve on-device,” Pagarkar says. “The user should never feel the system thinking.”

At Amazon, physical access: When trust is the constraint

Amazon Key In-Car Delivery introduced an entirely different form of engineering constraint. The challenge was no longer memory allocation or inference latency — it was consumer trust. Convincing users to permit automated access to their vehicles required the operational system to establish psychological confidence before any technical sophistication mattered.

Pagarkar worked on product structures that enforced strict operational boundaries around the delivery experience. Vehicle eligibility verification, real-time notifications, constrained delivery windows, package weight limits, override capabilities, and integrations with OEM telematics systems all functioned as behavioral safeguards designed to maintain user control throughout the process.

“Trust was the product,” Pagarkar explains. “The technical workflow only mattered if the user continuously felt in control of what was happening.”

The engineering challenge, therefore, expanded beyond software performance into human behavior modeling. The system had to reduce uncertainty at every interaction point.

“The moment a user feels like they lost the thread of what the system is doing, trust collapses,” Pagarkar notes.

This experience reinforced a broader principle that would later influence Pagarkar’s approach to enterprise AI systems: the hardest constraints are not always computational. Sometimes the system architecture itself must absorb human psychology as a primary design input.

What constraint-driven engineering taught him

The years spent working inside connected-vehicle systems ultimately shaped a consistent engineering philosophy. Constraints, rather than limiting design quality, often clarify which functions genuinely matter. Hardware scarcity forces cleaner abstractions.

Latency sensitivity exposes unnecessary complexity. Connectivity instability demands graceful operational separation between local and centralized systems.

“Constraints are clarifying,” Pagarkar says. “They force you to identify what absolutely must happen versus what is simply nice to have.”

The disciplines required inside embedded environments — strict separation of concerns, resilient hybrid architectures, local-first operational logic, and ruthless prioritization of essential functionality — later proved applicable far beyond connected vehicles.

“The limitation forced a cleaner separation of concerns than we would have built otherwise,” he reflects.

Those principles now inform how Pagarkar approaches large-scale AI deployment more broadly: systems become deployable not when they maximize capability, but when they minimize fragility.

Why this work matters now

As AI systems increasingly move into safety-critical physical environments — autonomous logistics, robotics, industrial control systems, and connected infrastructure — the engineering lessons forged inside vehicular platforms are becoming more broadly relevant. These environments cannot tolerate architectures that assume unlimited compute, perfect connectivity, or unrestricted user attention.

Pagarkar’s connected-vehicle cybersecurity patent remains a tangible artifact of that engineering philosophy: systems designed to operate locally, respond quickly, and remain resilient under severe operational constraints.

“Engineering under constraint forces you to build systems that survive contact with reality,” Pagarkar concludes. “And increasingly, that’s what modern AI systems are being asked to do.”