Why Enterprise AI Fails Without a Strong Data Foundation | Utilizing AI Ep. 10

Enterprise AI applications need a solid data foundation, bringing together disparate data sets in a secure and flexible manner. But despite years of effort, most businesses still have a diverse data environment. Before we will see the value of AI in enterprise applications, we have to solve the challenge of data access.

And that's what we're discussing today with Ken Jagen of cdata. Welcome to utilizing ai, the podcast focused on practical applications of artificial intelligence from the Future RUM Group. Each episode brings together diverse perspectives to explore news and use cases in the ways in which AI is transforming enterprise IT and the industries it serves.

I'm your host, Stephen Foskett, president of the Tech Field Day Business Unit here at the Futurum Group. Before we dive into the discussion, let's meet who's on the panel today. Hi everyone.

Brad Shiman. Um, good to be back with you. I am the VP and practice lead for data integration, excuse me, data intelligence.

I, I'm already thinking about chatting, chatting with Ken today, uh, of data intelligence, analytics, and infrastructure here at futurum. And, uh, it's, it's my pleasure to join you guys. And we have a, an exciting guest on, I'm going to introduce him now.

His name is Ken Yagen with cdata. Hi, Ken. Hi, Brad.

Brad, Steven, thank you very much for having me. I'm the Chief Product Officer at cdata, Ken Yagen, and, uh, CDATA is a leader and enterprise data connectivity and integration. And, and we have one of the first managed AI connectivity platforms on the market.

So excited to talk today about ai. Uh, as Chief Product officer at cdata, my focus is really on how our customers turn data connectivity into governed scalable foundation for enterprise ai. And that's why we're happy to talk to you about this, because again, this is utilizing ai, we're all about figuring out practical, useful solutions based on ai.

And I, uh, learned about cdata last year. And boy, it, it is such a great idea because essentially one of the ways in which AI is going to be become useful is when it can ingest and act on the various types of corporate data that enterprises have and really, um, bring that data together and give us, you know, help us to, uh, build applications that use it. The problem is that that data exists all over the place in all sorts of different formats and so on.

And from the initial discussions with cdata, it seems like y'all are, are really focused on solving that problem. So, Ken, let's start with just a little bit of an understanding. What's the problem when it comes to data and ai?

Yeah, Steven, uh, the, the problem around data and AI is really, data is an AI problem. Um, the strongest predictor of AI success really is that maturity of your underlying data infrastructure that takes and delivers the, to these powerful models that companies are investing in. And so the companies have to act on that data.

They need to be able to understand it, they need to be able to access it securely and correctly, and then they need to be able to take action on it, which is sometimes requires writing back into the systems as well. That is a data integration problem, and that requires a lot of sophistication and understanding the semantics of the data and how to access those systems. There's some, you know, new, new technologies and protocols and techniques that are greatly unlocking that, but you also need, uh, that understanding and governance layer as well.

And that's what we try to do at cdata. And I, I would, I would argue that there is no AI without data. Um, I, I think that they too go hand in hand, peanut butter and jelly all day long.

And, um, like Ken, you said it is a bit of a challenge for enterprises because they have been working hard for decades now to try to modernize and streamline and democratize access to their data estates. But that is not easy. And it's certainly, you know, if you take 10 enterprises and sit down with them and say, okay, guys, you know, where are you at in terms of, you know, trusting your data, having quality data available to your business users, uh, as well as your agents that you're building right now.

And I think most of them would tell you that, you know, it is very much a hit and miss sort of fair right now that they don't have full trust. They don't have full access. So we ran a survey this summer, um, uh, actually autumn, um, asking data professionals, you know, are you investing in, in, in AI and are using ai?

And, you know, as we see everywhere, you know, by and large, over 52% said, we are already using it. We are building on it. That is our top, top priority is ai.

Uh, and yet when you ask them, you know, what are your biggest obstacles? Guess, guess what the biggest one is? It's, it's not security, it's not integration, it's not money, it is data quality, trust and governance.

I agreed. And, uh, Brad, it's interesting 'cause we actually ran a very similar survey, uh, on our side, the state of AI data connectivity, and we spoke to over 200 leaders in both the enterprise and in software technology companies. And our findings were very, very similar to yours.

So we might've been talking to the same people. Um, we found this, we Probably were Maybe, yes, uh, 60% of companies had had the highest level AI maturity also had the most mature data infrastructure. Yeah.

