Is This AI a Real Game Changer?

Hinzugefügt: 2026-06-02

[00:00:00]I am here with Bruce Henderson, the chief technology officer of Sage-tech.ai to talk about the platform, the technology, the hows, the what'ss, and the wise. Bruce, how are you today, >> Dick? Always a pleasure when I get a chance to talk to you. Your podcast is amazing.

[00:00:16]>> Thank you, buddy. Likewise to you.

[00:00:18]Bruce, let's just jump right in. Take me back to the beginning. uh I did a segment with Deepo Sharma on sort of the the business use and the use cases around what Sage Tech is doing for people. I want to jump jump into the technical weeds a little bit here. First of all, how and why like how did you guys think about this? What problem were you actually trying to solve? How did this all come about?

[00:00:41]>> Well, yeah, you talked to Deepac, which was a good thing. He's uh he's really the business brains behind this. Where the heck did this thing come from? Uh my career Vic has been building and leading teams that maintain upgrade and even retire these massive complex systems that are at the heart of of the economy and the problem is one of throughput right that you can consider me a high-skilled individual and I work with teams of high-skilled individuals but there are very few of us and our ability to spend a day at a customer site or at I mean if you're part of the company working on a given set of problems is limited right and so in 2024 we built built a team um to create this AI system to solve all of that. What if you could take that level of skill, that breadth of knowledge about how software works and be able to upgrade any AI system to be able to handle that kind of cognitive load? That's where it all be.

[00:01:35]>> Wow. So, basically, you were architecting yourselves out of work.

[00:01:38]>> Hey, it's honest work if you can get it right.

[00:01:42]>> That's very anti- capitalism of you, but but very noble to say the least.

[00:01:45]>> Well, no, it's like this, Vic. um as a consultant which is what I did right before I started doing stage my income is renting one of me to one customer for one day right if I can do that as an AI that knowledge can now be employed on hundreds of projects at hundreds of customers around the clock in India in Latia in Chile and Argentina in the United States everywhere at the same time >> yeah that's that is most entrepreneurs problem to solve for sure so why now what was it a new idea Were there constraints before that made this impossible that suddenly now it's possible? And if so, what cracked it open?

[00:02:24]>> So, I mean, even in the present day, we're recording this in the middle of 2026, and the motion that's happened inside of AI tooling and modeling has been tremendous, but they still struggle with the massive complex legacy code bases. And we wanted to find a way to get AI to work efficiently with the millions of line code bases because your history goes back into these various systems. You know, 5 million, 10 million, 15 million lines, stuff that started being written in the 70s for God's sake. Yeah.

[00:02:54]>> How do you keep it alive? How because it is it is one of the the structural supporting features of your business.

[00:03:00]And so when we started context windows were relatively small and everyone's idea was we're going to take the codebase and jam it in to the context window and then start asking AI questions about that. That's very 2024 of everyone and we started in the same place. We quickly figured out that that was never ever going to work because even at that point the big guys were running if you paid extra and that's really only a small program in the in the enterprise world. We were after a much larger game.

[00:03:30]>> Yeah. And so I remember when I remember when this was a twinkle in your eye and we talked many many moons ago about it and you know for the folks who might not have listened to to Deepo's segment with me, why don't you give me the Bruce version of what this is built to do and how it works. So our original focus was that we were going to retire these old systems. I mean there are so many of them out there and and as you know so many of them have been they've tried to recreate them and retire them usually in the cost the enormous failures and so you wanted to uh end up transcoding them into these newer platforms that were easy to hire for easier to maintain and cheaper to operate and then reality hit with our first pilot customer is that we've got at that point a little 10person company in North Texas and were they really going to hand us the crown jewels tools of their entire organization and then allow us to create a brand new version built by an AI and then accept that back into their premise and into their systems. That was ridiculous on its face. Even if it was going to be free, like we weren't going to charge them anything, which we certainly weren't going to do. The cost of accepting this transcoded system, putting it through security, putting it through accreditation, putting it through audit was enormous. And so we quickly found out that there really wasn't an appetite for that. But we did find a route out of this in the ashes of that disaster. Don't bring code, bring knowledge. The stage context graph was born and we organized everything around a mantra which is your AI tools are going to be downstream of something.

