How zeb Rebuilt Consulting Around AI With Substrate

[00:00:00] - [Speaker 0]
Your agents aren't producing accurate answers because they don't have a complete semantic understanding of your data, and Denodo is solving this and solving it through semantic consistency. Through semantic consistency, your agents can start making accurate predictions in real time. So see what else Denodo can do by visiting denodo.com to learn more. But now let me introduce you to today's guest. What if the biggest barrier to AI success isn't the technology itself, but the fact that most organizations are still trying to force it into operating models that were designed for, let's face it, a completely different era.

[00:00:46] - [Speaker 0]
Well, my guest today is the CEO and cofounder of a company called Zeb. And together, we're gonna discuss a very bold experiment that went far beyond adopting AI tools. Because instead of simply adding AI to existing workflows, at Zeb, they made the decision to tear down and rebuild its entire operating model from the ground up and build it around an AI native architecture called substrate. So today, I wanna explore exactly what AI native actually means beyond the buzzword, why so many enterprises remain stuck in pilot projects without delivering measurable business value, and how treating AI as the foundation of an organization creates a very different set of opportunities and challenges. And my guest will also share lessons learned from rebuilding company culture, flattening traditional hierarchies, and creating a business where AI is no longer an assistant sitting on the sidelines, but a core part of how work gets done.

[00:01:54] - [Speaker 0]
And you'll also hear why Zeb has moved away from billing for time and instead guarantees outcomes and only getting paid when agreed business results are achieved. That's how confident they are. I will also discuss that growing demand for measurable AI return on investment and how substrates plan, execute, and evaluate architecture, how that works in practice, and why they believe that the future belongs to organizations that can continuously learn and improve through every single customer engagement. And if you've ever wondered why so many AI initiatives struggle to move beyond experimentation or what it would take to build an organization where AI is truly embedded into every layer of operations, I think you'll love this one. Enough for me.

[00:02:47] - [Speaker 0]
Let me get Mel onto the podcast now. So thank you for joining me on the podcast today. Can you tell everyone listening a little about who you are and what you do?

[00:02:58] - [Speaker 1]
Yeah. I'm Mal. I'm the founder and CEO of Zeb, and we are an autonomous delivery firm that has rebuilt itself around AI as the operating environment rather than treating it as a tool. So we essentially ship guaranteed business outcomes for all of our different clients through our execution system substrate, and we only get paid when those outcomes actually land.

[00:03:20] - [Speaker 0]
Awesome. Well, thank you for sitting down with me today. And I know it is a big week for you because you're gonna be announcing Substrate, which is an AI native operating architecture designed to completely replace legacy consulting workflows. But what I love about what you've described here is an AI native operating architecture rather than just another AI tool. What's that actually look like in practice?

[00:03:44] - [Speaker 0]
Because, again, it's a a phrase we hear a lot. Right?

[00:03:47] - [Speaker 1]
Yeah. Yeah. It it is really a phrase we hear a lot. It's it's thrown around a lot in the consulting space as well. Yeah.

[00:03:54] - [Speaker 1]
I think the core mistake is a mistake we honestly made in the past too, which is treating AI more as a feature. We treated it more as a tool, as an extension, and we didn't really change our organizational structure. So we kept the same org chart. We kept the same workflows, our delivery pyramid, our hierarchy. We basically just bolted AI into it.

[00:04:13] - [Speaker 1]
And it gave us, you know, definitely gave us time efficiencies. It made us faster. It made us have higher quality, but it didn't really give us the ROI that we were expecting or the promise of ROI in AI native. Think AI native for us, we realized actually meant the opposite. We have to treat AI as the foundation, as the medium, and really for us the substrate on which everything from an organizational perspective is built on top of, which is why we named it that.