And the inverse of that, 53% of companies that had immature AI also had immature data systems. So there was a strong correlation between the maturity of their data systems and the maturity of their AI initiatives. Yeah.

I wonder the biggest, oh, sorry, go ahead, Steven. Yeah. Lemme just Jump in there.

Okay. Hey, here's an, here's an edit point. We're demonstrating how to do this.

All right. I wonder if that is a cause or an effect or both. Uh, you know, I mean, if a company has a mature, uh, data foundation, if they really understand their data and they've, they've spent the time and energy and effort to, uh, bring it together in, in some way, uh, they may be better, uh, prepared to develop AI applications right from the start.

But at the same time, as you're pointing out, if they haven't done that well, then they're just not going to be able to get the benefit of AI applications, even if they do invest in them. What, what do you think of the chicken and the egg here, Ken? Is is this a, uh, uh, a, a requirement or is this a symptom?

I, yeah, I, I, I under, I understand, and I think I agree with you with some of this, with the, the dual nature of this. Um, and, um, I would say that there is a, if a company has a culture of stewarding their data, having good data infrastructure, they already have a culture that's gonna allow them to move quickly and adopt ai. And, but on top of which, they're gonna have that good infrastructure in which to, to do it.

Those that haven't made that investment, they're trying to play catch up, they're trying to, um, swap the engine in flight by plugging in better data while also trying to plug in ai. Um, there's some ways to accelerate that, but you're gonna have to do a little bit of the work required along the way. Um, and you know, what we try to do is see day is we try to help them sort of accelerate that, take advantage of what they have.

Um, the good news is, you know, often when you talk about data infrastructure, you think about, let's get everything into a data warehouse or a data lake, and let's stage it all there and everything. And that's important, especially when it comes to understanding your business and analytics. And you can apply AI to that.

But there's also sort of the need, and we saw this in our, our survey and our study as well for realtime data. Oh, yeah. And realtime data is not data that's staged in a warehouse, but the data that's sitting inside your operational systems data that you're gonna act on directly and orchestrate your workflows and business processes around.

And this is where agents in the world of AI are really starting to come into their own and their ability to sort of do that. And again, they require a good understanding of that underlying data. What is, what is the semantics of that data being stored in that underlying system?

You know, how do you operate on it? What are the correct ways to work with that data? And combining the semantics with that data access is what is that sort of accelerant that will allow you to take advantage of it and mature your AI projects much more quickly.

Yeah, I agree, Ken. And, um, it's, it's funny because access and understanding, you know, have to go hand in hand. And I, I feel like right now in the enterprise, we have unprecedented access comparatively to where we were just, you know, uh, a even a few months ago, uh, at the hands, for example, of the model context protocol that Anthropic came out with about a year and a half ago, and how, you know, surprisingly, you know, a a a dominant that has become as a means of helping models in particular access data, but understanding what the data means is, uh, I think a greater challenge and one that not a lot of companies are, are really, you know, uh, able, able to chat about.

Um, I mean, I would love to come back and actually talk about, you know, how the easy button of model context protocol and how dangerous that is, because I think you guys, uh, are are definitely seeing that in your customer base. But before that, can we talk about the semantic layer? Can we talk about, you know, what companies really need to do to build that understanding?

Do you feel, Ken, that we're getting to a point now where we have the ability to not go the data warehouse data mart route, but instead have this open composable data lake house, let's say that, you know, totally separates storage and compute and lets me use whatever query engine I want depending on who I am in the company and always have, you know, access to and knowledge of when I say quarter close for accounting and sales, that it means this and not that. Yep. Well, uh, you know, the, the, the common phrase is garbage and garbage out.

So you have to make sure that you're putting good data into, into that data lake, um, in order to apply that semantic understanding of it. So a absolutely, I think we are approaching that. And I think AI is, again, is an accelerant of that and the ability to, um, have deeper understanding of the structure of the data and the meaning of the data.

And both of those are important. Let me, lemme tell you what I mean by that. The structure of the data is, is housed, the data stored, what is, where do you find and how do you connect the different fields, uh, of the data together?

And, and, and then can interpret meaning out of that. And then understanding that data, like what does it mean? What is this number?

Is this a quarterly number? Is it a monthly number? Uh, does it include us or world or, you know, north America, you know, whatever that might be.

Understanding the context, what, you know, accounting principles, if you're talking about financial data, apply to it. So there's a lot of context in, in order to interpret that data. And AI is really good at sort of stitching that context together.