[00:05:04]Make sure that it's true.

[00:05:05]>> Interesting. So you wanted to you originally wanted to unpack everything and rebuild it and deliver it pretty back. So there was in a modern code base, modern ways of getting after it, modern ways of maintaining it and moving on from it and adding modules. And you met the front lines, legal compliance, other cycles of acceptance and testing and things of the like. And you went from code to code, right, to code to knowledge. And I I quoted you in another segment here when you told me about the CTO that didn't want his code back. And Deepak kindly walked me through that and explained it to me in a way that was deeper than our passing conversation about it was that he didn't want back the the commodities. He just said, "Hey, tell me everything in this inside this codebase that differentiates me from somebody else. That's the stuff I want back that I want to modernize, make better, continue to grow on." When when that CTO said that to you, was that a bit of an eye openener for you? Did it change the way and the shape you were thinking about this? Yeah, it completely um for lack of a better term, it completely baffled me for a moment. It's like what on earth are you saying? Your entire career is making sure that these systems run and operate correctly. It's it's a major European financial institution.

[00:06:16]I I love things like this because it was said simply, succinctly, and compactly, yet it it completely shifted the coordinate system around everything that I thought was true. And it and it kicked off an entire thought stream and process inside of Sage about what is it we're really aiming for down the road. And and I think this CTO said was was communicating that we've got all these bits of tin and wire that are the table stakes now for doing anything automated anything computer related inside the financial industry inside of any business. And as much as possible that needs to go away, right? I should only be focusing on my core business value.

[00:06:55]What is the value kernel that the software that I maintain that I operate that I make sure gets upgraded and is patched for security? What is that value kernel and how do I make the most of it?

[00:07:07]>> Interesting. You know, you you mentioned I think it was in a prior conversation that we might had as we were preparing for a good conversation here. You mentioned a queryable context graph as as part of the output here. Why don't you tell us what the heck that is? So context graph is a is a a term that's come up recently and is gaining a lot of traction in the AI world. We didn't have a single name for it, right? We called it the cognitive model for the longest time. The entire Sage engine exists in two pieces. One is to build this cognitive model and the other one's to serve it up. Deepac did a great job of talking about how we use something called model context protocol to inject slices of context back into the AI so that when you're working on a complicated problem in a large old piece of software, we bring the level of knowledge and the details necessary for your AI tooling to do a good job of it.

[00:07:57]So what how Sage works is it reads the source code. It interprets the source code as a set of facts and primitives, right? And we then take those facts and primitives and abstract out composite and aggregate facts. So we quickly map from you know we found something on this line which all of the really there are a lot of really good coding tools out here can do. We go from that into the conceptual. So the entire Sage engine revolves around how do you find classify and then exploit these these facts to build this context graph. Right? And this is really no different than what I used to do on a customer project. Right?

[00:08:35]I I land the first day. It's like point me at the code. I'm going to read it. I start keeping a notebook of like, okay, I found where the general ledger is. I found where the accounts receivable is.

[00:08:45]I found how we integrate with Stripe, right? All of these things. And being able to understand that and combine it with where all the pitfalls are is key to the core thesis of being able to how fast can we scale this up so that we create what we sometimes call in house the digital architect. So why why a graph right and not a vector store or relational database? How does that differ?

[00:09:09]>> So the reason why that that comes into into focus and um you know so vector rags is one of the things you just touched on and it it was at the time all the rage and believe it or not we we tried that first and it fell apart and the reason why that fell apart is that you're dealing with similarity, right?

[00:09:26]It's like I'm working on a blank. Go find all the chunks, right? because it takes your code and chunks it up into into blocks of text that it hopes are related and then you search on similarity based on the intent of what you're working on. Okay, that's better than being hit in the head with a sharp stick. But when we go back to the thesis of we wanted to create something that had a higher level of understanding and capability, we needed to start working at a conceptual level and vector rag won't get that for you at all. What you need instead is what we tend to think about as something like a pyramid with the basic facts that you discovered in the code at the bottom that then abstract to increasingly broader concepts until you get to the top where you've got a very compact and succinct description of here's what the system is, here's what it does, here's what it talks to, here's how it transacts, and here's how you run it. And that gives the AI then many different ways to enter into discussion with what the hell this thing is whether it's level or whether it's at the coding level.

