Skip to main content

Meet Bricksy - The Hyper-Personalized, Privacy-First AI Copilot for the Software-Defined Vehicle

Summary

  • Bricksy is a hyper-personalized, privacy-first AI copilot for the software-defined vehicle, built entirely on the Databricks Data and AI platform as an Android app that delivers voice-driven interactions with real-time car telemetry data.
  • The architecture streams vehicle telemetry directly into Unity Catalog via Zerobus for near real-time anomaly detection, while Vector Search and Lakebase enable the AI to recall car manuals, service history, and long-term driver preferences.
  • Sensitive telemetry never leaves the manufacturer's governance boundary because proprietary tools and functions are deployed directly on the Lakehouse, ensuring data sovereignty for OEMs while still delivering intelligent, personalized driver experiences.

Meet Bricksy - The Hyper-Personalized, Privacy-First AI Copilot for the Software-Defined Vehicle

Watch: Meet Bricksy - The Hyper-Personalized, Privacy-First AI Copilot for the Software-Defined Vehicle
As automotive industry pivots to the Software-Defined Vehicle (SDV), the challenge has shifted from collecting data to interacting with it in real-time. Drivers demand a seamless, personalized experience, while OEMs demand data sovereignty and low-latency interventions.
Bricksy, a next-gen AI agent powered entirely by Databricks is an android app. We'll demonstrate a unified architecture for building voice-enabled driver companion that thinks, remembers, and protects having:

  1. Real-Time Nervous System: Vehicle telemetry (Engine Temp, TPMS) streams directly into Unity Catalog via Zerobus, enabling near real-time anomaly detection.
  2. Infinite Memory & Context: How Bricksy utilizes Vector Search and Lakebase to instantly recall car manuals, service history, and long-term driver preferences.
  3. AI That Comes to Your Data: How manufacturers can deploy proprietary tools and functions directly on the Lakehouse, ensuring sensitive telemetry never leaves their governance boundary.

Talk By: Hussain Jagirdar, Solutions Architect, Databricks India Private Limited ;

Chapters

FAQs

What is Bricksy and what does it do?

Bricksy is a hyper-personalized, privacy-first AI copilot designed for software-defined vehicles, built entirely on the Databricks Data and AI platform as an Android app. It allows drivers to interact with their car using voice commands — asking about engine temperature, tire pressure, service history, or personal preferences without being limited to maps and music like current solutions.

How does Bricksy personalize the driving experience for multiple drivers?

Bricksy uses Vector Search and Lakebase to store and recall long-term driver preferences, car manuals, and service history. Multiple family members can have separate profiles so the car remembers individual preferences such as ambient lighting color or seat height without requiring manual reconfiguration each time.

How does Bricksy handle real-time vehicle telemetry data?

Vehicle telemetry data — including engine temperature and tire pressure monitoring system (TPMS) readings — streams directly into Unity Catalog via Zerobus, enabling near real-time anomaly detection and driver notifications. This real-time nervous system allows Bricksy to alert drivers to potential issues as they occur rather than after the fact.

How does Bricksy protect sensitive vehicle data for manufacturers?

Bricksy deploys proprietary tools and AI functions directly on the Lakehouse, ensuring that sensitive vehicle telemetry never leaves the manufacturer's governance boundary. This architecture gives OEMs data sovereignty and low-latency interventions while still enabling intelligent, personalized driver experiences.

Full transcript