And, um, at cdata we do is we take that we have some understanding of the underlying structure, semantics and a bit of the understanding of what the actual data is, and we inject that into the context of the model. And that semantic, semantic context is super critical because without it, you, I like to say is you're left with a system that just burns tokens on ambiguity rather than delivering value to your user. And that's so, uh, difficult when you have such a diverse set of data sources.

Um, you know, not every data source is created equal, and not everyone is going to be able to have that kind of context. Uh, talk to us a little bit more about how you deal with diverse data sets. Sure.

Well, there, I mean, enterprises, the, the typical enterprise uses hundreds of different systems with data stored in all sorts of different, uh, data, uh, locations. Uh, it could be internal databases on-prem software and systems, SaaS-based solutions, uh, partner systems and so on. So you have to be able to pull all that data together and connect it, uh, in the LLM in order for that context to be valuable.

And, and, and that is what a connectivity platform really helps with. We are actually able to go out and connect across systems and join data across systems, take a bit of the burden off the LLM so you're not consuming all of your context and all of your tokens by having to bring all the data and do that processing in the LLM, we can push that down into these underlying systems across multiple locations, and then expediently bring that back to the LLM so we can do the final sort of reasoning or actions that it needs to perform. So being able to handle diversity is really, really critical, especially in some of these new agent workflows that businesses are building.

We as humans, we deal with that sort of, you know, diversity day by day. You move in between what you used to call swivel chair integration and moving between system to system, pulling data together, copying and pasting, pulling up analytics reports. We do that as part of our job.

We're now asking AI and agents to do this. And so it needs to be able to manage and handle that diversity. So you need to be able to, to have a system and underlying infrastructure that supports, uh, that diversity as well.

Yeah. At scale, right, Ken? Because, um, as we start to get into, you know, these, these very advanced agent agentic pieces of software that we're building right now, getting data to the model is half of the challenge, half of that battle and, and not just understanding it.

And so you see a lot of investment right now in, in things like memory caching for being and being able to batch process and be able to, you know, not burn tokens, but still get the data to the models. And I think we need to also think about the fact that it's a entirely new constituency, uh, not just for consuming data, but for producing data. 'cause these agentic processes create a lot of information as they go, and it's data that needs to be managed by the business because, you know, you, the, we, I was just actually talking to, uh, a number of, uh, companies who are building out commerce systems that are agentic.

And the biggest challenge they felt they had was, was being able to take the data that gets generated from each interaction with their customers and to, you know, have that available to the agent, not just today, but tomorrow and the day after tomorrow. Yeah. And that, that's, that's where these, uh, data management platforms, large data lake solutions, can really value.

You have a place you can go store that at scale and then go back through, through agents, uh, and access it and bring it into the context of, of your workflow. Um, I do wanna, I can go back to Brad to this point. You've brought it up a couple a couple times and the concept of the explosion of access, uh, and, and, and what you were saying just there reminded me of it again.

And that is really important to think about because I, so I've, I've been around the data and application integration world for almost 20 years now, and saw the explosion of, of APIs and SaaS and integration and iPads and now, uh, with, uh, AI and agents and MCP and data's getting easy and easier to access, requiring less and less sort of technical work to, to bring it to the point of use within the business. And access is really critical access, both in terms of scale, like you said, you know, you can bring back too much data, burn a lot of tokens, uh, bring back inappropriate data that maybe the user's not, or the agent is not allowed to operate on. Or maybe the agent might do something with it that a user would know not to do.

Uh, so you need to be able to sort of govern that. You need to be able to handle at scale. Uh, you mentioned model context protocol.

You can have a tool explosion model context protocol represents everything as tools, and you can only handle so many tools within the context of an LLM. So you need to be very efficient in the tools that you expose within an agent to the LLM and to how much data you bring back. So leveraging the power of these underlying systems, not overload the LLM with too much data.

So there's a lot of things around access that need to be thought of by someone architecting an a gentech system. And, uh, again, those are areas that we, I spend a lot of time thinking about how do you actually scale this and do it effectively and efficiently. Uh, and it's something that we see our customers, um, really kind of struggling with when they come to us, but realizing that there is, there are better ways to do this.

There are definitely better ways. Um, and, and unfortunately the, the technology is moving so quickly that it's becoming a, as you mentioned, too easy to access data and to do so unwittingly, un responsibly. Um, and also it, it's, you know, performance wise, the, the tech, the tools that we have available to us are allowing us to build systems that we can't support our, our infrastructure just isn't ready for.