[00:04:39] - [Speaker 1]
And for us, it also meant going much more flat from a structure perspective because we realized a lot of our signals, a lot of the gaps in communication were happening because we had this hierarchy. We had people handing off to other people who then had someone else reviewing things. And for us, it it meant that we were treating the model more as an assistant that was, like, waiting for instructions at every single gate. And those instructions were only as good as sort of the game of telephone that was played along the way. And, you know, at this point, we're realizing AI really needs to be the first responder to most of this work, and we need to be able to over index on the human capital, especially why by entering the work while it's in motion.

[00:05:18] - [Speaker 1]
So the thought process we took is if we removed AI from our process, would our process still basically work? And if our process works, then we're not really AI native because AI is not necessary for us. But when we change our organization entirely, now if you take AI out of Zeb, it doesn't work anymore. Our organization literally wouldn't work without AI, which is how we know that we've truly been AI native because we treat it just as essential as everything else, every system that we actually have.

[00:05:47] - [Speaker 0]
And I hope you don't mind me saying this, but one of the things that I love about when I was doing a little research on you is I was reading how at Seb, you made the unusual decision, some might say, to scrap and rebuild your own infrastructure around substrate before offering it to your customers. Great stories. But what did that journey teach you about organizational change when and what were the toughest assumptions that you had to challenge along the way? Because I'm sure there was a few of them. Right?

[00:06:15] - [Speaker 1]
Absolutely. It was it was a pretty difficult journey, in all honesty. And now when I tell people about it, I really don't sugarcoat that, and I don't act like it was something that was done overnight. It took, like, a little like, basically, a full year of work on our side. And the work was a lot of it was in the thinking and the letting go at the leadership level of assumptions and preconceptions we had in in burning the model down.

[00:06:37] - [Speaker 1]
We had obviously invested so much of ourselves into this old model. So it wasn't easy to just take it down and rebuild from scratch, but we we decided that we were gonna operate on the first principle that we can't sell anyone on an operating model that we haven't done ourselves. So we really decided to become our own best first customer. And the hardest assumption for us to give up was we had tied a lot of expertise into these silos that we called specializations. So we had, you know, people call it practices, people call it verticals.

[00:07:06] - [Speaker 1]
We had specializations. Every services firm typically has some version of this where they either have, like, industry verticals or expertise verticals, and they basically say that, hey, there's deep and narrow experts across all of this, and the entire career ladder is basically you build depth in one particular lane, and then you get higher and higher in the org structure on that particular lane. When we thought about how AI really impacts this, we realized this is, like, one of the most automatable things that there actually is because, you know, a lot of the pattern matching that AI does, it honestly doesn't even do it does such a great job not just in a specific domain, but it does such a great job in an interdisciplinary perspective as well. So the thing that was really scarce earlier, which is that you have to hold, you know, one specialization or one discipline. At this point, the thing that actually compounded was having several disciplines at the same time and being able to build connections between them.

[00:07:56] - [Speaker 1]
So that really inverted, like, the way that we actually hired and organized, and we went to this, like, flatter builder only hierarchy. You know, initially, that is definitely challenging for our organization to consume if you tell managers, hey. Like, you're no longer managers. Like, it's hard for them to not feel like that's into motion. But I think the way that we also challenged them and solved it was we asked them, like, why did you really get into technology?

[00:08:18] - [Speaker 1]
And 99% of the time, it was never, oh, I wanted to be a manager. Right? That was never the answer. The answer was, I wanted to build cool things and I wanted to always be learning, and technology was the only field that evolved at a rate where it felt like there's a lifetime of learning. I could spend my whole life doing this and I'll still never know everything.

[00:08:35] - [Speaker 1]
And so when we when we over index on that statement and that ethos, we're like, hey, that's really what this is enabling. We're really there's still seniority at Zeb. Right? There's people that have higher levels of experience, that have more competencies across multiple things, and we reward them for that in the compensation model because it enables them to take higher levels of agency. So the builder only flat culture doesn't mean everyone's the same on the same pay scale and everyone's basically horizontal.