[00:10:25]>> That makes a lot of sense and clears some things up for me. You know people are very familiar with AI and you know most people at a basic level are interfacing with bots chat bots and things like Sage is not a chatbot. Okay.

[00:10:38]uh it's a digital architect per se is what I've heard you guys call it coin it that taps into the AI and you know it acts as a a growing set of enterprise programs doing the actual work in the fields let's break that apart a little bit Bruce what makes it an architect versus a code scanner >> right so what makes it an architect really comes down to can you have the this conceptual model is it working in abstractions the leap I mean let's let's set aside uh Sage AI for a minute when you're developing as a developer as an engineer some people make this leap to where they start having systems level thinking right can they think about things in terms of a scalable decomposition in such a way that they can hold entire fleets of systems in their head and figure out how you go from someone gave you a credit card transaction to the money ended up in the company's bank account those people become architects many times we needed to be able to replicate that through an AI mechanism. So what we wanted to do is start to build up this ability to think broadly across the systems. Now we talked earlier about how shoving your codebase even through vector rag if you've got a multi-million line system into an AI is never going to work. The AI is not going to be able to think about it, not going to be able to work with it. That scalable pyramid allows us to break the same chunk of the pyramid off across one, five, a dozen, 20 systems, line them up because they're compact, because they're small, feed them into the EI and say, "Please tell me what's happening across my portfolio." That's what turns this thing into a digital architect is its ability to repeatably extract the same kinds of features from the programs regardless of their source language and then be able to feed it into the AI in a form that it can understand and work with.

[00:12:27]>> Amazing. Walk me through how the graph uh gets built from a real code base.

[00:12:32]>> So the way it works is a little something like this. We start with a deterministic set of procedures um which are pretty straightforward. it goes and and brings all of the the code base in.

[00:12:45]So it looks at the file names, it looks at the directories, and we can start to infer what's going on from that. Things like file names are deliberate. People usually don't call them xyz.cs.

[00:12:54]It's usually a payment pipeline processor um you know.cs. So we can start saying, hey, look, you know, we found a payment system, we found an accounting system, we found a ledger system. In medical terms, we found the medical coding stuff. We found the ability to to integrate with fire databases. And so we start picking up clues very early about what's going on.

[00:13:13]We formulate strategies based on those of like what are my most important source files to go look at. We then have deterministic code that goes and start pulls facts out of those things. So we we end up with things like hey we found a data base right on line X and file Y.

[00:13:29]But you know any tool like cloud code can do that right? We we then start combining that with hey we found an entry point over here right? We've discovered a business rule. we we found a piece of a workflow that has this name and so we synthesize that into hey we found payment forwarding to the ERP over this rest endpoint and that's the point where the AI coding tools struggle is how do you get to that next conceptual level that actually mean something to the engineers because the engineers do it think in terms of lines of code but we all want to talk about where is my general ledger where is my inventory system make sense >> yeah it makes total sense And so we keep processing the there's a process where we go on we take those facts and then we synthesize them again we group them together by various associations and say hey inference system right and we use an external AI inference system we've combined these facts what do they mean right we get that back we store it and that forms the next layer up on the pyramid >> that makes sense I didn't know you used a third party inference system that's smart so now when I've built it I've taken all the code base in what can I actually query against it once once I have all my stuff as they say, >> right? So it ranges from a number of things and and our customers have taught us some really funny use cases. So there there's the basic one where it's like, hey, I'm an engineer and I'm about to do a a coding task and I'm going to be working in this file and my intent is to change this part of the program. The AI now whether you're using clawed code or cursor or anti-grabber or any of the rest great tools can talk to Sage through the MCP and say hey the intent is to make these sets of changes what does that affect and Sage can go hey look we're going to change this file and this file and this file that associates with this part of the process it's going to trigger these interface rules that's going to change the payload that's traveling across the wire and if you hadn't had that your AI coding tools would then have to accidentally or intentionally discover those and then you'd have to fix it. Instead, you're going to fix it on the cheap side of things before it's in code, before it's broken, before your tests fail because Sage has that depth of knowledge to inform your coding tools of what's going on. All right, that was the core use case. It's like how do we make we don't want to make >> developers necessarily faster. We want them to have a broader view of what's going on. Our customers have taught us though that there's a lot of leverage to people who don't have a codebase sitting on their desktop. If you think about the software world, there's product, there's marketing, there's sales, there's support, there's operations, and you really don't want those people having a a copy of your source code sitting on their desk. But they still need to understand with what is this software and how does it work? If they're using AI tools, the best the AI has to work with is to reach out internal wiks, marketing pages, some of which may be years and years out of date. Instead, it can talk to Sage. And Sage has a representation of the asbuilt, as deployed, as running codebase that went into production yesterday.

