Today, I’m talking with Wassym Bensaid, the chief software officer at Rivian, and the co-CEO of Rivian’s platform joint venture with Volkswagen, which everyone just calls RV Tech.
That joint venture kicked off about a year and a half ago with a nearly $6 billion investment from Volkswagen. It effectively puts Wassym in charge of the operating system and electrical architecture for every future EV from Volkswagen and its associated brands, including familiar names like Audi, but also new companies like Scout.
There’s a lot of Decoder ideas in there — I really wanted to know how that joint venture works and how it’s structured to preserve Rivian’s unique software culture, which you’ll hear Wassym talk about as the core element of the whole thing. I also wanted to know where the lines were — what parts of Rivian’s software get to be just for Rivian, and which parts of the core technology would be shared across the smaller company and the behemoth that is Volkswagen Group. And, of course, I wanted to understand how Wassym navigated the tension between the two. You know, classic Decoder bait.
Verge subscribers, don’t forget you get exclusive access to ad-free Decoder wherever you get your podcasts. Head here. Not a subscriber? You can sign up here.
It’s also a big moment for Rivian in general right now. The company is gearing up to deliver the more affordable Rivian R2, which is the first vehicle based on this new architecture, and the company also just shipped the AI-powered Rivian Assistant in its R1 vehicles. You’ll hear Wassym talk about Assistant as the beginning of a big bet for Rivian, as it tries to create a more agentic software platform in its cars.
I actually got to spend some time with the Rivian Assistant in an R1S ahead of my conversation with Wassym, and I found it to be a fascinating experience — certainly powerful and engaging while at the same time frustrating in a lot of really interesting ways. So I had a lot of feature requests, bug reports, and questions about the future of AI and voice assistants in cars.
Today, I’m talking with Wassym Bensaid, the chief software officer at Rivian, and the co-CEO of Rivian’s platform joint venture with Volkswagen, which everyone just calls RV Tech.
That joint venture kicked off about a year and a half ago with a nearly $6 billion investment from Volkswagen. It effectively puts Wassym in charge of the operating system and electrical architecture for every future EV from Volkswagen and its associated brands, including familiar names like Audi, but also new companies like Scout.
There’s a lot of Decoder ideas in there — I really wanted to know how that joint venture works and how it’s structured to preserve Rivian’s unique software culture, which you’ll hear Wassym talk about as the core element of the whole thing. I also wanted to know where the lines were — what parts of Rivian’s software get to be just for Rivian, and which parts of the core technology would be shared across the smaller company and the behemoth that is Volkswagen Group. And, of course, I wanted to understand how Wassym navigated the tension between the two. You know, classic Decoder bait.
So I asked Wassym about all of that, and also about his statements over the years that buttons in cars are just an anomaly and of course how he’s feeling about Apple CarPlay and Android Auto these days. You’ll hear it, but spoiler alert: Don’t get your hopes up.
This is a really fun episode of Decoder — we really get into the weeds on a lot of my favorite topics to talk about here on the show.
Okay: Wassym Bensaid, chief software officer of Rivian and co-CEO of RV Tech. Here we go.
Wassym Bensaid. You’re the chief software officer at Rivian. You’re also the co-CEO of a very important software joint venture between Rivian and Volkswagen, which is straightforwardly called Rivian and Volkswagen Group Technologies. Welcome to Decoder.
Thanks, Nilay. Super excited to be here.
I am very excited to talk to you. I have a lot to talk to you about. It occurred to me as we were doing the prep for this episode that you’re in charge of building a new kind of software for cars. But because of this joint venture that’s building a new kind of software company that’s building a new kind of software for cars, it is the most fractal Decoder I think we’ve ever had.
Awesome.
There’s a lot here. Let’s start with the organization. So, you’re the chief software officer at Rivian. I think a lot of people understand what that means. You’re the guy that they can yell at about CarPlay. Don’t worry, we’ll come to that.
There’s also the new Rivian Assistant, which is an intelligent agent inside the car that I’ve been playing with and I want to ask you a lot of questions about. Then, there’s RV Tech, which is the joint venture with Volkswagen. You’re building a new zonal architecture for a bunch of cars. I believe the R2 is the first car that’s going to run that new architecture.
Correct.
How does that all work? What are the lines between RV Tech, where you’re the co-CEO, and your role with Rivian, and what is the boundary between the software you build in the joint venture and the software you build at Rivian?
Before we dive into RV Tech and the joint venture, I think it’s really important to talk about the overall industry landscape. The automotive industry is going through a major disruption. The amount of software content in cars with technologies like electrification, connectivity, and autonomy is significantly increasing. That is creating a big divide between traditional OEMs and new tech-forward companies.
Consumers now have much higher expectations in terms of the overall experience and convenience. Multiple OEMs have tried really hard to get software content, but it’s not easy. It requires a very different type of talent. In some cases, it requires complete cultural change because you’re not only developing software. You also need to adopt different methodologies and ways of doing things. You need to be much more agile. When you look at the industry, companies tried to do that in-house. Some of them tried to partner. Some of them tried to use Tier-1 suppliers.
A lot of recipes did not really work, and that was the genesis of the great partnership we have now with the Volkswagen Group, which has really taken the Rivian technology stack — taken the software, the electrical architecture, as well as the Rivian DNA and culture — and married it with the Volkswagen Group’s incredible scale. It truly provides a fantastic opportunity for both companies because now we have a solution that can not only underpin Rivian vehicles — as you mentioned, the R2 is the first car the joint venture is shipping — but then also, in the future, every single electric model in the VW Group. This is from your premium cars like Audi, to luxury cars with Porsche, Bentley, and Lamborghini, all the way to mass market cars.
That suddenly provides an opportunity of scale. Also, it exercises the technology in very different ways, and it puts us in a wonderful position so that we can build an architecture and operating system for the entire industry.
That question about the architecture and operating system feels very complicated. As you said, the industry is moving to software-defined vehicles, which is a great buzzword. Every car executive I talk to clearly has a different definition of what “software-defined vehicle” means. What is your definition of “software-defined vehicle”?
First of all, I hate that buzzword.
[Laughs] You brought it up.
Actually, I can’t find a better name. So, I admit that I’m also using the same for a lack of a better definition.
But think about it this way. When you look at the older architecture in cars, it’s really an aggregation of multiple mechanical components. Underneath that, there are, in some cases, hundreds of electronic units, and each one of them is meant to do one thing. That’s actually mirroring the way those cars are built because they are developed using different Tier-1s and other suppliers.
In that world, integrating an end-to-end vehicle feature requires a ton of coordination between many of those suppliers. It requires very long development cycles. That approach kind of worked in the past when the expectations of consumers were not super high in terms of those end-to-end features. But I think with the advancement of EVs and with the types of user experiences that Tesla, Rivian,, and the Chinese cars are offering now, that’s no longer an option for any car manufacturer.
I’ll give you a small example. When you walk to Rivian — and I know you’re currently testing a [Rivian R1] Gen 2 Quad — let’s say you have your Apple digital key. You walk to the car and then the car recognizes you. Then, there’s a lighting sequence, and your entire profile is configured. Whether it’s the seats, the steering wheel, the infotainment system, the HVAC, everything is configured for you.
That sequence takes probably just 15 seconds, but doing that in the traditional world requires the coordination of more than 10 suppliers. You need to talk to the seat supplier. You need to talk to the door supplier. You need to talk to the HVAC supplier. You need to talk to the infotainment supplier. You need to talk to the security system. You need to talk to the cloud. You need to talk to the third party for the digital key. Just imagine that you want to slightly change that sequence for whatever reason. You have to go through another cycle of changes.
This is why that old model really doesn’t work anymore. Cars are now integrated systems with what we call “zonal computers.” We think about them as general-purpose, powerful compute that we place in the middle of the car, and they become the centralized brain of those different functions. The more software you can move on those zonals, the more it can provide control over those end-to-end features for the customers.
So, this is the pitch that every pure-play car startup has been making for a long time, right? The way that the OEMs built cars was done, and you shouldn’t have 1,200 ECUs from 1,200 different suppliers. That was fine for gas cars that were pretty dumb, where the only computer was like my old Pioneer head unit that had a fold-out screen. By the way, I love that head unit, if you could bring that back. I have fond teenage memories of my dumb old car with that head unit.
Now, the whole car is a computer, and you expect a lot of things to happen but that integration is too hard. What I would say broadly is that legacy OEMs have known this for years. They have been on their own journey to solve this problem, to cut down on the number of ECUs.
Ford CEO Jim Farley was on the show five years ago saying things like, “Too many ECUs; we’re going to cut it down.” Volkswagen, in particular, had its own giant project to do this that failed. I think there’s enough distance. You’re a year and a half into the new joint venture, and we can say Volkswagen’s CARIAD failed.
Why do you think the new joint venture and the infusion of Rivian culture is going to be successful when Volkswagen’s attempt to do it on its own did not net any positive results?
You’re getting me in trouble, Nilay.
That’s what I do.
What I personally appreciate about the Volkswagen Group’s decision is the recognition that developing what are called software-defined vehicles requires a complete, clean-sheet approach. You cannot approach it with Band-Aids and by having some level of software content in the car. As you said, the Volkswagen Group has tried. Actually, it has tried twice. But deep inside, there are two things that are really important here. One is that you need the right talent who are able to develop true software. Not abstracted functions like what the automotive industry is using — you have probably heard about AUTOSAR — but a true, hard-coded operating system.
Then, you also need a deep cultural change with a very different way of approaching the car and its overall development. The traditional model said that cars were defined many, many years in advance. People claim they know about software features four or five years in advance, and then it’s a very fixed waterfall approach. The way we design cars at Rivian is that we actually design the car around the electrical architecture, the software, and the adaptability of the software. So, software and technology have been at the table since very early on. It actually impacts the overall packaging of the car. We really use that platform and that operating system mindset so that we have a car that can evolve over time and get better and better for our customers.
Such changes are so deep that to do it well, you either need to have the right partner or you go with a clean-sheet approach. I think the Volkswagen Group has made the right decision to partner with Rivian in this case and to not only embrace the technology that we built from the ground up but to also embrace the culture, the approach, and the DNA of Rivian as a company.
How is the joint venture structured? I know you have a co-CEO, Carsten Helbing, who’s the Volkswagen CTO. So, you’re the two co-CEOs. How is it structured underneath that?
There’s a technical team underneath that: software engineering and electrical engineering. The technical team reports to me, and Carsten is my partner in crime. He takes care of the operations, and he’s also the main interface with the Volkswagen Group. There’s a ton of complexity in terms of managing different requirements and different inputs from the brands. He’s really doing all that arbitration so that we continue pushing towards a platform approach and reduce the overall complexity of the portfolio we’re supporting with the VW Group.
One of the questions I have here is that you describe it as an operating system. That seems like a good framework. People understand what operating systems are. I realize car operating systems are vastly more complex than people give them credit for, but it’s an operating system.
Then, there are the expressions of the operating system. I know that when our audience thinks of the software in the car, they think of the infotainment screen and that’s it. That’s just one expression, right? The user interface that Rivian is running… There are going to be other expressions for Volkswagen, for Scout, and I presume for Lamborghini. They’ll all be running the same core operating system expressed in different ways.
That is a real push-and-pull dynamic. Where do the features live? Who gets to build which feature? What are the core capabilities of the operating system and the platform versus what Lamborghini wants that it doesn’t want Rivian to have? How do you make those decisions?
First of all, I think it’s important to clarify the role of the joint venture. So, we’re responsible for the underlying electrical architecture and the operating system. When you look at a modern car today, pretty much every single interaction you have with the car is powered by software. You don’t realize it in a lot of cases. People tend to associate software with infotainment and with what they see on the UI and the screen, but there’s software everywhere in the car. I mean, there’s the way the car navigates, the way the car drives, the way the car saves energy, the way the car does cabin comfort. All of that is actually managed through software.
So, the way to think about this is that our role is to, first of all, build an electrical architecture with as few computers as possible in the car so that we simplify the overall packaging and the overall bill of materials. This is the brains of the system. On top of that, we develop software that the different brands can use so that they express their own identities. Think about it as us doing 80 to 90 percent of the hard work. Then, we provide customization hooks so that an Audi drives like an Audi and a Lamborghini has a different UI than a Rivian. But what’s happening under the hood, what’s happening behind the scenes, is based on the same platform.
When you think about that underlying electrical architecture and the zonal computers — you say we’re going to cut down the number of computers but have fewer and more powerful computers — one of the things that seems like an obvious opportunity for Rivian that might be way more complicated for Volkswagen is that you have a big battery that can just power those computers all the time. They can be online, they can be functional, they can be available. Volkswagen also makes gas cars and hybrids. There’s some pendulum swinging in the industry between electrics and gas vehicles, particularly here in the United States. Is that a challenge or are you just not thinking about their gas cars at all?
The joint venture’s scope, for the time being, is really about powering all the electric vehicles. This is the agreement we have with Volkswagen. One of the main reasons I joined Rivian is for the mission. I think the joint venture provides us with an extraordinary opportunity to accelerate electrification into many more cars around the world.
One of the first products that we’re building with Volkswagen Group is the ID.1, which is taking our technology to a mass-market vehicle. This is a car that will sell for less than $25,000, and it really opens the technology and that rich feature set to many more consumers around the world. Now, can the technology be used for non-EVs? Can it be used for hybrids or ICE vehicles? Obviously, the answer is yes, but for the time being, that is not the priority of the joint venture.
How big is RV Tech? How many people?
We’re about 1,500 people.
How is that split between Rivian folks and Volkswagen folks? Is it employees from both companies, or are they employees of RV Tech?
They are employees of RV Tech. Actually, we started with about 800 or 900 developers coming from Rivian, and then we had about 50 colleagues who joined us from the Volkswagen Group. The rest are developers and engineers that we’ve hired in the past 18 months. So, everybody’s RV Tech.
The reason I ask is that you mentioned at the very beginning that it’s an infusion of Rivian culture, but now they’re not Rivian employees. But at the same time, you are also the chief software officer of Rivian. How does that culture persist if the thing is its own entity, if it’s not as directly connected to Rivian, or if they’re not Rivian employees?
The way I define my job and my number one priority is to help the company grow and build on our two main assets, which are technology and our people and culture. With technology, I think we have a wonderful opportunity now to take that tech into many more cars across a wide range of the portfolio. Then there’s trends and culture. My daily obsession is to really make sure that we continue to have the same DNA: agility, being nimble, prioritizing action, quick decision-making, and iterating really fast so that we are at the forefront of innovation.
One of the other reasons I ask is that there are Rivian decisions that Volkswagen maybe won’t make. Rivian runs on Unreal Engine for the graphics in the infotainment. It’s really fun. I’m not sure that every single Volkswagen is going to run on Unreal Engine.
At least as I understand it, that’s a decision the different brands can make for themselves. But you’re the chief software officer at Rivian. You’re like, “We need better support for the Unreal Engine interface.” Maybe the platform doesn’t want that, and you wear that hat, too. How do you reconcile those tensions? Do Rivian’s needs always win?
What wins is how we can build the software in a way that allows for different expressions. I think in this case, Rivian’s interface will show up through Unreal Engine, but then we need to have hooks in our frameworks so that — and I know you will ask me this question — Volkswagen cars can have CarPlay. The team will develop that even though Rivian will not adopt CarPlay. It’s really about creating those different hooks in the operating system so that we allow for different ways to express the user interface.
This is so fascinating. Like I said, this is such a fractal episode of Decoder. It strikes me, just talking to you about this, that there aren’t a lot of models in an industry as big as the auto industry like this, where the big player is letting the smaller company define the culture, the opportunity, and the architecture, which will define its future roadmap. What examples have you looked at that are similar, where you can say, “That’s successful. We should build the model based on this and operate like this?” What versions of this have failed that you’ve looked at where you’re like, “I want to avoid those mistakes?”
I think there are many more failure stories than success stories when people look at joint ventures. This has been one of our guiding principles. We spent a lot of time discussing with VW leadership before we engaged in such a partnership. What made [Rivian CEO] RJ [Scaringe] and myself lean heavily into this partnership is, one, the opportunity and, two, the honest and constructive partnership from Volkswagen Group leadership.
First of all, we are talking about putting Rivian technology into the second-largest OEM in the world. This is, by far, the biggest licensing deal in the automotive industry. As RJ and I started the discussions with [VW CEO] Oliver Blume, his number one priority was that they needed to keep the Rivian way of doing things. We realized that we are not only bringing software IP and electronics IP but also a different process. We are bringing a different culture, and the VW Group needed that change from the inside.
Obviously, in some cases there has been daily tension. There are cases over the past 18 months where, as you mentioned, one brand might request a different requirement than another brand. But what really helped us to continue is that support from the highest levels of Volkswagen Group leadership to help drive that transformation and cultural change.
Let me ask you the other Decoder question, and then I want to turn to the software itself. I ask everybody this question. We’ve talked about it a little bit. How do you make decisions? What’s your framework for making decisions?
So obviously, my job every day is making decisions, but there are a number of guidelines that I try to apply. In terms of coaching with my team, I try to push decisions to the lowest levels of the organization as much as possible. One of the anti-patterns that I see with a bunch of companies is them trying to bubble up decisions with the highest levels of executives, and that tends to create a culture where things are slow and employees don’t feel really empowered.
Now, in cases where I personally have to make the decision, there are a few guidelines to the team: never come to me with one option, show that you went through an analysis, have multiple options, and then make a recommendation. I want a culture where I empower my team to have a forceful proposal and then come up with recommendations themselves.
The rule that I use to determine how much time I should spend on a decision is about whether it’s a one-way door decision or a two-way door decision. If it’s a two-way door decision, then I don’t need to spend that much time on it. It doesn’t really need a hard framework. We don’t need to go to extremes where we collect tons and tons of data so that we get to a decision. In some cases, I just use my gut. I’m a product builder at heart. I know that with some of the decisions, even if the data is against me, I should go with my feeling. In some cases I’m wrong, and I’m the first to recognize that.
Now, if it’s a one-way door decision, then that’s a different process that requires much more preparation and much more data, and then it requires arbitration for how we do things.
Give me an example in this context of a one-way door decision and a two-way door decision at RV Tech.
There’s multiple. I think one of them will probably lead to the next topic of discussion, which is our overall approach around AI. We had a ton of debates internally about whether we should just use a third-party AI solution or develop our own. There was a ton of tension because you look at the advancements in the AI world, and you would think that this is a hard problem to solve with everything that’s happening.
Now, it was really clear for me, given the opportunity and how transformative this is for the entire user experience, that we needed to own our destiny in terms of having a platform that allows us choice, that allows us to change foundation models as we wish and own the integration layer that allows us to power the entire car operating system.
So, this is Rivian Assistant. I’ve been playing with it for a few days now.
What do you think?
I had some searching conversations with it, just to push the boundary of what it can do. It’s super interesting to have a car where even within the interface, it does the wavy line on the main screen. It’s very much that the car is running this assistant, not an overlay. You can tell that the assistant can go and address lots of parts of the car, and then there are places where it can’t or it won’t.
Actually, I think one of the most interesting things about it is that it won’t tell you why it can’t do things. It is insistent that it won’t tell you why it can’t do things. Don’t worry, I have very specific questions. But it strikes me that this is a natural evolution of, “Okay, the whole car is run by a finite set of computers, and that means our assistant can just run around and talk to those computers and the functions that those computers control.” I have a Cadillac EV. If you try to glue an assistant onto that, it has to go talk to its CCUs. It’s just very obvious that something else is happening with Google Assistant in that car. That’s the opportunity. The assistant can talk to the whole car. Then there are places where it just can’t for some reason.
I’ll give you one example. It struck me as very odd. I was driving in the rain, and I said, “Hey, turn on the back window wiper,” and it just won’t. I thought, “Is that a safety reason? Is that because you don’t know how to do it? You’re lost in the zonal architecture?” I asked it, and it said, “I can’t tell you why I can’t do these things, but here’s where the button is,” which is really interesting for a car assistant to do. I’m not going to do it for you, but the button is on the stalk. Push the button. How do you make those decisions in the context of an assistant to figure out what it can and cannot do?
So, there’s a lot of things here. First of all, I think you described it really, really well. Our philosophy for the Rivian Assistant was to not just put in a chatbot and then slap it on top of the UI. It’s also about developing what will become the connective tissue that enables our users to interact with pretty much every single feature in the car and, even more than that, to bring their own personal digital ecosystem in the car through agentic integration.
Now, to your question about what it can do and cannot do, it’s obviously possible for us to control the wiper. I’m sure that you have seen that it can do way more. It can change your drive modes. It can change your ride height.
I could raise and lower the car at 55 miles per hour with the air suspension, which was cool and like the slowest low-rider experience you could possibly have, and then I couldn’t turn on the wiper. So, what is the split there?
Honestly, that’s one of my favorite features. The way I like to interact with it is that I don’t tell it to change the ride height. I tell it, “Okay, give me a drive mode with more pep,” and then it does it and changes to sport mode. I mean, this is really the magic of that true conversational experience.
Now, the reason it does not control the wiper is by design. We actually block a number of features that are safety-related. Cars are homologated and regulated. So, things related to wipers, windshield controls, highway assistance are regulated functions, which we block for safety reasons today through our framework. Safety is one of the core tenets in how we develop the entire experience.
The other one that struck me is that your cars have rear-seat sensors. We have kids, so every time I get out of my car, it reminds me there might be a kid in the back seat because it has sensed the weight. I think this is one of the funniest sensors any car can have because the car seat is always in the back seat. So, it’s always reminding me that the kid might be in the car.
So I asked, “Is anyone in the back seat?” Maybe this is just a bug, but it said, “I’ll find out,” and then it said, “I can’t access that sensor.” I said, “What sensor are you trying to access?” And it refused. I probably had a five-minute argument with your assistant about why it wouldn’t tell me what sensor it was trying to access.
The reason I’m asking this is not because it’s a bug or I really needed to know if anyone was in the car seat at the time. I’m just curious. You think about building the assistant that can access all of the sensors and the architecture and how that might work and how we might interact with cars. There’s a moment where you realize maybe it’s for safety reasons or maybe it just won’t work right now with the version you have because the LLM has to go talk to another computer and that computer has to give it permission. I don’t know if anyone in any part of the tech industry has figured out exactly how that should work, and I’m just wondering what your point of view is.
I think in this specific case, it should have actually told you what’s in the back seat. So, that’s a bug. That’s on me.
No, it was like, “I’m not telling you what sensor I’m trying to use.” I was like, “Why?” and it was like, “I’m not going to tell you what sensor I’m trying to get to.”
Yeah, that one is on me. I think the beauty here is that we have the team in-house. We’ll be able to calibrate that answer, and then we’ll fix it. Don’t worry. Nilay, I’ll send you an OTA next time when that’s fixed.
That’s very good. Every time we get a car executive on the show, I just complain about the experiences I have. It’s perfect.
But every assistant at every level is running into that specific barrier concerning how you talk to the computer and what permission does that other computer give you. Every assistant at every level is running into that specific barrier, and I’m just curious what you think the answer is.
Think about our architecture this way. The assistant has deep integration into the entire vehicle operating system. So, in theory, unless we have a bug like the one that you experienced, , you should be able to do everything with the integrations that we have built.
The only functions that are not allowed are functions that are safety-related, obviously because of the homologation reasons. But also there are functions where we are not comfortable with the level of reliability we can get from the LLMs to expose them to the end users. But that’s really the beauty of the internal, in-house orchestration layer that we have built where we have a ton of guardrails that allow us to control which functions are exposed by the assistant or not.
All right. You mentioned that I was going to get you in trouble. I’m going to get you in trouble again. In 2024, you said using buttons in a car is an anomaly of modern design. People love buttons in their cars, so you got in trouble for saying that, but the thing you said was that voice should be the future. This is the first gesture at voice being the future. Is it good enough? Because we’re right on the cusp of whether these things are actually good enough to build the kinds of products people want.
I think we are on the cusp of something really big. When you think about it, you’re in a car, you’re driving, you’re focused on the road. So, in theory, the primary interface with which you should be interacting with the car is actually voice. The only reason that drivers and consumers do not interact with the car through voice is that, to put it really bluntly, the technology has been broken. That’s really the beauty of what we have now with the technology disruption coming with foundational models.
The foundational models are providing us this wonderful opportunity to truly have a conversational experience where drivers can interact with the car in human language. I don’t need to tell the car, “Open the frunk.” I can say, “Open the front trunk.” Actually, I can say, “I have a bag in front of the car,” and it will actually open the frunk. I think that completely changes the way you interact with the car.
On top of that, we now have the opportunity with all the agentic framework to truly give people their time back in the car. I hope you tried our Google Calendar agentic integration. You can imagine how the experience will be in the future where you’re driving and can perform operations on your calendar. You should be able to perform operations on your email. In the future with the agent-to-agent integration, you can actually interact with many more apps from your own digital ecosystem.
Can I ask you about the word agentic in this context? To just describe it quickly for people, the way the Google Calendar integration works with Rivian Assistant is that it shows you a QR code. You connect your Google Calendar to it and then Rivian Assistant can read your calendar, add events, remove events, and do other calendar stuff.
I’m curious how that’s agentic and how it’s built such that the word agentic is meaningful because I’ve had like 500 apps over the past 10 years that can do Google Calendar stuff through the standard API. So, how is it agentic? Is it powered by [Anthropic’s] MCP? Is it something else? Why build it that way versus doing a bunch of API integrations?
I mean, you can build it with an API integration. I think the advantage of an agentic integration is that you can share the context, and then you can perform multiple integrations within the car. In this case, it is based on an MCP integration.
You can imagine that in the future, instead of having that mono access to every single app on your car — or honestly, even on your smartphone — you can start aggregating and connecting many of those apps through the agentic framework and have them present a unified user experience.
This is how we’re able to connect the navigation to Google Calendar, for example. I can go to the assistant now and say, “I want to plan a trip from San Francisco to San Diego, and I want to have two charging stops. I want them to be close to an Italian restaurant. I love Italian food.” The assistant would go and play that, and then I’ll say, “Okay, print the summary, add it to my calendar, and then send it as a text to my wife.”
When you have a behind-the-scenes agentic framework, this type of integration can really allow many more capabilities. This is where agentic can be utilized even further. You can start going into more autonomous functions. Let’s say you have an invitation in the calendar with XYZ details. You can start having reminders that say, “Do you want to go to this place?” “You’re actually really late to your meeting. Do you want me to start preconditioning your car?” So, that’s the beauty of bringing in the depth of that agentic integration.
I think I understand that. Rivian Assistant is in the car. It can access a bunch of apps and services you have. You can take actions across them. You’ve collected a lot of data in one place.
This brings me to a very deep existential question I have whenever anyone talks about ambient computing this way: Where does the logic live? The idea that you’re going to have that interaction in your car and not at your laptop or on your phone seems like a big jump to me. It was the same way when the smart speaker companies would be like, “You’re going to talk to your thermostat,” and would I think, “Why?” I’m going to talk to my phone. I don’t feel the need to talk to my thermostat in this way.
Do you think people are going to do that in the car, or are you going to bring your assistant to the Rivian app on a phone? Can you compete with Apple’s Siri and Google Assistant in that way? How is that all going to work?
Actually, the way I think about it is that it will be both. This is the big difference between the old world where we had unique applications and the new world where we have agentic integrations.
I think about Rivian Assistant as an agent orchestrator that has privileges because it can deeply integrate with the vehicle controls and the vehicle operating system. It understands safety. It understands which things to do and which things not to do. Nobody else can develop that better than us because we develop the entire vehicle software. But at the same time, it has interfaces and connections to other agents.
This is just the beginning. In the future, you can probably bring your own favorite assistant and chatbot to the car, and then it can share context with Rivian Assistant. I mean, these are the possibilities that this new world and this new type of integration are allowing us to do.
Is Rivian Assistant the kind of thing that is possible because of the RV Tech software stack? Is it possible that we’ll see Rivian Assistant or something just like it in Volkswagens as well, or is this special to Rivian?
This is special to Rivian. This is an AI stack that is developed uniquely for Rivian. This is Rivian’s brand priority as we see cars becoming more and more AI-defined. But we’re in discussions so that we can have similar technologies for the Volkswagen Group.
Rivian cars famously use LTE. When I first got in this car, I saw the LTE indicator, and I thought, “Oh, something must be wrong.” I drove around, and then I realized, “Oh, it’s just LTE.” Are there any latency concerns with that, especially with voice and going out in the world and doing whatever inference you need to do?
[Laughs] So, two things, Nilay. One, we need to get you an R2. The R2 has 5G.
There you go.
It’s coming soon, and it’s amazing. And two, I think you really touched on one of the architecture considerations for the technology, which is that when you look at vehicles like the Rivian R1 today, most of the interactions will happen with the cloud. So, as you say, it’s connectivity dependent. so they will work best when there’s strong connectivity with the external world. Now, there’s a number of interactions that happen locally with the car. If you tell the car, “I am cold,” that interaction is being managed by a small language model that sits directly on the edge.
The beauty of what will happen next as we get to the R2 is not only the 5G but also edge AI will be way more powerful and capable.
Just to be clear for the audience, when you say “edge,” you mean local, right? It’s running locally.
Yeah, local, meaning that the local computer on the R2 will have up to 200 sparse TOPS (trillions of operations per second) of compute dedicated to AI. I know this sounds extremely technical, but think about it as more capable than some of the self-driving platforms today. It’s more capable than the AI compute that you have in your smartphone.
All of that will be available locally in the R2 car, which is coming soon. That allows it, as you mentioned, to not face these connectivity limitations and issues and to get to much lower latency because a lot of the processing will happen directly on the embedded system so you can get a conversational experience that’s pretty much instantaneous.
Can I just ask you a very in-the-weeds question? We’re talking about putting compute in the car. We’re going to do some amount of local inference in the car. GPUs are expensive. RAM is expensive. How much of the bill of materials is RJ giving you to do all this in the car versus, I don’t know, bigger motors or bigger batteries? How much of the range can you pull off to do local inference in the car? This is the trade-off you’re talking about.
This is what I love about RJ. What has always attracted me to RJ is that he thinks about big things in the long-term. He knows, in this case, that the world is moving to AI. This is why decision-making from a bill-of-material standpoint is a very hard process with a ton of trade-offs all the time. You can imagine the tension between people wanting to push for a better exterior part, people wanting to push for a better interior part, and people wanting better technology. Then, we have what we call the”differentiation budget” in the car.
For RJ, there was absolutely no debate on whether we would equip the car with higher inference compute and more memory because this is really the future. It’s an opportunity for us to completely reshape the way people interact with their cars. To be honest, it solves itself in the long run from a unit economic standpoint because as we do more and more interactions locally in the car, we avoid the back and forth with the cloud. So, we avoid the connectivity costs, and then we also don’t have to pay for the cloud inference costs. So, in the long run, it’s actually economically positive.
That’s not just a spreadsheet you made up to win an argument that actually models out?
[Laughs] Kind of.
The reason I ask it is because my next question was about inference costs. They’re going up. There are rate limits with all the big providers. What model are you using right now? What are the frontier models you’re using right now?
The architecture that we have built is not actually model dependent. One of the architecture’s foundations allows us to interact and plug-and-play with different foundational models. Similarly, it can use different modalities in how users can input their requests, whether it’s voice or vision. It can use text if we want to enable that.
When it comes to the models themselves, we currently use a combination of internal models for everything that runs locally on the edge and models from Google. We have a partnership with Google. Things are going really well in terms of deep access to advanced Gemini models as well as the grounding of results also powered by Google.
This is another question I asked Rivian Assistant: what are the top five headlines on The Verge? I just wanted to see if this thing browses the web. It returned some results that I think are 24 or 48 hours old. These were the top five headlines from yesterday.
Does this thing have a web browser in the background, or is it just pulling from a Google data corpus? How does that work?
In theory, it should in theory connect in real-time. This is where the grounding with Google results comes into the picture. It should give you the latest headlines. So, if it didn’t, then that’s another one on me.
Well, I was just curious. Lots of people are having this experience now where the data in the model is old and there’s some cutoff, and I was just trying to find the cutoff. Then, I had a long searching conversation with it. We need to buy a new air conditioner, and I was just asking it to do math about air conditioner efficiency. It’s very boring, but this is what I talked to your car about for a while. It occurred to me that I was making it think very hard. I am wasting more energy asking how efficient an air conditioner I should buy. This is not a good ratio of energy spent to energy saved over there.
How does that work? You have to pay a monthly fee for the connectivity package to access Rivian Assistant, but then I might burn way more tokens than that fee could ever pay for. How does that math work out?
It really depends. In these cases, there are all sorts of what we call “rate-limiting” techniques that we can apply. If we have seen, like in your case, that you’re spending 20 hours discussing with the assistant, then we may do something behind the scenes.
It’s similar in the way we can configure the models. Given the types of interactions that you have in the car, you would not be interacting with the latest and greatest, say, Claude Opus 4.7 models so you’ll burn a lot of tokens. A lot of it also depends on aggregation across users in terms of the types of requests, as well as the arbitration we do between the edge and the cloud. As I mentioned, the more we move to edge and local compute, the better it is for us in terms of overall inference costs.
So, let me just ask you this question again. Now that you’ve shipped this software, people are using it. You’re getting extremely detailed feedback from me. Do you still think having buttons in the car is an anomaly?
I deeply believe that voice has the chance to be the primary interface in the car. I also think that buttons can exist, but they shouldn’t be the primary way with which you interact with the car. I think there’s more that is possible with voice since you can do more than one single function.
You don’t have to fiddle with so many functions. You don’t have to go deep into the touchscreen to look into specific features. A great voice experience can elevate all of that, allow users to talk to the car as a human would and really take the overall experience to the next level.
Are we going to get the HVAC buttons back in any future Rivians? That’s really what I’m asking here.
Actually, with the R2, we have a great way to add tactile feedback for HVAC.
Oh, the big paddles on the wheel?
Yeah. They’re really awesome.
That’s a good pivot, but I’m asking, are we going to get the fan speed button back in the center stack?
Not in the center stack, but we have the same thing on the Haptic Halo Wheels. It’s a great compromise.
You knew it was coming. I have to ask you about CarPlay here. It strikes me as you imagine this future where the car is connected to your calendar and it’s connected to all this context. It has autonomy, which is something you’re also working on. You get in the car, and it knows it’s time to go to work. You just say, “Let’s go,” and the car takes off driving.
This is when you would use a vast number of applications, right? This might be when you have to focus to push the buttons again. I’ll just make that argument. But this is when you would want a whole number of apps. I hear from our readers every time I talk to a car executive that, “The reason I want CarPlay is because there’s 5,000 apps on my phone and no car OEM is ever going to support them in the built-in infotainment.”
This is when you would say, “Okay, project your phone to the center stack. The car’s driving itself. Have at it. Phone projection all day.” Do you think the tide is turning, or are you still absolutely committed to not having CarPlay in Rivian vehicles?
First of all, it’s really important to go through the philosophy of how we see software in the car and the user interface. The challenge with screen mirroring solutions is that they take over every single pixel in the car, and that’s not the way we see ourselves interacting with our users. You drove our car four years ago, and you drove another car over the past few days. I hope you’ve seen how much has changed in the car. It’s truly been by bringing in end-to-end features, not only changing the user interface but having your navigation know exactly about your drive mode, know exactly about your efficiency.
Offering that level of convenience is what is really resonating with a lot of our customers. If I look at our own internal statistics from five years ago when we first shipped the R1T and the R1S, the number one request from customers was CarPlay. We did all sorts of surveys with customers at the time, and more than 70 percent of customers were requesting CarPlay. In the recent survey, that number is less than 25 percent because with the level of features that we have shipped to customers, level of end-to-end integration, and the level of convenience that we are bringing, CarPlay or Android Auto is no longer the topic of discussion.
What we’re seeing right now with the advancement of AI technologies is just another reason why I deeply believe that RJ and Rivian made the right choice by investing into our own technology and software. Cars are moving from, as you said, the buzzword “software-defined” to “AI-defined.” The possibilities now for such deep AI integration in the car make the entire CarPlay debate completely obsolete.
I really believe that the way you interact with apps — which are mono-threaded with single buttons or single icons — will be completely reshaped into a world where an agentic integration presents itself as a wholesome user experience.
I buy that in the big picture, but give me an example of that. I’ll put up an idea that I get from our readers all the time for you to react to. There are tons of little apps. They’re basically media-playing apps on phones, and it’s trivial to push the button for the CarPlay app.
The one that I always think about is an email from a reader who said, “I have a Bible app that is never going to be built into anyone’s infotainment system. It’s made by a small developer and I love it, and that’s why I need CarPlay. I’m always going to buy a car with CarPlay because of it.”
That is about as small of an edge case as you get, but this one customer is going to pick a car based on it. Are you going to make that developer build an agentic AI integration into the Rivian Assistant, or are you just going to lose that customer to CarPlay?
I mean, this is the beauty of the technology disruption in which we live today. The answer in that case does not necessarily need to be, “We will build an agentic integration for that particular app.” It can absolutely be if it is, say, Spotify or Apple Music.
But if it’s a small app, the answer could be that we have an integration for your favorite voice assistant in the car, and then you can ask the voice assistant to play that particular app through Bluetooth audio. That is possible as we open up the framework and allow more integrations to bring your own digital ecosystem to the car.
We’ll use Google because Gemini is more present on an Android phone than Siri is currently on an iPhone. It’s also your partner. You’re saying you can talk to Rivian Assistant and it knows your Google account and Android phone, it’s going to go talk to Gemini, and Gemini is going to go operate your phone and stream Bluetooth audio to Rivian Assistant.
In the future, all of that is possible.
Is that better or worse than phone projection? This is a different kind of loop than just saying, “Put the interface here and let the user do it.”
It could be possible through phone projection. I think the challenge with phone projection is that… First of all, as you’re driving, you’ll have to go through your phone. In some cases, you’ll have to press multiple buttons so you can get to the app menu. The other thing is that it takes over the entire screen, and that is a degradation of the experience.
Is the alternative solution available right now? No, but I think the beauty of this wave of technolo
Verge subscribers, don’t forget you get exclusive access to ad-free Decoder wherever you get your podcasts. Head here. Not a subscriber? You can sign up here.
It’s also a big moment for Rivian in general right now. The company is gearing up to deliver the more affordable Rivian R2, which is the first vehicle based on this new architecture, and the company also just shipped the AI-powered Rivian Assistant in its R1 vehicles. You’ll hear Wassym talk about Assistant as the beginning of a big bet for Rivian, as it tries to create a more agentic software platform in its cars.
I actually got to spend some time with the Rivian Assistant in an R1S ahead of my conversation with Wassym, and I found it to be a fascinating experience — certainly powerful and engaging while at the same time frustrating in a lot of really interesting ways. So I had a lot of feature requests, bug reports, and questions about the future of AI and voice assistants in cars.
So I asked Wassym about all of that, and also about his statements over the years that buttons in cars are just an anomaly and of course how he’s feeling about Apple CarPlay and Android Auto these days. You’ll hear it, but spoiler alert: Don’t get your hopes up.
This is a really fun episode of Decoder — we really get into the weeds on a lot of my favorite topics to talk about here on the show.
Okay: Wassym Bensaid, chief software officer of Rivian and co-CEO of RV Tech. Here we go.
Wassym Bensaid. You’re the chief software officer at Rivian. You’re also the co-CEO of a very important software joint venture between Rivian and Volkswagen, which is straightforwardly called Rivian and Volkswagen Group Technologies. Welcome to Decoder.
Thanks, Nilay. Super excited to be here.
I am very excited to talk to you. I have a lot to talk to you about. It occurred to me as we were doing the prep for this episode that you’re in charge of building a new kind of software for cars. But because of this joint venture that’s building a new kind of software company that’s building a new kind of software for cars, it is the most fractal Decoder I think we’ve ever had.
Awesome.
There’s a lot here. Let’s start with the organization. So, you’re the chief software officer at Rivian. I think a lot of people understand what that means. You’re the guy that they can yell at about CarPlay. Don’t worry, we’ll come to that.
There’s also the new Rivian Assistant, which is an intelligent agent inside the car that I’ve been playing with and I want to ask you a lot of questions about. Then, there’s RV Tech, which is the joint venture with Volkswagen. You’re building a new zonal architecture for a bunch of cars. I believe the R2 is the first car that’s going to run that new architecture.
Correct.
How does that all work? What are the lines between RV Tech, where you’re the co-CEO, and your role with Rivian, and what is the boundary between the software you build in the joint venture and the software you build at Rivian?
Before we dive into RV Tech and the joint venture, I think it’s really important to talk about the overall industry landscape. The automotive industry is going through a major disruption. The amount of software content in cars with technologies like electrification, connectivity, and autonomy is significantly increasing. That is creating a big divide between traditional OEMs and new tech-forward companies.
Consumers now have much higher expectations in terms of the overall experience and convenience. Multiple OEMs have tried really hard to get software content, but it’s not easy. It requires a very different type of talent. In some cases, it requires complete cultural change because you’re not only developing software. You also need to adopt different methodologies and ways of doing things. You need to be much more agile. When you look at the industry, companies tried to do that in-house. Some of them tried to partner. Some of them tried to use Tier-1 suppliers.
A lot of recipes did not really work, and that was the genesis of the great partnership we have now with the Volkswagen Group, which has really taken the Rivian technology stack — taken the software, the electrical architecture, as well as the Rivian DNA and culture — and married it with the Volkswagen Group’s incredible scale. It truly provides a fantastic opportunity for both companies because now we have a solution that can not only underpin Rivian vehicles — as you mentioned, the R2 is the first car the joint venture is shipping — but then also, in the future, every single electric model in the VW Group. This is from your premium cars like Audi, to luxury cars with Porsche, Bentley, and Lamborghini, all the way to mass market cars.
That suddenly provides an opportunity of scale. Also, it exercises the technology in very different ways, and it puts us in a wonderful position so that we can build an architecture and operating system for the entire industry.
That question about the architecture and operating system feels very complicated. As you said, the industry is moving to software-defined vehicles, which is a great buzzword. Every car executive I talk to clearly has a different definition of what “software-defined vehicle” means. What is your definition of “software-defined vehicle”?
First of all, I hate that buzzword.
[Laughs] You brought it up.
Actually, I can’t find a better name. So, I admit that I’m also using the same for a lack of a better definition.
But think about it this way. When you look at the older architecture in cars, it’s really an aggregation of multiple mechanical components. Underneath that, there are, in some cases, hundreds of electronic units, and each one of them is meant to do one thing. That’s actually mirroring the way those cars are built because they are developed using different Tier-1s and other suppliers.
In that world, integrating an end-to-end vehicle feature requires a ton of coordination between many of those suppliers. It requires very long development cycles. That approach kind of worked in the past when the expectations of consumers were not super high in terms of those end-to-end features. But I think with the advancement of EVs and with the types of user experiences that Tesla, Rivian,, and the Chinese cars are offering now, that’s no longer an option for any car manufacturer.
I’ll give you a small example. When you walk to Rivian — and I know you’re currently testing a [Rivian R1] Gen 2 Quad — let’s say you have your Apple digital key. You walk to the car and then the car recognizes you. Then, there’s a lighting sequence, and your entire profile is configured. Whether it’s the seats, the steering wheel, the infotainment system, the HVAC, everything is configured for you.
That sequence takes probably just 15 seconds, but doing that in the traditional world requires the coordination of more than 10 suppliers. You need to talk to the seat supplier. You need to talk to the door supplier. You need to talk to the HVAC supplier. You need to talk to the infotainment supplier. You need to talk to the security system. You need to talk to the cloud. You need to talk to the third party for the digital key. Just imagine that you want to slightly change that sequence for whatever reason. You have to go through another cycle of changes.
This is why that old model really doesn’t work anymore. Cars are now integrated systems with what we call “zonal computers.” We think about them as general-purpose, powerful compute that we place in the middle of the car, and they become the centralized brain of those different functions. The more software you can move on those zonals, the more it can provide control over those end-to-end features for the customers.
So, this is the pitch that every pure-play car startup has been making for a long time, right? The way that the OEMs built cars was done, and you shouldn’t have 1,200 ECUs from 1,200 different suppliers. That was fine for gas cars that were pretty dumb, where the only computer was like my old Pioneer head unit that had a fold-out screen. By the way, I love that head unit, if you could bring that back. I have fond teenage memories of my dumb old car with that head unit.
Now, the whole car is a computer, and you expect a lot of things to happen but that integration is too hard. What I would say broadly is that legacy OEMs have known this for years. They have been on their own journey to solve this problem, to cut down on the number of ECUs.
Ford CEO Jim Farley was on the show five years ago saying things like, “Too many ECUs; we’re going to cut it down.” Volkswagen, in particular, had its own giant project to do this that failed. I think there’s enough distance. You’re a year and a half into the new joint venture, and we can say Volkswagen’s CARIAD failed.
Why do you think the new joint venture and the infusion of Rivian culture is going to be successful when Volkswagen’s attempt to do it on its own did not net any positive results?
You’re getting me in trouble, Nilay.
That’s what I do.
What I personally appreciate about the Volkswagen Group’s decision is the recognition that developing what are called software-defined vehicles requires a complete, clean-sheet approach. You cannot approach it with Band-Aids and by having some level of software content in the car. As you said, the Volkswagen Group has tried. Actually, it has tried twice. But deep inside, there are two things that are really important here. One is that you need the right talent who are able to develop true software. Not abstracted functions like what the automotive industry is using — you have probably heard about AUTOSAR — but a true, hard-coded operating system.
Then, you also need a deep cultural change with a very different way of approaching the car and its overall development. The traditional model said that cars were defined many, many years in advance. People claim they know about software features four or five years in advance, and then it’s a very fixed waterfall approach. The way we design cars at Rivian is that we actually design the car around the electrical architecture, the software, and the adaptability of the software. So, software and technology have been at the table since very early on. It actually impacts the overall packaging of the car. We really use that platform and that operating system mindset so that we have a car that can evolve over time and get better and better for our customers.
Such changes are so deep that to do it well, you either need to have the right partner or you go with a clean-sheet approach. I think the Volkswagen Group has made the right decision to partner with Rivian in this case and to not only embrace the technology that we built from the ground up but to also embrace the culture, the approach, and the DNA of Rivian as a company.
How is the joint venture structured? I know you have a co-CEO, Carsten Helbing, who’s the Volkswagen CTO. So, you’re the two co-CEOs. How is it structured underneath that?
There’s a technical team underneath that: software engineering and electrical engineering. The technical team reports to me, and Carsten is my partner in crime. He takes care of the operations, and he’s also the main interface with the Volkswagen Group. There’s a ton of complexity in terms of managing different requirements and different inputs from the brands. He’s really doing all that arbitration so that we continue pushing towards a platform approach and reduce the overall complexity of the portfolio we’re supporting with the VW Group.
One of the questions I have here is that you describe it as an operating system. That seems like a good framework. People understand what operating systems are. I realize car operating systems are vastly more complex than people give them credit for, but it’s an operating system.
Then, there are the expressions of the operating system. I know that when our audience thinks of the software in the car, they think of the infotainment screen and that’s it. That’s just one expression, right? The user interface that Rivian is running… There are going to be other expressions for Volkswagen, for Scout, and I presume for Lamborghini. They’ll all be running the same core operating system expressed in different ways.
That is a real push-and-pull dynamic. Where do the features live? Who gets to build which feature? What are the core capabilities of the operating system and the platform versus what Lamborghini wants that it doesn’t want Rivian to have? How do you make those decisions?
First of all, I think it’s important to clarify the role of the joint venture. So, we’re responsible for the underlying electrical architecture and the operating system. When you look at a modern car today, pretty much every single interaction you have with the car is powered by software. You don’t realize it in a lot of cases. People tend to associate software with infotainment and with what they see on the UI and the screen, but there’s software everywhere in the car. I mean, there’s the way the car navigates, the way the car drives, the way the car saves energy, the way the car does cabin comfort. All of that is actually managed through software.
So, the way to think about this is that our role is to, first of all, build an electrical architecture with as few computers as possible in the car so that we simplify the overall packaging and the overall bill of materials. This is the brains of the system. On top of that, we develop software that the different brands can use so that they express their own identities. Think about it as us doing 80 to 90 percent of the hard work. Then, we provide customization hooks so that an Audi drives like an Audi and a Lamborghini has a different UI than a Rivian. But what’s happening under the hood, what’s happening behind the scenes, is based on the same platform.
When you think about that underlying electrical architecture and the zonal computers — you say we’re going to cut down the number of computers but have fewer and more powerful computers — one of the things that seems like an obvious opportunity for Rivian that might be way more complicated for Volkswagen is that you have a big battery that can just power those computers all the time. They can be online, they can be functional, they can be available. Volkswagen also makes gas cars and hybrids. There’s some pendulum swinging in the industry between electrics and gas vehicles, particularly here in the United States. Is that a challenge or are you just not thinking about their gas cars at all?
The joint venture’s scope, for the time being, is really about powering all the electric vehicles. This is the agreement we have with Volkswagen. One of the main reasons I joined Rivian is for the mission. I think the joint venture provides us with an extraordinary opportunity to accelerate electrification into many more cars around the world.
One of the first products that we’re building with Volkswagen Group is the ID.1, which is taking our technology to a mass-market vehicle. This is a car that will sell for less than $25,000, and it really opens the technology and that rich feature set to many more consumers around the world. Now, can the technology be used for non-EVs? Can it be used for hybrids or ICE vehicles? Obviously, the answer is yes, but for the time being, that is not the priority of the joint venture.
How big is RV Tech? How many people?
We’re about 1,500 people.
How is that split between Rivian folks and Volkswagen folks? Is it employees from both companies, or are they employees of RV Tech?
They are employees of RV Tech. Actually, we started with about 800 or 900 developers coming from Rivian, and then we had about 50 colleagues who joined us from the Volkswagen Group. The rest are developers and engineers that we’ve hired in the past 18 months. So, everybody’s RV Tech.
The reason I ask is that you mentioned at the very beginning that it’s an infusion of Rivian culture, but now they’re not Rivian employees. But at the same time, you are also the chief software officer of Rivian. How does that culture persist if the thing is its own entity, if it’s not as directly connected to Rivian, or if they’re not Rivian employees?
The way I define my job and my number one priority is to help the company grow and build on our two main assets, which are technology and our people and culture. With technology, I think we have a wonderful opportunity now to take that tech into many more cars across a wide range of the portfolio. Then there’s trends and culture. My daily obsession is to really make sure that we continue to have the same DNA: agility, being nimble, prioritizing action, quick decision-making, and iterating really fast so that we are at the forefront of innovation.
One of the other reasons I ask is that there are Rivian decisions that Volkswagen maybe won’t make. Rivian runs on Unreal Engine for the graphics in the infotainment. It’s really fun. I’m not sure that every single Volkswagen is going to run on Unreal Engine.
At least as I understand it, that’s a decision the different brands can make for themselves. But you’re the chief software officer at Rivian. You’re like, “We need better support for the Unreal Engine interface.” Maybe the platform doesn’t want that, and you wear that hat, too. How do you reconcile those tensions? Do Rivian’s needs always win?
What wins is how we can build the software in a way that allows for different expressions. I think in this case, Rivian’s interface will show up through Unreal Engine, but then we need to have hooks in our frameworks so that — and I know you will ask me this question — Volkswagen cars can have CarPlay. The team will develop that even though Rivian will not adopt CarPlay. It’s really about creating those different hooks in the operating system so that we allow for different ways to express the user interface.
This is so fascinating. Like I said, this is such a fractal episode of Decoder. It strikes me, just talking to you about this, that there aren’t a lot of models in an industry as big as the auto industry like this, where the big player is letting the smaller company define the culture, the opportunity, and the architecture, which will define its future roadmap. What examples have you looked at that are similar, where you can say, “That’s successful. We should build the model based on this and operate like this?” What versions of this have failed that you’ve looked at where you’re like, “I want to avoid those mistakes?”
I think there are many more failure stories than success stories when people look at joint ventures. This has been one of our guiding principles. We spent a lot of time discussing with VW leadership before we engaged in such a partnership. What made [Rivian CEO] RJ [Scaringe] and myself lean heavily into this partnership is, one, the opportunity and, two, the honest and constructive partnership from Volkswagen Group leadership.
First of all, we are talking about putting Rivian technology into the second-largest OEM in the world. This is, by far, the biggest licensing deal in the automotive industry. As RJ and I started the discussions with [VW CEO] Oliver Blume, his number one priority was that they needed to keep the Rivian way of doing things. We realized that we are not only bringing software IP and electronics IP but also a different process. We are bringing a different culture, and the VW Group needed that change from the inside.
Obviously, in some cases there has been daily tension. There are cases over the past 18 months where, as you mentioned, one brand might request a different requirement than another brand. But what really helped us to continue is that support from the highest levels of Volkswagen Group leadership to help drive that transformation and cultural change.
Let me ask you the other Decoder question, and then I want to turn to the software itself. I ask everybody this question. We’ve talked about it a little bit. How do you make decisions? What’s your framework for making decisions?
So obviously, my job every day is making decisions, but there are a number of guidelines that I try to apply. In terms of coaching with my team, I try to push decisions to the lowest levels of the organization as much as possible. One of the anti-patterns that I see with a bunch of companies is them trying to bubble up decisions with the highest levels of executives, and that tends to create a culture where things are slow and employees don’t feel really empowered.
Now, in cases where I personally have to make the decision, there are a few guidelines to the team: never come to me with one option, show that you went through an analysis, have multiple options, and then make a recommendation. I want a culture where I empower my team to have a forceful proposal and then come up with recommendations themselves.
The rule that I use to determine how much time I should spend on a decision is about whether it’s a one-way door decision or a two-way door decision. If it’s a two-way door decision, then I don’t need to spend that much time on it. It doesn’t really need a hard framework. We don’t need to go to extremes where we collect tons and tons of data so that we get to a decision. In some cases, I just use my gut. I’m a product builder at heart. I know that with some of the decisions, even if the data is against me, I should go with my feeling. In some cases I’m wrong, and I’m the first to recognize that.
Now, if it’s a one-way door decision, then that’s a different process that requires much more preparation and much more data, and then it requires arbitration for how we do things.
Give me an example in this context of a one-way door decision and a two-way door decision at RV Tech.
There’s multiple. I think one of them will probably lead to the next topic of discussion, which is our overall approach around AI. We had a ton of debates internally about whether we should just use a third-party AI solution or develop our own. There was a ton of tension because you look at the advancements in the AI world, and you would think that this is a hard problem to solve with everything that’s happening.
Now, it was really clear for me, given the opportunity and how transformative this is for the entire user experience, that we needed to own our destiny in terms of having a platform that allows us choice, that allows us to change foundation models as we wish and own the integration layer that allows us to power the entire car operating system.
So, this is Rivian Assistant. I’ve been playing with it for a few days now.
What do you think?
I had some searching conversations with it, just to push the boundary of what it can do. It’s super interesting to have a car where even within the interface, it does the wavy line on the main screen. It’s very much that the car is running this assistant, not an overlay. You can tell that the assistant can go and address lots of parts of the car, and then there are places where it can’t or it won’t.
Actually, I think one of the most interesting things about it is that it won’t tell you why it can’t do things. It is insistent that it won’t tell you why it can’t do things. Don’t worry, I have very specific questions. But it strikes me that this is a natural evolution of, “Okay, the whole car is run by a finite set of computers, and that means our assistant can just run around and talk to those computers and the functions that those computers control.” I have a Cadillac EV. If you try to glue an assistant onto that, it has to go talk to its CCUs. It’s just very obvious that something else is happening with Google Assistant in that car. That’s the opportunity. The assistant can talk to the whole car. Then there are places where it just can’t for some reason.
I’ll give you one example. It struck me as very odd. I was driving in the rain, and I said, “Hey, turn on the back window wiper,” and it just won’t. I thought, “Is that a safety reason? Is that because you don’t know how to do it? You’re lost in the zonal architecture?” I asked it, and it said, “I can’t tell you why I can’t do these things, but here’s where the button is,” which is really interesting for a car assistant to do. I’m not going to do it for you, but the button is on the stalk. Push the button. How do you make those decisions in the context of an assistant to figure out what it can and cannot do?
So, there’s a lot of things here. First of all, I think you described it really, really well. Our philosophy for the Rivian Assistant was to not just put in a chatbot and then slap it on top of the UI. It’s also about developing what will become the connective tissue that enables our users to interact with pretty much every single feature in the car and, even more than that, to bring their own personal digital ecosystem in the car through agentic integration.
Now, to your question about what it can do and cannot do, it’s obviously possible for us to control the wiper. I’m sure that you have seen that it can do way more. It can change your drive modes. It can change your ride height.
I could raise and lower the car at 55 miles per hour with the air suspension, which was cool and like the slowest low-rider experience you could possibly have, and then I couldn’t turn on the wiper. So, what is the split there?
Honestly, that’s one of my favorite features. The way I like to interact with it is that I don’t tell it to change the ride height. I tell it, “Okay, give me a drive mode with more pep,” and then it does it and changes to sport mode. I mean, this is really the magic of that true conversational experience.
Now, the reason it does not control the wiper is by design. We actually block a number of features that are safety-related. Cars are homologated and regulated. So, things related to wipers, windshield controls, highway assistance are regulated functions, which we block for safety reasons today through our framework. Safety is one of the core tenets in how we develop the entire experience.
The other one that struck me is that your cars have rear-seat sensors. We have kids, so every time I get out of my car, it reminds me there might be a kid in the back seat because it has sensed the weight. I think this is one of the funniest sensors any car can have because the car seat is always in the back seat. So, it’s always reminding me that the kid might be in the car.
So I asked, “Is anyone in the back seat?” Maybe this is just a bug, but it said, “I’ll find out,” and then it said, “I can’t access that sensor.” I said, “What sensor are you trying to access?” And it refused. I probably had a five-minute argument with your assistant about why it wouldn’t tell me what sensor it was trying to access.
The reason I’m asking this is not because it’s a bug or I really needed to know if anyone was in the car seat at the time. I’m just curious. You think about building the assistant that can access all of the sensors and the architecture and how that might work and how we might interact with cars. There’s a moment where you realize maybe it’s for safety reasons or maybe it just won’t work right now with the version you have because the LLM has to go talk to another computer and that computer has to give it permission. I don’t know if anyone in any part of the tech industry has figured out exactly how that should work, and I’m just wondering what your point of view is.
I think in this specific case, it should have actually told you what’s in the back seat. So, that’s a bug. That’s on me.
No, it was like, “I’m not telling you what sensor I’m trying to use.” I was like, “Why?” and it was like, “I’m not going to tell you what sensor I’m trying to get to.”
Yeah, that one is on me. I think the beauty here is that we have the team in-house. We’ll be able to calibrate that answer, and then we’ll fix it. Don’t worry. Nilay, I’ll send you an OTA next time when that’s fixed.
That’s very good. Every time we get a car executive on the show, I just complain about the experiences I have. It’s perfect.
But every assistant at every level is running into that specific barrier concerning how you talk to the computer and what permission does that other computer give you. Every assistant at every level is running into that specific barrier, and I’m just curious what you think the answer is.
Think about our architecture this way. The assistant has deep integration into the entire vehicle operating system. So, in theory, unless we have a bug like the one that you experienced, , you should be able to do everything with the integrations that we have built.
The only functions that are not allowed are functions that are safety-related, obviously because of the homologation reasons. But also there are functions where we are not comfortable with the level of reliability we can get from the LLMs to expose them to the end users. But that’s really the beauty of the internal, in-house orchestration layer that we have built where we have a ton of guardrails that allow us to control which functions are exposed by the assistant or not.
All right. You mentioned that I was going to get you in trouble. I’m going to get you in trouble again. In 2024, you said using buttons in a car is an anomaly of modern design. People love buttons in their cars, so you got in trouble for saying that, but the thing you said was that voice should be the future. This is the first gesture at voice being the future. Is it good enough? Because we’re right on the cusp of whether these things are actually good enough to build the kinds of products people want.
I think we are on the cusp of something really big. When you think about it, you’re in a car, you’re driving, you’re focused on the road. So, in theory, the primary interface with which you should be interacting with the car is actually voice. The only reason that drivers and consumers do not interact with the car through voice is that, to put it really bluntly, the technology has been broken. That’s really the beauty of what we have now with the technology disruption coming with foundational models.
The foundational models are providing us this wonderful opportunity to truly have a conversational experience where drivers can interact with the car in human language. I don’t need to tell the car, “Open the frunk.” I can say, “Open the front trunk.” Actually, I can say, “I have a bag in front of the car,” and it will actually open the frunk. I think that completely changes the way you interact with the car.
On top of that, we now have the opportunity with all the agentic framework to truly give people their time back in the car. I hope you tried our Google Calendar agentic integration. You can imagine how the experience will be in the future where you’re driving and can perform operations on your calendar. You should be able to perform operations on your email. In the future with the agent-to-agent integration, you can actually interact with many more apps from your own digital ecosystem.
Can I ask you about the word agentic in this context? To just describe it quickly for people, the way the Google Calendar integration works with Rivian Assistant is that it shows you a QR code. You connect your Google Calendar to it and then Rivian Assistant can read your calendar, add events, remove events, and do other calendar stuff.
I’m curious how that’s agentic and how it’s built such that the word agentic is meaningful because I’ve had like 500 apps over the past 10 years that can do Google Calendar stuff through the standard API. So, how is it agentic? Is it powered by [Anthropic’s] MCP? Is it something else? Why build it that way versus doing a bunch of API integrations?
I mean, you can build it with an API integration. I think the advantage of an agentic integration is that you can share the context, and then you can perform multiple integrations within the car. In this case, it is based on an MCP integration.
You can imagine that in the future, instead of having that mono access to every single app on your car — or honestly, even on your smartphone — you can start aggregating and connecting many of those apps through the agentic framework and have them present a unified user experience.
This is how we’re able to connect the navigation to Google Calendar, for example. I can go to the assistant now and say, “I want to plan a trip from San Francisco to San Diego, and I want to have two charging stops. I want them to be close to an Italian restaurant. I love Italian food.” The assistant would go and play that, and then I’ll say, “Okay, print the summary, add it to my calendar, and then send it as a text to my wife.”
When you have a behind-the-scenes agentic framework, this type of integration can really allow many more capabilities. This is where agentic can be utilized even further. You can start going into more autonomous functions. Let’s say you have an invitation in the calendar with XYZ details. You can start having reminders that say, “Do you want to go to this place?” “You’re actually really late to your meeting. Do you want me to start preconditioning your car?” So, that’s the beauty of bringing in the depth of that agentic integration.
I think I understand that. Rivian Assistant is in the car. It can access a bunch of apps and services you have. You can take actions across them. You’ve collected a lot of data in one place.
This brings me to a very deep existential question I have whenever anyone talks about ambient computing this way: Where does the logic live? The idea that you’re going to have that interaction in your car and not at your laptop or on your phone seems like a big jump to me. It was the same way when the smart speaker companies would be like, “You’re going to talk to your thermostat,” and would I think, “Why?” I’m going to talk to my phone. I don’t feel the need to talk to my thermostat in this way.
Do you think people are going to do that in the car, or are you going to bring your assistant to the Rivian app on a phone? Can you compete with Apple’s Siri and Google Assistant in that way? How is that all going to work?
Actually, the way I think about it is that it will be both. This is the big difference between the old world where we had unique applications and the new world where we have agentic integrations.
I think about Rivian Assistant as an agent orchestrator that has privileges because it can deeply integrate with the vehicle controls and the vehicle operating system. It understands safety. It understands which things to do and which things not to do. Nobody else can develop that better than us because we develop the entire vehicle software. But at the same time, it has interfaces and connections to other agents.
This is just the beginning. In the future, you can probably bring your own favorite assistant and chatbot to the car, and then it can share context with Rivian Assistant. I mean, these are the possibilities that this new world and this new type of integration are allowing us to do.
Is Rivian Assistant the kind of thing that is possible because of the RV Tech software stack? Is it possible that we’ll see Rivian Assistant or something just like it in Volkswagens as well, or is this special to Rivian?
This is special to Rivian. This is an AI stack that is developed uniquely for Rivian. This is Rivian’s brand priority as we see cars becoming more and more AI-defined. But we’re in discussions so that we can have similar technologies for the Volkswagen Group.
Rivian cars famously use LTE. When I first got in this car, I saw the LTE indicator, and I thought, “Oh, something must be wrong.” I drove around, and then I realized, “Oh, it’s just LTE.” Are there any latency concerns with that, especially with voice and going out in the world and doing whatever inference you need to do?
[Laughs] So, two things, Nilay. One, we need to get you an R2. The R2 has 5G.
There you go.
It’s coming soon, and it’s amazing. And two, I think you really touched on one of the architecture considerations for the technology, which is that when you look at vehicles like the Rivian R1 today, most of the interactions will happen with the cloud. So, as you say, it’s connectivity dependent. so they will work best when there’s strong connectivity with the external world. Now, there’s a number of interactions that happen locally with the car. If you tell the car, “I am cold,” that interaction is being managed by a small language model that sits directly on the edge.
The beauty of what will happen next as we get to the R2 is not only the 5G but also edge AI will be way more powerful and capable.
Just to be clear for the audience, when you say “edge,” you mean local, right? It’s running locally.
Yeah, local, meaning that the local computer on the R2 will have up to 200 sparse TOPS (trillions of operations per second) of compute dedicated to AI. I know this sounds extremely technical, but think about it as more capable than some of the self-driving platforms today. It’s more capable than the AI compute that you have in your smartphone.
All of that will be available locally in the R2 car, which is coming soon. That allows it, as you mentioned, to not face these connectivity limitations and issues and to get to much lower latency because a lot of the processing will happen directly on the embedded system so you can get a conversational experience that’s pretty much instantaneous.
Can I just ask you a very in-the-weeds question? We’re talking about putting compute in the car. We’re going to do some amount of local inference in the car. GPUs are expensive. RAM is expensive. How much of the bill of materials is RJ giving you to do all this in the car versus, I don’t know, bigger motors or bigger batteries? How much of the range can you pull off to do local inference in the car? This is the trade-off you’re talking about.
This is what I love about RJ. What has always attracted me to RJ is that he thinks about big things in the long-term. He knows, in this case, that the world is moving to AI. This is why decision-making from a bill-of-material standpoint is a very hard process with a ton of trade-offs all the time. You can imagine the tension between people wanting to push for a better exterior part, people wanting to push for a better interior part, and people wanting better technology. Then, we have what we call the”differentiation budget” in the car.
For RJ, there was absolutely no debate on whether we would equip the car with higher inference compute and more memory because this is really the future. It’s an opportunity for us to completely reshape the way people interact with their cars. To be honest, it solves itself in the long run from a unit economic standpoint because as we do more and more interactions locally in the car, we avoid the back and forth with the cloud. So, we avoid the connectivity costs, and then we also don’t have to pay for the cloud inference costs. So, in the long run, it’s actually economically positive.
That’s not just a spreadsheet you made up to win an argument that actually models out?
[Laughs] Kind of.
The reason I ask it is because my next question was about inference costs. They’re going up. There are rate limits with all the big providers. What model are you using right now? What are the frontier models you’re using right now?
The architecture that we have built is not actually model dependent. One of the architecture’s foundations allows us to interact and plug-and-play with different foundational models. Similarly, it can use different modalities in how users can input their requests, whether it’s voice or vision. It can use text if we want to enable that.
When it comes to the models themselves, we currently use a combination of internal models for everything that runs locally on the edge and models from Google. We have a partnership with Google. Things are going really well in terms of deep access to advanced Gemini models as well as the grounding of results also powered by Google.
This is another question I asked Rivian Assistant: what are the top five headlines on The Verge? I just wanted to see if this thing browses the web. It returned some results that I think are 24 or 48 hours old. These were the top five headlines from yesterday.
Does this thing have a web browser in the background, or is it just pulling from a Google data corpus? How does that work?
In theory, it should in theory connect in real-time. This is where the grounding with Google results comes into the picture. It should give you the latest headlines. So, if it didn’t, then that’s another one on me.
Well, I was just curious. Lots of people are having this experience now where the data in the model is old and there’s some cutoff, and I was just trying to find the cutoff. Then, I had a long searching conversation with it. We need to buy a new air conditioner, and I was just asking it to do math about air conditioner efficiency. It’s very boring, but this is what I talked to your car about for a while. It occurred to me that I was making it think very hard. I am wasting more energy asking how efficient an air conditioner I should buy. This is not a good ratio of energy spent to energy saved over there.
How does that work? You have to pay a monthly fee for the connectivity package to access Rivian Assistant, but then I might burn way more tokens than that fee could ever pay for. How does that math work out?
It really depends. In these cases, there are all sorts of what we call “rate-limiting” techniques that we can apply. If we have seen, like in your case, that you’re spending 20 hours discussing with the assistant, then we may do something behind the scenes.
It’s similar in the way we can configure the models. Given the types of interactions that you have in the car, you would not be interacting with the latest and greatest, say, Claude Opus 4.7 models so you’ll burn a lot of tokens. A lot of it also depends on aggregation across users in terms of the types of requests, as well as the arbitration we do between the edge and the cloud. As I mentioned, the more we move to edge and local compute, the better it is for us in terms of overall inference costs.
So, let me just ask you this question again. Now that you’ve shipped this software, people are using it. You’re getting extremely detailed feedback from me. Do you still think having buttons in the car is an anomaly?
I deeply believe that voice has the chance to be the primary interface in the car. I also think that buttons can exist, but they shouldn’t be the primary way with which you interact with the car. I think there’s more that is possible with voice since you can do more than one single function.
You don’t have to fiddle with so many functions. You don’t have to go deep into the touchscreen to look into specific features. A great voice experience can elevate all of that, allow users to talk to the car as a human would and really take the overall experience to the next level.
Are we going to get the HVAC buttons back in any future Rivians? That’s really what I’m asking here.
Actually, with the R2, we have a great way to add tactile feedback for HVAC.
Oh, the big paddles on the wheel?
Yeah. They’re really awesome.
That’s a good pivot, but I’m asking, are we going to get the fan speed button back in the center stack?
Not in the center stack, but we have the same thing on the Haptic Halo Wheels. It’s a great compromise.
You knew it was coming. I have to ask you about CarPlay here. It strikes me as you imagine this future where the car is connected to your calendar and it’s connected to all this context. It has autonomy, which is something you’re also working on. You get in the car, and it knows it’s time to go to work. You just say, “Let’s go,” and the car takes off driving.
This is when you would use a vast number of applications, right? This might be when you have to focus to push the buttons again. I’ll just make that argument. But this is when you would want a whole number of apps. I hear from our readers every time I talk to a car executive that, “The reason I want CarPlay is because there’s 5,000 apps on my phone and no car OEM is ever going to support them in the built-in infotainment.”
This is when you would say, “Okay, project your phone to the center stack. The car’s driving itself. Have at it. Phone projection all day.” Do you think the tide is turning, or are you still absolutely committed to not having CarPlay in Rivian vehicles?
First of all, it’s really important to go through the philosophy of how we see software in the car and the user interface. The challenge with screen mirroring solutions is that they take over every single pixel in the car, and that’s not the way we see ourselves interacting with our users. You drove our car four years ago, and you drove another car over the past few days. I hope you’ve seen how much has changed in the car. It’s truly been by bringing in end-to-end features, not only changing the user interface but having your navigation know exactly about your drive mode, know exactly about your efficiency.
Offering that level of convenience is what is really resonating with a lot of our customers. If I look at our own internal statistics from five years ago when we first shipped the R1T and the R1S, the number one request from customers was CarPlay. We did all sorts of surveys with customers at the time, and more than 70 percent of customers were requesting CarPlay. In the recent survey, that number is less than 25 percent because with the level of features that we have shipped to customers, level of end-to-end integration, and the level of convenience that we are bringing, CarPlay or Android Auto is no longer the topic of discussion.
What we’re seeing right now with the advancement of AI technologies is just another reason why I deeply believe that RJ and Rivian made the right choice by investing into our own technology and software. Cars are moving from, as you said, the buzzword “software-defined” to “AI-defined.” The possibilities now for such deep AI integration in the car make the entire CarPlay debate completely obsolete.
I really believe that the way you interact with apps — which are mono-threaded with single buttons or single icons — will be completely reshaped into a world where an agentic integration presents itself as a wholesome user experience.
I buy that in the big picture, but give me an example of that. I’ll put up an idea that I get from our readers all the time for you to react to. There are tons of little apps. They’re basically media-playing apps on phones, and it’s trivial to push the button for the CarPlay app.
The one that I always think about is an email from a reader who said, “I have a Bible app that is never going to be built into anyone’s infotainment system. It’s made by a small developer and I love it, and that’s why I need CarPlay. I’m always going to buy a car with CarPlay because of it.”
That is about as small of an edge case as you get, but this one customer is going to pick a car based on it. Are you going to make that developer build an agentic AI integration into the Rivian Assistant, or are you just going to lose that customer to CarPlay?
I mean, this is the beauty of the technology disruption in which we live today. The answer in that case does not necessarily need to be, “We will build an agentic integration for that particular app.” It can absolutely be if it is, say, Spotify or Apple Music.
But if it’s a small app, the answer could be that we have an integration for your favorite voice assistant in the car, and then you can ask the voice assistant to play that particular app through Bluetooth audio. That is possible as we open up the framework and allow more integrations to bring your own digital ecosystem to the car.
We’ll use Google because Gemini is more present on an Android phone than Siri is currently on an iPhone. It’s also your partner. You’re saying you can talk to Rivian Assistant and it knows your Google account and Android phone, it’s going to go talk to Gemini, and Gemini is going to go operate your phone and stream Bluetooth audio to Rivian Assistant.
In the future, all of that is possible.
Is that better or worse than phone projection? This is a different kind of loop than just saying, “Put the interface here and let the user do it.”
It could be possible through phone projection. I think the challenge with phone projection is that… First of all, as you’re driving, you’ll have to go through your phone. In some cases, you’ll have to press multiple buttons so you can get to the app menu. The other thing is that it takes over the entire screen, and that is a degradation of the experience.
Is the alternative solution available right now? No, but I think the beauty of this wave of technolo