[00:07] Good morning everyone. So today I would be talking about a Brickse. Brickse is the one of the hyper-personalized privacy first AI co-pilot that we have defined for the software vehicle. Before
[00:19] I start my presentation, right? I would be showing you some of the snippets why we want to do it and why we started doing this. So we were working with one of the vehicle manufacturer, one of the leading
[00:32] vehicle manufacturer in India. And and that's how we started it. We founded some of the blockers and uh What was the problem statement? Yeah. So right now if you see the problem
[00:45] statement was that there was a need for a personalized co-pilot, right? If now in the driver's point of view, there could be like whether can I have a voice command functionality and I can answers
[00:59] I can have a bot that can actually answers to any of the questions related to my car, right? And it should also work should with my car telemetry data. Now the problem is right now we also
[01:11] have the Gemini with this Apple CarPlay and Android Auto all of these things, right? But mostly they are limited to the to the maps and the music. That's all,
[01:23] right? Whatever the functionality that you have in the phone, right? But in case you want to go deep dive into it and you want to understand that hey, whether is there any possibility where I can converse with my car and check that
[01:36] hey, suddenly there is an increase in the engine temperature. Is it happening? What is happening? What what is the reason behind it, right? Or maybe you are in a petrol station, gas station and you don't know what is the exact
[01:50] tire pressure that you is required for your car, your model, right? And you can just quickly check with your bot that hey, for my car what is the ideal tire pressure I look like, right? And then it should answer in that it should be 40
[02:03] points, 30 points, whatever it is, right? So, one of the biggest challenge obviously would be that it should work with the car car telemetry data, right? For the software defined vehicles.
[02:15] Also, in if we say for the hyper personalization, there should be a possibility of adding the long-term preferences, right? So, in case many of the this car has been driven by
[02:27] let's say a family of like two, three, four folks, right? And the car should remember all of the preferences like for a person A, maybe it he prefers a red ambient light, right? For the person B
[02:39] and the driving height should be like for the medium or the high and all of these things. You don't need to go over and over there and just make the car settings as per before you drive, right? And also, you you have you should also
[02:53] remember the short-term sessions, right? So, similarly, if you if you think mostly right now when we converse with the any of the co-pilot or the any of the car assistant, it's like a command. You give
[03:05] a command and you take the output, right? But sometimes to make it more natural, now the the industry is moving towards the multi-turn conversations where you could first ask that hey, uh
[03:17] how much time will I get from place A to place B? So, it will answer hey, for for going to the place B it would take around 20 minutes, right? And then you would you would answer that is there any
[03:29] markets nearby or maybe I can check out something. So, it should remember the old conversation that you're having, right? All this becomes a very important aspect when you're conversing with a actual co-pilot rather than a board that
[03:41] just follows your task. Now, as a driver's point of view we have looked upon, but as a manufacturer point of view, right? So, in order to make all of these things work, it would be very important that the real-time telemetry
[03:54] data should flow for your AI, right? That is a challenge. Right now, whatever the AI that you get in the car is mostly about the the phone assistant that you have already. It's just It's in the
[04:06] loudspeaker mode. That's all, right? And it's it's just showing the interface in in your car's um um monitor, right? Now, but the AI would be
[04:20] in the real blocker would be how to pass all this telemetry data, which is it's huge in number to the AI so that it can do the analysis and the action for you.
[04:32] Number one. Number two. Is there any a framework where I can update all my car manual based on the new updates, replacement, or servicing? For example, maybe in case
[04:44] after a servicing, you are just conversing with your car and just saying that, "Hey, I feel there is some voice that I'm getting. Is it because of the last yesterday's servicing that I had? Is there any issue
[04:56] in the suspension, right?" So, it should know what's the recently has happened to the car. So, it's actually a brain of the car that you're talking to and it knows what's happening inside, right? So, right now, is there any framework to
[05:08] update the car manuals? Right now, for a manufacturer, no. And the privacy and the security obviously comes what with all the AI frameworks and the solution, right? That whenever this the big
[05:20] giants, tech giants, if you want to bring the AI to this this complex AI to a car, either you need to pass all of your telemetry data, all of your car's data to the AI, right? Or some
[05:32] tech giants in the industry, right? And the manufacturers are not interested in doing that, right? And as as we have talked about, there there is a need for a unified AI
[05:44] framework, like which is kind of using the structured data set uh unstructured data set and the real-time telemetry data, right? So, moving forward,
[05:57] so, what we have introduced is the Brick-C. Uh now, like quickly show you up the architecture diagram of the Brick-C, right? So, in the left-hand side, you might see the few um
[06:09] drivers who are interacting with the same car, right? And in the in the first it the first panel is showing the voice co-pilot and the Android client, which is doing two things. First of all, it's doing your speech to text, text to
[06:22] speech, because that's the mode of communication that you would be interacting with your car. And there would be obviously many sensors in your car, right? In the electric vehicles, obviously the the sensors would be way too high. And
[06:35] that would be giving up all the information directly right away to the any of your uh uh back-end system, right? Uh in this particular um framework, what we have enabled is all
[06:48] this telemetry data of the sensors data is directly flowing to the data bricks in following the medallion architecture of the bronze, silver, and gold. And the transfer is happening via zero bus ingest, right? So,
[07:02] uh this is the ingestion part. Now, in the middle of the middle of the diagram, you see the Brick-C. Brick-C is actually the agent that is interacting with the data. And it's also interacting in the
[07:15] right-hand side, if you see is the league base. Now, what exactly is the need for the league base? As we talked in the as we discussed during the drivers' point of view, there was a need for personalization, right? So, whenever
[07:27] um so, like Ali, Bella, Chloe, they are kind of interacting with the Brick-C, the agent would be same, but their memory for the short-term preferences and the long-term preferences should be separated out there. Should be
[07:41] uh be should be stored somewhere with a persistent storage so that after 5 days if if uh Ali came and then he again talked to the uh same car, it should remember that hey hey he prefers the red ambient light and
[07:54] uh driving mode is like say sports mode or something sort of this, right? So, this is how you kind of uh uh distinguish and uh have the persistent storage with the Lake Base. And the in
[08:06] the topmost part in the top left, you see is the Databricks vector search index. Now, all of this vector data, so what we have designed a framework where uh during the uh whenever you buy a
[08:18] vehicle, right? So, the car manual will be ingested into the vector search so that all the paragraphs, all the manuals like what what is the ideal uh engine, what is the ideal um uh engine temperature, I would say, and uh tire
[08:31] pressure, or any of the sensors, right? All of this information would be ingested in the vector search, and which will be identified by your vehicle identification number, VIN. Right? Uh that would be uh obviously incorporated to the Brixy.
[08:44] And after some point of time whenever you are doing some sort of servicing, whenever you are making car available to a uh um uh service center, right? They would have a framework where they can just upload the PDFs into uh
[08:58] uh uh a portal, and that portal will ingest that PDF, which will have all the servicing logs, and it will ingest again to the same uh VIN number to that vector search index. So, that in case you ask some
[09:10] questions, uh that would be uh available for your Brixy agent to work with. Now, in the left side, you also see a health diagnosis uh diagnosis tools. Now, what health diagnosis tools are uh all of
[09:22] this uh you can think of all the propriety uh tools or some some of the functions or some deterministic logic that you want to incorporate, and all the different manufacturers wanted to incorporate,
[09:34] that can easily uh pull. So, right now we are using UC functions as a tool. In UC function, you can define what exactly uh, in the diagnosis, what are the steps that needs to be followed, what all protocols needs to be followed,
[09:47] everything would be defined under the health diagnosis tools, right? And that's how you you are Bricksewels be interacting. And then in the right hand side, what we are showing is though we have taken the input, we have
[09:59] framework to interact with all the different components, but what is the output, right? How can I yeah, see the output whatever what the car car should also do some action as well, right? If I'm saying that
[10:11] turn on my preferred ambient light, it should first take the data from the rig base that hey, what is the preferred ambient light for Ali? It's it is red, and then it should actually turn on the preferred ambient light, right? So, what we have done is we have we have given a
[10:25] framework where we are building custom MCP server as the Data Bricks apps, which are interacting with the three of the things. First, we have made a simulated car dashboard since we don't have the physical
[10:37] car right now here so to show you, but this is how you whatever the actions that will come up from the Bricksee can be shown directly to so the the output will be shown directly in the car
[10:50] dashboard. Second part is the servicing portal. Servicing portal is actually a DMS dealer management DMS or any portal where in case there is some mis happening happens, so the
[11:02] Bricksee can directly recommend hey, do you want to book a servicing slot with the with your manufacturer, right? And it can easily navigate through what are the slots available in which area,
[11:14] and do you want me to book it? And if if you say yes, and it will book it for you, right? And similarly, since we all of the telemetry data is again in the Data Bricks ecosystem of a manufacturer,
[11:27] right? We want all of this analysis of the driver like how the driver is driving or how the all the profiling of the user profiling can be done and that could be helpful for let's say
[11:40] other and downstream application. It could be maybe like insurance, right? If a driver style is way too rough, right? Where he do does a rash driving, then maybe the similarly we know how the driver can and
[11:53] also what is the possibility of diagnosing all of these things, right? So, this is how the architecture looks like. I just I'll show you two use cases and we'll quickly move to
[12:05] the demo video recording that I have. First use case is in this particular what I we have built is this is the mobile application that we have what we are calling as a Brixy.
[12:18] It's just right now to show for you guys, we have made a simulation of all the sensors, the vehicle data and engine start-stop and the driver's name, right? So, whenever the engine starts, right?
[12:30] Basically what will does it will does it will check here the tire pressure monitoring system of the back right tire is three, which is a kind of which is a point to be taken care of, right? The So, the front end will send a
[12:42] notification to the Brixy model, which is our model serving endpoint, right? Of a supervisor agent. That would send on the three it will it will call the service center MCP tool to book a slot
[12:54] based on the driver preferences. Obviously, this won't happen in a single conversation. It would take some multi-turn conversation to happen, right? And the fourth part is the Brixy sends the again when all the
[13:07] slot booking happens, right? Then the Brixy will send the voice response back to the front end and Brixy will give the output to the particular driver that here I booked a appointment for the servicing, right?
[13:19] So, this is for the diagnostic and safety. Similarly for the hyper personalization that I showed you like we made a dashboard for you to show like similarly if uh Ali says that hey I'm feeling a little
[13:32] warmer like little warmer is very non-trivial command right I'm feeling a little warmer so the Brexly should know first of all that hey what was the temperature before and how does he prefer and similarly the front end sends
[13:46] the request to the Brexly it will call the MCP server to reduce the temperature to 90 degree the temperature will get reduced and the output will be sent response back to the driver
[13:58] right >> Do you have this app on your phone? >> Okay. Okay so given the time constant that we have and I just wanted to describe that how we
[14:11] have kind of enabled talking to is like we we have made a mobile app which was getting shown in the video where it's interacting with a voice assistant directly via via voice right and all the all the
[14:25] fields are basically the sensors that we have and that sensors are all the sensors telemetry data is getting ingested into the data bricks right Okay can I go now?
[14:37] No no worries no worries. So all the telemetry data is getting ingested directly from the data bricks and the the AI is where the data in the data bricks we the Brexly is where it's sitting in the data bricks and
[14:52] all the ingestion after the ingestion happens we all the there is a data pipeline which is kind of taking the bronze silver and the gold medallion architecture on top of that we have
[15:04] we have kept the genie where it's whenever you want to converse with the structured data set genie is one of the sub agent that is helping the Brexly to answer the questions and then
[15:16] there is also the lake base part in the lake base part we have stored all the short term preferences then the long-term preferences, which is kind of helping a driver to interact during the converse. And we
[15:29] have also shown shown a functionality where you can directly converse to book appointment. And whenever you book appointment, you can directly in the portal you will obviously see all the different slots available for a
[15:42] particular region. And that slot will be booked directly when you converse with the bot. So, we have we I'm we are kind of open sourcing this whole framework, right? And this whole
[15:54] for code functionality will be available in GitHub as well. So, please do ping me in case you require any help and happy to help on these things. Thank you.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.