The Predictive Model Reshaping Retail Operations at Scale - with Chris Slovak of Unframe
The AI in Business Podcast · 13 Aug 2026
Source: https://podcast.emerj.com/the-predictive-model-reshaping-retail-operations-at-scale-with-chris-slovak-of-unframeai
Transcript: https://podcasts.opennash.com/shows/ai-in-business/the-predictive-model-reshaping-retail-operations-at-scale-with-chris-slovak-of-u-c8dfb1/ (via OpenNash Podcasts, machine-generated)

Welcome everyone to the Emerj AI in Business podcast. Today's guest is Chris Slovak, Global Field CTO at Unframe. Unframe builds secure AI native software that integrates directly with a company's existing systems, letting enterprises deploy custom AI solutions on their own data quickly. Chris joins us on today's episode to focus on how retailers move from isolated AI experiments to systems that handle inventory, promotions, and supply chain decisions in real workflows. He also outlines how modular components shorten deployment timelines and make it possible to update individual parts of the system as technology changes.

Today's episode is sponsored by Unframe. In this episode, we cover retail AI workflows. To go deep on AI topics and learn how retailers are using anomaly detection to flag fraudulent transactions in real time, download our free PDF report. AI in retail executive cheat sheet at Emerj dot com slash rcs one. That's m e r j dot com slash rcs and the number one. Now the conversation with Chris. Chris, welcome to the show.

Thank you, thanks for having me, appreciate it.

Uh, I'm excited about this episode. In the last episode in this series, we focused on why retail AI pilots fail and stall. It's often scattered data, brittle workflows, and no unified way to deploy. And Larissa walked us through how modular AI native architecture finally solves that problem. And she had that but beautiful picture of Lego blocks and how you've got these systems that you can choose from to accelerate the deployment. And that was great way of framing that.

So today we're moving past the pilot stage and into what happens when AI can actually run across promotions, inventory, supply chain, all of those retail problems. And I love the fact that we're speaking to you because you've seen this working and that's what we're interested in. So what is a core retail wide deployment model that lets AI move from isolated pilots into repeatable margin moving workflows?

I think the 1st thing we like to do is focus on a problem. Because often customers are so worried about getting data aggregated that they they don't get started. And so I think, you know, when we engage, the 1st thing is to identify where we could create value. Uh, often it's either dealing with if they're retailers, supply chain management, identifying where there's potentially, you know, latency in supply or logistics workflows, trying to forecast out trends in terms of what inventory needs to be.

Where, you know, obviously, like, if you start to break these things down, what you kind of get into is dealing with, like, inventory transfer costs and obviously working capital if you're talking about supply chain. But ultimately, it's what is the problem that can generate real value? Where? Where can we either increase revenues through having inventory where it should be, where it's going to be purchased, or creating cost savings, avoiding transfers or missed opportunities in sales? So it sort of matters.

What is the customer's problem? And then how do we fill in the gaps and get them from where they are today, regardless of where their technology lands or is what state it's in? And what they want to achieve, and how AI sort of fills that is the sort of always the question.

And I think we're seeing that across industries. There was a lot of focus on getting the right models and ensuring you choose the right model. And it's really a shift in thinking of. We are trying to solve real world problems within a specific business, so you really need to look at your own business. What are the pain points, what? What keeps coming up within your business as the easiest way to more money, happier customers? And what of all of your problems would be the easiest to solve?

Start there, and then when you start seeing the results, then build it up from there into the less obvious pain points. Is. Is that what I'm hearing from you?

well, I think you have a lot of people starting from a perspective of technology. And I would say that the biggest false workflow is to aggregate and fix and clean and create data models before you start solving problems. And so, you know, I I'll give you like a very tangible example of this, right? So two, three years ago, everybody purchased a modern data warehouse, whether it's a Databricks or a Snowflake. You built up on top of one of the hyperscalers like a fabric, like everybody had this like centralization motion of data.

