Part I of this series laid out the case for why the automotive industry’s data infrastructure has outpaced its intelligence infrastructure and introduced the Agentic Loop — Sonatus’s framework for closing that gap: Detect → Collect → Reason → Act → Learn. In Part II, we will get specific about what each stage actually does, and why the sequence matters as much as the individual phases.
DETECT
Detection is the entry point of the loop, and its quality determines the quality of everything downstream. Done poorly, it floods the system with noise. Done well, it acts as a precise filter — surfacing signals that matter while ignoring those that don’t.
Traditional detection in automotive systems tends to be rule-based: threshold crossings, fault code triggers, binary pass/fail conditions. These rules were written by engineers at a point in time, based on known failure modes. They are, by definition, retrospective — calibrated to catch problems already seen, in isolation from the broader system context in which they occur.
Detection in an agentic architecture is different. It operates probabilistically and contextually, drawing on patterns across multiple vehicle domains simultaneously — not just powertrain or thermal management or vehicle networking in isolation, but the intersections between them. A thermal event that coincides with a specific network traffic pattern during a particular driving scenario is a different signal than the same thermal event in isolation. Context changes meaning, and detection has to be context-aware to surface the right signal at the right moment.
Critically, detection runs continuously — not as a batch process at the end of a test day, but as a live layer embedded in the vehicle’s intelligence infrastructure. This is what makes the loop agentic rather than merely analytical.
COLLECT
Once something worth investigating has been detected, the collection stage determines what data gets captured — and just as importantly, what doesn’t.
The shift here is from always-on logging to event-triggered, targeted collection. Always-on logging generates significant volumes of data, the vast majority of which will never be analyzed. It is expensive to transmit over cellular networks, expensive to store, and expensive to work through. More importantly, bulk logs typically lack the context needed to make them actionable: without knowing what triggered a data capture, raw telemetry is difficult to interpret.
Event-driven collection inverts this relationship. When the detection layer identifies a signal worth investigating, the collection stage assembles a targeted capture: the right channels, the right time window, the right cross-domain context — captured precisely around the event of interest. Instead of gigabytes of continuous logs, an engineer receives the data that matters, richly annotated with the conditions under which the event occurred.
This is what eliminates the re-drive. The context that was previously lost — the window that closed before anyone configured the logger — is captured the first time, because the system was already watching for it. The prototype doesn’t need to go back out. The engineers have what they need.
REASON
Reasoning is the stage that most clearly separates an intelligence architecture from a data architecture. It is where the loop moves from “what happened” to “why.”
Vehicle systems are complex in ways that make manual root-cause analysis increasingly difficult. Cross-domain interactions — between powertrain, thermal management, ADAS, and vehicle networking — create failure modes that don’t surface cleanly in any single data stream. An experienced engineer might spend days correlating signals across CAN logs, Ethernet captures, sensor data, and system event traces to form a hypothesis about root cause. And that expertise is not easily transferred: it lives in individuals, accumulated through years of diagnostic work, and it becomes a retention risk the moment people consider other opportunities.
The reasoning stage in an agentic architecture applies AI-assisted analysis across exactly this kind of multi-source, cross-domain data. It doesn’t replace the engineer’s judgment — it compresses the time from data to hypothesis. It surfaces candidate root causes with supporting evidence, structured for an engineer to review, validate, and act on. The engineer remains in the loop; the loop simply runs faster and handles more complexity than any individual can manage manually.
There is also a knowledge preservation dimension to this that the industry tends to underestimate. When diagnostic expertise is encoded into the reasoning layer — when the accumulated pattern-recognition of expert engineers is captured in a system rather than residing only in their heads — it becomes a durable institutional asset. It doesn’t retire, it compounds.
ACT
The action stage is what makes the loop genuinely agentic rather than merely analytical. Without it, the Agentic Loop is a sophisticated reporting system. With it, intelligence becomes an outcome.
The spectrum of actions is deliberately broad. At one end: surfacing a structured finding to a validation engineer, with supporting evidence and a candidate root cause, through whatever tools they’re already using. At the other end: triggering an OTA configuration update to a specific fleet segment, or flagging a service recommendation for a vehicle at a specific dealer location. Between these extremes are a range of automated and semi-automated responses, calibrated to the confidence level of the reasoning, the stakes of the decision, and the organizational policies of the OEM.
The action layer is also where the loop produces its most visible business value. Findings that previously required days of manual analysis and a scheduled meeting to act on can surface and propagate in hours. Fleet quality interventions that previously required a warranty spike to trigger can occur before the first customer complaint arrives.
LEARN
The learning stage is what separates the Agentic Loop from every other approach that has been applied to vehicle intelligence — and it is the most strategically significant stage of all.
Every other stage of the loop is valuable in isolation. But without the learning stage, the loop is static: the quality of detection, collection, and reasoning on cycle 1,000 is no better than on cycle one. The learning stage closes the loop in the literal sense — outcomes feed back into the detection models and reasoning knowledge base, updating them based on what was confirmed, what was incorrect, and what new patterns emerged.
This means the system gets demonstrably better over time. Not incrementally better in a marginal way, but compoundingly better — because each cycle adds to the accumulated intelligence of the system, which improves the quality of every subsequent cycle. We’ll return to why this matters for OEM strategy, because we believe it is the most important implication of this architecture.
Why “Operating System” Is the Right Metaphor
Let’s be precise about the operating system metaphor, because it risks sounding like positioning language if it isn’t grounded correctly.
An operating system doesn’t perform the application’s function. It manages the underlying resources — compute, memory, I/O — so that applications can focus on what they’re built to do. It creates a stable, shared platform on which many different kinds of work can run efficiently.
The Agentic Loop plays the same role for vehicle intelligence. It manages the underlying complexity of vehicle data — detection, collection, reasoning, action, learning — so that the teams building on top of it can focus on their actual work: making engineering decisions, improving product quality, serving customers. It doesn’t replace any of those functions. It creates the conditions for each of them to operate with significantly higher velocity and quality than they could without it.
And like an operating system, it becomes more valuable the more functions run on top of it. A shared intelligence substrate across validation, quality, and service is worth more than the same capability deployed in silos — because the patterns learned in validation inform detection in the field, and the failure modes confirmed in the field feed back into validation baselines. The loop doesn’t just run within a function; it connects functions.
The Loop in Practice: Pre-SOP and Post-SOP
The architecture of the loop doesn’t change across the vehicle lifecycle. What changes is the data source and the nature of the action at the end.
Pre-SOP, in validation, the loop operates against prototype vehicles running structured and unstructured test scenarios. Detection identifies anomalies in real time during the test drive. Targeted collection captures the relevant context on the spot — before the vehicle returns to the garage and the window closes. Reasoning surfaces candidate root causes for the validation team the same day, sometimes faster. Action might mean an immediate test protocol adjustment, or a design finding routed to the engineering team responsible. Learning updates the detection and reasoning models for the next test cycle, so the system arrives at subsequent tests already knowing what to watch for.
Post-SOP, in the field, the same loop operates across a fleet of production vehicles at scale. Detection identifies emerging patterns — failure modes clustering by region, driving cycle, software version, or environmental conditions. Targeted collection confirms the signal with precise, reproducible evidence from the vehicles where it’s occurring. Reasoning diagnoses root cause at the fleet level. Action might mean an OTA update to a specific software configuration, a proactive service campaign before failures become visible to customers, or a quality alert to a component supplier. Learning incorporates the new failure mode into the detection baseline so the next platform starts with that knowledge already built in.
The architecture doesn’t change shape between a validation garage and a fleet of production vehicles, only the data source and the action at the end do. That consistency is more than a design detail, though. It’s the reason this type of system gets more valuable the longer it runs, which is the part of the argument that matters most for how OEMs should be thinking about this now.