[00:09:00] - [Speaker 1]
What it means is that everyone now has individual agency. No one is responsible for other people. They are supposed to show shared ownership of the projects that they're a part of. And, you know, once once our team kinda understood the deeper details of a lot of this, they realized that we were actually giving them exactly what they've always desired.

[00:09:19] - [Speaker 0]
There's so much I love about your story, especially how you're not afraid to tear up the rule book. I mean, not only did you re rebuild your own infrastructure around substrate, you took it a step further. I mean, one of the boldest parts of your model is outcome based pricing where clients

[00:09:35] - [Speaker 1]
Yeah.

[00:09:35] - [Speaker 0]
Only pay after agreed outcomes are achieved. And I speak to a lot of people on here, and I think the only other company I know that are doing this that I've spoken with are Zendesk, and it is an incredibly bold move. So why do you believe the consulting industry has been slow to move away from that just billing for time? And and what has been the reaction from your customers when when you tell them about this?

[00:09:55] - [Speaker 1]
Yeah. It's it's an interesting question. I think that for us, what we've realized about the consulting industry, definitely something that we clung to on our side as well, is that it's such a great business model, billing for time, like, the seller. For us, it was a great business model. But when you apply AI to the equation, you realize it's quite adversarial for the buyer because a lot of the efficiencies you're now getting, all you're doing is really increasing your own margin to an inordinate amount, and you're never passing any of that efficiency onto the buyer.

[00:10:25] - [Speaker 1]
So part of the outcome based pricing was just the realization of, hey. We're getting all of this efficiency. We should pass it on to the people that we're partnering with because otherwise, we're in a very vendor client relationship, and that's never the the company that we wanted to be. We wanted to be a partner in the business, in the in the actual thick of things with our clients, and we didn't want them to feel like there's a separation between Zeb and them, where they're always constantly negotiating with us. It's always this, you know, hey, you guys are the vendor.

[00:10:53] - [Speaker 1]
You need to do this. These are the tickets. Solve for the tickets. That was never the business that we wanted to be, and that's not what we set out to build. So when we thought about it from that perspective, outcome based pricing was one of those commitments that more than just what it is on paper and the effect of it, it was us showing the customer that we're going to put our money where our mouth is.

[00:11:12] - [Speaker 1]
That's the most tangible way we can show them that we mean it when we say we're a partner and not just a vendor. And at the end of the day, we realize that it's honestly better for us as a whole because that line actually enforces the kinds of projects that we take. It enforces the kinds of, you know, clients that we choose to partner with, and it also enforces the way that we actually get into business. It's not easy for us, but that that lack of ease actually makes us a much sharper and a much a much more organized and disciplined organization, which I think is absolutely necessary if we're going to really survive long term in the age of AI.

[00:11:46] - [Speaker 0]
And I was also reading when researching it that you said that AI should be treated as a a primary consumer of business systems rather than just an assistant that's sitting on top of them. Again, incredibly refreshing. But can you tell me more about that shift and what it means for leaders that are planning their AI strategy over the next few years?

[00:12:05] - [Speaker 1]
Yeah. I think this shift is has been one of the most, like it's one of those sentences that when I say to executives, I can see them, like, really start to like, their the wheels start turning really hard, and they're like, oh, like, that is interesting because they've always been thinking of AI as something also that gets bolted on some existing process or some existing tool. And so, like, know, people started I think a lot of it is because people started with chatbots, and when they started realizing that chatbots existed, they were like, okay. Well, we can now adapt the chatbot into our tool, into our process. But that was also still treating humans as the primary consumer.

[00:12:39] - [Speaker 1]
It was let's speed up the answers that we can give people. Then once we, I think, started realizing especially through this evolution of, like, agentic loop architecture, MCPs, all the things that have been sort of commoditized from an agentic perspective and the level of autonomy that agents are now able to have, the real next shift of unlocking actual efficiency and value creation is to treat AI as the primary consumer. That changes multiple things. Right? It one is that the system's main job then becomes feeding the agents, like, actually clean, structured, contextual data that they're able to then use to make an action.