And many, many, many companies are like, still like smack dab in these two year long cycles to migrate and import. And more, more like, finally, model their data. The whole idea there is, well, if I have all the data from all my sources of truth, quote unquote, and then I have it all modeled and it's all linked correctly. Then I can ask any question and get any answer. And then I can apply AI, cause the data is quote unquote clean and quality, then I'll apply the models to automate.

I think that we're thinking wrong. Agents and agentic systems in particular don't necessarily need one source of aggregated data truth. They can reason like a human can across multiple systems, so long as there's context and semantic linking. And so that sort of changes a sort of fundamental architecture decision, which right now is a massive blocker to starting to solve some of the core problems, right? So, like, let's break it down for retail, right? So you have ERPs and CRM, and then you have your point of sale systems, and they probably all semi talk.

But the truth is, state of order, supply inventory probably to some extent live a little bit in each. And so if you're trying to understand what product needs to be on the shelf at what store, and whether or not you can get it there. Or need to order more, need to split shipments, that problem is something that a human is probably doing in a spreadsheet today. So what do you do? Well, well, we're gonna move it all into Databricks and then we're gonna run a report that does that.

But that program is probably still twelve months out. We could build an agentic system that understands that it needs a component of information from ERP, a component of information for your CRM, a component of information for point of sale, a component of information from the warehouse. Bring those together in real time and make a decision. So, like, replace the thoughts of well, I need to centralize all my data with well. A human actually has to pull data from a bunch of places to do their job today.

To how do we make an agentic system that doesn't require the data to be centralized and can actually do the work that a human can in a fraction of the time?

So I'm going to ask you to bear with me because I'm envisioning this in a specific way and you'll fix me where I'm wrong. I'm thinking of a restaurant and the orders are in a system. Maybe it's just written down by the chef, the recipes are in the recipe book, and then you've got the manager who knows how many bookings there are for that evening. And all of this data is there. So you can either decide to get one laptop for the company and have all of those things.

Now you've got to ingest and type in all of your recipes, you've got to daily update what your fridge has, what your cupboards have. And then also the manager has to ensure that every time a booking comes in, it is putting it on that one laptop. That is one way to think about it. You've got all of that information there, and of course, then you can reference it and you can ask questions of it. That's fine.

Or you can rather have a real good manager of the entire restaurant, and he knows where the recipe book is. So if he needs, uh, to understand something about a recipe for that evening, it goes to the recipe book and it pulls what it needs. It goes to the fridge and checks whether all of the uh, products are in there, the ingredients, and then it can go back to the system that does all the bookings. It's all different system.

There is data there are very few industries, and especially retail, where there there's no data. The data is being captured. There's not really another way of doing business these days, it's being captured. It's thinking differently, not bringing all of the wonderful would be if it's all on one laptop, but that's not what agents need. They just need to understand how all of these data sets relate to each other, the context, and then know where to go find it.

And then obviously the governing, ensuring that it's not your waiter or the competition coming in and checking in on your recipes. So you need that governance and safety. Was that even close to understanding what this is about?

I think you're spot on. And what you're getting to, which is like one of the biggest risk factors in these types of systems, is adoption. So in your world, right, where you're talking about, like, it's all in the one laptop. That changes the chef's workflow, it changes the the staff's workflow, it changes the management, it changes how people do their jobs. Because they all have to gravitate towards this one thing. And then they have to adopt how they work to it, just so we can update it in a centralized place to then get an outcome.

Whereas that doesn't make a lot of sense. In fact, that that is in conflict to making people more efficient and generating value, um, in processes that exist. And so when you think about, and and I love your example, cause it's such a simplistic one, you know? But if you think about a more sophisticated situ situation where you have vertical and or horizontal based businesses that are trying to manufacture and deliver products to the shelves, they're very complex.

And there's a lot, a lot of different hands and a lot of different systems and a lot of different processes. So instead of forcing all that change to centralize, or hope that you can centralize, because in many cases it's a bridge to nowhere, instead, build your solutions to use the data where it lies and how it lies, and work to extract the information necessary for the agent to do the job that it's set to do. And like, this is a mind shift, and one that is not just the way you plan to build solutions, but it also is becoming more fundamental in that.