[00:16:31]>> That's so powerful. You know, I'm I'm getting a little bit of a twitch here hearing you talk about it because it's bringing me back to a time where I worked at a very big bank and I led a big technology organization. in the bank about 1,200 people. And when I inherited the group, we had an epidemic of defects post-prouction. Every time a release went out, it was a proverbial boob show.

[00:16:55]Okay. It was bad news. And >> we've all been there, Vic.

[00:16:59]>> Oh, man. It was so bad. And you know, and it took, it's funny, you know, and these releases were quarterly. No, they were four months. They were trimester.

[00:17:07]They they were every four. Yeah. Three times a year. And so a lot of work, a lot of cycles, a lot of testing cycles, you know, QA doing its best, but no visibility like what you're describing.

[00:17:19]No, no sort of cross impact analysis that was systemic versus tribal, right?

[00:17:25]Tribal knowledge ruled as king back in those days. And I just think about our ability to minimize, if not completely defeat, the post-p production defect wounds. And our defects weren't because the things that the team wrote were bad.

[00:17:41]It's because the things they discovered it broke left, right, center, up, down.

[00:17:45]That was the problem. They just they just didn't have a good view into what the interoperability was and you know how one module affected the next. And because as I talked to Deepac earlier, I told them most organizations don't have great documentation. At very best, it's it's good or maybe even very good. Never is it pristine 100% accurate, at least not in my luck or experience. N >> and we've gone on journeys to fortify that to try to fix that. I think when I when I left that organization, we went from hundreds and I'm telling you close to 200 postp production defects. The last release I did with that group, there were six. And so I'm going to put a big W on the I'm going to put a big W on the board for the team on that one.

[00:18:30]But it was it was herculean. It was it was lots it was way more testing. It was way more testing harnesses, a lot more cycles. It was so much heavy lifting.

[00:18:39]And this tool sounds like like Nirvana for anybody running enterprise change management that this thing would just >> Oh, yes.

[00:18:46]>> be incredible. Wow. That's that's fantastic. What outputs do people get from Sage? What you know, tell me tell me once I run my codebase, what am I looking at?

[00:18:55]>> So, what you're looking at there are a number of different outputs that that people tend to consume. One of the first things we did if you remember the the whole idea was don't bring code bring knowledge is we started producing documentation from the code set itself because we synthesized back to concepts we did not talk about on line five you've got this and on line 500 you've got this. We said, "Hey, you know, we found business functions in here and here are the business functions we found, right? We we found your uh you know, we found your payments processor.

[00:19:24]We found your um you know, your uh dispute resolution system." And it immediately mapped from the code into the terms that not just the engineers, but the business users knew about. This was revolutionary. We would create these very transportable markdown documents.

[00:19:39]We build them into a site for the customer and their reactions were usually one of startlement because not only did it build them, it kept them up to date. And so this comes to one of the core thesis that's that's fallen out of stage is that we're trying to take away work that the engineering team probably didn't want to do anyhow. Sitting in meetings, writing documentation, you know, writing >> impact reports. We want to automate the daylights out of that stuff so that your development team is busy focused on the code and how to implement the changes that you need. So there's this documentation set there and which has continued to grow and evolve and can get incredibly detailed, breaking out all of your business rules, breaking out all of your use cases, breaking out all of your workflows and processes. things that you would hire a systems integrator team to spend a year to a year and a half pulling out for you is now done automatically by the AI. The other piece is this model context protocol interface that we've talked about. And what that does is it really gives a more powerful AI like claude or GPT or GROC access to the this context graph this cognitive model. So that if you come up with an idea like hey let's say I'm a CEO and I want to know hey why is this change taking so long? You can just give it an open-ended question and it will go off and it'll say hey Sage Model I want to know about the technical debt. I want to know about the tricky parts of the code.