And I, I like to think, you know, when I, when I think about cdata and you know, vendors that are playing in the space, you are that at the end of the day, it's about, you know, helping customers see that they should not go the shadow IT route because that, that's dangerous. Um, but there are options to, you know, accelerate what they have and to meet those evolving capabilities as well as needs that we're seeing start to, to come into market. I mean, I saw a model come out just this week, uh, that has the ability to handle 400 tool calls in a single, you know, long running pass.

That's insane. Uh, there, that is, that's, that's a lot of processing, a lot that, a lot of power that you have in that, in that type of model. And that's the thing, we don't know what's gonna come out next week.

We don't know how these models are going to evolve and what capabilities they have. We know they're gonna do more than they do today. And so you have to kind of plan for this unknown future.

And so when you're thinking about how you design these systems, you do need to think about scale and governance. And you also need to think about what might be possible six months from now. Um, and the other thing is make sure that you're designing to, to update and refresh this, realizing that your architecture's gonna change.

There's gonna be innovations to take advantage of. So you have to be agile. And so you need to use underlying infrastructure that's also agile and gives you that flexibility.

Don't tie you down to, to one particular model or infrastructure vendor, uh, allow you to move around, consume new data sources that you didn't necessarily have that you weren't thinking about before. So that agility is really important in this type of fast moving world of ai. Well then that point that you're making about is, goes to the point of maintainability.

And that's been a, a key problem. Anytime you're building an application that integrates diverse data sets or tools. I, i is the inherent sort of fragility of those systems because, uh, you know, vendors can change the ways that their APIs work.

Uh, they can change their, you know, they could abandon, uh, one API or another. They could, uh, really upset the apple cart. And this is especially true.

It gets multiplied when you have more and more and more disparate, you know, components in there. So one of the points that I was gonna ask, and, and I think you've sort of just a answered it, is why not just rely on the vendors to make this accessible? Why not just work with, uh, you know, whatever happens to work?

And I think that the, your answer might be, because even if it works now, it might not work later. And also maybe, you know, different vendors may have different approaches. They may not wanna support this or that model, and you would perhaps allow them to, uh, integrate with, um, a broader set of data.

Is that right? Yeah, exactly. You might wanna switch vendor, you wanna wanna switch model vendors, uh, next year.

You know, did you tie yourself to the, to the capabilities or the interface of that particular vendor? Or do you have the ability to kind of switch, switch, switch that out? Uh, this is particularly the case when going with sort of full stack solutions from some of the legacy players.

You miss out on some of that innovation that's happening in the market. 'cause they're gonna be a little bit more, they're gonna be a little bit slower to bring that capability to market. And so you, you wanna have that agility.

That's exactly right. Yeah. And I, I think it's, um, you know, when I look at the marketplace for this year, uh, one of our biggest trends that we see evolving is this acceleration through integration.

And that, you know, last year we probably would've talked about, you know, the format wars and is it gonna be Apache or, or you know, is is it gonna be Delta? And you know, that's done. It is, it is definitely, you know, Apache iceberg all day long.

And that separation of storage and compute I mentioned, and what that does is place the burden on the vendors who are building these systems to, to provide that sort of interoperability. And what I worry about honestly, is that we sometimes, when we get a shiny new toy, we over rely on that toy to, to scale with, you know, our needs in the marketplace. And I think MCP is one of those that's just been so overused, uh, you know, right now that it's, it's becoming itself a, a sort of liability in terms of that.

That's, you know, like we talked about before, understanding the meaning of the data that it's accessing, accessing the right data. How do you secure that access point? Because those standards, like a 2:00 AM CP, any other framework you wanna throw out there for integration is, you know, an abstraction layer.

And those abstraction layers aren't free, right, Ken? They, they do have a cost you have to pay, I think. Well, I think I, I, I wanna agree and disagree with you on that.

So, uh, I agree, I agree that there is, there is, you, there's a trade off whenever you have an abstraction layer. 'cause you're, you're always, you're always in a trade off. 'cause otherwise you would go to a proprietary approach and you might get something very much more specific for your needs.

But abstraction layers help markets sort of stabilize and mature. They allow people to focus on one thing, and that's what MCP has done. It's allow people to focus on a single way to connect their data, their, uh, and their tools into the LLM.