You're seeing the rise of mCPS and agent to agent communications. I got started in tech working on soap APIs at Yahoo, right? Super rigid, super documented, you know, APIs. And then that's given way to rest, which is a little bit more flexible, the programmatic web, if you will. I don't know that APIs are, I mean, they're gonna be there, right? Don't get me wrong, like APIs and programmatic working isn't like going away anytime soon. But are we gonna?

We're gonna get to a world where agents are other asking other agents on system to to give them information that they need. And allowing the agents on the verticalized systems to understand the context, the schemas and the meaning behind the question, just like a human would. This like radically changes how you think about building products. And also, if you believe that this is the future and the and the way in which things are moving, it really means that.

Leave the data where it is, in whatever format it is, only address inefficiencies in process where it really, really makes sense, and allow agentic systems to connect the dots to sort of bring together services and and drive to quicker outcomes. Like, are you like an inventory management solution? Instead of aggregating the data, let an agent go and pull what's necessary to answer a question, radical change in how you deal with data and workflows.

And that solves that stalling issue that Larissa sort of pointed out to us. Because in in the old way of thinking, at some point you're going to get stalled. Because something's not in place, something's not in the right format, something's not in the right storage. So this new way of thinking opens up scalable deployment. And also, as Larissa pointed out, it's modular, so whenever a new, because, let's say, you introduce a new product or a new system.

Now you have to remap all of that architecture, figure out, okay, how do I get this to talk to that? Whereas when you've got that intelligent system that knows what to find you, you just snap it in. I'm making it sound more easier than it is, but of course, snapping it in. And it's it's not reworking the architecture every time you introduce something new. So I'm really excited to to hear from what you've seen. Which retail use cases have delivered the clearest before and after transformation, and what measurable outcomes did those deployments produce?

What have you seen? That's been really interesting.

Yeah, so we built an inventory intelligence solution sort of on top of a customer's data set, using a hybrid of data, classic data extraction, modular components. We store the data in both, you know, relational as well as vector databases, so that we can do, you know, factual pull throughs. You know, what is the actual inventory I I have on hand? But also we created, you know, uh, more of a relational near neighbor type data set. So we can start to understand and break down per skew, per store, per size, and and start to rank things.

And so in doing this process and getting it up and running, the estimates that we have from the customers, we're saving them somewhere between forty and fifty thousand dollars in both time and data management costs. I mean, these are, this is significant, right? Not not only are they making great decisions and projecting out forty x ROIs, but the fact that they're like immediately saving this money. And it's tangible in time and cost of systems is pretty incredible.

And I think you hit on modularity is such a key thing, because maybe in my future world that doesn't really exist. So sometimes you are actually connecting and extracting data, but when you make these data extractions, like in your case of the the recipe book, could you take the recipe book and throw it in an LLM? And would it be able to process through and give you an answer? Probably, or would it make a lot more sense to tell a classic deep learning OCR model?

That's a fraction of the cost? Hey, look at this page and pull out the information that we need. And so when we think about modularity, it's what tool for this? Step of data processing makes the most sense from an efficiency, quality and cost perspective. And guess what? Maybe three or four years from now, or maybe even three or four months from now, that might not be the right call. That's okay. Let's put a different Lego block, as you heard Larissa talk about, like, let's swap it out.

And that's a big part of how we partner with our customer. We're in it to drive to the outcome, we're not in it to provide the technology. And so as the technology changes, as your systems change, it's kind of my whole concept about bridge to nowhere. Like, the reason that centralized data systems are a bridge to nowhere is every one of the source systems that's feeding into that is constantly evolving. Your business is constantly evolving, so like, you're never going to be at an end state, and that's okay.

It's kind of the same model we take, which is it's never going to be complete. So you just have to work with what you have. And you have to be ready to swap out components and swap out integrations and swap out tooling. Ultimately, with a focus on an outcome, if your outcome is to have perfect centralized data, I think that that's never going to happen. But we can build an outcome to focus on. How do we provide I inventory intelligence to the best quality we can today, using the data that is readily available to us today?