[00:13:13] - [Speaker 1]
And the human becomes more of that secondary viewer, not necessarily the dependency or center of gravity. And this is actually better from a human capital perspective because a lot of the things that people actually are passionate about and curious about is not the work that they do. And that's what we find in every company that we talk to when we talk to HR leaders. They didn't get into it because they wanted to be paper pushers. They got into it because they care about people.

[00:13:36] - [Speaker 1]
They wanna ensure the best employee experience. Those are things we're trying to free up time for them to actually have ideas on that. Talk to their resources. Talk to the actual employees. Figure out where they could help unlock a better employee experience.

[00:13:48] - [Speaker 1]
And now AI gives them the scalability and the execution where maybe previously they always had to depend on either an IT team or some other software vendor to give them the thing that they wanted. AI is now able to unlock that, which is why we believe in selling sort of substrate to other companies as well because the efficiency and the model it's unlocked for us, we believe, is something that could be broadly applicable to many companies.

[00:14:11] - [Speaker 0]
And I think over the last eighteen months, we've heard a lot of stories of businesses experimenting with AI, struggling to get out of pilot phase, struggling to get ROI. And Substrate operates through plan, execute, evaluate, and that loop is it really just stood out to me straight away. It's like, you make it sound so simple, but it's bang on the money there. But but walk me through how that process works in a maybe a real customer engagement and how it offers or how it differs from a traditional consulting project life cycle.

[00:14:41] - [Speaker 1]
Yeah. Yeah. I mean, the simplicity of substrate is really a design philosophy at the end of the day, because our theory was let's not get super specific about each of the variants or, you know, let's not get too specific about the skills that need to be built into each one. Like, let's give the system a a bit of opportunity and and a bit of trust to auto evolve itself to the needs because the needs are always changing. So we tried to create these base loops that we knew would hold true in every project that we did.

[00:15:08] - [Speaker 1]
If we look at every project that we did, there was some version of a planning phase, there was some version of execution, and there's some version of evaluation. Right? But traditional consulting so far has operated very linearly even with the change from, like, a more, you know, into a more agile model. It's still been pretty linear in reality because it's it's very front loaded and you scope something, you start an SOW consulting firm staffs that that scope of work. They deliver over months, and then you find out at the end the client finds out at the end in user acceptance testing whether it actually worked.

[00:15:41] - [Speaker 1]
So a lot of the risk gets compounded through the process and then gets sort of offloaded to the finish line. And that's where a lot of the, I think, the more contentious consulting vendor client conversations end up happening is at UAT because there's some gap in expectation versus reality. So substrate, we wanted to make a very tight loop that's able to basically run-in parallel. So planning is where we define with the client. We've defined exactly what the outcome is that they're looking to achieve.

[00:16:07] - [Speaker 1]
We've actually built up a lot of context through the course of those conversations, and all of that context gets transferred systematically through substrate. And Substrate is then able to use the planner variant to break the work into very verifiable units. The execution variant is Substrate actually doing the work. So it generates actual artifacts, the code, the deliverable, the integrations between systems. And for all of this, it's using, you know, documentation either provided by the client if they have it.

[00:16:33] - [Speaker 1]
In some cases, it has to reverse engineer systems to generate its own documentation. And in some cases, it's using our wiki of all of the projects we've done historically and applying those efficiencies of, you know, this is the gold standard architecture for this type of problem, pattern matching and applying that directly to the work. So every new project we does gets the benefit of all the previous projects we've done. So the evaluation loop, I think, is the real core part, and people undersell or underestimate this. This is basically a separate verification step completely independent in every single ticket at the ticket level that actually checks the work against the defined outcome.

