Building an AI Database for Agentic GTM Operations on Databricks

Summary

Rippling's 2,000+ GTM operators were spending time building data pipelines instead of selling, so the Growth Engineering team built GTMEI, an AI database on Databricks combining declarative Spark pipelines, ML-based entity resolution, and Vector Search to power personalized agentic operations across sales, marketing, and RevOps.
Key technical innovations include a DRYE (Do not Repeat Yourself Embeddings) approach that avoids redundant embedding generation, ML-based deduplication for entity resolution at scale, and Growth OS agents—general purpose, analytics, and engagement types—that use the Genie API for natural language data queries.
The platform delivered a 33% lift in demos booked and a 20% lift in pipeline opportunities, demonstrating how a unified AI database enables GTM teams to scale agentic workflows without requiring every operator to be a data engineer.

Building an AI Database for Agentic GTM Operations on Databricks

Rippling's 2,000+ GTM operators previously needed to build data pipelines themselves for insights. Traditional warehouses failed at combining heterogeneous sources, maintaining entity resolution at scale, and cost-effectively handling LLM workloads. The company needed a unified, AI-first database powering personalized, agentic operations across sales, marketing, RevOps, and customer success.
Rippling built GTMEI, a production AI database on Databricks combining declarative Spark pipelines, ML-based entity resolution, Vector Search for semantic retrieval, and Growth OS agents. Learn key principles: avoiding redundant embeddings, incremental processing, and data interoperability. See business results: 33% lift in demos booked, 20% lift in opportunities, and massive TAM expansion through LLM-powered workflows.
🤝

Chapters

FAQs

What is GTMEI and what problem does it solve at Rippling?

GTMEI is Rippling's AI database built on Databricks that unifies heterogeneous GTM data sources, resolves entities at scale, and powers agentic workflows for sales, marketing, RevOps, and customer success. It eliminates the need for individual GTM operators to write SQL queries or build data pipelines themselves just to understand their book of business.

How does Rippling handle entity resolution across multiple data sources?

Rippling uses ML-based deduplication to resolve entities such as companies and contacts that appear differently across multiple source systems. Rather than relying on deterministic ID matching, the model identifies records that refer to the same real-world entity even when field values vary, maintaining a clean unified view at scale.

What is the DRYE approach and why did Rippling implement it?

DRYE stands for Do not Repeat Yourself Embeddings and addresses the problem of multiple workloads independently generating embeddings for the same underlying data. By centralizing embedding generation and reusing vectors across Vector Search and other consumers, Rippling avoids redundant compute costs and ensures consistent semantic representations across all agents.

What business results did GTMEI deliver for Rippling?

GTMEI delivered a 33% lift in demos booked and a 20% lift in pipeline opportunities. These results came from Growth OS agents using the unified AI database to surface the right accounts at the right time with personalized context, replacing the manual SQL-based book-building that account executives previously relied on.

Full transcript