Now if you just just utilize it in that way, and you don't think about how you deal with authentication, how you deal with governance, how you deal with security, how you scale it, how do you manage it, change management, all of that, then you're gonna be in trouble. Like you say, then it, then it's a crutch and it, you're, you're not going to be successful at the end of the day. Um, if you just use agreed, go grab the latest MCP server in some open source community, it might work for you original initially, but you might, you're quickly probably gonna find out it's a bit brittle, it's a bit fragile.

Even some of the ones from some of the first party, uh, providers out there, they're incomplete. Um, and they don't maybe have all the capabilities that you need in order to solve for your problems. So you gotta build around that.

And that's one of the things, it's c data, we're looking at that. We've built our own MCP servers for over 300 different critical business systems. And we built all the governance, we built the, uh, security, we built the scalability.

And I also added that semantic layer around it to make it much more effective and much more efficient, so that now you do have something that you can rely on that's stable and that you can, uh, scale your systems on top of. Well, yeah, I recall there being a market, oh, I'm sorry, Steven. Uh, I I recall there being a market specific to integration, um, that that's all vendors did, and they built connectors.

And we, we seem to, as a marketplace, have tried to move away from that and say, oh, you can just do it yourself. But that's really not the best approach when you're trying to have a system that could adapt to that changing data estate that we've been talking about. To be able to say, today I need Salesforce data cloud tomorrow, I, I need something on, you know, a totally different platform from SAP.

Yeah. And I, I would say, you know, for very simple things, for very simple APIs, uh, a lot of roll it your own. But as Cdata, we've lived in that sort of world of connectivity for many, many years.

We have 10,000 customers that are, uh, that are licensing and using our connectors, including some of the largest software companies in the world, um, that are embedding it inside their platforms, uh, in order to provide connectivity out to other data sources. So connectors are a critical component cp as we're talking about here, model context protocol puts an abstraction over that concept. Um, so that anything that you can connect to anything that has an API, you now have a way to plug it in to an LLM and make use of the data and make use of the actions that you can perform.

And, and that's important to, to think about. It's like MCP can be data access, but it can also be operational execution. Uh, and there are other concerns when it comes to operational execution.

You're changing data, you're triggering workflows, you're, you're triggering actions within your organization, within your enterprise that have implications. And so again, security governance and all around that scoping it, scoping the permissions down to the set that are necessary for that agent to perform the types of actions that would be necessary for whatever its goal or objective is, and not allowing it to stray beyond that. Yeah, I think that you all have a lot more experience with MCP than most of the folks listening.

Um, I wonder, I, I appreciate you kind of bringing those, the, uh, thoughts to, to the fore here about MCP and thinking about governance and security. Um, what else could you tell us if, if we want to kind of step back here a little bit, um, what should people know about MCP if they're looking at it, if they're thinking of implementing it? Um, you know, what have you learned in all the years of developing or the, the year of developing all these, uh, MCP servers?

Um, what are the lessons you've learned? Yeah, I mean, the lessons I learned, first of all, MCP sits on top of the underlying data sources, the APIs or the, uh, the SDKs are used to access them. There's a lot of complexity.

You know, just because something is rest doesn't mean it operates in a certain way. So there's a lot of complexity underneath it that you need to deal with in order to have a good functioning MCP server authentication is still hard. We, which it could be easier.

I mean, so back in the day, I actually worked on the, uh, saml uh, committee to develop that as a standard, took us a long way. We're still, you know, utilizing that inside of OAuth and everything else. So, but there is a lot of complexity when it comes to identity.

And you, and also with MCP, you have to think about identity in the context of the user now in the context of the agent user and the, and the scoping of that identity. So that, that's something to deal with. Um, there are their own little sort of enhancements or additions that each, um, client has created open ai.

They have their open ai, they have their apps, uh, Claude Anthropic Claw, they have skills, they have different things that they're building around MCP that are specific to each of them. And so you need to think about how your MCP server is gonna interact with each one of these, whether it's a chat LLM type agent or an agent platform. Uh, that's something to think about.

And then there is, there's governance, there's, how do you discover the registry for discovering, I mean, it's, it's okay if, you know you've got a handful of MCP servers, but what if you've got thousands of M CCP servers? What if everything in your enterprise is suddenly, uh, MCP enabled? Now you need to have a concept of a service registry and some sided governance around it.

Um, so we're not getting away. We had that problem with APIs and API management. We had it back in the SOA days with SOA service registries.