[00:21:04]And it's like, oh, wait. What you're trying to do intersects this tricky part of the code that was originally written in 2005 and is kind of junky. The CEO just self-service on that. He didn't have to call up the CTO, the lead architect or the lead developer on the team. The CTO can now self-service on that information. And that is another one of these great outputs.

[00:21:21]>> You know, what's it take to scale something like this? Somebody's got 500,000 lines of code versus the 15 million that you talked about, >> right? So the way that we built this context graph this cognitive model was intentional to handle scale right so I talked about how the first step is to find the basic facts that are in the code right let's take you know one of the things that we work use as a benchmark is an open-source cobalt accounting program believe it or not there is such a thing it's a bit over a million lines of code and we go and we start walking through that codebase and we find facts in the code maybe we'll be generous a million of Right? A million facts. A million rows in a database is big, but not really big. No cares about, right? It's easy for any database. We go through that derivation step where we start grouping the facts based on what we do. We think this is part of this endpoint. This is part of the menu system for the green screen. And we say, hey, AI, interpret that. Okay. It says, well, you know, we're really boiling down to a set of atomic facts of this program does this and has that in one of these. That's maybe tens or hundreds of thousands. Again, very easy for a database to resolve. And as we build that pyramid up, we get fewer facts back from each reynthesis. And so we end up with a record set that's usually fairly small.

[00:22:38]>> And if you can handle a 2 million, 1.5 million thing in in a size of that, you can get to the bigger numbers. Now, there's cognitive limits that kick in, right? when you start crossing about 20 million lines of code, it's like the ability to look across something that big is still constrained by things like context windows, by attention in the AI and all the rest of that stuff. But as the frontier models advance, those barriers fall and we ride along with it.

[00:23:05]>> Amazing. Hey, um, people talk about an AI inference layer. Okay. And from what I understand, that's the part of an AI system that's responsible for taking a trained model and actually putting it to work in the real world. So can you tell us a little bit about your AI inference layer, how you think about it, etc. >> Yeah, so we actually outsource our inference. By default, our inference layer is going to be a cloud 4 series model running on Amazon Bedrock. We have a rather I'll call it a diabolical prompt layer that understands that based on a given set of facts and where you are on that on that context graph what questions you want to ask and there's very intricate very comprehensive machinery that's holding hundreds of hours with work that says based on this set of facts let's ask this prompt with these kinds of bits of context seated in there ask it to produce a JSON structure and record what came back right so it's very important that We understand the limits and the capabilities of that inference layer. Some models are what we call high skill, some we use for uh medium skill prompts and some we use for low skill prompts. And the ability to match the level of skill necessary with the inference capability is the key to doing this without breaking the bank because you can quickly exhaust yourself in terms of spend on tokens on this. If you just use the high-end models like GPT55 or Opus 47, yeah, >> you'll quickly make yourself poor. So y understanding the right inference endpoint to use for the right question is key to doing that efficiently.

[00:24:40]>> Cool. Do you have is there any open source tooling in the stack?

[00:24:43]>> So we use a lot of open source tooling.

[00:24:45]For example, the way we can swap between AI inference providers is because we do use the open AI protocol standard are also MCP itself is open source and has undergone a bunch of changes and is about to change again as more and more companies use it to power their agentic systems. All of the cracks, all the defects are popping up. So where possible, we try to ride along with open source.

[00:25:09]>> Very cool. Hey, I want to talk about ephemeral environments for a second. You know, a lot of labs are pouring a ton of research into ephemeral execution. And you know, the big question is if the model's robust enough to describe them, then do we even need to write code anymore?

