Rivian’s chief software officer, Wassym Bensaid, is making a bet that the next era of cars won’t be defined by screens, apps, or even the familiar physical controls drivers have relied on for decades. In a wide-ranging conversation, Bensaid argued that the “software” in a modern vehicle is already everywhere—driving, energy management, cabin comfort, navigation—and that the real opportunity is to centralize that software into an operating system and architecture that can evolve quickly. In that world, he says, voice becomes the primary interface, and features like Apple CarPlay (and the traditional button-first approach to infotainment) become less necessary.
The context matters. Bensaid isn’t only speaking as Rivian’s software leader. He’s also co-CEO of RV Tech, the platform joint venture between Rivian and Volkswagen Group Technologies. That partnership began about a year and a half ago with nearly $6 billion from Volkswagen, and it effectively places Bensaid in charge of the underlying operating system and electrical architecture that future Volkswagen Group EVs will build on. The first vehicle based on this new architecture is expected to be Rivian’s more affordable R2, while the longer-term goal is to scale the same core technology across a much wider portfolio—from premium brands like Audi to mass-market models.
But the most provocative part of Bensaid’s message isn’t about compute or architecture. It’s about interaction design: what drivers should do when they get into the car, how they should control it, and whether they should expect the same kind of phone-centric experience that CarPlay and Android Auto represent.
To understand why he thinks CarPlay is becoming obsolete, you have to follow his argument from the bottom up—starting with how cars are built today, and why that approach makes fast iteration difficult.
In the older automotive model, a vehicle is essentially an aggregation of many mechanical components and hundreds of electronic units, often developed by different suppliers. Each unit is designed to do one job. That supplier-based structure has historically worked because consumer expectations for end-to-end features weren’t as high. But Bensaid says the industry has crossed a threshold: electrification, connectivity, and autonomy have raised the bar for what drivers expect to happen seamlessly, quickly, and reliably.
He offered a concrete example: a personalized welcome sequence. Imagine walking up to a Rivian and using Apple digital key. The car recognizes you, runs a lighting sequence, and configures your profile—seats, steering wheel, infotainment, HVAC—within roughly 15 seconds. In the traditional supplier-coordination world, Bensaid claims, changing or extending that sequence requires coordination across more than 10 suppliers: seat, door, HVAC, infotainment, security, cloud services, and the digital key provider. Even small changes can trigger another long development cycle.
His point isn’t that legacy OEMs don’t understand the problem. It’s that the structure of the system makes it hard to move quickly. So the solution, in his view, is to treat the car as an integrated software system built around zonal computers—general-purpose, powerful compute placed centrally in the vehicle. The more software you can move onto those zonal computers, the more control you gain over end-to-end customer experiences.
This is where the “operating system” framing comes in. Bensaid describes RV Tech’s role as building the electrical architecture and the operating system layer that brands can use. Brands then express their identity through customization hooks—different UI choices, different behaviors, different “feel”—but the underlying platform remains shared. He characterizes RV Tech as doing roughly 80 to 90 percent of the hard work, leaving brands to tailor the experience rather than reinvent the foundation.
That foundation is also meant to reduce the number of computers in the car. Instead of many specialized ECUs, the architecture aims for fewer, more capable computers. The payoff is not just cost or packaging; it’s speed. If the car’s behavior is governed by software running on centralized compute, then updating features and improving integration becomes more feasible over time.
Bensaid also addressed a question that often comes up in these discussions: what about non-EV vehicles? Volkswagen makes gas cars and hybrids, and there’s a pendulum swing in the industry between electrics and ICE. RV Tech’s scope, for now, is powering electric vehicles. Bensaid said the agreement is focused on EVs, and he framed the partnership as a mission-driven effort to accelerate electrification globally. He acknowledged that the technology could theoretically be used beyond pure EVs, but emphasized that the joint venture’s priority is electric platforms.
From architecture to interaction: why voice is central
Once you accept the premise that the car is increasingly controlled by software, the next question becomes: how should drivers interact with that software?
Bensaid’s answer is blunt. He believes voice should be the primary interface in the car. Buttons can exist, he says, but they shouldn’t be the primary way people interact with the vehicle. His reasoning is tied to driving reality: drivers are focused on the road, and the interface should minimize distraction and menu navigation.
He also argues that voice hasn’t fully taken over because the technology wasn’t good enough. In his view, foundational models change the equation by enabling a more conversational experience. Instead of issuing rigid commands like “open the frunk,” drivers can speak naturally—“open the front trunk”—or even describe intent in a way that the system can interpret. He described a scenario where saying something like “I have a bag in front of the car” triggers the frunk opening, implying a shift from command-and-control to intent-based interaction.
This is where his earlier “buttons are an anomaly” stance returns. In the conversation, he reiterated that he still believes voice has the chance to be the primary interface, even if tactile controls remain useful for certain functions. He also pointed to a compromise approach for HVAC: with the R2, Rivian plans tactile feedback for HVAC via hardware elements like haptic controls rather than relying on a traditional center-stack button layout.
The deeper claim isn’t simply “voice is better.” It’s that voice becomes more powerful when the assistant is integrated into the vehicle’s operating system rather than bolted on top of a screen.
Rivian Assistant: not a chatbot overlay
Bensaid’s description of Rivian Assistant is one of the most important parts of the discussion, because it explains why he thinks CarPlay is less relevant. He doesn’t portray Rivian Assistant as a generic chatbot layered onto infotainment. Instead, he frames it as an intelligent agent with deep integration into the vehicle operating system—able to address multiple parts of the car and perform actions across vehicle functions.
In practice, that means the assistant can do things like change drive modes or adjust ride height. Bensaid highlighted an example where the assistant can raise and lower the car at highway speeds using air suspension, but refuses to control the wiper. That contrast illustrates the system’s boundaries: some actions are allowed, others are blocked.
Why block certain requests? Bensaid said safety-related functions are regulated and homologated, so the assistant framework blocks them for safety reasons. He also mentioned reliability guardrails: even if an LLM might be able to interpret a request, the system may not expose certain functions if the reliability level isn’t sufficient for end-user control.
This is also where the conversation gets interesting for anyone who has tried voice assistants in cars. Bensaid acknowledged that assistants can refuse requests in ways that feel opaque to users. In his own example, the assistant refused to reveal which sensor it was trying to access regarding rear-seat occupancy. Bensaid called that behavior a bug and said it should have been able to provide the information, promising an OTA fix.
That exchange points to a broader theme: the assistant’s “permissions” aren’t just about whether it understands language. They’re about whether the system’s orchestration layer allows the assistant to invoke specific capabilities safely and reliably.
And that orchestration layer is exactly what Bensaid says other approaches struggle to replicate. If the assistant is deeply integrated with the vehicle’s operating system, it can coordinate actions across the car in a way that a phone projection or a screen-based app ecosystem can’t.
So where does CarPlay fit?
CarPlay is, in many ways, the opposite philosophy. It’s a standardized way to project a phone’s apps into the car’s infotainment system. For years, it has been the answer to a simple consumer complaint: automakers can’t possibly support every app people want, so let the phone handle it.
Bensaid doesn’t deny the appeal. He acknowledges that early on, CarPlay was a major request from customers. But he claims the demand has dropped dramatically. According to his account, more than 70 percent of customers requested CarPlay around the time Rivian first shipped the R1T and R1S. In a more recent survey, he says that number is below 25 percent.
He attributes the decline to Rivian’s end-to-end integration and convenience features. As the car’s own software becomes more capable—knowing about drive mode, efficiency, and other contextual details—CarPlay becomes less of a necessity. In his view, the built-in experience is no longer just a screen with apps; it’s a system that can coordinate vehicle behavior with user intent.
Then he adds the AI argument. With AI-defined cars, he says, the CarPlay debate becomes obsolete because the way people interact with apps will change. Instead of tapping icons for individual apps, an agentic integration can present a unified experience. The assistant can interpret intent and execute multi-step tasks across systems.
This is where his “agentic” explanation matters. Bensaid describes agentic integration as context-sharing and multi-integration execution, not just calling a single API endpoint. He gave an example involving Google Calendar: the assistant can read a calendar, add or remove events, and plan trips with constraints like charging stops and preferences for food. The assistant can then print summaries, add items to the calendar