Why Platform Maturity Determines Agentic AI Success

WEBVTT
00:00:20.800 --> 00:00:24.160
Tech Unboxed with BBD.
00:00:24.719 --> 00:00:28.000
Welcome to another BBD Tech Unboxed.
00:00:28.079 --> 00:00:29.519
And today I'm with Jason.
00:00:29.600 --> 00:00:32.000
And Jason is a real human being.
00:00:32.240 --> 00:00:36.159
Ladies and gentlemen, he will enlighten us about Agentic AI.
00:00:36.320 --> 00:00:38.799
Jason, can you please introduce yourself?
00:00:39.359 --> 00:00:40.079
Yeah, sure.
00:00:40.560 --> 00:00:43.200
So, like Quinn mentioned, I'm Jason, Jason Perry.
00:00:43.600 --> 00:00:46.960
I am a cloud and platform engineer for BBD software.
00:00:47.359 --> 00:01:01.439
I work out of the Netherlands and I've been on a number of our clients dealing with things like container orchestration platforms, serverless platforms, data platforms, and now with all of the hype around us and what we're discussing today, AI platforms.
00:01:02.399 --> 00:01:07.760
And you recently did an article in Tech UK, which is a very nice magazine.
00:01:08.480 --> 00:01:16.480
And I I was reading your article, and what struck me was less about size, more about strategic deployment.
00:01:16.719 --> 00:01:21.040
So can you light us a bit more what you meant by this phrase?
00:01:21.519 --> 00:01:22.480
Yeah, definitely.
00:01:22.879 --> 00:01:28.079
And I think it's something that will become probably a bit of a common theme throughout our discussion.
00:01:29.040 --> 00:01:31.280
Cost is becoming a big factor.
00:01:32.400 --> 00:01:44.640
It doesn't really make sense to throw a tech that's becoming increasingly more expensive at problems where there's deterministic options or basically where AI isn't suitable.
00:01:45.439 --> 00:01:57.920
And what we're seeing really is that a lot of enterprises know that they want to use AI, but and they're investing in it heavily, to be clear, but they're struggling to identify suitable concrete use cases where AI really makes sense.
00:01:58.159 --> 00:02:10.479
And that's kind of what I'm referring to here is um strategic deployment focuses on taking AI where it's really going to be beneficial for an enterprise, deploying it there, and then quantifying the benefits that they get out of it.
00:02:11.280 --> 00:02:22.560
I was also surprised because recently there has been some press coverage around uh some of the larger organizations that pull away from AI and actually go back to human employees.
00:02:24.000 --> 00:02:30.000
Yeah, um I kind of think that might have been a bit of an overinvestment from some companies.
00:02:30.080 --> 00:02:38.000
You know, some jumped the gun too early during a time where uh AI was still very much an emerging technology, although it still is even today.
00:02:38.240 --> 00:02:41.840
And during a time where token costs were quite heavily subsidized.
00:02:42.000 --> 00:02:52.400
Uh so basically what we saw was some companies going all in on a technology that hadn't yet been proven to be cost effective, and now we're seeing a bit of a correction for that in some companies.
00:02:52.560 --> 00:02:56.800
But overall, I would say there's still a very positive outlook on where AI is going.
00:02:56.879 --> 00:02:59.120
We just have to be cautious about how it's implemented.
00:02:59.759 --> 00:03:09.759
Well, it's funny that we we talk about that side of the equation, but there's also the other side of the equation, which is it's very simple to set up, it's uh it's a five-minute job.
00:03:10.000 --> 00:03:15.280
Um but I think it in reality it's much more complicated, isn't it?
00:03:15.680 --> 00:03:17.120
Uh it definitely is.
00:03:17.360 --> 00:03:32.800
Um and I think it's kind of important to highlight the difference here between people using existing or pre-built offerings for things like productivity versus actually implementing AI or agent solutions into business workflows.
00:03:33.280 --> 00:03:38.080
Um and if you look at the ecosystem, it's becoming very broad.
00:03:38.560 --> 00:03:45.360
So what you would typically expect, uh you've got everything, I mean, let's just ignore training and hosting large language models, right?
00:03:45.520 --> 00:03:47.199
Because that's a completely different ball game.
00:03:47.360 --> 00:03:49.280
You still have to deal with all of the other concerns.
00:03:49.439 --> 00:03:57.520
You've got governance, cost, observability, uh, security and access control, all of these different factors come into play.
00:03:57.680 --> 00:04:04.000
And it's quite rare to have the skill, uh, the knowledge, and the experience in-house to cater for all of these different topics.
00:04:04.240 --> 00:04:13.840
And even if you do have that, it's pretty rare for organizations to have platforms at a level of maturity where you can immediately uh build AI solutions on top of your platform.
00:04:15.280 --> 00:04:22.319
So so you mentioned uh security, compliance, costs, and I think an important one is personal identification.
00:04:23.120 --> 00:04:23.519
Definitely.
00:04:24.000 --> 00:04:34.079
But if you look at all of them and and you would look at projects that you have been running for some of your clients, what would you say is the the biggest offender and how would you rank them?
00:04:36.319 --> 00:04:39.600
I think that's a bit of a tough one because it's changing over time.
00:04:40.000 --> 00:04:43.519
Um so I would say it's hard to rank them, but just to go through them.
00:04:43.839 --> 00:04:47.759
Cost, like I mentioned, wasn't as much of a concern initially.
00:04:48.000 --> 00:04:56.720
Uh, but now we're seeing even massive AI budgets getting consumed pretty rapidly uh due to the changes in subsidization and token costs.
00:04:57.120 --> 00:04:59.680
We also see now that compliance is catching up.
00:04:59.839 --> 00:05:05.439
You've got things like the EU AI Act, um, and these are really important because they can be showstoppers, right?
00:05:05.519 --> 00:05:08.240
They can end entire projects if you're not compliant.
00:05:08.560 --> 00:05:14.720
And then security is typically the kind of thing that people don't think about as much as they should until something goes wrong.
00:05:14.959 --> 00:05:21.120
Uh so they're all very important factors, but I think right now the thing that's in focus a lot is cost.
00:05:22.079 --> 00:05:25.279
Uh what about the um identification part?
00:05:25.839 --> 00:05:33.360
What people typically are not thinking about at the moment, I would say, is that agents need to act autonomously.
00:05:33.519 --> 00:05:33.920
Right.
00:05:34.079 --> 00:05:38.560
Of course, where possible, you want a human in the loop to make sure nothing has gone crazily wrong.
00:05:38.800 --> 00:05:50.879
But what we need to do is make sure that agents have their own identity, that they can get access to the systems that they need when they need it, that they only have access to the things that they need access to, and that they lose it when they no longer need it.
00:05:51.040 --> 00:06:05.439
And that we can scale this across large organizations where you're going to have at some point many agents running simultaneously, doing all sorts of things without human oversight, but you still need an order trail to understand what's happened and potentially where something has gone wrong.
00:06:06.720 --> 00:06:12.399
Now I'll take you back on the question of sort of ranking them and providing me the biggest offender.
00:06:12.560 --> 00:06:14.160
Which one would that then be?
00:06:17.839 --> 00:06:19.759
Sure, you bring in uh a tough question.
00:06:19.839 --> 00:06:29.920
Yeah, let me say I'll go for cost being the biggest offender at the moment because I think that uh budgeting is becoming super crucial.
00:06:30.079 --> 00:06:34.720
And I'll say that um identity is probably the most technically complex one to deal with.
00:06:35.199 --> 00:06:41.120
Looking back at compliance, um specifically in Europe, you already mentioned the EU AI Act.
00:06:41.439 --> 00:06:48.480
There's also another one in the UK, there's another one in uh in the US, that's multiple versions across the world.
00:06:48.800 --> 00:06:52.639
The these frameworks are evolving, but where do you see this going?
00:06:52.720 --> 00:06:56.160
And and how do you see that being useful on your day-to-day job?
00:06:56.560 --> 00:07:03.759
Like I mentioned, they're kind of catching up with all of the rapid development that's been happening over the past few years in the tech space.
00:07:05.040 --> 00:07:11.839
And compliance is becoming increasingly a serious concern that a lot of projects have to take into account.
00:07:12.079 --> 00:07:17.600
Um, where we see it going, well, we obviously try to engage with the parties working on these acts and frameworks.
00:07:17.839 --> 00:07:28.800
In some ways, this is to give them guidance from what we're seeing out in industry, and in other ways, it's so that we can get an idea of where things are heading to make sure that we're not building something that's going to be non-compliant at some point.
00:07:29.040 --> 00:07:37.279
What we're kind of seeing is that everyone is positive about the use of AI, but very cautious about what and when you can do things with it.
00:07:37.519 --> 00:07:45.680
Um the thing I think societally that we haven't really solved is how to make or how to give responsibility to an AI agent.
00:07:45.839 --> 00:07:51.600
And when I say that, what I really mean is if something goes wrong, usually up until now you've been able to blame a human.
00:07:51.680 --> 00:07:52.639
And that was great, right?
00:07:53.040 --> 00:07:54.879
You could fire Bob if he did a bad job.
00:07:55.279 --> 00:08:02.959
But if you've got an AI agent that's made a crucial mistake, somebody's lost money, even worse, somebody has potentially died in serious situations.
00:08:03.199 --> 00:08:06.879
There's no real way, legally speaking, to deal with that.
00:08:07.120 --> 00:08:17.600
And that's kind of a problem that's going to be difficult to take care of uh in terms of legislation and compliance, and something that we're really going to have to think about from a technical perspective.
00:08:18.800 --> 00:08:23.040
Well, we also talked about um sort of the benefit that it brings.
00:08:23.199 --> 00:08:28.399
Um how do you think that today benefit has been measured within organizations?
00:08:28.800 --> 00:08:31.199
Yeah, that question is on a lot of people's minds.
00:08:31.360 --> 00:08:37.039
Things are a little bit opaque at the moment in terms of measuring token costs and benefits.
00:08:37.360 --> 00:08:56.399
Uh the problem that we're seeing really is that if you're taking some of the existing offerings, let's start off with the like subscription-based offerings, it's often opaque or uh ambiguous as to how many tokens or how much usage you're getting for a certain like amount of requests.
00:08:56.879 --> 00:09:02.879
So what people are typically doing is they're going towards AI-based uh bully, which is more predictable.
00:09:03.039 --> 00:09:11.759
But then even when you do that, it's hard to quantify how much benefit you're getting out of a specific, let's say, amount of tokens.
00:09:12.000 --> 00:09:17.840
And I think there needs to be a lot more focus on minimizing the amount of tokens per correct answer.
00:09:18.559 --> 00:09:26.879
Up till now, there's been a lot of focus on decreasing cost and or tokens in general, but that doesn't really help if the output is not useful.
00:09:27.440 --> 00:09:40.799
Um, so it's kind of important here to focus on picking, like I mentioned earlier, use cases where you can demonstrate and quantify the benefit AI has, and then you can tie that back into the cost per token that you're actually uh seeing.
00:09:41.600 --> 00:09:43.600
I like that notion that you bring in play.
00:09:43.919 --> 00:09:46.080
It's almost like the return on investment.
00:09:46.399 --> 00:09:50.000
You have the amount of tokens and you try to get the most out of it.
00:09:50.639 --> 00:10:00.080
Are there any other ways companies can prepare on this idea that the the actual token costs would be rippled down to their actual invoices?
00:10:01.120 --> 00:10:02.080
Yeah, definitely.
00:10:02.240 --> 00:10:02.720
Definitely.
00:10:02.879 --> 00:10:10.240
Um I would say uh you can kind of rank them from more simple things you can do to more technically complex things you can do.
00:10:10.559 --> 00:10:16.240
So number one, I keep going on about this, but really picking use cases where AI makes sense.
00:10:16.559 --> 00:10:16.799
Right?
00:10:17.039 --> 00:10:21.679
Don't throw it at just any problem, be very intentional about where you're using it.
00:10:22.000 --> 00:10:26.240
Number two, building in platform guardrails to avoid overspending.
00:10:26.480 --> 00:10:45.200
So this is everything from budgets per uh, let's call it API key, um, to actual budgets per project, cost monitoring, alerting, all of the typical things that you would have seen up till now in broad enterprise platforms, but specifically apply to agentic AI solutions.
00:10:45.440 --> 00:10:50.639
And then you can really get into some technically complex things that we're seeing these days for intelligent cost control.
00:10:50.960 --> 00:10:58.240
That's things like semantic routine, model response caching, and these often go through uh tools like an AI gateway.
00:10:59.039 --> 00:11:11.440
It was something that also struck my eye when I was reading your article that you mentioned uh it's easy to include policy guardrails uh within the actual prompts and within the actual agentic flows.
00:11:11.679 --> 00:11:13.279
Is that exactly what you meant?
00:11:13.679 --> 00:11:23.600
It's important to make a distinction here between what's happening from the user side and what's happening from the platform side because the focus of the article is really from a platform engineering perspective.
00:11:24.480 --> 00:11:40.080
And I think uh the policy guardrails that we typically see and implement coming from the platform side, where we try to build things in so that consumers of the platform or users of the platform get those security and compliance uh by default.
00:11:40.320 --> 00:11:48.799
So you don't really want to be in a situation where a user of the platform has to be responsible for making sure that they do this in a secure and compliant manner.
00:11:49.039 --> 00:12:06.639
We want to make sure from a platform engineering perspective that we give users the peace of mind that when they do something within our ecosystems or our environments that we build up for them, that they won't run into a situation where they can do something irresponsible or insecure.
00:12:08.159 --> 00:12:13.039
Well, it's an interesting um perspective that you put uh people against the platform.
00:12:13.200 --> 00:12:16.720
So who do in your in your perspective, who is then most responsible?
00:12:16.879 --> 00:12:26.559
Is it the platform engineering or is it actually the user to ensure that you comply with uh being within the costrails, being within the policy guardrails and so on?
00:12:26.799 --> 00:12:42.879
It's a bit of a shared responsibility model, like we often see in tech, but I think at the foundation of it, it starts off at the platform, because the platform engineers are the ones who are expected to have the knowledge, the experience, and the responsibility for ensuring that these types of things can't happen.
00:12:43.120 --> 00:12:48.240
Of course, from a user perspective, you should always be doing things like trying to make sure you're being secure, right?
00:12:48.320 --> 00:12:56.559
Try not to use tools that could be potentially compromised, try to make sure that you stay within the cost guardrails, be intentional about where and when you do things.
00:12:56.879 --> 00:13:04.399
But ultimately, the goal of platform engineering is to try and remove that burden, that cognitive overhead from consumers of the platform.
00:13:04.720 --> 00:13:14.320
Platform engineers want to take that responsibility and want to make sure that their platforms are easy to use so that consumers don't have to worry about all of these types of concerns?
00:13:15.120 --> 00:13:22.639
More of a personal question because you call it platform, but in your explanation, it sounds to me a lot like a good architecture.
00:13:23.120 --> 00:13:32.799
Are there like advice that you can give in order to help companies to deal with the situation better?
00:13:33.200 --> 00:13:41.360
Yeah, I can definitely try, and to your point, your platform architecture is probably the number one determining factor of whether you get this right or wrong.
00:13:41.679 --> 00:13:45.279
And uh I kind of alluded to this in the article as well.
00:13:45.519 --> 00:13:54.799
I think the level of platform maturity that an organization has is directly correlated with how easily they can deploy agentic AI solutions.
00:13:55.039 --> 00:13:57.200
So I can unpack that a little bit.
00:13:57.679 --> 00:14:06.799
The thing that we're seeing is organizations that don't have a level of platform maturity tend not to be able to do all of the things that I was just discussing, right?
00:14:06.960 --> 00:14:10.000
They don't have a way to automatically enforce policy guardrails.
00:14:10.240 --> 00:14:25.360
They don't have a self-service mechanism so that engineering teams can consume these types of capabilities, which means that every single engineering team then gets that responsibility for making sure that they're secure and within the guardrails and all of those different kinds of concerns that we've been discussing.
00:14:25.600 --> 00:14:37.360
So, my recommendation for organizations would be to start focusing on your platform foundation before you get to the point where you're trying to scale agentic AI solutions across your business.
00:14:37.600 --> 00:14:45.440
Because the platform engineering foundation is what gives you the ability to automatically apply those guardrails, those cost uh budgets, all of those types of things.
00:14:45.679 --> 00:14:51.279
And then once you have that foundation, you can look at the specific AI relevant topics.
00:14:51.360 --> 00:15:03.360
Like I said, maybe you're implementing an AI gateway, maybe you're creating custom policies that are tailored towards AI or agentec solutions as opposed to your more broad workload uh policies.
00:15:03.840 --> 00:15:11.600
But yeah, so my recommendation is definitely just focus on a strong platform foundation to enable you to build your AI solutions on top of that.
00:15:11.919 --> 00:15:24.799
What you also talked about in the article was um it's not about uh being like always right on the the largest model, but it's more the challenge about uh choosing the right model.
00:15:25.120 --> 00:15:29.360
So LLM becomes small LM, right?
00:15:29.600 --> 00:15:30.320
SLM.
00:15:30.639 --> 00:15:32.799
So what's your take on that?
00:15:33.360 --> 00:15:40.159
Yeah, I think something that we're seeing more and more is a shift in perspective.
00:15:40.480 --> 00:15:44.720
LLMs give you what we typically call general intelligence, right?
00:15:45.039 --> 00:15:54.320
But if you're trying to use it for a specific problem, let's say trying to um assist with coding, it doesn't really matter that a large language model can help you with a medical problem, right?
00:15:54.399 --> 00:15:57.440
That's got no relevance or no bearing on the problem at hand.
00:15:57.759 --> 00:16:01.120
So what we're seeing or what we think, and this is a prediction, right?
00:16:01.200 --> 00:16:02.960
Where it's not really broadly implemented.
00:16:03.519 --> 00:16:05.200
We like predictions in this podcast.
00:16:05.600 --> 00:16:09.200
I'll get to you it's then I'll give you my hot take at the moment.
00:16:09.440 --> 00:16:10.399
Yes, please.
00:16:10.720 --> 00:16:17.519
I think there's going to be a large shift towards small language models that are very focused on specific problems.
00:16:17.840 --> 00:16:29.200
I think number one, the cost factor that we spoke about will become huge here because the hardware resources that you need to run a small language model versus a large language model it's vastly different.
00:16:29.519 --> 00:16:44.720
And um just so that everyone knows, essentially a small language model, you take an existing smaller model, so not the massive amount of parameters that you would expect in your frontier models like Fable, uh GPT 5.6, you would take one of those models.
00:16:45.120 --> 00:16:46.559
Immediately taking the big ones.
00:16:46.960 --> 00:16:47.600
Yeah, yeah.
00:16:47.759 --> 00:17:03.759
So if you if you eliminate those large language models, right, and you move towards the the smaller ones, for example, your Kimi K2.5 and now K3 has just been released, you take those types of models or even Quen and you're training them or fine-tuning them on a specific topic.
00:17:04.000 --> 00:17:10.160
That yields a small language model, and then what you want to do is benchmark that against the performance of a large language model.
00:17:10.480 --> 00:17:25.759
And what we're often seeing, um at least in certain situations, like I said, this hasn't been broadly adopted yet, is that for specific topics, you can get similar performance with a small language model for that topic to what you would get from a large language model.
00:17:26.160 --> 00:17:35.279
And um, I think one of the best kind of ways or one of the best examples of this is Cursor and their Composer 2.5 model.
00:17:35.680 --> 00:17:40.559
It's a small, relatively small language model compared to the large language models.
00:17:40.720 --> 00:17:50.480
Its performance for software engineering and for coding is excellent, but it definitely won't give you that general level of intelligence that you expect from the uh larger language models.
00:17:51.440 --> 00:17:59.519
Are you not also sort of moving into a discussion where you actually have the discussion cloud on-prem or on device?
00:18:00.240 --> 00:18:07.519
Yeah, um, I'll say that's something that we're definitely discussing in a lot of different clients and internally at BBD at the moment.
00:18:08.960 --> 00:18:14.480
The cost trade-off, but also the compliance, governance, data sovereignty.
00:18:14.720 --> 00:18:20.720
I mean, I think there's probably been a lot of discussion at the moment about EU sovereignty from a cloud perspective.
00:18:21.039 --> 00:18:25.519
People are really thinking about where they should be running their workloads.
00:18:25.839 --> 00:18:36.960
And small language models make that thought process a lot easier because you're not worrying about installing massive uh GPU-based instances on your own infrastructure, right?
00:18:37.200 --> 00:18:43.680
So I'm not saying people should necessarily go in that direction, but it gives you the option if that's where it makes sense for your business.
00:18:43.920 --> 00:18:51.519
You don't have to rely on these big frontier model providers or the large cloud uh providers for resources that you may not have internally.
00:18:51.599 --> 00:18:54.000
So it makes that discussion a lot easier to have.
00:18:55.039 --> 00:19:01.920
Well during this conversation and also in the article, you talk about uh different things.
00:19:02.079 --> 00:19:07.920
You talk about better prompting, uh limit the tools, make them the right tools.
00:19:08.240 --> 00:19:13.279
You talk also about memory um management, something that we didn't talk about here.
00:19:13.839 --> 00:19:20.559
Um Which of those uh tend to give you the biggest lever if you need to get started in an organization?
00:19:22.480 --> 00:19:23.920
Yeah, that's a really good question.
00:19:24.000 --> 00:19:34.000
I would think it's important to mention here that um some of these can be complex things and it doesn't always make sense for an organization to start off with these from the get-go.
00:19:34.559 --> 00:19:35.119
Right.
00:19:35.440 --> 00:19:49.119
So what we're seeing is in some cases um it makes sense to actually build your own agency harnesses, and that's for really complex workflows, complex use cases where you need this type of benefit.
00:19:49.519 --> 00:20:03.279
But if you're looking at the more general use case, ones that aren't uh specifically complex, I would say very much so trying to limit the amount of context that goes into your model is one of the big kind of gains that we're seeing.
00:20:03.599 --> 00:20:10.720
Because the more you put into these models, the more attention you lose, and the more reliability you lose in turn.
00:20:10.880 --> 00:20:17.359
So I would say things like your prompt, making sure that they're streamlined, making sure that the context that you give is narrow.
00:20:17.519 --> 00:20:24.079
So try not to give it an entire folder, try to give it the specific files that make sense for the problem that you're trying to solve.
00:20:24.240 --> 00:20:27.519
Um, that's also where semantic search comes in that a lot of these models have.
00:20:27.599 --> 00:20:30.960
They're searching for the specific context that makes sense for the problem.
00:20:31.119 --> 00:20:32.319
And then your tools, right?
00:20:32.559 --> 00:20:36.400
Try not to install just any old tool and skill that you see.
00:20:36.640 --> 00:20:41.839
Often what it does is it bloats your context in cases where the agent is never going to use it.
00:20:42.079 --> 00:20:51.440
So for each kind of problem that you're trying to tackle, really focus on getting the context, the tools, the skills in place that are relevant for the thing you're trying to solve.
00:20:52.559 --> 00:21:03.599
Well, Jason, we're almost at the end here, and uh I just want to make um uh a summary statement here, and you tell me whether I'm I'm right and if I understood well what you uh you're saying.
00:21:03.920 --> 00:21:16.960
So you say a company AI platform maturity is directly correlated to the success of deployments of Argentic AI and also related to the cost management to it.
00:21:17.759 --> 00:21:18.720
Is that correct?
00:21:19.200 --> 00:21:21.119
Yeah, I would definitely agree with that.
00:21:21.359 --> 00:21:26.559
Um like I said, you need a foundation to build and scale out these solutions, right?
00:21:26.799 --> 00:21:33.680
And I'm not talking about small, little individual implementations, I'm talking about broad enterprise adoption.
00:21:33.920 --> 00:21:45.680
You need that platform foundation to build in the guardrails, make sure that you're ready to adopt and scale AI solutions across your business, and I think that's where a lot of focus should be placed.
00:21:46.000 --> 00:21:48.880
And why should you be ready looking forward in time?
00:21:49.039 --> 00:21:52.720
Do you expect every company to be at the high level of maturity?
00:21:52.880 --> 00:21:56.160
Or right now I think many aren't.
00:21:56.400 --> 00:22:01.359
And I think for many, it doesn't make sense to build that capability internally.
00:22:01.599 --> 00:22:05.119
Um, we're seeing a lot of providers coming out with offerings.
00:22:05.279 --> 00:22:08.000
Let's look at Versal and Cloudflare, for example.
00:22:08.319 --> 00:22:14.640
I think that a lot of companies, especially smaller ones, it would make sense to just adopt those types of offerings.
00:22:14.960 --> 00:22:24.799
But for large enterprises, I definitely foresee a large focus on building out that platform maturity internally to enable this broad AI adoption.
00:22:25.200 --> 00:22:30.640
Now, most of the companies that will listen will probably reflect and they'll think, Jason, come and help me.
00:22:30.720 --> 00:22:32.640
So how can they reach out to you?
00:22:33.119 --> 00:22:33.519
Yep.
00:22:33.680 --> 00:22:38.400
Well, if you need help with setting up um agentic AI platforms, we do have experience with this.
00:22:38.559 --> 00:22:39.440
You can reach out to us.
00:22:39.519 --> 00:22:46.319
Um, we're at bbdsoftware.com, or uh you can reach out to us on LinkedIn, contact me personally, and I can refer you to the correct people.
00:22:46.640 --> 00:22:51.039
Well, thank you very much for joining us today, Jason, and thank you also to the listeners.
00:22:51.119 --> 00:22:55.759
Please stay tuned as we're gonna do more deep dives here on Tech Unboxed.