[00:17:06] - [Speaker 1]
So it has it has a very clearly defined outcome, both technical as well as operational, and it's not able to even commit code unless that outcome has been truly verified systematically. It writes the scripts. It executes them. If there are problems, it actually gives that feedback back to the planner and executor variant. They make changes, and then whatever that final deliverable is, as long as it passes evaluate, then it gets committed to an actual development environment.

[00:17:32] - [Speaker 1]
So this way, we're gating everything, you know, not on faith. There's a systematic check, and it's auditable as well. So we're able to sort of prove to anyone that needs to see how that actually happened, you know, where where in the life cycle was the spec written, where was it verified, how was it verified, all these questions that traditional consulting firms sometimes are challenged in terms of answering because there's humans in the loop, they're the ones doing everything. That's basically what we're obviating. I think the the biggest difference is really where the the source of truth is.

[00:18:00] - [Speaker 1]
In a classic delivery model, is this working typically as a status meeting. Right? There's like a go, no go meeting. There's a story that someone is telling at the consultant level saying, yeah. You know, like, we have sixty five percent pass rate, so, you know, that's pretty good.

[00:18:13] - [Speaker 1]
I think we can go to just next phase, and we can make modifications. There's a lot of these intrinsic judgment calls that are made on very gray areas, and we know because we've been a part of all those meetings. But now in our loop, there's a measured signal in every single cycle. So instead of discovering much later down the line that the wrong thing is being built, we're course correcting, and we're able to demonstrate to the customer along the way. We're chipping outcomes along the way.

[00:18:36] - [Speaker 1]
So not all the outcomes are delivered at the end. We're delivering them along the way. So they're actually seeing the work getting done, and they're seeing it being tracked, executed, and evaluated through the entire process.

[00:18:47] - [Speaker 0]
And for anybody listening today, maybe feeling inspired by what you're talking here and everything you're showcasing, and maybe they're from an organization who have previously invested heavily in AI pilots, but are still struggling to demonstrate that meaningful ROI. But based on your experience, where should business leaders be focusing first if they they wanna secure those measurable outcomes rather than experimentation for the experimentation's sake and and risk drifting into analysis paralysis as well?

[00:19:17] - [Speaker 1]
Yeah. It's a it's a great question. I think this, like, pilot purgatory is what we we call it a lot of the time. We think it arises, at least from what we've seen, people pick projects based on what is either technically interesting or sort of shiny and cool to them, things that seem more marketable. They sort of prioritize those elements more than what's economically viable.

[00:19:38] - [Speaker 1]
So then you end up either with, you know, a vendor giving you sort of a clear, clever kind of demo, and it doesn't really graduate to anything. Or something gets built, but it doesn't actually ROI, so then no one decides to put it in production. Our advice has consistently been in our process has been to start from the outcome. And this is another big thing that the outcome based pricing forces is very objective binary outcomes that are measurable. So we're essentially advising customers and helping them say, we want success to mean this metric is moving by this much.

[00:20:07] - [Speaker 1]
Very specific. Which means we can measure the metric now, and we know what the baseline is, and we know that it needs to move by this much, and we can measure it once this has been implemented as well. So once we know and they know that we are all very clear on the levers that need to be able to move, then we have that level of specificity, and we're not working towards a vague goal that we can evaluate, that we can price, you know, that can be proven. Those are the things that make pilots stay pilots. And so we we are trying to take this a little bit more, I think, unglamorous kind of approach because getting to down into the weeds of the metrics is not anyone's, like, favorite thing to do that we've seen on the client side, but we believe that it's, like, one of those things where we take our medicine, it's really good for the long run for the health of the project and health of the partnership.

[00:20:51] - [Speaker 1]
And this way, ROI is something that we can both quantify, and it doesn't have to be a, know, he said, she said on whether it was achieved or not. We have something measurable. We can prove whether it was achieved or not.