And I think that's interesting. Everything is changing so quickly that the model that you use today might be optimized for a specific outcome. You you spoke about efficiently, cost and quality. It often depends, and cost needs to be factored in there because some models are more expensive than others. So you have to be focused on what is most important in a specific case. Is it quality, is it the speed? What is the most important goal or metric or KPI for that specific system?

And you have to be able to swap it out as new things go to market, and you can't go back and rearchitecture every time that happens, you'll be blocked. And I like the way you put it. I think the way enterprises have looked at it in the past is okay. This is a two year, three year, sometimes even longer process of of moving, of migrating to a specific architecture, specific storage. And then at the end of that, there is light at the end of the tunnel, where we start seeing returns on that.

And I think that a lot of people have been left disillusioned by that. And is the promise of AI really real? We've been working at this for a really long time. And the goals keep, uh, the goalpost keeps moving. Because as new models come in now, this doesn't matter now, this, this matters more, storage matters less, and your governance matters more. Now, you keep going back. Whereas in this case, you are fitting this into your system as is, and you can, of course, get more efficient in your storage, et cetera.

But that's a byproduct, that's not something that it's not a prerequisite to getting the model in there and getting results from there. So are there specific use cases where you've seen? Even the client might have been surprised with how quick, how fast the deployment was and how big the results, the money savings. What other stories would you like to share with us?

yeah, and I think we're in a real difficult world right now, where everyone's thinking buy versus build, and I have that conversation often. Like, well, maybe I just need to build it all in house and own it all myself and like. But if you think about it, like, the reason that SaaS and software companies exist is because they've consolidated talent and they've consolidated knowledge around how these systems work. They've built all the reuse like we have, we've built all the reusable components, right?

Like we already have in some extent, like undifferentiated plumbing that we can deploy rapidly on your behalf. Now the question is like, how do we do that quickly? And how do we do that in the commercial relationship that we both benefit by working together? So it's not a build versus a buy, it's kind of like a build and buy together. I I think this is probably the biggest mind shift, and probably going to be one of the hardest things for our entire industry.

Because I've been selling software solutions, SAS, for 20 years, and the model is pretty much let me show you all the features. 90 of them get your problem solved. You buy it, I deploy it, and hopefully you get there. And I have an vested interest in you getting there. And I might throw some professional services at it, right? But kind of I sold you a tool, you know, I sold you the hammer. You got to go build the house and a lot of that's on you.

And I can kind of direct you and give you some blueprints. But like most of the time, it's like, on you, counter to you. Build the architecture, you make the hammer, you buy the nails, and you build it all yourself. But these are polar opposite commercial models. One is build upfront hope for value, the second one is invest upfront and drive to value. But the cost is much harder to. And everyone will tell you like, building is cheap, it is not at all, it's the maintenance that's expensive, right?

And to have the talent to do it right, the knowledge gap is always an undercut. This new world where we align on outcomes and we invest together commercially on those outcomes. And you've heard Larissa talk about, we don't get paid until it works. That's a mind shift change on how partnerships align. And by the way, if we're both driving to an outcome together, trust me, we want to get there fast, just like you want to get there fast.

We both want to get there fast, right? Because we're investing into it. And I just think that when you talk about aligning on an outcome, money, where the mouth is. And the commercial aspect of the model is a huge new factor. Because all these massive SaaS companies who have been building their businesses on future contracts and TCV and commitments. And like, their value is baked, their stock price is baked into this. May have to shift into a world in which they don't get paid unless it works.

This could be a huge shift. And so I just think, you know, the aligning to outcomes is important. Obviously, that we agree that what success looks like. But I think the commercial construct in which companies enter into in the future is another monumental shift that's happening. And it's all driven by sort of this advancement. And and when we enter into relationships like that, and we focus on time to value, because it's a mutual goal, then using the solutions that we have and working together to sort of fill in the gaps.

