Inventory AI at scale: chatbots, simulations, and agents on Databricks

Summary

Hilton Grand Vacations built an AI-powered inventory platform on the Databricks Data and AI platform using chatbots for intent harvesting, what-if simulations for impact analysis, and multi-agent workflows for autonomous optimization across hundreds of resorts.
The platform, nicknamed Doctor Strange, moved decision velocity from days to hours by enabling human-supervised autonomous optimization with built-in guardrails and approval workflows.
Observability and intent tracking were built into the agent-driven workflows to establish the enterprise trust needed for operators to rely on autonomous recommendations in a complex timeshare business.

Inventory AI at scale: chatbots, simulations, and agents on Databricks

Building AI systems for complex supply chain decisions requires solving both the technical data problem and the decision-making workflow. At Hilton Grand Vacations, managing thousands of inventory decisions across hundreds of resorts, constrained by intricate business rules and revenue streams, demanded a new approach beyond traditional dashboards and BI tools.
This talk explores how HGV built an AI-powered inventory platform on Databricks using chatbots for intent harvesting, what-if simulations for impact analysis, and multi-agent workflows for autonomous optimization. Learn how they evolved from prototype tools to production systems with human guardrails, achieved decision velocity gains by moving from days to hours, and built observability into agent-driven workflows for enterprise trust.
🤝

Chapters

FAQs

What is the inventory challenge at Hilton Grand Vacations?

Hilton Grand Vacations manages thousands of inventory decisions daily across hundreds of resorts, constrained by complex timeshare business rules, lockoff units, multiple revenue streams, and yield groups. The prior process was highly labor intensive, relying on dashboards, spreadsheets, and email to coordinate decisions that could span many resorts simultaneously.

How does the chatbot for intent harvesting work in the HGV AI platform?

The chatbot was the first phase of the solution, capturing business intent from inventory managers through conversational interfaces rather than forms or tickets. Analysis of chatbot interactions revealed patterns that informed what-if simulation use cases and shaped the design of later agent-driven workflows.

What is Doctor Strange in the context of HGV's AI platform?

Doctor Strange is the name HGV gave to their multi-what-if agentic system, which runs multiple inventory scenarios simultaneously to identify optimal outcomes. The system operates with human guardrails and approval workflows to ensure that autonomous decisions can be reviewed and overridden by operators.

How does HGV ensure trust in autonomous AI-driven inventory decisions?

HGV built observability and intent tracking directly into their agent workflows so that every automated decision is explainable and auditable. Human approval gates ensure operators review high-impact recommendations, which was a key factor in driving adoption across the organization over a three-year journey.

Full transcript