[00:21:02] - [Speaker 0]
And also, something else that stands out here is instead of renting software, Zeb gives clients ownership of a fork of the substrate engine. Again, this challenges so many assumptions around SaaS and vendor lock in, etcetera. So what led to that decision, and how does it change that relationship between technology provider and customer?

[00:21:24] - [Speaker 1]
That's a it's a great question and, again, a huge part of our design philosophy. Yeah. When we thought when we thought about who, like, Zeb should be, we really we really felt that success for us meant that both our employees as well as our customers have more independence and more mobility after us being in their life than before. And that means that we have to build everything to discourage dependencies. It's a bit counterintuitive by from a consulting perspective.

[00:21:52] - [Speaker 1]
I think all of consulting has been built as well as SaaS for, you know, its virtues has been a dependency relationship. It's they call it stickiness, whatever. It's it's recurring revenue. There's names for it, but it is a dependency. That is really what it is.

[00:22:06] - [Speaker 1]
And our thought process was if we really believe that Zeb can be value accretive, is truly a partner to our customers, then we should be able to not treat substrate like a black box. We shouldn't be treating it like, hey, this is you're paying us because we have this special thing that you don't have. The thing that they really should want to pay us for is the fact that we've built this entire organization around it, and we've built, like, a very specific function of the organization is built around auto evolving strep substrate. Right? Like, making it better every single time.

[00:22:36] - [Speaker 1]
That's the secret sauce. That's really what you're paying us for is the way we view it. And we're going to approach this partnership like no other and give you, if you so desire, the ability to use this internally as well. You can own it. Right?

[00:22:48] - [Speaker 1]
We'll modify it. We'll customize it to you. But for us, the the thought process here is the engine substrate is not really the moat. The moat is the research layer and the fact that Zeb is a very research centric and oriented organization that's constantly extending the engine, and that's really what we believe the meaning of handing over, like, a fork of substrate is for us. The client's never a hostage.

[00:23:09] - [Speaker 1]
We never want our clients to feel trapped or feel like, hey, you know, we have to use them. We want them to use us because they want to use us, because we're a partner, we're not a vendor. And, you know, again, every commitment I think you'll see across this release is is built specifically for that.

[00:23:25] - [Speaker 0]
Everything that you're saying and your attitude here is just so refreshing to hear, and you and your cofounder are building a company around an architecture that continuously learns and improves with every project that it executes. And, I mean, I was gonna say if we look ahead three to five years, but, I mean, that is just impossible looking at how much change we've seen in the last three to five years. But, I mean, how do you see consulting software delivery and enterprise operations? How do you see it all changing if AI native systems become the norm rather than the exception? It really feels like you're leading the way here.

[00:23:59] - [Speaker 0]
But where do you see it all heading?

[00:24:01] - [Speaker 1]
Yeah. I think I think more and more we see the lines between these dissolving. And I think just in general, that's a theme that we're starting to see more and more is silos are starting to dissolve because the agents are operating across a very wide connective tissue, and they're able to detect patterns and take actions across many systems, and they're able to be multidisciplinary. So the things that have held us back often as humans where we only have so much capability and we can only build expertise so quickly, that a lot of those limits have been removed. So knowledge work is looking very different.

[00:24:33] - [Speaker 1]
Right now, you sort of have these three separate industries of, like, advisory, build, you know, run. You have a a lot of different companies that specialize in one of these things or two of these things, but not often all three. But for us, when the system that we're giving customers is actually the same system that's building things, and it's also the system that can operate. We're taking a very systematic approach to these things, and so those categories stop kind of making sense. And you don't necessarily want to hand off between them because it is one continuous loop.

[00:25:02] - [Speaker 1]
The only way you really unlock the most efficiency is by treating it as a continuous loop. So I think overall, like, delivery is going to stop being the sort of depreciating asset from a human perspective because the people that are going to be involved are going to be value creation people. Right? So the traditional consulting project that sort of ends and the value starts kinda decaying as soon as the team leaves, that's kinda the old model. And a system that's going to learn from every single engagement, that's the new model.