[00:25:24]>> Yes, >> that's above the answer is above my pay grade by the way, but I know it's not above yours. So, do the audience a favor here. Please explain ephemeral environments to someone who's never heard of them before. So they have not publicized this because um it's a little it's a little space agy but if you watch especially in coding tools like cloud code or any of the rest of them you can see that at times the model will go you know I've got some work to do here and I'm not going to spend tokens on it.

[00:25:54]What I need is I need to write this complex query that's going to run against my Postgress database and I only need about 10% of the records that are probably going to come back that meet a certain criteria. So I'm going to write a little program and it writes a little program JavaScript >> or Python and then runs it and then harvests the information coming back out of that. So the first time I saw I said whoa whoa whoa whoa what are you doing and >> that was kind of when I saw Python being executed that was my response to whoa whoa what's happening here >> right and and one of the great things about using AI development tools is it will explain it to you can stop and you say what did you just do I wrote a program because it was going to be faster and cheaper to do that it's like you have the capability to do that oh yeah let me tell you how it works I'm like what what right and then and indeed that's that's what's happening so what you end up now is if you abstract from that it's a pattern Your AI can write just in time code in order to fulfill a purpose. And what's limiting it is knowing when it needs to do that and how to solve a problem by writing the code rather than shoving tokens in memory and then you roll the dice on whether it hallucinates for you. And so I thought that was really cute and interesting the first time I saw it like a little more than a year ago. But since then the frontier labs are spending a significant amount of money to codify this capability.

[00:27:10]>> And then right and and so you have to maybe cast that forward is that if at some point the capability to create this just in time code is is really good and really fast and the gating factor isn't the code or the virtual environment.

[00:27:27]It's this it's the ability of the AI to understand where does Sage play in that?

[00:27:31]>> Yeah. Where does Sage play in that?

[00:27:33]>> Well, as as the encyclopedic almanac of how your software works, the entire nature of what is actually the value kernel here. What what work is it? We're back to the CTO's question is I don't want that back. Right.

[00:27:47]>> Right.

[00:27:47]>> What didn't the CTO want back? Did the CTO back want the the messaging system back? That's you know Apache C or it's it's CFKA message cues probably not. Did they want back their data sources and syncs? Probably not. In an AI based future, do you even still need a web interface if the AI is now carrying the intent for you? Well, maybe not.

[00:28:11]>> And so, the ability to create code as needed in a repeatable, understandable way that matches the spec because your AI under Sage built that spec can become a key differentiator to running in an agentic future.

[00:28:25]>> You're right. It's sci-fi and it's it's it's good. And I'm glad you explain it. At least I understand it. And I typically tell people, explain it to me like I'm in fourth grade because many topics I still am. But thank you for that. I I do understand. And I do recall actually my first response when I saw it break out, start writing an application and then using that application to execute what you know based on the prompts I was. I was like, this is some crazy stuff going on here. It's amazing.

[00:28:52]>> Yeah. Where do we go from here?

[00:28:57]I know where we go from here. Bruce, you and I have known each other quite some time. And back when I was in corporate America, you and your team have literally come to the rescue many, many, many times. And what I used to tell people about your group of of of experts is what I call them is that these aren't your guys out of college and gals out of college that have two years of.NET under their belt and, you know, and they're they're writing.net apps. These are the real engineers of the industry.

[00:29:26]They've worked in the biggest places.

[00:29:28]They've written books on topics. They've executed in trading environments at the highest velocity and the highest amount of transactions. I won't age your group, but let's just say it is a very big collection of extremely tenured and experienced people. Is that fair?

[00:29:45]>> Yes.

[00:29:46]>> There's a lot of snow on the roof as as I guess one colloquial term would put it.

[00:29:49]>> Okay, fair enough. how and when I see new entrance coming into the market with technology, I don't want to maybe I'll offend somebody. It's sometimes laughable. It's it's they're belting, you know, commercial tools together and they're slapping some things together and but you know, as we said earlier, that bell curve, you know, people will get exposed. How much has the experience of your team really played into the development of Sage Tech versus what other competitors are doing? I'm going to give you a gut feel on it. I think it has to be massive, you know. I I think it has to be massive because as we talked about exposing the bell curve, you can take I AI and put real bad stuff in it and you'll get a pretty output. It'll be a pretty output of bad stuff.

