Welcome to the Practical AI Podcast, where we break down the real-world applications of artificial intelligence and how it's shaping the way we live, work, and create. Our goal is to help make AI technology practical, productive, and accessible to everyone. Whether you're a developer, business leader, or just curious about the tech behind the buzz, you're in the right place. Be sure to connect with us on LinkedIn, X or Blue Sky to stay up to date with episode drops, behind the scenes content, and AI insights. You can learn more at practicalai.fm.
Now, onto the show. Welcome to another episode of the Practical AI Podcast. This is Daniel Weitnack. I am CEO at Prediction Guard, and I'm joined as always by my co-host Chris Benson, who is a principal AI and autonomy research engineer. How you doing, Chris?
Doing great today. How's it going? It's going great. And I know this is going to be a great conversation for a few different reasons today. One of those being our guest is one of the speakers at the upcoming Midwest AI Summit, which is going to be amazing.
There's going to be a bunch of amazing speakers there. I'm going to do a bit of MCing, see if I don't mess that up. We'd encourage our listeners to check that out October 15th in Indianapolis. You can get 20% off with Practical AI 20, so check that out. So, amazing speaker.
Going to be at the Midwest AI Summit. Also a fellow podcaster, which is great. One of the hosts of Cloud Foundry Weekly, and a tech marketing whiz at Broadcom-Tonsu-VM-Wear. So welcome, Nick. Great to have you.
Thanks for having me. Great to be on the show. Excited. Also excited to see you all in person in Indianapolis. Yeah, it's going to be fun.
We're representing the good representation of the Silicon Prairie here. I like it. So, yeah, Nick, I know you're going to be talking. One of the things I thought was cool about your talk at the Midwest AI Summit is you bring in this concept of taking agents.md and shipping that to a production environment where you run an actual agent in an, quote, enterprise environment, which seems to be really fascinating. We recently had on someone from the Agent2KI Foundation who is kind of stewarding the model context protocol and agents.md and those sorts of things.
So very relevant kind of carry on from that conversation. But I'm wondering as we set that up, what exactly does it mean to be operating in an enterprise environment? What you're working with, your kind of day to day, what makes an enterprise environment an enterprise environment? What are some of the concerns or characteristics of that type of environment? And I know you're always experimenting.
You do a lot of home lab stuff as well. So always have a whole range of experience in working in different sorts of environments. So yeah, if you could just help us understand from a general perspective, what does that mean when you say kind of enterprise? Right. So yeah, if we think about the enterprise, we think about a few things.
One, let's just assume you're going to have not limited or no internet access. And I've been at Vee Martingay for about five years. And before that, I was at one of these large enterprises for about 14 years. So when we had vendors come in, they'd always be like, they'd always assume that we could just go to the internet. And I was always like, well, try again, because that's not going to work here.
So that's kind of always like the biggest hurdle where you're going to be regulated and or you're not going to your way. You can do at home. It's not going to be what you can do at work, so to speak. So you're going to be highly regulated. You're going to have to deal with potential like PCI or SOCKs compliance or HIPAA or FIPs or any kind of thing.
And I could probably go on and on about all the different compliance tiers that you'd have so it's just a whole different ball game where you could potentially do something that has dramatic consequences. And you have a highly controlled, highly regulated environment where even some of the customers I work with are like, they actually have the real air gap or we're carrying in things physically into the data center because there is no internet access type of thing. So it's a wild world, but it frustrates a lot of new folks to the enterprise base. But if you've been in a while, you know how to deal with it and how to handle it type of thing. And I guess people have been dealing with these types of environments for quite a while, because there have been enterprises for quite a while.
Maybe just give us a sense of leading up to AI agents. And we'll talk about agents here in a second, but leading up to AI agents, what were some of the ways that you could, I guess, put some ointment on those pains of working in that sort of manner? How would you get an application into that sort of environment or have it be enterprise ready, quote unquote? And then we can shift and talk about what changes with agents. Yeah.
So I think I currently work for more Tansu and we run a platform as a service geared for private cloud, whether that be on your own bare metal in your data center, or you could deploy it on a private cloud in your own, like VPC on hyperscaler, that type of thing. But we think about that. We want to, in the scope of enterprise, you have all these regulations, controls, et cetera. You want to make that path to production kind of the least resistant and easiest path. And if you make that path production, like all the check boxes, and everything good to go, that's going to be a highly adopted path.
So the whole concept of Tansu platform, it's actually based on an open source project called Cloud Foundry, which is, I think, predates Kubernetes and Docker. So 2011-ish is when it kind of started originally out of VMware and spun out and then became part of an open source project. So it's been around in battle testing, seeing a lot of things where you have that concept of, like, I just want to take my code and send it to the platform and the platform is going to know the best practices for, it's going to build a container for the developers, so the developers don't have to worry about securing the container or anything like that. The platform will take care of that. It will handle ingress, like certs, certificates, all the load balancers, all those things just handle health monitoring, potentially even kind of like sandboxing the apps from each other.
Maybe some of these labs may learn from, but the apps can't escape type of thing. And if the app needs services like a database or messaging, middleware, anything, even a large language model, it can, what we call, bind or connect to a service on the fly. And that's all handled underneath the cover. So it's just a few commands, like you push bind the scale of your app with just a few simple constructs. And that's how you go to production.
And what we see with enterprises, what's that path, once they take this, it's been certified, they're all these different standards. It's just kind of like an unlock for these enterprises because it's so easy and so simple to use. And they don't have to re-certify everything. It's just like this framework that you can use to get apps into production. And the biggest thing is that you want these enterprises or the businesses that don't want their developers hand crafting a new platform or a new way to deploy apps for every sub-team and have like a hundred different snowflakes, right?
They want the same repeatable pattern across the board so they can audit it and secure it and have their developers actually spend time writing the business logic versus fiddling with infrastructure. So that's kind of like the whole premise behind the platform is just construct and you know, it is a platform. And as you can imagine, go ahead and yeah. No, no, go ahead. Finish up and then I'll follow it.
All good. Okay. As you can imagine, those principles and we're talking about apps could probably play nicely into this agent world that we're living in. So it sounds like you're drawing a lot of commonality between kind of traditional app development and all of the structure that we're all used to. We've been doing forever and kind of now we're into the sogentric world and maybe people have been thinking about that in a different way.
But it sounds like you've really kind of said, and correct me if I'm wrong, I'm going to throw something out here, like it's kind of the same thing in the sense of, there are differences but agents and apps should sort of be treated the same way. Is that, am I getting that correctly in terms of how you're structuring that and that maybe people need to look at what they've been doing for years and make that work for agents in the same way? Is that, is that a fair? Yeah, I think it's a pretty fair assessment and we're starting to see that more and more just within our customer base. And you know, even like if you think about like apps back in the day, like someone would write some app on their laptop and like run it on their laptop, but it's like, we can't just run out, you know, like you got to get it off your laptop somewhere.
And the same thing with agents, like I got this, apparently these agents from my laptop, if I shut up my lid, everything stops. Like I don't really want that to happen. I want that to run 24, 7, 365 and do all the work I give them. So yeah, I think that's kind of precisely what we're going with. So I guess then begs the question, why are people kind of throwing out what maybe their intuition, like in certain ways people are saying, oh, we have agents now, we need to do something totally different, which is maybe driven by some things that make an agent not, not just a sort of simple application, but also it doesn't necessarily mean, you know, obviously we have to throw out everything we've learned about platform engineering and how to deploy things.
So in our mindset, what, where does the kind of agent equals just another app? Where might that fall apart? Or what are the kind of unique characteristics that you're dealing with on the agent side, on the deployment pathway that you might not have had to consider before or at least are considering it anyway? Well, I mean, I think some of the biggest differences, right, where like you talk about Cloud Foundry and Tensor platform, it was kind of based on this premise of a 12-factor application, where like storage and state are a little, you know, decoupled cleanly from the actual apps, you could like, you know, like, I can scale up to a thousand instances and be fine and you handle session-stating things. The traditional harnesses are agents.
We're kind of built originally just like, ah, I've got file system access. I'm not going to write about your empty files. And that's like my memory. Everything's great. And you're like, well, you start to get into a cloud world that things spin up and down in a ephemeral.
You're going to want to save those empty files somewhere. They're going to go off into the ether. So that's probably the biggest challenge when you start talking about how do we take the app deployment methodology, right, and then push that into like an agent running on a kind of a cloud platform, per se. It's probably the biggest challenge. And then just kind of getting the fact that there's some valid use cases for like your laptop or whatever, but then also as we're starting to see more and more, like enterprises want agents to be on demand and like usable kind of in a, like say, in a CI CD pipeline or like on, you know, within part of their, you know, e-commerce suite or just normal applications.
And you want those to be kind of really close to the apps, right? Because if you're, if you have them way off, you know, even just from a peer networking perspective, if you have, you know, the agent or the LOM or whatever, that's like, you know, 30 hops away from the microservice is trying to call it. There's, you know, physics that are going to add on to all of that latency and potentially at scale, even be problematic. So they kind of want to co-late all the, and co-locate the intelligence with the app and the data as close as possible. That's what we've seen too.
That's something that I didn't expect really because some of these, some of these responses are kind of long, but it's like, we, we see with our customers at scale, like, we want to get the LOMs and the agents closer to us and our actual apps using them and the people using them as well. And not to mention if you're using some of these SaaS providers, they're maybe not the most reliable in terms of what traditional enterprises expect in demand. So you can't just have them, you know, going offline for hours, because, you know, even at my past job, the very first thing I did there was work on a warehouse inventory system. And I was just, say, it was for a large retailer, that was a grocery retailer in the US. And I was, you know, intern out of college and the app was older than me at the time, still older than me.
And, you know, it was a bunch of like, you know, you know, C and shell scripts on Unix systems. And if that thing went down, like within five minutes, like the warehouse was backing up trucks like on the interstates. So it's like, you have to like the scale of enterprise, which is just, you know, having a, you know, like consumer is a completely different scale. So that's why some of all the things we're trying to make them a little bit more enterprise grade and more, more used to what these enterprises expect from software. Some mornings as I'm drinking my morning coffee, I listen to live news updates to figure out what's going on in the world.
And it seems like recently everyone is talking about AI kill switches. But the reality is that there is no one AI kill switch. We've moved from models to agents. Those agents are connected to multiple models. They have an agent harness.
They're connected to MCE servers and tools. And those agents are acting within a fleet delegating to one another and interacting with one another in that environment. What you don't have is a single kill switch that solves all of your problems. But that doesn't mean that you can't exert your control. You just have to exert that control across various layers of that stack through, of course, component input output safeguards, but also controls on agents tied to their agent identity, things that track tool misuse or memory poisoning or gold drift, et cetera.
And what we're providing at Prediction Guard, the company that I lead personally, is an AI control plane that you self-host in your own infrastructure that gives you that control plane or control layer for the relevant stack that agents operate on top of. I'd encourage you to check out what we're doing at predictionguard.com slash practical AI. Go ahead and book a call with myself and the team to learn more about how you can gain control of the agents operating in your environment and exert zero trust principles in the way that you operate those agents. So check us out at predictionguard.com slash practical AI. That's predictionguard.com slash practical AI.
So Nick, I would love to dive back. I want to kind of build on what you've been sharing so far. And part of that is that we're all diving into this multi-agentric world where, you know, some late last year, you know, you'd have an agent. And then, you know, for most people, I think, getting into multi-agents, it was probably developers and the environments that the AI providers were making available and you had multiple agents working on the project. But now we're really seeing, you know, with these work products and other things that have come out, we're seeing agents really multiplying across, you know, many different contexts and with a lot of different utility.
And it's moved out of being just frontier services. And we're now doing that with our hosted agents as well that we're running. And so like this multi-agentric world has just taken off in a very short amount of time. And as you're, as you, I'm kind of, I guess I'm asking if you can kind of paint a picture as you start scaling this out in the enterprise and what that looks like. Like, could you describe, you know, and we have analogies as you've pointed out with kind of the traditional software development world and the containers and all the, you know, and how you're structuring deployment and stuff.
Could you talk a little bit about what that looks like, kind of paint a picture so that somebody can really get that in their head on me, first of all, about what that multi-agent world looks like when you were doing, when you were doing all these right things that you need to do in the enterprise. So I mean, I think that the first thing that we want to focus on is that the enterprise, you know, needs to get whatever technology approved throughout their system. And then we, so we are providing a harness called the Tensor Agent Build Pack and that helps to that process. So our existing customers already have our customer, you know, we're already approved so that we can help provide them those tools. And we just make that process just another app deployed on the platform.
So I probably haven't covered this yet. I'll explain what I build pack is, right? So when you, when you, I was about to, I was about to ask you that if you kind of dive into what the specifics of each of those things does. Sure. So when I would do demos before AI and before, you know, later, two or whatever, we would always take like a Java app and it was like a simple kind of like, you know, music album called it's pretty music or whatever.
But we take that Java code to be like a jar file, like compile Java code and we're like, all right, now we're going to take this, we have a little simple manifest file that tells us what the name of the app is, how many, how much resources to give it. We just want to command the called Cuplish and that would then just take that code, the jar file and upload it to platform and the platform would be like, oh, it's a Java app. So I'm going to use the Java Build Pack and the Build Pack is basically kind of a command set to make a best practice container based off that use case. So the Java Build Pack knows to do all the JVM memory calculators, do the JDK certificates and everything that's best practice to run Java in a container on a cloud platform. So we're going to do it at, you know, we would attach database and, you know, all these things and show how that scales.
Now we've taken that same concept and then said, hey, we're going to have this agent, we're going to see a push an agent and instead of like, you know, machine readable code, we have a human readable language, the agent's empty. So basically you tell what the agent it's going to do and then you just push it to the platform and it starts up with, you know, within a minute type of thing and you can scale it up, you know, push as many agents as you want. And I think the coolest thing I've seen is that once we're on the platform, then we can run models on the platform. So, you know, obviously a lot of our customers are air gapped and some of them were, we're smart enough to buy GPUs a few years ago. So some of them have lots of GPUs that can run all these local models and have a great experience.
Some are wishing that they bought GPUs and, you know, hardware as the pricing of all this hardware goes through the roof. But then they can run local models and tie the agent to that or if they don't have, you know, they might have a contract with them, another cloud providers or one of their, you know, one of their approved LMS a choice and we can register that. And then that kind of gave us a simple like, here's your out of box agent with chat experience. And then, you know, along the way, like we've done a lot of things with MCP, same as the model context protocol. I probably you guys covered that on the show before, but it's, you know, basically way for an app to talk to an LMM like very, very high level, right?
So we, that's become, you know, useful as well as we then give the agent tools via MCP service and even at Broadcom, like the only way approved way to use for our developers is to deploy MCP servers on, on Tensor platform so that we have a whole set of MCP servers that are improved and hosted and they're kind of secured and maintained because they're very similar to applications as well. And then we have a concept of like the MCP gateway service that kind of registers that and secures all those servers so then we can then extend the gateway to that agent. So then the gateway, those agent now has like secure access to a runtime, you know, battle test runtime. It can talk to an LMM that's approved and get tools via and gateway. And then we're starting to add in like the memory service as well to have kind of a shared memory service.
So we're kind of expanding all of that out where we're seeing all those best practice app, lifecycle, go to, you know, see a push, go, here's an agent, here's all the things it wants to do. And then, you know, it can be a security review agent. Like one of the things I showed, I was like, I think a week or two ago, I can't quite remember, I was in Las Vegas for a conference, we were exploring and I had like a five phase demo where I walked through this. Maybe I'll show a little bit of this at the Midwest summit here, but, you know, push the agent bind, bind all these services at the end goal was like the boss level was like, all right, now we have these agents sitting in there and I can hook them up to a repo with like an event listener or a webhook and say, all right, now do a sick, like, you know, issue five on my repo to a security review on this repository.
And then like, it sends it off to the agent via a webhook and like, oh, the Tensor agent and like it just fires up, it gets it, you know, fires up on the platform, it gets a request and it's just immediately pulls down the repo and starts doing a security review and then publishes or pushes up to the issue that I created on GitHub and says, this is security review. So you can see how that flow would be really useful in enterprise where like maybe on every get commit, you just have all these agents spinning up on the fly that could be a security review agent, you know, potentially like a, you know, a style or, you know, code quality review agent or potentially even like a, I don't think it may be a design review agent all firing up on the fly as things like call. So it's kind of like, and then they all have their, they're all in their own little sandbox and everything's proper because part of, you know, the platform for a while, it's been like this very secured container runtime where like we have, you know, they can't talk to each other unless you've enabled them.
So they can't go to the internet, unless it's enabled, they can't, you know, escalate otherwise they only get access to what you give them. So it's kind of that benefit as well. And then obviously they're containerized, they don't have access to the underlying host system as well. And so as we've seen, you know, some of these things of uncritual agents forms, I think we have some remedies here that some of these, some of these AI labs could maybe take into account and implement some best practices that's when throughout the past two decades. The unplanned swarms.
The swarms that you don't necessarily want. I actually have a two second follow up. And that is, it's, it's for my benefit. And you know, we've talked a lot on the show over various episodes about agents, you know, using MCP to get access to different apps and services and tools and stuff like that out there. We haven't really talked about what an MCP gateway is.
And I was wondering if you could share that for a moment, just as a detail because that's kind of the one little new piece of architecture that we've never touched on on the show. Sure. Yeah. So if you think about MCP gateway as a way to easily control and scale access to MCP servers, especially within a cloud, like it's platform. So we may have like 30 or 40 MCP servers that we run around.
I don't know how many it is, right? And then those get bound, those get registered and bound to certain specific MCP gateway. So maybe there's, you know, and the MCP gateway is something we can spin up on the fly on the platform. There are many different MCP gateways out there. There's many different AI gateways out there.
Some of them are like the same, the one in the same, but you basically register MCP servers to this gateway and the gateway kind of controls access, so to speak, and regulates that. So you may say like, you can bind to this gateway and you only get these MCP servers. You only get these MCP tools within it, that type of thing. So it's a way to easily abstract all the different MCP servers that may be an organization and kind of direct them into a certain, either a certain agent or we even have a flow where like you can take as MCP gateways that we run that front, all of our MCP servers. And then you can say, Hey, go give me a way to connect this to my cursor or my cloud code or my whatever.
And then it just injects it in there. And then your local agent has all the tools that are approved as well for your organization. And then it's just like a simple click and then it just registers. And like depending on the MCP server helps the panel the office well, because some of them are like, well, if it's my, if I'm using the GitHub MCP server, I want to pass my end user credentials all the way through the MCP server, because I don't want, you know, I don't want it just to be like, well, here's our generic service account for the entire organization and every GitHub action is going to be, you know, seen by that one account. You have to have the individual identity pass through.
So you have like the concept of like SSO and sign in as well for an identity for agents or humans running their agents on their desktop. So that's kind of a quick level of you. And then we're great way about that too, because it's all flowing to that gateway, we get metrics out of it so we can see all the tool calls and all the events happening coming from the agents to the MCP servers and back and forth. So you can kind of see what's happening, especially if maybe if there's something unexpected, you're like, well, this one agent, you know, made 200,000 tool calls to, you know, delete repo, like, oh, like, maybe we should alert on that. Like, that's probably not good.
Yeah. So, you know, another visibility or metric to see what agents are doing, you know, what tools are doing as well. So I guess hopefully that made sense because that was how I understand it. Right. Yeah, that was great.
And there were a couple things that you mentioned in there I think are additionally worth digging into. And you kind of have this, if I'm understanding right in part of the build pack that you're working on, part of that centers around kind of pushing an agents.md file, you mentioned, like, people have these MD files hanging around, you mentioned memory, you mentioned identity. I'm wondering if you could kind of help us understand, like, if I have, if I'm working on my laptop, right, and I'm using a certain agent harness, I may have an MD file that is kind of generic. And then I have files that are created by the agent that it uses that are only corresponding to my single agent.
And then I have, you know, memory and then, you know, calls into other things as you're pushing this, like, off the laptop. Now I imagine taking that off. Like what belongs in like an agents.md file and what is like, as you were giving that example, right, you may have one agent in the platform that is a security reviewer for the security reviews, right. When you spin that agent up, does each instance of that each session have a unique identity? What is the, what's unique about that session and the data that that is generated by that session versus maybe the things that are always static?
Like, I'm not sure if the agent's not MD is always static. So could you help us understand, like, which are the static elements? That's developing over time. How is that like state of the agent spread across, you know, the implementation, I guess? Sure.
Yeah. So if you think about it, like, in this specific implementation, the agent's build pack is basically like the boilerplate code of what you want the agent or app to do. So like, I'll do demos and I'll have to be like, you're a pirate. Like, like, one of my demos is like, you're a, you're a, you're a, you're a, like, you're a senior software engineer. You know, you're gonna, you're gonna watch this Jira, like a page or I forgot the terminology here.
I basically like, watch this Jira queue and look for any inbound tickets as inbound tickets come in, review them and like, you know, make sure they're a good quality. Like, here's all these different things you want to do and like, don't do any of this. So it's more of a very simple agent something where like, it's just ton like this agent, what it should do and how it should act. And then you can call that and how like, all right, well, like, you know, ticket 500 came in and it was poorly documented and like update that Jira ticket and you know, whatever. And then you can add some things like talk like a pirate.
So it's like, all right, make two, you know, it's like 500 is terrible. Like, like go back and, you know, update that type of thing. So that's kind of where that static part of it is. And then like the memory service we have, we can attach it. You can have, you know, potentially memory of a certain project.
But you know, we kind of envision like each set of teams that have their own multiple set of agents, right? And it could be like, well, you know, team A's agents have the access to team A's memory. So as they come up, they know like all of this historical data of like what, like the architecture of the application, the, you know, what's been done before, you know, like the roadmap, that type of thing. So as it spins up and does like a security review, it can make, you know, proper decisions and proper guidance so that, you know, as you kind of build your local agents and kind of give them memory and they become smarter that memory service as you have agents spin up and down. They just immediately immediately know what's happened before, know how to proceed.
As you heard at the beginning of this episode, some amazing people like Nick, who's the guest on this episode, are joining us at the Midwest AI Summit October 15th in Indianapolis, Indiana. Nick is going to come talk about what it looks like to deploy AI agents in real world environments. And we've got a bunch of other amazing speakers talking about how AI enabled teams work, how to make decisions about what to say yes to and what to say no to in relation to AI and much more super practical and amazing talks. Plus there's going to be an AI engineering lounge where you can actually sit down with folks like myself, I'll be there, get get review on your AI architecture, your stack, your roadmap, et cetera, towards the rollout of things like agents or other AI technology.
This is a practical amazing event that you don't want to miss. There'll be great food, great people, great networking and practical value. Do not miss this. It's October 15th in Indianapolis, Indiana. And you can use the code practicalAI20 to get 20% off registration.
So go to midwestaisummit.com and use the code practicalAI20 to get 20% off registration. Before we were going into break, I think I may have cut you off when you were just starting to say something, you want to dive back into that real quick? No, I think I covered it. I think I covered it. I'll probably answer the question again.
That's no problem. Okay. So really, I really like this has been really good for helping me try to conceptualize, you know, how all this fits together. I think I had some understanding, but you've gotten a level of detail. I want to ask you, as we are looking forward, I have several questions that are really kind of driving my thinking.
You've got me thinking creatively based on what you said. As you look at, we talked about MCP, there are new things coming out, things like, you know, there's the A2A, which is the Agent to Agent protocol, and organizations are starting to look at that. And they already have their MCP servers, maybe, but they're trying to get the structure and kind of bring the sanity around it that you've been talking about. Then they kind of go, oh, okay, it's not so different from what we've already know. But as this is evolving very fast and you have things like these new protocols, do you have any guidance on how to start integrating this constant flow of change in terms of, first on the technology, and I'll hit the other half of that afterwards.
But if you're trying to bring things in and make it work, and have you guys thought about how to structure that? I think it's, I mean, I guess we'll just say take baby steps from everything, right? Because especially when you talk about the enterprise scope, they can be a lot slower to adopt some of these new technologies. So you kind of layer that on, and you don't have to necessarily adopt all of these things at once. You can maybe just get a simple agent running.
For most, those places, just getting access to an LLM is still the biggest hurdle, right? A secure proof. And then potentially, you know, going through the AI, AI Council or either committee, right? Like everything must run through the council and be approved. If you know, like most, you know, if you're not, if you never worked in enterprise, most large enterprises have a company.
So I know something. For everything. It's like, well, we shall go to the committee and we shall present our idea. We'll wait six months and see what has the result been, right? So you just got to have to work through the councils and the committees and all that fun.
But once you finally get something approved, just just iterate and you're like, don't try to boil the ocean, make baby steps, you know, and get progress. And then as you'll like, and you'll learn the technologies, then the next step will just kind of be obvious. And then you'll get to make the agent better if I get some MCP servers, get them tools. All right. And then I've got these tools approved and then add on to that.
And then, you know, you know, and some of these guardrails help, you know, of native platform help enterprises bring these tools to light because it's not just, you know, all this random stuff downloaded from the internet, right? Which that can be its own danger nowadays. So having the, you know, having some guardrails in place is a good thing. If you've had, you know, if you have experience with some of these platforms or apps running before, take that, take that experience and that knowledge and kind of bring it forward and utilize your existing people and skills. I think too, I think a lot of times, I've seen organizations like a new technology will come up and that a new team will be built and that new team will decree, but there's so much other like really skilled people that could help.
And it's always kind of a friction too. So how to try to get the teams to work together too, not just have the new team do all the new things and then the teams, the teams have been there all the while have that. Like that's always another constant flow. So try to try to break those silos down as well to help, you know, get people up to speed and get through that process. Having worked in multiple enterprises myself, I think, you know, that last point, I think I've seen that multiple times across different organizations and, you know, how do you bridge that?
I think part of it, you know, you have, you kind of have every organization has its internal politics, they all have kind of the different structures. It's really common, say new tech, new team there, but then I think people recognize, you know, why? You know, that kind of, you'll see that and sometimes you'll see a reconciliation, but it always seems like a little bit of a struggle when that happens. You can try to, you know, do you have any thoughts around as you're trying to do that? You know, you may have, you know, a lot of big organizations have, you know, they're very like one, one business unit, maybe almost like a different universe from another business unit sometimes.
And so how do you get that kind of cross adoption where you're taking advantage of maybe both the new teams that may be there, but also some of the old structure teams and you're trying to spread the capability across the larger organization in a useful way? Do you have any guidance? You know, I imagine it can't be that different from, you know, the more traditional app dev side, but I think, I think this is a struggle that a lot of, that a lot of forms are facing right now. Yeah. Well, I think, yeah, so I mean, it goes, I think a lot both ways.
So if you have the new team, right, the new team can look, the responsibility team is like, engage every other team because they have a lot of people that can help you out and achieve your goal, right? Because the new team probably most likely has a very stressful and like, you know, like adopt AI everywhere or before it was like go cloud everywhere, right? Like those goals are like not quite easy to get going and enterprise. But the new team needs to like, you know, it potentially run, you know, office hours, weekly office hours, reach out to their other teams, you know, maybe before, you know, like, like a lunch and learn if you're in the office and have people in the office, that type of thing and just have like a forum for people to come in and learn and get started and like ask questions and not, you know, like, Hey, like I saw this, you know, this post about, you know, this new platform or this new AI thing.
How do I get started? Is there any documentation or what can I do? I can I do get started and just kind of have like an open and like, you know, very welcoming place to get started to bring in the folks and then if you're on some of the, you know, let's say not new teams or teams that have been around while being engaged and reach out to those teams because a lot of the new people are going to need help and like, you know, they're maybe under stress. So it's just breaking that down. And then I think with this iteration, right, it's going to happen a lot faster than I think people just naturally want to work together because I think I was at Veeamix floor and I did a few talks and I started every talk with like, all right, let's get a show of hands in the room who has used one of these tools like in at work, like cursor, clock code, whatever.
Pretty much the entire room and all of them went up and I was like, well, that's a lot more than I expected. So like the adoption rate, even at, you know, the traditional like, you know, platformer, developer, engineer, and you know, or just infrastructure admin at some of these personas as well into that scope. So the entire enterprise I think is picking up on this really fast and you know, the more collaboration I think it just will help out. So, you know, just office hours, you know, reach out, be proactive. And I guess if you're on if be be be mindful or be open to change, I just, this is just in general, if what I've seen before and if you're resistant and resist the change and you know, that's that's going to kind of get you labeled and kind of put off the side.
But if you're, you may be, you may have your own opinions, but if you present them in a way, that kind of is, let's say, maybe open minded per se, you have a better chance at some of those key learnings that you've dealt with throughout your career to actually be applied in the new way as well. That makes sense. I'm curious. I want to circle back for a moment on something you said, as we're talking about kind of spreading across my mind goes to security because I know in, you know, in my industry security is a pretty big deal and we do have air gap things and stuff like that. That's what we do in defense.
But as you're thinking about that, you know, one of the topics that is a really common topic now is kind of going back a few weeks, we covered it in depth on a previous episode, that the whole open AI swarms got out, hugging face that whole thing. I offer people back if they don't have to know if they're not familiar with it to our episode recently, they covered that. And but that is top of mind. It's not only top of mind for security, but it's top of mind for legal. It's top of mind for comms as they're thinking about what do we do?
It's something like this where to happen in artwork, whatever that org is. And can you, can you talk a little bit about, you know, as you've, as you've kind of brought the enterprise structure up to date to deal with agents and, you know, it's, we're beyond just the traditional software and app world and we're, we're taking some of the same lessons and reapplying them in a new context here. Can you talk a little bit about how that helps on the security side? If for the folks out there that are really, you know, that's their job is to keep things from really going awry. Can you talk from a moment about keeping things in the box, if you will?
Yes, for sure. And then I guess I'll put a disclaimer. These are all could be suggestions that the help out with. If you really dig into some of the hugging face stuff, it's a little like scary. So I'm not to say that we're like better than all of the iLabs or anything like that.
So, but if you look at some of the things or how that kind of got started is where they, you know, like started getting out of the sandbox, right? And then they found things that were like, they could get access to, or, you know, having monitoring control around what those apps or agents can do is, you know, something that's been, been in mind for all enterprise apps, right? So like having, you know, kind of guardrails, even like network zones. Like, hey, this is a highly regulated zone. It's super locked down.
Like even just like traditional firewall would have potentially blocked a lot of this stuff, right? So it's kind of key, like, you know, a lot of the core enterprise learning to kind of maybe take that for like, you know, the old team or some new team. Like, well, guys, you get to just, you know, I don't know, had some basic controls. And like, I think they've talked about like, their monitoring wasn't working and they weren't really monitoring it and like, you had all these agents, worms. And then of course, then they got to the artifactory, which then found the weak link and the artifactory had internet access and somehow they magically, you know, zero data, the artifactory instance multiple times.
So not to say that we could prevent everything, but it's just, you take those, at least core enterprise technologies that maybe would have helped out a little bit of just, you know, agent control, like hardened sandbox type constructs, very, uh, lockdown network controls. Um, that would help a little bit potentially, um, you know, just, you know, monitoring what's in the, in the agent, make sure that the agents are, you know, somehow injecting tools that they're not supposed to have. I'm not sure if that was an issue or not. But you know, when you talk about an application that whole dependency sack is always up to up to ground. So you want to make sure that the dependencies sack, container, everything is in the whole OS and the whole platform is trying to patch and reliable as possible.
So it's a, I think the key thing is obviously, you know, we have the whole mind bending effect that they somehow made this messaging board on artifactory and then they got to lead it and they recreated it. So there's that factor, which I think everybody's a little like, that goes into the whole AI is going to kill us thing that happened over the weekend, right? Versus, uh, just do some basic security and basic stuff, right? Just to clarify that. So, yeah, yeah, yeah, yeah, yeah.
If you're not on AI Twitter or AIX, there's a lot of posts around, you know, somebody left anthropic and a bunch of anthropic people start posting around that they're afraid that, you know, there's a greater than 10% chance that AI is going to, you know, take out humanity over the weekend slash Friday and then that started up a lot of conversation, let's just say. So that's what I was referring to. Yeah. Yeah. Yeah.
Okay. Um, I guess that's useful. I appreciate that. I, we like to finish off by kind of giving you kind of a free form question and that is kind of toward the future as you are doing your job and, you know, running your podcast and talking to people and kind of building up, you know, your perspective on where things are going with this. We ask, we like to ask guests to go ahead and get crazy and prognosticate just a bit and we don't hold you to it.
But like really the way we do this is when you're, when you're kind of just letting your mind wonder and you're thinking about these things in the back of your mind, going to bed at night, having a glass of wine, whatever it is you do to chill out. What do you think things are going? Like what, what, and you can choose the timeframe that you like, but I really like to think like, what do you think is coming? What's next? Um, why, you know, what, what should, should orgs be having a thought toward for the future, even if it's not, even if we're not there yet today.
Um, any, any thoughts on what that future looks like as we close out? Oh boy, it could be, it could be many things. But I think from a enterprise perspective, I think we'll see a lot of like team change and I didn't, we're all changed. And not even just an enterprise like the whole like, from the business side, things are going to change a lot, right? Cause you start to see, and I was going through old episodes of my podcast this year and just some of the old, this started this year and there's just now was like, wow, has a lot has changed.
Like, I can't imagine like, can you like, you know, imagine a couple of years from now, how much change, the rate of change is now. It's excellent. It's, it's hard to imagine that. But I definitely think from a business perspective, we're going to see like a radical change in like how, you know, development and your product management and everything changes or everything kind of, you know, there should be like new roles get created, you know, orgs are going to change. I think, I think for the good to you, cause I think there's always a fear of job loss, but I find that I, and I've heard this echo across many personal experiences, I'm like working harder than I ever have, cause I have all these agents and they like, they need stuff for me.
I'm constantly like, I'm doing building things that I always wanted to build, but just never had the time to you. So, um, I feel like we're all going to be busy and it may be, maybe we need to, you know, not not get too crazy with agents, but it's hard for me cause it's, it's, it's fascinating. It's just, it's really enjoyable. So doing a lot of things with automation, I can only imagine what these agents are going to be like in the next six months in terms of, you know, what they can do for you. I think we'll see a lot with voice come, come into play, maybe even a new style of interaction with the computer as well.
So, um, that will be interesting as well. And then I, obviously I think, you know, did you see that the posts are like hugging face had little robot things on sale? Yes. Yeah. Yeah.
So like a little micro duct. I did. She's like, you have enough toys. You just know. Well, I may have ordered a few for the family and I'm going to go there and go awesome.
So like, like robotics and things like, you know, I think the LLM is great and wonderful, but there's so many more possibilities where we could go that, I guess like for humanity, right? As long as you know, we prevent the Terminator scenario, it'll be great, right? Absolutely. Absolutely. Yeah.
Great. I appreciate you painting that. That helps a lot. Yeah. The rate of change is just insane now.
And I don't, I agree with you. I think it's going to get faster and faster. Um, but great way to end the show. A lot of fun. Always.
And finding those things out however they think things are going. Thank you for coming on the show today. It was a great conversation. I learned so much. Um, really appreciate that.
And I hope you'll tune in to Club Boundary Weekly to hear you talking more about these topics, and they should definitely go to the Midwest Summit and hear your talk. Um, I was there last year, I did a talk. I won't be there this year. Uh, so I'll have to see if I can get a hold of the video on it or something. But anyway, thanks for coming on practically out today.
Thanks for having me. Alright. That's our show for this week. If you haven't checked out our website, head to practicalai.fm and be sure to connect with us on LinkedIn, X or Blue Sky. You'll see us posting insights related to the latest AI developments, and we would love for you to join the conversation.
Thanks to our partner, Prediction Guard, for providing operational support for the show. Check them out at predictionguard.com. Also, thanks to Breakmaster's cylinder for the beats and to you for listening. That's all for now. But you'll hear from us again next week.