[00:25:28] - [Speaker 1]
Each project is actually making the next one better, which is how I think we're viewing delivery is going to be an appreciating asset because it's truly making the value of our company higher. When I talked to, you know, Sid, our CTO about this, his entire thought process here is that the architecture has to physically improve with everything that it executes. And the unit of the competition actually becomes the rate at which our system learns. Right? Not how many people we put on a problem, which is what enables us, you know, even as a 500 member company, like, the people are not our signal of how successful we are.

[00:26:01] - [Speaker 1]
Like, we have to actually talk about it in outcome shipped in the actual units of value that are shipped. And I think you're gonna start seeing this really big change where the pyramid org starts getting smaller, flatter, builder dense. You're already seeing it a lot in AI native organizations where they're hitting success rates and revenues so much higher than anyone thought possible with so many fewer people than people thought possible. And it's because these systems are just scaling capability at a rate that's kind of unimaginable.

[00:26:29] - [Speaker 0]
Thank you so much for sharing your story today. I think it's a powerful and thought provoking moment to end on. That is Substrate, man. It learns, self adapts, and improves with every project that it executes instead of just layering AI tools onto old processes. And the big takeaway there, it can cut project timelines from months to minutes.

[00:26:51] - [Speaker 0]
But anyone listening wanting to learn more about this and continue the conversation with you or your team. Where should they go? Where can they keep up to speed with everything?

[00:27:00] - [Speaker 1]
Yeah. Zeb.co is our website, zeb.co, and we also have a LinkedIn page where we post all the great updates and research updates that are happening at Zeb.

[00:27:10] - [Speaker 0]
Awesome. Well, I love what you're doing here, especially how you scrapped your entire infrastructure, rebuilt it, weaving an AI native operating system into every layer of the new design. Incredibly bold move, and that isn't the only one, of course. But also, today, we talked about what AI native really means. Big buzzword right now.

[00:27:29] - [Speaker 0]
And why it's so hard for companies out there to bring it to life, especially as the demand for ROI on industry wide investments in AI continues to grow. And for all of these reasons, I think this conversation today feels more topical than ever. So I will add links to everything that you mentioned there. I urge anyone listening to check out the blog post associated with this, episode today and find out more. Get in touch, and have a play, and experiment, and see where it leads, and then feedback to me.

[00:27:58] - [Speaker 0]
But more than anything, Mel, thank you for bringing all this to life today.

[00:28:02] - [Speaker 1]
Thank you. Thank you so much for the opportunity, and super excited to be here.

[00:28:06] - [Speaker 0]
Wow. What an inspiring guest today. I mean, having listened there and digested everything that she said, I think one question still remains, and that is how many organizations are genuinely AI native, and how many are simply adding AI onto existing processes? I mean, my guest today offered a compelling argument that the next wave of AI adoption is gonna require a much deeper change. And whether you agree with every aspect of Zeb's approach or not, there's no doubt here that that willingness to challenge long term standing assumptions, I think, creates an interesting perspective on where enterprise tech could be heading next.

[00:28:46] - [Speaker 0]
And as businesses continue searching for that elusive measurable return on AI investments, I think the organizations that do rethink how work gets done, I think they're the ones that will have that advantage over those that are still trying to optimize systems that were built for a completely different age. So question for you all. If AI became the foundation of your business tomorrow rather than just another tool in the stack, What would you need to change first, and what are you gonna take away from today's conversation? Techtalksnetwork.com. You'll find out all information that we talked about today in the blog post associated with this episode.

[00:29:26] - [Speaker 0]
And most importantly of all, let me know your thoughts. But that's it for today. I've taken up far too much of your time already, so I'll return again tomorrow. Same time. Same place.

[00:29:36] - [Speaker 0]
Bye for now.