So, for example, we have a multiline insurance company that we work with, and they had several different use cases that they had to deploy. And their whole problem was like, how do I bring the basis of it, and how do I build a little bit, and how do you build a little bit? Well, in the prior world, it was taking them around nine months to build one full end to end, you know, system, use case solution.

Now with us, they do it in two weeks. So you think about what that means for them to work together with us. We're using a common platform now, and I'm not trying to sell. But like, this is the relationship that I think is warranted, right? You're building a bit and we're building a bit, and we're driving to an outcome together, and we both want to get to the outcome. Because that's where the value is meant for both of us.

And so it's as much the technology and the building blocks and the modularity and being able to swap pieces and components out. But it's equally like the commercial relationship, which I think is changing materially in this new industry. The conversation shouldn't be about build versus buy, they should be. How do we build together? how do we align our outcomes together? If we do that, guess what? Time to value will be a common metric we work together on.

And if we can provide our customers a solution in two weeks, working together versus nine months on their own, we can iterate through and we can actually afford to fail. This is a big thing that no one wants to talk about. Nine to twelve month projects that are costing millions of dollars cannot fail. It's too much of an investment to fail. A two week project that maybe doesn't generate as much value as you think. That's, you know, it's a classic sort of failing fast, you know, Facebook attitude.

We want to be in that world. I think that's what AI is all about. Build quick, fail fast, see if you generate something, move on to the next thing.

I like the fact that you're sort of framing this as a symbiotic partnership. And the thing is, at the end of the day, like you said, time to value. And we've heard this before. Fail fast, and I think it's not always as practical. What does fail fast mean? Fail fast means that you had a specific goal set for the next nine to twelve weeks. If you haven't reached that goal, you must have learned something, even if it's just that that wasn't the right use case.

You've learned something, it's almost an education, you've built something that might not have worked, but you probably learned something from that process that you can apply to the next process, which will accelerate whatever comes next. Looking at this partnership, is it also looking at the complete, full life cycle that needs to be kept in mind?

Yeah, I think you're hitting on sort of two pieces of the puzzle, right? One is one is technical, but the other is a little bit more strategy, right? So I always talk to my customers about incremental growth, right? And incremental improvement. Like, I want a giant hairy problem and then I want to, like, chip away at it and generate value in two week cycles. And every cycle is going to get you something that's tangible and usable versus like, nine months from now, hopefully it works.

And I think that that's just got to be part of the way, and maybe that's a little bit of a startup mentality, just how we like operate. Like, we want to see if it works, see if it's moving the needle in the right direction, right? And then move on. And I think that that ties in also with this whole discussion around accuracy. I've had this discussion all the time. Is like, if the answer that you're getting from a system is consistent, but consistently ten off, is a ten gap good enough to make a decision?

And I would argue that, like most of the time, it is. What you're trying to do here is make things more efficient, you're trying to be faster, quicker to respond to impacts in your business, or respond to customers. Like, accuracy is not as important to speed and quality, and quality is more kind of, in my opinion, more about consistency. And so I think that when we think about incremental growth, we need to think about what the value or metric we're targeting, not necessarily like a goalpost, but how we grow it each time.

And I think if we do it in that light, then that business change doesn't actually affect us as much. Because, like, we can kind of tweak from sprint to sprint, from month to month, and we can even move what our KPI is for a particular sprint. Driving towards this ultimate end goal of customer happiness or revenue or cost is the big, big item that we're targeting, right? Because, you know, when you talk about cost, and you talk about revenue, and you talk about quality and risk, there's 50 different smaller KPIs that you can target.

So I think at a project level and a strategic level, we can kind of deal with some of that change and what have you? Now? You got to something else that I really like to talk about, which is like tribal knowledge, right? People, people change, processes change, the business change, the legality around the business change. Like all of these are either stuck in somebody's head or they're sitting in a piece of paper. This is actually where technology context layers, as you know, Peter calls, like ontology layers, we call it knowledge fabric.