[00:08] Well, good morning everybody. Uh, welcome to another fun day here at uh, data and AI summit uh, led by uh, data bricks. Uh, my name is John Coutay uh, head of growth engineering here at Ripling where I'll be talking about building an AI database for Agentic GTM
[00:26] operations. Uh this is actually my second time speaking here at data and AI summit. Uh in a past life I was up here uh with uh American Airlines and stream talking about how we were uh transforming their aircraft operations
[00:41] to run in real time with the data lake uh and an early version of a AI database in my opinion but now uh we're basically looking at how we can apply this architecture to a new uh domain which is uh GTM operations. So excited to to jump
[00:58] into that. Uh so just quick forward-looking statement uh disclaimer that I'll put up in front of you. You can all read this on your own time. But uh what we really wanted to get to so like but when we were getting into the uh AI database like first we had to
[01:15] align on like the goal the vision what we actually wanted for uh for Ripling. So, first we really have to look at Ripley's mission, which is to free smart people to work on hard problems. And we essentially wanted the same for our GTM
[01:30] team uh of close to 2,000 operators. So, what we set out to build was something that was definitely ambitious at the time. Uh I'll get into our legacy architecture and also some dynamics with Ripling. Uh so Ripling, you know, we
[01:47] recently passed uh a billion dollars in ARR uh you know, on the heels of our new AI product. Um a year ago, the AI product was not out yet. Uh but we knew that the company had extremely uh ambitious goals, uh you know, from our
[02:04] executive leadership, uh and a lot of urgency to execute. Uh and this went all the way from leadership down to every single IC. Uh so at a company like Ripling, we're a platform, we're multi-product, we have uh tons of rules of engagement uh for doing go to market.
[02:21] And we looked around, we realized that wow, uh account executives, marketers, SDRs, uh with the current stack, they basically all have to be really good data engineers. They have to write SQL queries to build their uh their books and like prioritize what they're working on. Uh they had to be able to do data
[02:38] ingestion from different sources. Uh and our question was like okay are people going to be selling or people going to be building data pipelines. So our our job here in growth engineering was to basically say hey we're going to automate these tasks uh you know we're going to automate uh SQL analysis data
[02:53] ingestion signals collection uh and we're also going to automate the analysis meaning if they ask questions like hey you know we ran a Super Bowl ad uh in January 2026 how did that actually impact we know we got a lot of views there but how did that impact downfunnel
[03:10] metrics? Uh so we really wanted to build out this source of one source of truth that uh over a thousand GTM operators could rely on to do their jobs and they all very uh unique uh critical jobs with different roles and access to data. Uh
[03:26] so all of that was was a very ambitious plan at the time and I'll I'll I'll tell you why. First looking at our legacy data stack. Now if you look at this I think in in in 2017 2018 maybe this was considered the the modern data stack uh
[03:42] going left to right uh when you look at batchbased ingestion from your CRM your marketing tools uh your website uh run it through some uh orchestrators uh have transformation jobs that are
[03:57] scheduled through uh tools like dbt run on a legacy cloud uh data warehouse and really that was uh you know again I think if you looked at this uh you know uh close to 10 years ago this was famously coined the modern data stack
[04:14] but for our our use cases and demands around uh AI on near real-time data this was actually holding us back and I'll tell you why um fragile fragile scheduling across multiple code bases and code paths one logical job had to
[04:30] actually be written across uh your your orchestrator your scheduleuler or uh uh transformation tool uh you had to track lineage in the warehouse with with separate queries there uh data ingestion uh was through a mix of SAS tools and
[04:48] in-house solutions uh and all the AI use cases that we were looking into at the time even basic ones you know which I consider just LLM pure LLM based summer was quite uh uh expensive and slow and
[05:03] and didn't really meet our SLAs's. Uh so setting a bit of context there. So I'm just going to jump to the platform we ended up building. Uh so when we look at our GTMAI platform, again we're going left to right. So uh a lot of the the
[05:18] traditional principles still stand. Uh but what you see here is the medallion architecture powered by uh you know what we built out as declarative essentially declarative spark jobs for ETL ingestion summarization classification
[05:35] uh models that were trained to do entity resolution uh and this gave us the uh low-level components that we needed uh to really have control across things like uh uh incrementalization of data processing uh
[05:52] tight control around data delivery SLAs's if we wanted to go before you know our our data delivery SLAs's were somewhere in the order of 24 hours we didn't really have a good answer uh if we were pressed and usually just avoided having that conversation uh now with this current stack uh you can see
[06:09] exactly in the code uh in one line what the endtoend data delivery SLA is because we've essentially unified this all through one uh mono repo uh even though we're still going across multiple layers of compute but we unified the data ingestion the processing modeling
[06:26] uh into the data bricks lakehouse. So again going from left to right we have our data sources which are still pulled from SAS uh tools but also in-house solutions um and the data ingestion you know one of the biggest biggest changes we made is
[06:43] focusing on change data capture so relying on uh both CDC for data ingestion uh from upsource relational sources but also once we're in Delta Lake the fact that we have a uh essentially a CDC API over bronze and
[06:59] intermediate tables with the change data feed exposed allow us to uh both optimize our costs and optimize our data delivery. Uh so I'll get into each one of these components and the use cases and and where the data is eventually served to users. Um but you can see this
[07:15] is this is definitely uh uh very much you know it's it's one GTMai platform but support supports lots of different ways of data ingestion uh also hybrid retrieval and most importantly agentic workloads that are both human triggered
[07:30] and uh completely automated. Uh so I'll get into the Genie API and where this data is ultimately served. Here's a quick preview of the user interface that we built internally which is called growth OS. um using uh our AI platform
[07:46] as the the back end. Uh I'll I'll get into the details of the UI here. Uh but this is an internal uh application that we have over 2,000 users uh interfacing with the agents that are uh using the GTMEI database as its backend.
[08:03] So I think it was close to a year ago now. Uh we had an extremely basic use case. We were like, "Hey, how do we start throwing LM at our data?" That's that's kind of seems like a low hanging fruit, pretty obvious to do. Um, with our legacy data warehouse, uh, we immediately ran into some issues there,
[08:20] mainly on cost and latency, uh, and, you know, access to to latest greatest models. Uh, the legacy warehouse fell short on some of these work workloads. Just uh, straight up same same data set, same LLM prompt, uh, similar open source
[08:37] model. it was still much higher cost to use this legacy warehouse uh slower end processing uh and you know I think there were some architectural limits that we ran into where the inference was shipping out to a separate compute plane um with data bricks you know it was a
[08:53] no-brainer we were able to run this job uh significantly cheaper uh it was faster for end toend processing uh using our uh incremental uh streaming data processing uh and lower inference costs and just a simple declarative uh data
[09:10] processing interface there. Um so I've been talking about the infrastructure but you know what is the actual hard problem in GTM data. Uh it's figuring out what what's actually real. You get a lot of data in in GTM. Uh I
[09:25] like this slide. I think it demonstrates it well. uh if you if you look at pure uh persona based segmentation and pull all the data that a vendor will give you about a person where they try to classify certain parts of them and and you get to make a decision on how to how to personalize segment you know uh
[09:42] basically personalize your product offer to them um it's not going to give you reliable data right so if we actually look at this comparison right Prince Charles and and Aussie Osborne uh if you ask an enrichment vendor you know they're both male they're both born in,
[09:57] you know, 1948, raised in the UK, uh, married twice, uh, wealthy and famous, uh, but you probably wouldn't, uh, have the same conversation with them, and they probably have different interests. So, obviously, we're not selling to
[10:13] Prince Charles and Aussie Osborne, but uh, same problem stands. What we really want to do is identify compelling events in the market uh, with growth engineering. So, this is the left side of the architecture diagram. So we wanted freedom to basically pull data from any number of sources heterogeneous
[10:31] whether it was coming from a structured vendor API, whether we were scraping it from the web, whether we were doing change data capture from our CRM or internal databases um and distill that in a way that was easily uh consumed by the GTM operators
[10:46] however they want to do it. If it was a marketer, they could build large audiences for campaigns. uh if it was a seller, they knew how to sequence and personalize individual emails by doing all the data summarization on that person. Um both a mix of person level intent and company level intent. And
[11:04] when we say intent, we really mean like what is the actual business reason that they would want to start talking to Ripling, right? Because Ripling, we have the unified uh platform for people operations. People operations is quite broad. uh there's many many applications depending on you know what you're
[11:20] actually working on. So our job here in growth engineering is to make sure that we're saving our internal GTM operators times but also saving our customers time and thinking about the user experience for them where we're not wasting a breath right we know the second we start talking to them we're we're speaking
[11:35] their language we're offering them a consultative solution. Um so when it actually comes to the the the data pipelines here again going left to right we have the data ingestion from any number of heterogeneous sources. uh we we're using delta live tables uh with
[11:51] change to capture uh schema enforcement uh going bronze silver gold so on the bronze layer we just do the ingestion uh we've always focused on interoperability uh which I'll get into with iceberg and how we set that up on S3 uh and the
[12:09] entity resolution DDU normalization these are actually quite uh uh varied workloads depending on which data we're processing uh at a given time but the spark declarative interface did give us the control to do that uh and I'll get more
[12:25] into uh entity resolution uh which was another differentiator for um data bricks the way we're able to use the uh ML uh model management capabilities and data processing there to optimize it. So for an n-siz data set,
[12:43] you can have a brute force solution that's somewhere in the order of uh n square uh bigo where you basically go through and you're you're going to go through all the pairs in your data set and you're going to ask is this the same person, right? That's brute force, extremely slow, extremely inefficient.
[13:00] So what we actually went with uh was a mix of uh blocking and these uh comparisons. So there was a supervised learning step where through all our heterogeneous uh uh sources we're able to pull the data uh unify it on some
[13:16] basic blocking keys and do some uh uh labeling on whether it's a match or not a match and essentially training this uh regression model on which string matching algorithm works best uh for for
[13:32] that particular column. Um and in the end what we get is you know we might have several appearances of the same actual person across vendors and and and data that we ingest. What we really want is one golden record with a confidence
[13:47] score. Uh and over time we're continue to tune and measure the performance of our confidence score. And this again varies with with lots of data analysis because anytime you onboard um a new data set that we've either pulled from the web or a vendor uh there's work that
[14:03] we have to do around analysis. Uh some of the issues we ran into here was uh basically figuring out uh you know if we run this massive spark job on uh hundreds of millions of records for entity resolution what's the right way
[14:19] to partition the job we don't want to run into issues around uh partition skew. Uh ultimately this this this comes down to having uh uh very close awareness of the data. Uh and again this is where data bricks uh capabilities of
[14:35] building these notebooks where we can iterate and analyze data quickly uh allowed us to uh basically design our our uh spark jobs uh appropriately. We ultimately did run this through uh the uh prediction job uh and it is reliably
[14:51] able to uh ddup uh people across multiple vendors. And ultimately, you know, my main recommendation here is every time you're bringing on a new data set uh which may have uh some canonical matches in your existing data is always start with the
[15:07] data analysis like get get a notebook that goes through and tells you all the all the data distribution in your columns cardality because that's ultimately what's going to impact the performance of your job. uh then you can start getting into uh training your your
[15:23] ML models because especially if you're doing this at scale uh you need to know how to structure your pipelines first. So this is for the data ingestion into the lake. Um obvious next use case that we had to solve was semantic search at scale. uh with the rise of MCPs that
[15:43] could go directly on your warehouse, on your CRM, uh on your SAS tools, what we found out was and and and we leaned heavily into this at Rippling. We're very uh uh AI forward here and and and rapidly adopted this across thousands of internal um operators where yeah, we
[16:00] said, "Hey, take Claude uh take your uh uh LLM tool of choice. Let's hook up the MCPS. Let's experiment with it. And basically what we found was just tons of duplicate costs. Um because you can see if you if you uh directly hook up your
[16:17] uh LLM chat tool to your warehouse, you're going to recomputee your embeddings and remodel the data ad hoc based on what the question is. We found out very quickly that people generally have similar shaped questions. And there's really no reason for uh an LLM to reindex this data uh ad hoc every
[16:34] time someone's asking this question. Um, and I'll get into the exact cost savings here, but we we basically came up with a internal technical principle here, which was uh, you know, kind of like the DRRi, but dry with a E appended to it. Don't
[16:50] repeat your embeddings like model your data once for AI. Um, and essentially what we did there was build a uh a pipeline in in data bricks that ingested the data from all these sources. Uh I'll
[17:06] get into the exact model that we used uh on the next slide but uh we went through found all the business use cases right found all the right deterministic ways that users wanted to retrieve data and then the right fuzzy matching and made it a hybrid search using uh data bricks
[17:23] vector search product uh which we also rolled out uh to over a thousand internal users uh and it's able to handle the volume and scale but mainly you know what we're getting out of it is better quality results for their questions because you know if you did
[17:39] the equivalent with a LLM chat tool and and MCP directly on your warehouse all the deterministic filtering goes out the door right it's still going through it's it's basically computing every embeddings for everything trying to uh predict the next best token based based on these questions that really should be
[17:56] you know very uh boolean yes or no it should match or it should not match but you have that slight probabilistic risk that's going to give them the wrong answer. We basically solved that problem with uh data bricks uh vector search by coming up with the uh predicate
[18:12] filtering that we wanted to do up front. Uh we modeled the data based on that. Um we did use uh the uh data bricks uh gte model. Uh we had some eval where we compared it to multiple other models and uh it passed our quality uh benchmarks
[18:30] and and met our cost goals. Uh and we did find that uh when we were going through this uh building that pipeline on about two and a half years worth of data and and running the back fill and building out the index was actually less than you
[18:47] know one B2B SAS AI tools vendor costs doing the same job but this is obviously doing it in a much more reliable way. So significant cost chain uh savings going with that approach um and a lot more precision on the uh results that we're
[19:04] serving to our internal business users. Um so the other tip that I have there is we are using uh storage optimized uh vector search on data bricks uh which keeps the index colloc uh with the
[19:20] lakehouse. you're going to get better performance. Uh you're going to get faster results there as well and and and lower costs. Um that's ultimately ultimately what we experienced uh when we were rolling this out. Um so basically a mix of LLM based
[19:36] classification and summarization in the indexing process to come up with these tags uh some deterministic filters where someone says hey you know I want to get the sentiment uh of a customer that's in the retail vertical assigned to you know this account team uh tagged with this
[19:53] opportunity and you want to make sure that you know all these deterministic fields like uh the industry opportunity data uh segment etc are all just using filters and the ANN runs on the embeddings. Um the embeddings are also
[20:09] something that we self-manage. Uh so if you look at the the the actual table behind this uh you'll see you know a 1024 dimension uh array uh and that actually gives us uh portability which comes back to my original point about uh interoperability and flexibility that uh
[20:27] we support with our AI database uh allowing multiple consumers of this data you know with still supporting ANN and vector search uh no matter who is actually uh consuming this data for that particular application.
[20:42] Um, so great, we built a vector database and we want to roll it out to a GTM team. Um, you know, they're still going and using all their applications and you know, I'm just kind of sitting there in the corner saying, "Hey, you know, we have this great vector database. You know, why is no one using it?" Um, everyone's saying like, "Dude, we want
[20:58] agents. We don't want like a vector database." Which fair, that's a good it's it's hard to compare yourself to Claude and, you know, tell people to go log in and start running uh queries against a vector database. So how we solved that problem uh was growth OS. So growth OS was a userf facing application
[21:16] uh that users could get a uh uh native LLM chat experience with this data. Uh but but before going into reverse engineering you know chat LLM chat applications we really wanted to start out with like what are we actually getting at here with growth OS? What is
[21:33] the actual goal? Um, and the way we really see it was, you know, why do CRM exist? Why does data warehousing exist? Why does dimensional modeling exist? It really, you really just want one single source of truth, institutional knowledge and shared
[21:50] memory across thousands of people internally. You don't want everyone to have their own version of the report. You don't want everyone to have their own private spreadsheet. So we essentially wanted to roll this out at our internal scale where we have the shared GTM memory uh which you know includes accounts, contacts, plays um
[22:07] and business outcomes. Uh if we look at the next uh uh ring here in this concentric circle, you know, we have performance intelligence scoring uh prioritization uh that our data science team worked out uh uh worked on and and released uh to our
[22:24] sales or which basically scores and prioritizes accounts uh and feeds that feeds it to the sellers in a way that's actionable and prioritized for them. Um and then the next ring is really the people, right? We talk about the pipelines, but these pipelines don't matter if people don't use them. Uh so
[22:40] we really have uh uh the reason we're embedded so closely with the GTM organization is so uh we're obsessed with solving you know the problems of our internal customers across sales, marketing, revops, data science uh and making sure that we're really building the platform that's making them
[22:55] productive uh and infuse them into all their operations. So whether it's building uh audiences for campaigns uh whether it's doing classification on different segments whether it's you know getting the right messaging that's winning in the field from the customer's
[23:12] word of mouth that we get from gong transcripts all of that is embedded into their workflows with a unified chat application where they can just use the uh experiences that they're used to uh if we rolled if if we rolled these capabilities out into uh a a native chat
[23:30] tool. But really what we want to get at with the growth OS is, you know, our own harness, our own context store, uh something where we have lots of control and also optionality, right? Because I think we've all seen the news, you know,
[23:45] about, you know, the skyrocketing spend that we're seeing uh on uh LLM tools uh locking your entire business operation into one foundation model companies harness is extremely risky uh
[24:00] because you will find that you'll have to dedicate a massive ops team just to manage your MCPs, your connections, your marketplaces, your your your plugins and you have no ability to lift and shift, right? you've basically taken all your uh business logic, your data, your operations, and said, "Hey, we're we're
[24:17] betting on this one LM provider being really good partners to us, which so far, you know, I don't know if anyone's maybe maybe maybe there's some evidence of that, but what we really want to do is say, hey, we have the the the GPM AI database, uh, which is our data. We
[24:33] think it's our IP uh and also the open harness, uh, that fuses into our operations. So coming back to growth OS uh we have our general purpose uh AI assistant uh we have our analytics agents that our data science
[24:48] and analytics team uh uh rolled out and you know we have a a very sophisticated analytics operation data engineering operation at our company. We didn't want to build like yet a new uh system uh for for Texas SQL. We wanted to make sure that you know we were getting the
[25:04] compounding value of you know getting everyone's uh uh hard work into the system. And the third one is engage AI which is a specialized uh marketing uh specialized set of marketing agents. Uh if we actually look at this uh it'll
[25:21] probably look familiar. I mean it looks uh I think we've all converged on similar experiences for chat tools. Uh we used uh Verscell uh on the front end of this. Um and we basically rolled out
[25:36] uh personal level agent memory but also institutional knowledge tracking you know one source of truth for you know how people are using agents uh in GTM operations. This is what's hooked into our GTM AI database. So use cases like hey you know I want to do data analytics
[25:53] uh I want to do enrichment. I want to come up with an account plan. Uh I want to get alignment uh across team members by building a new presentation or deck uh that I can easily share with them. All the all this was built in a growth OS uh into our general purpose agent. So
[26:10] looking back at our architecture here, I'm really focusing on the right side now, which is like the data consumption and and and how people are actually uh uh uh using this data with AI agents to automate their tasks. And um a big
[26:26] component of this is Genie. Uh so we're using the Genie API for uh a lot of our reply classification workloads and analytics. Uh, Genie is nice because it uh it gives you both a a workspace where you can go in and uh test the uh the LM
[26:46] experience yourself. Uh gives you great auditing and reporting on what kind of questions are being asked and it lets you serve this via API uh which is great because you know I think again I keep talking about interoperability, flexibility, optionality. Uh Genie API
[27:02] does actually give you the ability to do that. Uh so like I said we had our front end uh hook into Genie API and then a mix of other uh uh Texas SQL analytical systems. Uh I also want to share our uh engage
[27:18] agent which is uh another very uh uh impressive technical feat here uh where marketers could basically chat with this to build rich audiences uh uh multivaried audiences uh across different verticals uh personas
[27:34] uh account segments uh any way you could slice and dice this data. Now marketers have a way to do this and we also track and maintain all the campaign metadata uh for analytics purposes. This is all streamed into our AI database and data
[27:50] lake and data bricks where we can do ad hoc analysis on uh campaign performance also using tools like Genie but also the uh uh vector search on uh email reply classification and uh getting sentiment from our our
[28:06] actual performance there because ultimately like what we want to do is make a great experience for our customers the minute we start talking to them. uh if they feel like we're spamming them or we're hitting them with messaging that's not valuable uh we're not doing a good job as a goto market organization. So now with this we have full visibility into both the sentiment
[28:24] and also the way we're segmenting and personalizing uh for our uh uh prospective customers. Uh four principles we choose again this is actually three. I don't know why I said four. Um maybe I'll come up with a
[28:40] fourth one on the spot. Uh the first one is uh dr don't repeat your embeddings. Um I think this is just uh another case of what's uh uh old is new again in data modeling. If you know that people are going to ask similar questions over and
[28:56] over again, you should premputee and model that data. The same goes for AI agents. uh you'll see a lot of these questions have similar shapes and you want to push this down to uh ANN uh or cosine similarity or just operations that are more efficient uh and more
[29:13] deterministic for retrieval in these use cases. Uh the other one is incremental processing especially when you have LLM based uh classification summarization workloads. Um you don't want it to drop and uh reload and and resummarize all
[29:30] your data on every turn. Um you also want to optimize processing and performance as much as you possibly can. Um so all the features in data bricks around change data feed and delta lake uh being able to manage your own uh monotonically increasing sequencing
[29:45] keys. um I consider that very table stakes for these uh a IML uh data ingestion pipelines um data interoperability uh so one of the things I didn't touch on too much but it's in the architecture diagram is we use Delta Lake with
[30:02] compatibility mode which is essentially metadata exchange with iceberg we have uh our our data engineering team uh maintains an excellent uh iceberg implementation uh on AWS and anything that We maintain in delta
[30:18] uh tables of compatibility mode is queryable in other iceberg uh compatible uh data warehouses and compute engines. Uh even though you know this team's uh uh heavily deployed in data bricks we still have many uh stakeholders that are
[30:33] using different uh warehouses and compute engines to retrieve this data. We basically wanted to model and serve the data once uh and then uh I'm sorry we wanted to model the data once and and serve it anywhere across different uh consumers. So interoperability interoperability gave us the uh
[30:49] flexibility to do that and also the uh API based interfaces for AI that data bricks serves is also extremely valuable. Um and we we definitely went in this uh as the default uh not an afterthought. uh did a little work. It
[31:05] required a little bit of uh iteration to ensure that uh interoperability was working across each consumer as expected. Um which ultimately did require a bit of testing and a bit of uh heartache to make sure that you know the data was actually able to be queried in
[31:22] these other engines. But ultimately uh with the right uh uh cataloges uh and the right uh permissions it it it effectively works uh quite well now. is a major part of our operations. Uh so getting into the results, uh we
[31:41] did stage some AB tests early in the in the process. I think this is actually back in December is when I pulled this. Um but with our new engine where we basically automated all the data collection uh uh summarization uh segmenting the right surfacing the
[31:56] right data for personalization with the system. We saw 33% lift in uh demo's book, 20% lift in opportunities. Um and with this we also have uh new uh massive TAM increase. Uh so really what we're
[32:13] doing with this uh data ingestion through these vendors is ultimately increasing our total addressable market and much cheaper sales plays. uh the cost to run these you know LLM enabled plays through you know a B2B uh you know sales tool is exorbitantly
[32:30] expensive. Uh when we looked at this we basically saw this is just basic you know compute and uh inference and and serving the data in a smart way not some thing that had to be abstracted by you know uh uh a rigid B2B SAS tool. Um so
[32:45] significant uh savings from vendor reduction there as well. Um yes and you know continue to work across sales ops uh data science growth marketing uh and you know with the the work that we're doing here in growth
[33:00] engineering uh what I really want to highlight is if you look at everything uh end to end right the the entire architecture uh one of the really the thing that we're most obsessed with is like the the internal users their goals their metrics
[33:16] um and I'm I'm going to if If you give me a follow on medium, I'm going to talk a bit about metrics trees and what we've done to actually correlate uh performance which each one of these agent operations and I think that's you know as we look into things like
[33:32] building loops and automated tasks and giving agents basically a goal and letting it operate uh autonomously to achieve that goal. We basically given it the right surfaces and layers of uh uh systems of action uh
[33:48] for agents with with our GTM operators really focusing on scale and having access to better data, better signals and um ultimately you know make a better experience for rippling customers because all our questions to them
[34:04] everything we're we're positioning for them is extremely valuable. I would pointed less you know upfront uh questions just to qualify and get basic uh uh questions answered on the use cases. So uh looking at this architecture end to
[34:21] end uh the the main places that we're looking to uh boost uh features is basically through uh enabling autonomous uh actions with with AI and I think that again starts with a strong data foundation and the right API layers for
[34:36] uh for action there. Hey, thank you so much everybody. I hope you all uh enjoy the rest of the show. Uh super exciting time to be here at Data and AI Summit. 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.