[00:08] Well, hello everybody. Uh, my name is Igni. Uh, I lead AI at Hilton Ground Vocations. I do all the things AI, you know, agents, chats, boys and everything. Throughout this talk, I'm going to talk about how we solved uh, inventory problem for uh, Hilton Grant Vocations. Uh, and um, this is not going
[00:26] to be a sales pitch. This is not going to be about dollars. It's not going to be about revenue or anything. This will be a pure engineering story and the sweat the team has put into it. And uh I hope you learned something on our mistakes and our successes.
[00:42] A little things about Hilton Grand Vacations. This is not a regular hospitality business. This is a time share company. So our owners and club members they uh own the rights the li um to the um rooms and weeks uh they own
[01:00] inventories yielded in multiple dimensions uh we have uh a lot of resorts uh a lot of partners and this is a very complicated operational business from the within it itself I'll have you six story uh six acts in
[01:16] the story uh describe you the problem. I'll describe uh how we started, what we went through and in the end of it you will learn uh why we called the doctor inventory strange as a solution. Let's start with the problem
[01:33] uh inventory. There are resorts, there are rooms, there are nights um and we have to operate them. we have to uh make sure that the rooms are busy, make
[01:48] sure that the rooms are available to our members. So the daily ritual weekly or monthly or anything is go to your lovely open uh PowerBI, open the dashboard, open the Excel spre sheet, compare to everything, email somebody, review
[02:05] something, create another spreadsheet and everything and everything. We do have demand models. We do have machine learning stuff, but it's not widely used uh yet. Well, back in the day, now it's obviously used uh heavily. It's all uh
[02:21] very labor intensive. And if you think that labor intensive like on one resort, well, we have many. We have uh hundreds of resorts. All of those resorts are separated into yield groups. There are 10 of tens of those.
[02:36] There are segments. It's all a very very big configuration mess in terms of the how the rooms are being occupied and how been sold and everything. The lovely uh situation on the time share business is a lockoff units where we have
[02:51] combination of units combined together and you can book uh several of them. There are multiple revenue streams. It's not just members uh it's uh other folks. they can book up to a year in future and we have to hold that liability and make
[03:08] sure it actually works. So with all on top of this mass there are thousands and thousands of business rules which govern this whole thing uh of uh what is allowed and what is not. I'm sure everybody has a BI solution of your kind. I'm sure you know that statement.
[03:25] You have hundreds of reports, hundreds of dashboards, hundreds of CSVs and none of them actually answer the question of the day. I'm sure a typical story for all of us. So how did we solve it? Uh we started uh early about like three years ago
[03:41] migrating from a legacy systems to data bricks. We started using data bricks. We ported all our data to data bricks. We started with a medallion architecture. Uh we ported all the machine learning models to it and started you know data
[03:56] bricks and then more data bricks. The reference architecture is very familiar to everybody. Uh we have data sources. We all organize them in a big data lake with a fancy silver and gold layers. We build a bunch of uh ML flow on top. We
[04:12] build machine learning models which are using all this data. All amazing, all typical. Everybody has it. Uh if you've been in data bricks for more than a year, it's great that we've built six platform uh six uh machine learning models and not just one. But all of that has to be
[04:30] maintained, has to be operationalized. Uh so each model uh leaves its own life cycle. Uh each model is drift detected. It's all automated. Our data scientists do not babysit this. They only get an alert when something drifted. Uh with a
[04:46] new model version to be, you know, allowed or rejected to be pushed to production. Six models sounds not that much. However, they predict a lot of demand. uh about a lot of constellations, a lot of well things which matter for
[05:01] operationalizing the inventory so that the rooms are full six models again. However, they predicted one very important thing and the most important thing is they actually not used heavily which was a funny revelation uh to us in the middle
[05:18] of this journey that you can just uh you know you can add more models if they produce only a dashboard of a kind or if they produce only a graph of something this is just more data points we don't need more data points was there feedback
[05:33] from our customers from our internal customers I mean we need decisions So how do we get to that uh in terms of solutioning to decisions rather than just more data. Uh the solutions uh started simple.
[05:49] Everybody adds a chatbot. We are not different. We started with a chatbot. However, the chatbot question was not your typical you know talk to your data chatbot. Let's ask a question to your model. Let's ask the question to your current availability of a particular
[06:05] resort or something. Yes. All that was supported. The key feature was actually logging everything. So we logged all the questions. We uh accumulated all of that. And the most important thing was the intent of the questions. So
[06:23] people ask me quite often, why do you even build chatbots nowadays yourself? Why not just use something out of the box copilot of the world gen or anything? Well, that's the reason we need to know what people actually do with a chatbot and what they ask inside of it and why they ask it because that's
[06:41] the important thing, right? What they what problem are people are trying to solve. We get lucky here because we got a business buy in because usually when you get a chatbot and it doesn't work and it doesn't answer your question, well, customer gets frustrated. Again, we got lucky. Our business partner said
[06:58] we're fine with that. that our your chat chatbot is not answering the question right away. We're happy with that. It's fine. We will teach your chatbot to answer our questions. After the chatbot, it's immediately you know because we have the dashboard
[07:14] problem. We have hundreds of report problem. Everybody goes to create your own dash dashboard route. So did we. So aside from the chatbot, we created a you know create your own dashboard in the chatbot so that you can ask whatever the
[07:29] data point you want right now without actually you know looking into those reports. And yes we were the crazy people who allowed AI to write code for itself and run it in production for
[07:44] itself. And that actually did pay out because you know all the you know dashboards and all the plots and all the graphs we're on the fly right away in the chatbot instead of looking into those dashboards you just get the answer right away directly. How did it help us?
[08:00] Very simply during this journey while the chatbot was there and you think that your data model is ready your golden layer is great. Well no we actually just acquired a company during that phase. Obviously their data was not moved into ours. Obviously it was dirty. It was you
[08:17] know bronze layer only. So this thing worked and on top of the bronze layer we just let it uh actually you know before the whole data set was you know you know ported to the medallion thing. So if
[08:32] you're afraid of running AI code in production that's fine. Just do the guardrails and it will be all right. it actually is possible. During that thing, out of the chat bots, out of the questions, out of the intents we discussed, we found a problem uh that
[08:48] people were always asking, you know, the good old disk defragmentation from the past. It's the same problem for inventory. We do have some rooms which are sometimes there just sitting at their idle and not bookable just because not they're you
[09:05] know that they're not bookable because they're busy but they're not bookable because the rules are messed up or something is messed up in the data and they're just not visible to anybody. They're sitting there and just burning. So we found that and we built a very good old school you know disk diff fragmentation utility on top of that
[09:22] which applied to inventory and it you know believe me or not paid off for the entire MVP. So it's not the chatbot which paid off the MVP. It's not the tuck to your data. It's not the medallion. It's actually the use cases we've harvested out of the chatbot which paid it off for the entire MVP. So when
[09:39] you guys start building something ask yourself what is your MVP? what is your business getting out of it and make sure that it's actually you know solve the problem for the kind it's all great you have chatbot you have
[09:55] you know dashboards you have answers but they answer the question which you didn't ask they ask ask uh the questions you usually ask is what will happen if I make a change in the system so they only give the current situation in a chat in
[10:11] a dashboards gives a snapshot of now but it doesn't give the impact of a change. So we decided to do a what if simulation like what if I make some changes in the inventory. What if I will move 100 rooms from left to the right. What if will
[10:27] happen and tell me more. So if you can draw me a dashboard of the current situation well tell me the dashboard of the impact. Tell me what happened when I move 100 rooms from left to the right. What if is great. It actually you know
[10:43] our customers loved it because they could simulate the impact of their changes and that's a daily operation for hundreds of people there on operation side. However, what if has a flaw. What if is a question which you already thought about asking. You know what
[10:58] you're asking. You know the intent but how many times you actually know what to ask very infrequently. Right? So it's basically became a validation tool rather than the ask tool. But we went further. We said, you know what? If you can't simulate one what if, how about
[11:15] doing many what ifs, let's go all of it, basically. And let the machine do the crunch. Let the machine do all those questions in some guardrail fashion, obviously. Uh, and ask all of that at the same time and give you one answer or
[11:32] many answers. I hope you you see where it's going, right? you know like from one question to many questions and a lot of questions and that's why we call it documentary strange all those questions are in future all those questions are simulating the impacts of all the
[11:48] changes for each yield group for each resort for each unit type for each membership you name it has four levels so we what we did is out of one simulation we generate thousands of those we have multiple layers And the
[12:05] layer four is where we are right now. It's basically a you know a mission control center which is presented not you with a dashboard of a kind like oh if you move 100 rooms to here you will earn 500 bucks or something like that. It just gives you the full picture of what's going on at a region resort or
[12:21] anything like that. The consumption of this is not a chatbot. The consumption of this is CTA driven you know mission control. And I stole it from my past from a security space. Who ever been in security space? They know what security operations
[12:37] center is. We build the same thing for inventory, you know, mission control center. It has multiple nodes. It it it multiple perspectives. I would say sometimes you care about the burn. Burn is how many rooms actually you know go
[12:53] sit idle. Sometimes you care about the pace, sometimes you care about availability, sometimes care you care about marketing. Those questions change every day. That's why the dashboard is, you know, has perspectives. The customer feedback again from the
[13:08] chatbot from the intent detection. We didn't even knew that they we wanted it. When we simulate things, let's add a knob. How much we want to simulate? Do we want to simulate aggressively? Do we want to simulate marketing situation? Do we want to
[13:24] simulate this or that? all through the very basic intuitive you know like drag and drop kind of dial in a in the UI and then you click the button wait a little bit and you get your answer why it is hard you may say you're
[13:41] getting let's just like 200 resorts thousands of rooms it's not really complicated why why why hard actually it is hard because if you look at the bookable window of you know a year in the future and all those permutations and compute powers necessary to you know
[13:59] review it all if you do the brute force that's like an NP hard problem do I claim that we solve an NP hard problem no of course no what we did is we actually pruned the tree we prune the states so heavily that it actually can
[14:14] run overnight uh I show you the previous picture yeah thousands of agents doing this overnight because uh we can use a machine learning model predictions for demand as our oracle as our validation. I mean
[14:29] does this move actually make sense of any kind. So you may ask this is just a regular workflow you know make a chrome job run thousand jobs overnight call it a day why why it's so hard well uh we decided
[14:47] to do it slightly differently we decided to do it with agents for one particular reason like as I said the questions change all the time you don't know what they answer the questions so building a workflow for questions which you don't know pretty much an impossible task so we decided at fluidity versus just you
[15:05] know like hard coding this whole thing. One of the daily use cases from our customers was I have 100,000 rooms. I have 90,000 rooms. I didn't know what to do with them, right? You know, tell me AI, where should I place them in a particular
[15:22] yield group, in a particular segment? How do I effectively, you know, sell it better? Basically, right? Can you build such a workflow? No. Right? It's only the agent can answer it and use it with all those demand predictions and uh uh some guard rails.
[15:39] The crew and the workflow is bounded. We obviously didn't allow it to go crazy. It has guardrails. It has a scratch pad idea where it basically says I mean you are allowed to let's say overcompensate things in marketing for this particular
[15:56] resort or not. And you may find on the picture a funny kind of thing. I don't know how many people use it. There's always a human in the loop. You know in any AI talk there is always human in the loop. Human in the loop here human in loop there. That's the weakest point of the any solution because humans are well
[16:13] it's your slowest you know element in the system. So we decided to do it slightly differently. We decided human as a tool so that the actually confirms all those actions from the user and user logs in in the morning or you know during a day sees its dashboard sees its queue clicks yes approve reject or
[16:30] something and then that's how it's going to you know be used. Under the hood, it has the knob which runs through every agent prompt. Uh under the hood, it has a scratch pad. Again, I have no idea
[16:46] that there is some other data which you know is in the human minds because not everything is recorded in your data set and will never be again. There is tribal knowledge which has to be collected which has to be applied every time and it has to be put in a scratch pad.
[17:06] Every Y solution talks about observability. Oh, we want to cost control it or we want to make sure that our agents don't go off the rails or we want to make sure that our agents, you know, are doing the right thing. All true. I mean business for many many years. All true, very
[17:22] important topics. However, I want to keep your attention on one thing. Collect the intent for all the agents. Basically, not just observe the cost, not just observe the compute. Don't observe their kind of dry run or anything. Observe what they are doing and actually collect it back to again
[17:39] from intent perspective. What a user is asking the agents to do and present it back to um uh you know the operator basically right uh with that uh I'll go you with the
[17:54] adoption. So this was a long journey this was multiple years. So we had a year of data cleansing. We had a you know basically you know the boring part. It was no fleshy demos nothing just you know grint basically making all this data available to AI in data bricks.
[18:12] Then we went to the CI uh CIO dashboards. We built all the dashboards and everything. It's another year. Then the Doctor Strange which is another year. So it all was a three-year journey. So what worked? workflows only workflows only
[18:28] harvesting. So what didn't work? Don't sell AI as a timesaver. This is not a timesaver actually. It just makes you more effective to solve different problems. We always observe that oh I
[18:44] mean I could do more with this. I've never seen any anybody who actually does less with AI. It's always more. We were too forward. A lot of those tools were prototypes which we're you know we're constantly doing it with business and checking with them and
[19:00] everything. There was too much forward I would say. Uh what I mean by this is always prepare the you know the backup plan. Always have a boring part of the story. Always have something which is operational in the end which comes to
[19:16] production. Not just a prototype or like oh a flashy demo but something which runs in the end. um do everything AI. I'm sure everybody um you know who does the chatbots or talk to my data AI kind of chatbots, you
[19:32] connect to the database and you think that it will solve a problem. No, it will not. Chatbot is not the means. Uh it's not even a solution. It's just again a harvesting tool. Um any AI story requires some return on
[19:47] investment. As I said, not the chatbot paid for the MVP. Uh, not anything. The boring part out of the chatbot paid for everything else in AI and our operations and our, you know, basically engineering costs. From a Roy
[20:04] perspective, everybody's like, "Oh, okay. How much money did you guys make?" I promise you no dollars. I don't have dollars here on purpose. It's a percentages or something like that. in our business in our you know scale half a percent of impact is a lot of money so
[20:19] that's our KPIs the key point of the again the Roy was a decisioning and the velocity of the decisioning because before you can imagine with hundreds of reports hundreds of dashboards this whole workflow of you know do I make this change or not took time now it
[20:37] takes you know hours basically instead of days the decision velocity was our number one uh return on investment and uh we will not come back and that's the reason not just from the engineering standpoint of view it's from the business perspective the the business
[20:55] now cannot operate with this whole thing they all like it in terms of I can just go into the product ask the question simulate the change of I want what I want get an answer within a minute of like what will happen if I do this or that click approve reject done instead
[21:11] of all the days and you know green work of dashboards and uh reports what we learned data. So any AI solution will say oh we need just more AI more LLMs better LLM more agents none of it you need more
[21:29] data actually generated through the lens of this project so whatever data you have is just not enough just generate more and you know rinse and repeat uh back to itself failures are very important the I mean
[21:44] what I said is like about the forward deployed engineering is the more failures you have the better you are. Just make sure that those failures are recoverable. Adoption is great. Everybody talks about adoption. I don't know. We measure
[22:00] adoption in percentage of people using AI. We stop doing that because I mean people use it sometimes, very often, sometimes not. Most important stuff is is it operational? Is it part of your workflow? Is it doing it well or not? And a few things to take home is the AI
[22:17] solutions, the chatbots, you know, dashboards, agents, it's a UX problem. It's not about how how cool your UI is. It's not how cool your AI is. It's not how much money it actually brings. Is it are your users are actually using it? Is
[22:34] it usable to them? Is it solving their problem or not? And the last but not the least is obviously workflow first. With that, I hope you learned something uh from how we do it. I know it was very high level on purpose. Uh and with that,
[22:50] thank you very much.

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.