This is where semantic linking between data, intent of data, tool usage like this is where that glue comes into play. And why it's so important for customers to not try to. I mean, they should invest into the context layer, should be wrong, but not to turn a context layer effort into another database warehouse effort. Because I'm seeing that happen, too. It's like, well, we can't start until we have all the context from everybody. Put in one place.

It's like, No No, let's think about that as an incremental tool as well. And if we do both of these together and we generate feedback loops between the two, we have a path to incremental growth. Both from a contextual perspective, so that we can ever change the knowledge necessary for agents, but also we can actually deal with the change of the human side, right? Because we're pulling that information in. And I think that this that problem is something that is totally not talked about in the industry today.

Because let's face it, the boomer generation is aging. They have tremendous wealth of experience and knowledge that, like, unfortunately, like, probably isn't written down somewhere. It's wisdom in their head. And like, we, as the next generation of leaders, have to figure out a way to, like, bring some of that knowledge into the context layer so that agents can do and understand those nuances. So, you know, there's tech here, there's strategy here, and then there's like this macroeconomic piece that's kind of really fun to talk about.

If we do it right, we can solve for that as well.

And you touched on two very important things for me is you mentioned consistency. And I think that sort of solves, or that speaks to the trust issue. Because it's one thing to have an outcome, but if it's different every time, you mentioned, like, if there's a ten accuracy, as long as it's sort of consistent. You can trust that the model, that the agent is working because it's consistent. It's very much like a human. A human can be consistently wrong, but at least, you know, it's consistently wrong.

And then the other thing, and if I am bringing something to the table that either sounds horrible or is completely a mess, that tell me. But it sounds to me like, instead of thinking of this context layer as birthing a brain, a child, it's more like building a brain. So don't expect it to be fully grown and then start using the brain, you can build a brain, and it's that's the thing about agents, it keeps grabbing context as you feed it to it.

So in that sense, it is like a child where you can keep feeding it, or an intern you keep feeding it. But don't think of this as you need to start with a fully formed brain, and that's when you start getting value. Is that close to right? You can build this.

You couldn't be more spot on. Like, you have to consider in your design choices that it will change. This is a fundamental reality of these systems, is that they will change. Not just like the components and the legos will be swapped in and out based on other technologies that advance, like maybe even the core model itself will change. Like, all of that has to be modular, but the concept that the core context is going to evolve over time, like that has to be core to your design decisions.

And here's where it compounds, like these two things come together to really compound. Because if my first use case that I solve, let's say it gives me exposure to sixty of the major business entities and tools that I use today. Well, guess what? Use case number two is already like sixty of the way there. There's got to be overlap. Now I might have a gap, I got to go add another ten, twenty, I got to add a couple modules, but guess what?

Use case three is even faster, and four and five, and faster and faster. Again, this is how you go from nine months to two weeks, right? And it builds on itself, because the more use cases that you put in, the more knowledge fabric understands. Which, by the way, that means that the agent that's over there reasoning on a specific use case actually sort of knows what the other agent is doing. Now, whether or not you give it the guardrails to do that, that's a decision in your design, but conceptually, it can.

And think about the most efficient people in a business today. I call them T people. I stole this from my old CEO, so I got to give him a shout out. But T people versus I people. I people are very. I work in a department and I know exactly how my tool works, and I know everything about that tool. I'm an I person, but the more effective person is like, sort of the T person. They may work in one area and really understand what they do for the business, but they also understand how it applies to different areas of the business.

And they can bring the context in. Well, when I'm doing this job, I know that, you know, Bob in accounting, he's going to want this, and Susie over customer support, she actually is going to think about this. Those are the most valuable type of humans that we have. Like, why not build agents that do that, right? And I think as we develop these knowledge fabrics, or what we all know as fabric, these contextual layers that are shared, right?

But building them by design to slowly and surely share context across them in an enterprise. Like, we're going to build more and more T people, and that's going to really unlock value and more coordination.

