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 Whiteneck. I'm the CEO at Prediction Guard. Really excited for today's episode because it fits right in the theme of our show, which is practical AI, focusing on some things that are actually useful and practical.
Have with us today, Hamza Tahir, who is co-founder at ZenML. They have a new product, a new project, out, Kitaru, which is focused on agents and making agents durable, which is super interesting. Hamza is joining us today. I think you're out at the AI engineers' world's fair, right? Yeah, it's like 7,000 people, all of our crowd gathered in one big hallway.
It's just fantastic to be in San Francisco when the energy is so high. Yeah, that's awesome. Always inspiring and really cool to see also growth in that from Swix and others who really built up an amazing community over time. Friends of the show, so if you haven't checked it out, go ahead and check out what they're doing over there. Yeah, excited to dig in today.
Hamza, maybe just to set the stage. I know your co-founder of ZenML is some background with that, a project and product around MLOps. Now you're getting into agent-agent things. I love your perspective on maybe first off the world that you have been inhabiting around ML and ML pipelines. As now we're all thinking about agents and generative AI and all of these things, from your perspective, before we get into agents specifically, what role does the more traditional ML models, training pipelines, et cetera, play in our world moving forward from your perspective?
Awesome. That's a great one to start with. Thank you for inviting me on the show. Appreciate the opportunity. I co-founded ZenML about five years ago.
This was almost at a point where MLOps was really reaching fever pitch on... There was all sorts of chatter about how to productionize AI and machine learning workloads. I had done four or five years of that in my previous job, where I was co-founded with another company trying to deploy ML models in disparate compute backends and all over, especially out of Germany, Rambes. That led me to having a framework internally that we used that you could write workflows and acts and you could deploy them on these different backends. That turned out to be open source.
We got a bit of production at the beginning and a few projects and revenue and we raised and that's been the story so far. Smacked up in the middle of this. From then to today, we had the agent Renaissance and it felt a bit funny because in MLOps, it was DevOps reinventing itself and with agents, it's MLOps reinventing itself. At the end of the day, it comes down to these basic principles of how to write good software engineering code that runs non-deterministic code in a way that's safe and reliable and retribles. I think if anything, even if you throw away every other tool that we ever used in MLOps, the principles and the learnings that we took from productionizing these applications at scale still translate and are being rediscovered even at the AI URS where I sometimes hear talks.
I seem to remember I've heard this talk before in the MLOps conferences. So yeah, I'm happy to chat deeper if you're interested in that particularly. It's interesting, like you're talking about the workflows, DAC pipelines. There was very much this phase. At least this is how it occurred to me.
I don't know if everyone had this perspective, but there was this phase with generative AI around workflow automation and there was this very much workflow focus for some time with things like NADN or whatever. Those tools are still very useful, of course, but there's this DAG focus and now it seems like people have thought, well, I remember having Jeffrey from News Research on the show and he's like, well, with their Hermes agent or whatever, it's like, well, I don't want to impose my workflow into this, but there's still a workflow under the hood. There's decisions made. There's a workflow executed. It's just like you're not defining it.
And so from the human perspective, you actually don't see that workflow in a visualized DAG, but it exists under there. Is that partially why you think some of these principles carry over or reinvented in a new way? Because at the end of the day, there is some flow of things being executed. Yeah. I mean, a graph, like all software is essentially a graph.
When you write code, you have if this executes that, that's the sequence of steps you're doing in a graph. I think the way we talked about workflows before were more deterministic. Obviously, for example, I come from the world of machine learning pipelines. Like load your data, reprocess your data, train your model, evaluate your model. So we sort of knew the steps ahead of time, and that landed itself to a graph structure.
And graphs introduced order to the chaos of just willy-nilly scripting things. And then obviously, DAGs are directed acyclic graphs, but they are graphs. So they're directed in one direction. They're acyclic. They don't have cycles.
They don't loop back. So in the world of aliens, the acyclic part gets very tricky because it cycles all the way down, right? It's loops. So it's where we had to reinvent ourselves as well. Back in 2003, four users started hacking our pipeline engine to run agents like dynamic steps, traditional branching, state-swatter-fact store workarounds.
And then, you know, we were like, they're starting to fight our abstraction. And we introduced a new dynamic mode. And I think the main key difference here is really, as you said, everything is a workflow. Everything is an agent. In my opinion, it's just an unrolled graph.
So it's like, I don't call it to a call. Sometimes you do the two calls together. So you're just like a tree structure. So the trace, I guess, is a graph. So we just needed to make our system more capable of having graphs that are defined in real time versus statically different compiled at the beginning.
And we did that quite early. And since then, the same abstractions have worked. Except, yeah. And we can get into this. There's these whole new work that we need to think about different things about, like durability, estate management, retries, and how those things work and replays.
And those other things that have been working on in the last two years. Yeah. I would be curious to know maybe as we get into those things, maybe just some of the, I guess some of the stories or types of failures that you see, there's like one piece, which is like how we handle those, how we instrument things, how we, to your point, make our agents more durable. But that's assuming like they need to be made more durable. They are currently not durable.
They're fragile, right? So what are the, I guess, help the audience understand some of those main categories of why agents in our world today are not durable or reliable or however you define that. Yeah. So I think in order to follow that thread, we need to see where the world is going, right? So if you look at how agents, most people when they think of agents, honestly still outside of our little bubble of the seventh of people in the most county center, they think that agents are these local cloud code instances or, you know, the, you know, our like air mass or something.
Yeah. And I think that because we come from this revolution of local, local processes that run on your computer and your token maxing, you know, at, in your local machine, I think that it's very hard to then understand durability because that durability, I guess, and recovering from failure in your local machine is, it's turned out it's a simpler problem than when these things migrate out of your little machine and go into a sandbox or somewhere in your computer, in computers running in the cloud defined by your company that are executing arbitrary code and doing all sorts of things like MCB calls and, you know, like loading skills. And would this be like to kind of go off of your point? This would be certainly people are running cloud code or whatever on their local machine, like you're talking about, but ultimately, at least the way I've heard companies express this is to really lean into this element of how the future is going to play out.
There will be this digital workforce, however you want to think about it. There's agents that are operating and actually taking action within your enterprise infrastructure, that aren't tied to someone's laptop and they maybe then eventually are not just acting, you know, in a single agent type of way, but eventually there is, there are many of these agents that are operating, which I'm sure adds another level of complexity. Yeah, these fleets or swarms or, you know, multi-agent architectures that keep coming up, I think they're getting very real. So I mean, the companies that we work with are doing these things. And what ends up happening once you do that is there is no limit to the scale that you can reach to compete, right?
I'm just regarding token spend. And I mean, why would you not arbitrarily scale that to 100,000 agent executions per hour, if you could afford it, once that you loosen the yoke of the laptop, right? So I have the feeling that, you know, as things as infrastructure gets more and more mature and architectural practices get more mature, we can't really predict how much volume of agents would be running once they're not running locally. And that migration is well and truly underway right this year. And people who get there tend to just like this sort of slow adoption and then suddenly boom, there's like a crazy increase.
And then at that scale, of course, you have different sorts of problems with agents. Like, and I guess that's what we can spend a bit of time talking about. And these agents that would run in your cloud environment, you know, disconnected from your local environment, you know, people might have some ideas of some of the local ones, like a cloud code or open code or open cloud or whatever we're talking about. Could you give us some examples of kind of the other type of agent? Like what are they built on top of?
Like, what are these? Do you envision these as mostly kind of software vendors that are building vertical focus agents and they're deploying, you know, into companies or companies building them themselves? I'm just trying to get like a bit of a vision for people of like what these things might be. So I think this is a big battle in the industry right now. Who owns that part of the stack?
So you know, you let's start with the most easiest part of the stack. It's the harness, right? So the harness and the model providers have been for the last year, type key coupled. And I like maybe should spend a little bit of time talking about the harnesses. Yeah, go ahead.
We've mentioned it on the show, but I think always it's like, this is one of those concepts that has popped up and it is often very subtle for people like what we're talking about. It's very ephemeral anyway, because what used to be an agent is now a harness. So the definition I cling on to in July 2026 is basically, you know, we had this notion of an LLM model, right? The LLM model is simply a token generator. So in itself, it doesn't do anything.
It doesn't do action. So the way we did action was we started three years ago with structured outputs and tool calling. And suddenly what is structured output into calling? It's simply imposing policies on what type of tokens can the model generate to predict the next action inside the environment in which it's playing. So you can, ahead of time, you give it like five tools and you say, hey, you have get weather or you have like ping-hansa or like ping-dang and you have all these bunch of tools to send emails or do different things.
And here's the definition of the parameters of these tools. And then whenever you think that you need more information, given that description, you can return me a bunch of tokens, which I can parse and actually map that to my code and execute it. And that while loop, that's the agent, right? And suddenly we started having a program that runs on your machine at the beginning, which mapped those tokens back to the tool calls. And turns out that's harder than it looks.
I still remember when I did it the first time, like three years ago, it was like, you literally have the literally do a exact like an eval or in Python, which converts the string into code and runs it. I guess that's what's happening under the door. But basically, three years of software development later, we had things like Cloud Code, which started doing more things while having that while loop. So things like compaction when the context window gets too big or things like ensuring that the tool calls have the right parameters. Indexing memory.
Yeah. Indexing memory. So that software program is called the harness. So it's basically the thing that gives your brain a hands like a body. So your brain is just spewing out tokens and converting those tokens into actions.
And the outcome that comes out of combining the harness and the model is the agent, right? So so that's how I think about it. I will obviously be very embarrassed in a year when I'm listening back to this. For what it's worth, I mentioned Jeffrey and Nus, like he gave the same, a very similar metaphor of brain and body. At least we're in safe.
Yeah. We're in safe. Safe territory for now until the industry decides to flip this. So so so obviously the most famous harness is being like some interesting phenomenon started to happen because what we ended up figuring out is that the model started to ask them to open performance and what the model providers quickly found out given their valuations is that if you just make this program better and you manage context better and you manage memory and all those things, general purpose tasks get easier to solve. And therefore, you could just make a better program, right?
The better program will win given the model's day static. And then they started a weird RL loop. So what they what they did was they, like Cloud Code for instance, has a very, you know, Cloud Code is the harness and underlying it is open for a day. And Opus 4.8 by now, unlike Opus 3.5, understands what Cloud Code itself is. So it's self-aware in the way it's running inside Cloud Code.
So when it calls a tool like edit file, it actually uses certain parameters and the tool calling is very accurate. If you if you drop GPT 5.5 into Cloud Code, the harness, that would not be as accurate. It wouldn't perform as good because simply the two things have coupled together. So the harness with the reinforcement learning loop that has gone on for the last year now has coupled deeply with the with the models. Now, on the same time, there has been this renaissance of open harnesses, right?
So we had by we have frameworks like Lengraf or by Nanticai. And those harnesses are of the opposite opinion that we should have an open standard that shouldn't be tied to the model because we don't want to be tied to the model. I mean, if the US government decides to ban and unbend models, that shouldn't affect our business outcomes. And that has been an underlying tension in the industry for the last year and hasn't resolved yet. My intuition says that open harness will win, which recognizes those things.
But on the other side, I mean, you know, better than most people that I mean, it works, right? So why do I use anything else? So that's another thing. Yeah, I would guess that there's there's going to be a mix for for some time. You see this also with the existing software vendors who are trying to figure out how they show up within within agents like a net suite or a sales force or whatever.
You see on the one side them officially supporting MCP interaction with their platform because they see maybe well, the value of our platform is how we manage this data, how we create a function on top of it, the ability to do actions within this environment, and the interface through which people do that like an agent really like where the value is in the platform and that data not so much the web interface through which people interact with the product. But then on the other side, you see the same individuals, you know, the same companies creating proprietary agentic things in their web, you know, web app, which you can't swap out to your point.
You can't swap out the, you know, in many cases, you can't swap out the underlying endpoint to change out the brain to your point. Yeah, because the brain ultimately is commoditized. It's like electricity. So what else are going to make the next whatever a trillion dollars on and that's the whole stack, right? And we haven't even gotten to the point where it's so this is all local, right?
So this revolution is happening December 25, we come into this era of suddenly this works, excuse me for the language. And then it's like, okay, so what has started working? So we have buy and you have open claw and the innovation is that it's running all the time and it has a heartbeat and it's like it's managing memory somehow better. And okay, what did we actually change or we changed our nest? So somehow, like Peter Steinberger and Mario and I mean, like those guys, they had better ideas how to manage that program, which just got fired.
And, yeah, and, you know, we haven't even gotten to the point where let's get these things out of the computer and into a community faster or something. Yeah, yeah, super, super interesting. Sometimes the gap between AI generated ideas and production ready work can be really frustrating. Agents can produce things that aren't editable and don't live in your core workflows. That's why I really love what our partner framers doing with the way they're integrating agents into their website platform.
Teams work in the same place where the real site is designed, managed, reviewed, and published. It lands on a canvas, stays editable, and can be published when the team is ready. Framer is a complete website platform, not just a builder, so teams can launch and keep improving their sites in one place. Learn how you can get more out of your website from a Framer specialist or get started building for free today at framer.com slash practical AI for 30% off a Framer pro annual plan. That's framer.com slash practical AI for 30% off framer.com slash practical AI rules and restrictions may apply.
Well, Hamza, it was really good intro to, I guess, just how to think about or categorize some of these things and the shifts that we're seeing in our mind. Let's go under the assumption that maybe there's even people listening to this podcast that have envisioned products that have agents in them. They're maybe building agents that they intend to sell into the enterprise, or maybe it's part of people in a larger company that are building their own agents for operational efficiencies or internal tools. They are picturing that future that you described, which is, hey, I actually want these things to run off my laptop. I'd be able to take my laptop going to a meeting and not have to keep it up all the time for my agent.
In that sense, then, assume we have some of those agents running in that type of environment. What are some of these, I guess, fragilities or points about agents in terms of how people are architecting them now, how they're building the agent harness piece that make them fragile, not durable? Yeah. So I think first, we have to understand the different types of agent workloads that can run in the background. If you're talking about a chatbot interface, which is or voice agent, that's largely different from a personal system that's running or deep research or auto research that's just doing a single loop and always on and achieving some outcome.
So I think that for all of those different types of use cases, there's different infrastructure pieces and different ways to think about it. So I would say that it's a simple agent that's running online somewhere. I think that I would personally default to something which is very easy, whether that's using the motor providers and Tropic Managed Agents, they have inbuilt routines and all those things inside the harness now that you can deploy and take care of all of that infrastructure for you. Now, when it starts getting more complex where your workflow starts looking a little bit more business processing, meaning you have a workflow, which is doing things like fetch an order here and do some processing with an LLM, which is an agent loop here and then do some post processing there.
So then it starts looking a bit more complicated. And if you do that at scale, then you might want to own that infrastructure. So the first thing you do is sort of have an agent platform internally as an enterprise. But this I highly encourage people who are scaling beyond single teams to really invest in, similar to MLOps where the people who built the best MLOps platforms like Uber, they want them to have their markets. I'm not saying that the ML platform was the reason over one of the techs again, but it was a big reason that they made things like search pricing and they were the best product out there in the market for a while.
And I think the best companies will be the ones that invest internally to build platforms that can run these things at scale because simply the act of doing that informs you so much internally of what works and doesn't work for your particular business context. In that, I guess the set of things that you need to have in place to support that, let's say I didn't want to go down that path, I want to own it. What are some of the main sets of things that need to be thinking about? I guess. Yeah.
So the first thing is you need to pick your harness or you need to give your teams the ability to create using an agent framework, whatever, let's say you're using Lengrad for identity I or something like that. Then you need to deploy it onto some compute target. Let's say you have big something, probably you have other applications running, so probably you use the same thing whether that's ECS or AWS or whether that's a community cluster running somewhere. Now you have an API, so you have a REST API. I'm more of a Python.
I'm going to get Python analogy. Let's say you have a fast API application, you have a post-rest call that kicks off an agent. Obviously, the first failure more that will happen is that these things are not quick requests restful that just execute in milliseconds. These are very stateful processes that run for a long time. They can't run in process.
This is where you start to farm out things, actually do things like workers and task use. When you start thinking infrastructure like that, then you need to think about what is a tool-based system? Is it a push-based system? This is just where in the realm of how do we execute this so that at a certain scale, it keeps working. Then, obviously, you have this very simple task.
You have an API, and you just directly from the API, you spin up a worker, like a salary worker. You don't want to be doing that because one of the workers goes down because at scaled workers can go down for a number of reason, like network failures or maybe the part didn't exist at that point because somebody was using your underlying compute for something else. A very normal one-on-one architecture is just putting a message queue, a message program in the middle of that. You have a bus, and the fast-duty server, which is the entry point, puts events on a bus, and then these events are terribly persistent. Then you have workers that can spin up and down, and you can do an intensive task, like an agent or a group inside that worker.
From there, you have this problem that, oh, this system is very hard to update. You have to ensure things like need importance and you need to make that system more observable. Or for example, if you're processing a file upload and suddenly you have a multi-work flow system, your task consists of two steps rather than just one thing. Maybe you're calling something at the beginning and then you're doing something else, suddenly you have dependencies between the workers. So, suddenly, this complexity starts to explode from a very simple, oh, I just need to slap a queue in front of my fast API to, okay, I need to tag a workflow execution.
Nothing. Then you're looking at it, okay, how do I make this tag orchestration thing work with my harness, and how do I make things like in-flight updates? What if there's a long-running task for 30 days? And that's running for 30 days. I mean, most tasks are not running for 30 days, but they can very soon, right?
And what if the next person kicks off another 30-day task, but that's a different, you've updated the code. So, what happens in the 31st stage? Should I use the latest code or should I use the old code that's virgin to that agent system? And what happens within the 30 days? The LML model gets banned by the viewers' government.
I'm going to keep saying that because I'm in the US now. So, yeah, yeah. There's a whole plethora of problems that start happening from the infrastructure perspective to make things really reliable and that you don't just write defensive code all the time. You don't want your developers to be writing defensive code. You want them on the offense, right, use cases.
And what about, I guess, and I really liked how you framed this when I was looking through the Kidaroo pages and docs, is like, there's a lot of questions that you could be asking. What if the tool calls timeout? What if I don't use a re-ranker? Can I use a cheaper model for that? There's a lot of, I guess, developer side questions that come up.
Certainly related to some of those things, like the supply chain thing you mentioned about a model being all of a sudden identified as a supply chain risk, which I think is a very real one. But there's all these other things. There's so many possibilities of how you could update your agent harness. It's very much, I mean, I remember just when I would teach workshops and just talking about ML models or single LMM calls, I would get pushed back saying like, well, how do we test these things rigorously, right? They're non-deterministic and they could return anything.
And having a background in physics, we wouldn't know a lot about the universe if we weren't able to test things that were non-deterministic, right? So I look, this is, I mean, you're so right, because I was lingering too much on the infrastructure side probably, like the developer side, the things that you're talking about is post fact that once those things are running, so you have some notion of stage, then you have so much pressure. It's a multi-layered problem. Yeah, yeah, there is the infrastructure and there it's like both interact in interesting ways, like in the way how long something takes or how it times out or whatever, certainly related to network and infrastructure. But then there's all of these choices that you can make within the agent, right?
Yeah, I'll give you a good example. I mean, imagine you have a coding factory, like this is the buzzword for EIE right now, right? Coding factories. So we're going to automate software engineering and imagine that an agent is running in such a system that I described in workers. And suddenly it obviously has to execute code, right?
So it needs a sandbox and this is why the sandbox providers like E2B data on our model are so popular nowadays because you need a sandbox to execute our pre-code. So that's another problem, suddenly that appeared on the infrastructure side. And now what if the file system that you're editing the code, you fail before you can commit the code? Like how do you get back to that state? When, you know, 20,000 tool calls in to our code is almost about to finish the feature and it just suddenly fails and are you mounting the file system into the pod?
Because this is not your machine anymore, right? Yeah, yeah. Typically when pods die and then how do I, like even if you get to the end and it finishes, like what if somebody looks at that and says, this is a feature? This is not what I wanted. So how can I go back and evaluate?
Do your point? Like how can I go back and evaluate? Like, hey, could I have done this faster, cheaper, better if I had done an experiment of using GLM maybe instead of GPD or maybe I wanted a different tool call. Maybe I should have given it so many tools. It got confused.
Maybe just give it two calls and start again. Yeah. Yeah. And I think that would be especially true if you are moving from this, like this is my personal agent, which I can look at the output and then maybe provide, you know, I can actually commit to memory or skills or that sort of thing. Like, this is how I want it to go.
This is how you should do things. But it's another thing if these are more autonomous, they're operating in the enterprise environment or like I'm a software vendor and I'm creating my own, you know, my own agent, which is my product, my IP. And this shouldn't just be like a general purpose agent, right? Like there should be an opinionated take on how to do these things in this vertical that operate better because I'm infusing actual opinions into the harness. Yeah.
Actually, that is the biggest unsolved problem, right? Then like, I mean, you've probably been building agents for years now. So I still am terrified updating my agent in production. I'm terrified because I have no idea. I have literally no idea given the entropy in that system, how I can even adding a word to the system prompt or to happen.
And that terrifies me in a world where you have hundreds and hundreds of millions of these things running in enterprise in flight, right? And suddenly you have to, you have to task the poor agent developer to grok all of these context states in the very stateful application and try to make an educated guess as to how to update the system in a way that wouldn't break for all your customers. It's almost impossible, right? Without giving the right observability, given the right ability to go back in time and introspect and try to run some of these experiments. Like, you need to have sort of a simulated, I keep saying physics words, entropy, it's just a simulation.
So yeah. And that's some of what you're doing with the Kidaroo, right? Which is, could you explain kind of, maybe just introduce a little bit of the idea behind that. And I know there's some really interesting things around replay, for example, but yeah, I would love to hear more about that. So yeah, Kidaroo comes from this concept of, you know, it still uses ZenML.
So ZenML is our open source product that's been running in production for enterprises for five years now. So we really, we sort of know how to do workflow orchestration now. So we, our task this year was how do we convert that into using that engine in a way that's ergonomic to agent builders and sort of try to take opinions on some of the things that we just spoke about. So Kidaroo is built on top of ZenML. It's a new SDK and a new UI that's works almost from the harness backwards because I think very important is the harness layer because that's what most people are, is the entry point to agent building.
And a lot of the opinions taken in that harness layer, actually, as we just talked about in this episode, it do matter a lot at the infrastructure layer. So our goal is to build an open runtime that allows you to take any harness and deploy it in a way that you don't have to think about some of these problems. And then on top, it gives you all these goodies of replay. And how we end up doing that is turns out, if you hook into the harnesses, there's certain checkpoints in state that you can snapshot and store while you're running it on, let's say, a Kubernetes cluster that will make life a lot easier once those inevitable failure modes to kick in. So the first order of business was how do we get the best world-class adapters for all the popular harnesses, like a propagated SDK, open AI, it's SDK that you can just drop Kidaroo as a runtime in and it gets it from your laptop out to the production.
And then once it's running, it makes it resilient to tool calls failing in the middle of an agentic loop by storing that state in an external database or a blob storage. And once we have that state, then we have all sorts of interesting questions like you already talked about what if you want to mock a tool call or if you want to change the replay a different model and drop that in the middle of your trace. And this is a very interesting problem anyway, like from a scientific perspective, because if you change the model midway in a multi-turn conversation or multi-turn situation, then what ends up happening is that you never really know that the agent would have ever gotten to that point if you had started with a different model anyway.
So it's anyway a broken experiment. And also the problem is that when you replay from the middle, you have certain, like if you swap out GLM with code code, like the harness differences also make it just hard to just start again from that point anyway. So there's a lot of code that you have to write in order to make that experiment somewhat feasible. And again, it's not perfect and we're still working with our customers to make it good, but given that you're grounded in your production traces, production executions, and you have a big enough sample size, you could then, like we have seen early signs of where you could just say, oh, I should have just used an open source model or a smaller model, or I should have just swapped out some of the tool calls and made it a bit easier. And I would have gotten a better and cheaper result in place of that.
Yeah. Do you view this as, but what's the way to put this? So like I think of, you know, taking it out of the AI agent world into like manufacturing, you have like a pipeline in your manufacturing or a line in your manufacturing plant, there's always going to be a bottleneck in there, right? And so often what people recommend, right, is you find the bottleneck, you ignore the other things, you address that bottleneck, and then you have a new bottleneck, right? So one way to approach this would be that way.
You could also approach this and look at, well, there's all these things happening, right? It's really, yeah, there's, of course, all sorts of optimization theory on like how to optimize things, but like, there's all sorts of things that are actually coupled together, right? If I optimize this, then that gets faster, but creates a different, you know, a different problem. So like, what have you noticed after actually having, which I think a big piece of this to your point is like actually getting visibility into what's happening, but then comes the next question of, well, now, now what, right? Like, what are the best, and maybe it's a part of like, we don't know the best practices around addressing some of these things yet.
Yeah, I mean, exactly, like exactly how I imagine it as well. It's like playing a game of whack-a-mole and trying to sort things out. So when you fix one thing, another thing breaks, I think the first order of business, so I checkpoint everything. So that's the durability aspect, right? So I mean, obviously there are latency concerns, you need to be efficient about it, but checkpoint everything so you can look back.
And then I think it's almost humanly impossible to do all the experiments, so you've got to get agents doing that, right? So I think our goal really in the future is how can we close the loop from like once, because you sort of know the outcome, right? You want to cheaper, better, faster model agent at the end of the day. So we have the production executions, the traces, and the first thing I ask people to do when they're using it, I'm like, run it for a week, and then after a week, just filter for the most expensive traces, which were successful, watered by your customers, go through the checkpoints and see the Bartlex, just like you said, and figure out the common failure modes and then go from there. But obviously, my goal is not that humans do this, our, you know, we ship to MCPC, CLI, day one of Kitaru, because we know that eventually that problem needs to be solved by other agents that sort of are embedded in that loop.
So my ultimate goal is you have every time you launch an agent, you have a companion, like a companion, a nurse agent. Trainer, or, yeah, that's a loaded term, but. Exactly. I mean, something like a trainer that's, you know, that's constantly looking at, okay, what is this guy doing wrong? And then running experiments in the back, replaying things and constantly editing that thing.
And we're very far away. I mean, to be clear, this is a, this is a, this is a dream, because then, you know, even builders can start from a really state and get to a very efficient state very quickly. But I think we need more tooling and infrastructure to make that possible, because that is eventually the future. And I guess that does get to, you know, a really good place for us to kind of start wrapping up the conversation, which is as you see the current state and you look to the future, maybe on both sides of this, like what's one area where you're really encouraged and, you know, it excites you of like, hey, things are going in this direction. And I'm really happy about that.
And this is maybe what we could expect. And then maybe something, like you said, oh, if we could solve this, if we could move this big rock, like that would open up a lot of opportunities, any thoughts? So I start with the thing I'm less optimistic about for now as an industry, because, you know, you catch me at the very opportune time right after this, I'm going to go to the AIE conference, so I'm going to be at the World's Fair and working around the Expo. It strikes me how many people have different takes on solving the same four or five problems. So I think we're at this fever pitch of like we have an MLOps in 2021 when Chip Huan, like maybe we can drop that article in the show, it's very good.
It's a very good, yeah, like when we get an explosion of tools when we had these MLOps problems and investor money came in, and then, you know, it was just extremely confusing to figure out the modern MLOps stack or on top of the data stack. And I think that this is why, I mean, we're sort of contributing to that noise, right? By taking opinions, but I feel like we are very early in deciding the canonical ways of separating things like the harness and the infrastructure and the deployment paradigms. And I'm less encouraged by that by the model providers taking such aggressive stances on how to deploy things and how aggressively they make things hard to other vendors to be interoperable. Although there are some good signs sometimes, but you know, it's just they're pushing to the harness and when you're pushing to the harness, you want everything running on your own front.
I think this is this is this is a slight negative economical impact. But on the other side, okay, here are things where I'm very optimistic. You have amazing open efforts with open source models, like mini Macs or like the KIMI models or take something like GLM coming out of China right now, but hopefully also the US and Europe with this trial that have made it very economically viable to start, like the enterprises have started to really take it seriously to replace that the bigger model providers with their own systems.
And I think that's going to be eventually where when they start thinking, okay, we need to have system engineers that think of that problem and start being around with and fiddling with the other pieces like the harness and the durable runtime. And I'm very encouraged by the fact that we have now performing models that are just this is like two weeks old, right? So GLM is as basically 95% of what was for credit, which is phenomenal. Like we are we were at a trajectory that that was very far away. But in a world where you can have sort of the same performance with open models, then I think you see more investment in creating internal platforms that can deploy those agents and then open harnesses will be a huge thing in my opinion, because a thing like buy or a thing like open code or something like that or even specific harnesses for law or for science or something with probably exploding growth.
And suddenly you have this thing where people will start realizing that actually investing in internal infrastructure at the enterprise level is probably going to be the competitive differentiator in a world where the tokens regress down to the cost of electricity and the models become commoditized. And this is I'm extremely, extremely encouraged by the recent progress around that. Yeah, that's I think a great perspective. And I think it encourages people also that are listening to the show. Please check out these open projects around open harnesses.
A lot of them are even linked in the ZMML website and integrations that they have. I encourage you to check out the ZMML website, try some things in your own environment. It's never been easier to spin up some of your own tools and infrastructure and try things. And I would encourage that you'll find some links in the show notes. Thank you so much for joining us, Tomza.
It's been great. Thank you for having me. All right, 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.