[00:30:35]>> It'll be believable. It'll be plausible incredibly believable and you'll defend it in the most simplistic forms. You remember the lawsuit might been the first one that was very large about a guy citing u precedent in a in a in a court of law that because he found it on chat GPT and there was no such case and he got sued and the law firm got sued.

[00:30:57]So talk about the the bell curve being exposed. It was pretty ridiculous.

[00:31:01]Anyway, back to it. How has this amazing stable of seasoned tenur experts really created a a competitive advantage for you and this tool? It's absolutely essential, Vic. Um, I will talk about the fact that through through this professional services company that gave rise to stage tech AI, there are literally centuries of experience that are getting ready to retire, getting ready to move on to other things. What I mean, in the Deepac podcast, which I encourage all of you to go watch and listen because it's absolutely stunningly good. He talks about the knowledge cliff and the knowledge cliff is one of our core use cases. It's where you've got a developer who was key to building a a you know loadbearing system for your enterprise and they're going to retire, right? They've had they've had a full career. What do you do with all that knowledge? We faced it ourselves.

[00:31:49]We had high skill people who's like, you know, I'm done doing software and stuff.

[00:31:52]I'm going to go fly kites and have fun, right? And I wish them all the luck in the world, but when they leave, they take a lot with them. And so part of the original genesis is can I take can we take what's left codify it and stuff it into an AI mechanism and that was one of the founding ideas behind Sage. It's absolutely pivotal that we've got incredibly deep experience and we're working hard to harvest it as best we can. So you're saying not only can we multiply you who wants to stick around for a while and continue to have fun, but we could m we can multiply and leverage the decades and decades of expertise that have come out of the entire team and make that repeatable and continue to train models on it and get smarter.

[00:32:36]>> We think that the core value proposition, Vic, we think that that's why we're going to end up being different. I buy into it because I've had the experience of working with, you know, at least a half a dozen to 10 of these professionals over the years and they've saved my ass every time they've walked through the door. I mean, but I was like, "Oh, I need my ass saved. Oh, I know who to call. I'm going to call Bruce. We're going to figure it out and call Bruce and Tony, and then we'll get a SWAT team in here and, you know, we'll make things happen."

[00:33:04]>> Bruce, as we wrap up here, is there anything you don't think we've talked about that would be vital to get across in this brief chat that we've had? I think that one of the things I' I'd like to communicate is where this is going.

[00:33:15]We touched a little bit on ephemeral environments and one of the things that has leapt out at us as we've onboarded customers and as we've looked at their systems is just just how small the footprint of the loadbearing portion of their enterprise is. It's one thing to suspect it. It's another thing to have your AI tooling be able to build these graphs in a repeatable way and then extract similar information across them and say just how big is that? and it's shockingly small. I think the future of AI is going to revolve around people doing better work rather than more and it's going to take a different kind of engineer. At one point you talked about chief prompter being a thing and what's really been interesting to me is the difference in paradigm in coding for an AI system versus coding for any other kind of system. Right? When you're working with AI tools, it's not about being able to decompose the logic so much as it is being able to render a good narrative because the AI thrives on narrative. Your ability to tell the AI a detailed, spectates into the quality of what you're going to get out of it.

[00:34:21]>> Awesome. Capitalize on that going forward.

[00:34:24]>> Let's have a little fun at the end here.

[00:34:25]Let's do a little lightning round. You want to have a little fun with me?

[00:34:28]>> Yes. Yes.

[00:34:29]>> Cool. All right. Let's do it. What's the most overrated thing in enterprise AI right now, your opinion?

[00:34:33]>> Oh, it's scaling laws and the fact that big bigger models are going to be better. The ability for for the AI engine to hold context, hold attention, and be able to allocate resources to um to resolve your prompt. Yeah, they're they're going to have difficulty with that one.

[00:34:52]>> All right. What's the most on bigger on bigger context and you guys are welcome to it. It's going to be a lot of fun, but it's not going to do what you think.

[00:34:59]All right. What's the most underrated technical risk that nobody is talking about?