And I think in, I'm sure it's very pertinent in most industries, but especially in retail, where the margin is so tight. Adjustment to inventory, the slightest adjustment to pricing affects the whole system. And having a T who knows how this decision would likely impact the rest, or at least know that it will impact. Because often these things happen in silo. And it's like, at the time, the warehouse finds out you've ordered ten times more stock because there's more demand, the warehouse is full.

Where do you put this? The problem's already in your face, it's at the warehouse and you have no way to put this. So, especially in retail, these, as you call them, agents are really important as a retail leader today, and you might be absolutely anywhere in your transformation journey. So if you could give advice to one business leader who has sort of invested in this unified data storage system, what would be the one advice you would give them?

And then someone who hasn't started at all, a retail company who's literally they've got Excel sheets for each of those, what would you give to those business leaders?

Yeah, I think pick a target, a problem, and start addressing the problem, and don't get too hung up on the problem. Is a technical one. And this is such a hard thing for me to say, cause I'm such a data person and used to, like, build data models in Snowflake. But the world is gravitating so rapidly to solutions that don't necessarily require that level of clean, accurate data sets to actually move the ball forward. And so I don't think you should stop, by the way, if you've invested in those systems.

And you want those systems to be a system of record so that you can do, you know, accounting level reporting to the board. Like, by all means, you need to continue down the path to do that. Don't let that be the thing that stops you from actually trying to address some of the real problems on the front line. That can add a lot of value to your business. Because I think you can do both in parallel, so long as you consider the concepts in your design of modularity, right?

And that change and evolution is just going to be part of how you do it. And shameless claim. If you work with a partner like us that does exactly that, then you're in really good shape, right? And I just think it's a bit of a change in how we think about execution, you know, we need to kind of move away from some of this waterfall approach and really move into the, you know, the sprint cycle. I know everyone's doing that and everyone's been adopting it agile for 20 years.

But like, let's take that up a level to like our business strategy.

And I think that is quite the mind shift because a a a lots of IT ops things have moved in sprints, but at a strategy level, it has been quarterlies and yearly meetings. And and you're saying, bring it up to that level, even think in sprints. Yes, you'll always have an overarching strategy, which in most cases is more money, less, uh, happier customers, the bottom line. But on that strategy level, it's going to be difficult for me to actually wrap up this episode because there were so many interesting and rich insights.

But what I will say is start if you're in retail, this is rich ground. Where can you create value quite quickly? And that's usually a business problem that is showing up quite often. Start with that, have the mindset of failing or learning fast, solve one problem at a time, get those gains. Those will accelerate probably most other use cases within a retail company, because that context sort of lives across your system. Think of it as a T agent who has context and knows how stuff influence each other, and then think of the context layer, not as a starting point.

You're building this, and yes, of course, you can always build within your own company. But you need to think of the life cycle, you need to think of the learning curve. How many mistakes will you have to make before you learn? What a partner who's been focused on this within their own business, how fast they get to results compared to where you would get in nine to twelve weeks. And then also, this is a symbiotic partnership.

When everybody's got the same goal in mind, you get there faster. It's a together goal. You know your company, a partner most probably knows the systems, the coding, the models, the agents, the deployment model that works. Thank you so much for your time, Chris. I wish I had more time, but hopefully I'll see you again.

Yeah, thank you so much for having me.

We're wrapping up today's episode. I think there are three key takeaways from our conversation with Chris. First, waiting to centralize and clean all your data before deploying AI is often a bridge to nowhere. Agents can pull context from systems as they are. Second, modular incremental deployment lets teams swap components in and out as tools and models change, instead of locking into a rigid architecture that ages badly. And finally, outcome based partnerships, where cost and speed are tied to results rather than features delivered, are reshaping how retailers evaluate who they build AI with.

In this episode, we cover retail AI workflows. To go deep on AI topics and learn how retailers are using anomaly detection to flag fraudulent transactions in real time, download our free PDF report. AI in retail executive cheat sheet at Emerj dot com slash rcs one. That's m e r j dot com slash rcs and the number one. For further executive level analysis and to join our network of leaders delivering workflow impact with AI, visit Emerj dot com.

On behalf of the team at Emerj, we'll see you on the next episode.