It's, uh, we had it even back in the corba days in the nineties. So it, it's, you know, naming and discovery is always gonna be an issue. It's gotten a bit easier, um, with LLMs, but with MCP, you still have that, that concern.

Yeah, bring, bring back middleware. Uh, I, I, I, I love the, the, the SOA era just because we, we were trying to build software the right way, and it just, it just turned out that it was a little bit more difficult than we thought. Um, but may, maybe we have the option now, but I, I, I totally, you know, agree with what you're saying, Ken and I, I feel like, you know, when you're talking about CPS as just another means to, to get to those sources, you do have to consider the models.

And I felt for a while now that the models themselves, especially the frontier models, are much more than just, you know, uh, uh, an endpoint that you're querying. It's, they're actually platforms. And so you need to have standards, you need to have some sort of registry to understand when Google changes the Gemini, um, API subtly that, you know, it's, it's not gonna break your application tomorrow.

Uh, maybe the model itself changes in, in its ability to like, um, refuse a request or continue the request. And all of that is, is much harder to deal with when we have these models that, that are non-deterministic that we're using as infrastructure. Exactly.

If I, if I can just summarize some of my thoughts on that. Uh, so I'm a proponent of MCP. I'd like that it's being developed in real time and tested in the market and iterated on as opposed to being developed in a, in sort of an ivory tower and, and over-engineered.

We've seen that in the past. So I really like the approach that, that the vendors have taken to kind of come together on this and, um, try to not try to solve too much and allow other infrastructure and software companies and the LM providers to come in and build around that, to, to kind of sort of polish those rough edges and provide the additional support and capabilities that are needed. Uh, I think that, uh, one of the key areas that, that needs a little bit more work and that we're focused on is that semantic context, as we've talked about and under understanding what's, what the capabilities are, the underlying systems.

Uh, I think that it opens up and allows for real-time data access and action. I think that's very important. Uh, and it recognizes that so much of the enterprise data is in this sort of structured format that agents able to access and operate on and com.

That combination with these types of standards and these types of capabilities will allow us to get to sort of this promise of digital employees, digital agents that are agent to agent working together, uh, swarming together to solve, uh, solve problems and operate businesses more effectively and create more enterprise value for us. So all of that said, I think it's time to, for companies to be investing in their data connectivity, investing, investing in their infrastructure, and to do this to enable AI to answer and act on their business. Yeah, thanks for that.

And, uh, I think that's a good message to leave our audience on here. Uh, as Brad said at the top, uh, you know, you can't really build an effective AI application without good data. It's all about the data.

And, um, that means that this is an area that, uh, companies are gonna have to invest in if they're going to have an effective AI application. Thanks for joining us. Uh, before we go, uh, many of our listeners may wonder how they can continue this conversation or where they can connect with you.

Uh, Brad, uh, let's start with you. Uh, what are you researching? What are you working on, and where can people find you?

Yeah, right now, I'm, I'm actually building out a new, um, comparative report using our, our, our signal, um, ag agentic report process on data intelligence platforms. And that's gonna be all about how you get that semantic layer and put that in action just like Ken said. So looking forward to that.

com. Excellent. And, uh, Ken, how about you?

Great, thank you, Steven. Uh, likewise, uh, happy to people to reach out to me, connect to me. LinkedIn's, uh, gonna be the best way.

Ken Yagen on LinkedIn, on other social, on, on X and other things as well. Uh, I mentioned earlier, but I encourage you to download cdata state of AI data connectivity report from our website. We'll provide the link, uh, along with this podcast, and you can also check out our product.

com. Uh, and I'll be speaking in March at the Gartner Data and AI Summit in Florida. So if you happen to be there, come check out talk.

We're gonna be talking about, uh, the same topic there. Excellent. And, um, as for me, uh, you know, I run Tech Field Day, uh, this week is AI Infrastructure Field day four.

com and the Tech Field Day socials, and of course, we will be having another AI Field Day in May. So keep an eye on the Tech Field Day socials to learn more about that. Thanks for listening to this episode of the Utilizing AI podcast.

If you enjoyed this discussion, please do subscribe on YouTube or your favorite podcast application. Also, drop us a line, uh, give us a rating, give us a review. We'd love to hear from you.

This podcast is brought to you by the experts at, uh, Futurum Group, uh, where Insight meets ai. ai, the utilizing AI YouTube channel or textron's, uh, new TV app. Thanks for for listening, and we will catch you next week.