[00:35:03]>> Okay. Well, this is this is one I face daily. It's desklling, right? And cognitive atrophy. The amount of brain power and wattage it takes to be able to step into a complex environment and code successfully is pretty big. When you start delegating some of that or a lot of that to an AI, that part atrophies.

[00:35:22]Now, if you get good at AI and work with it a lot, you grow new skills and new capabilities. But I'd worry about the younger engineers and their ability to become senior engineers and architects if they don't have to do the reps.

[00:35:36]>> Fair enough. What is the favorite tool?

[00:35:38]What is your favorite tool rather in your stack that most people might not have heard of?

[00:35:43]>> So inside of Sage, there are a couple of interesting and unique things going on.

[00:35:48]One of one of the concepts, the tools we'll call attractors. You can think of attractors as probes into semantic space. A piece of software is going to describe a semantic space. Right? This is one of the keys to how stage builds its graph. We use these things called attractors as little gravity wells or little weights that say for this fact we've discovered is it part of accounting? Is it part of DevOps? Is it part of database maintenance? And this shortcut was essential to us being able to rapidly build powerful high leverage cognitive graphs.

[00:36:20]>> Awesome. This is a question everybody asks anybody who's built anything and I almost don't want to ask it because this is relatively new but then again everything's moving so fast. If you started this all over right now today from scratch, is there anything you would have done differently?

[00:36:37]>> Yeah, there are a number of things we would do differently. Some of which resulted in lessons learned that informed what we're doing now. And in fact, we have designs on doing it over again. And there are things that we would do differently in terms of how we set up the semantic network, how we build the cognitive model. It works really well. It works better than probably most people would assume it or would be able to figure out how to do it. But we've now done the reps and we've learned how to do it even better.

[00:37:03]So there are there are a number of things that we would change in terms of whether we picked a Python ML stack as our basis, which is what it was. It brings with it its own problems when you need to deploy it inside of someone's firewall. Hey, here comes the source code. All it takes is one nefarious person to now have a copy of how the Sage analysis engine works. We'd probably pick compiled languages. We'd probably pick a higher efficiency interface into the inference engine. We might actually opt for something we considered at the front, which was to build our own inference engine because the cost of inference is going up and nothing's going to stop it. And the ability to control that cost is directly related to our ability to deliver value to our customers at a price point they're willing to pay.

[00:37:45]>> Awesome. Last question. You know a bunch of stuff about AI. What's the one thing that you know for certain today about AI in 2026 that most CTOs still don't believe?

[00:37:56]>> It's not going to solve your problem.

[00:38:00]>> Everything and and everything everything you own and operate now will pass through a filter whether or not it will ever work in an AI space or not. And some of them won't make it. And you need to figure out what it is you're going to do about it. It's not a simple question.

[00:38:15]It's a very complicated one. And you need to enlist tools, whether it's ours or someone else's, to help you make that transition. Every software piece, every system that you run in 2030 will have passed through that filter. Be ready.

[00:38:27]>> Bruce, you know how when you watch a movie, the very last line of the very last scene makes you go, "Hey, I think they're make they're creating a sequel."

[00:38:36]Well, I think that question and that answer probably opens us up for for another episode down the road. Uh, I'm here for you, Rick.

[00:38:44]>> That's awesome. Bruce, thanks so much for coming on today. Every anybody who's watching sage-tech.ai, you can follow Bruce and team's work there. Also, don't forget there's a part one of this uh segment. It's with Deepo Sharma. It's a business track for listeners who want sort of the executive framing about what's going on here. And of course, a selfish plug for myself.

[00:39:06]Thanks for watching 10,000 Miles and go check out some other episodes. I've had a lot of fun with musicians, rock stars, entrepreneurs, young people finding their way in their career. But I'll tell you one thing, guys. Uh, and Bruce here, the AI stuff is on fire. My top episode right now is 327,000 views with roughly a 60,000 subscriber base. I'm told that's pretty decent. It's on AI, so I expect us to get some traction here and and get people listening and interested.

[00:39:35]So, Bruce, thanks again for today. Much appreciated.

[00:39:39]>> Have a great day. Bye. Please don't forget to like, comment, share, and subscribe.