Hamza Tahir says he co-founded ZenML about five years before this episode, when MLOps interest was at a peak.
“So I co founded ZenML about five years ago, so this was really, almost, um, at a point where ML Ops was really reaching fever pitch”

9 Jul 2026 · 46m · Daniel Whitenack, Hamza Tahir · 23 quoted facts
Hamza Tahir argues that AI agents are the next chapter of MLOps, the practice of running machine learning reliably in production. Agents are non-deterministic software that must be safe, retryable and observable once they leave a laptop. His company's new open source project, Kitaru, builds on ZenML to checkpoint agent state so failures can be recovered and past runs replayed and improved.
The central tension is between model providers and open alternatives. Providers like Anthropic tightly couple their models to their own harnesses, the programs that turn model output into actions, while open harnesses aim for portability. Tahir expects open models, open harnesses and in-house agent platforms to win as models become commodities, though he admits the tooling landscape is noisy and unsettled.
Tahir says the principles from productionizing ML, such as retries, safety and reliability around non-deterministic code, carry over directly. He notes talks at the AI Engineer World's Fair resemble old MLOps conference talks.
Traditional pipelines are directed acyclic graphs with no loops, but agents loop continuously. ZenML users began hacking its pipeline engine to run agents in 2023, which led the team to add a dynamic mode where graphs are defined at runtime.
Reinforcement learning has trained models like Opus 4.8 to work well inside their own harness, Claude Code. Tahir says dropping GPT 5.5 into Claude Code would perform worse, which pushes against open, swappable harnesses.
Agents that run for days cannot live inside a simple web request, so they need task queues and durable message brokers. Updating code mid-run, workers dying, and sandbox file systems vanishing all raise questions about which version to run and how to recover.
Kitaru snapshots agent state in external storage so runs can be replayed with different models or mocked tools. Tahir admits mid-run model swaps are an imperfect experiment, but production traces can still show where a cheaper model would have worked.
Tahir defines it as the software program that wraps a model, turning the tokens it generates into real actions like tool calls, and handling things like memory and context compaction. The model plus the harness together make the agent.
Once agents run in the cloud for long periods, things like tool call failures, crashed workers or dead pods can wipe out hours of work. Durability means saving state so the agent can resume or be replayed instead of starting over.
Kitaru is a new open source runtime and SDK from the ZenML team, built on top of ZenML's workflow engine. It plugs into harnesses such as the Anthropic and OpenAI Agents SDKs to checkpoint state and enable replay and observability.
Tahir says even adding one word to a system prompt can change behavior in unpredictable ways across many in-flight, stateful runs. Without good observability and the ability to replay past runs, developers cannot tell what will break.
Tahir recommends it for organizations scaling beyond single teams, comparing it to how Uber's ML platform helped it win. He argues internal infrastructure will be a competitive differentiator as models become commodities, while simple agents can use provider-managed options.
Stated by the speakers. Each quote matches the transcript, which shows what was said, not that it is true.
Hamza Tahir says he co-founded ZenML about five years before this episode, when MLOps interest was at a peak.
“So I co founded ZenML about five years ago, so this was really, almost, um, at a point where ML Ops was really reaching fever pitch”
Hamza Tahir says he spent four or five years deploying ML models at a previous company he co-founded before starting ZenML.
“And I had done four or five years of that in my previous job, where I was co founding um, another company, uh, trying to deploy ML models”
ZenML grew out of an internal framework for writing workflows and DAGs, was open sourced, gained early traction and revenue, and raised funding.
“And that turned out to be ZenML. We open sourced it, we got a bit of traction at the beginning and a few projects and and revenue, and we raised”
ZenML introduced a dynamic mode so workflow graphs could be defined at runtime rather than compiled statically in advance.
“So we. We introduced a new dynamic mode.”
Tahir describes a large language model as a token generator that cannot take actions on its own.
“The LLM model is simply a token generator, so in itself it doesn't do anything, it doesn't do action.”
Tahir says action-taking by models began about three years earlier with structured outputs and tool calling.
“So the way we did action was we started three years ago with structured outputs and tool calling”
Tahir defines an agent as the combination of a model and a harness, the program that maps model tokens to actions.
“And the the outcome that comes out of combining the harness and the model is the agent, right?”
Tahir says Claude Code is a harness running on Opus 4.8, and that the model has learned to recognize the harness it runs in.
“CloudCode is the harness. And underlying it is Opus 4.8, and um, Opus 4.8. By now, unlike Opus 3.5, understands what CloudCode itself is”
Tahir says placing GPT 5.5 inside Claude Code would perform worse because models and harnesses have become coupled through reinforcement learning.
“If you drop GPT 5.5 into Cloud Code, the harness, that would not be as accurate, it wouldn't perform as good”
Tahir names Pi, LangGraph and Pydantic AI as open harnesses that argue for standards not tied to a single model.
“So we had Pi, we have frameworks like LangGraph or Pyantic AI, and those harnesses, uh, are of the opposite opinion.”
Tahir says moving agents from laptops to cloud infrastructure is underway in 2026, with adoption described as slow and then sudden.
“it's like this sort of slow adoption, and then suddenly boom, there's like a crazy increase.”
Tahir cites Uber as an example of a company whose strong ML platform helped it win its market, including features like surge pricing.
“Similar to ML Ops, where the people who build the best ML Ops platforms like Uber, they won them, their their markets.”
Tahir describes a standard architecture where an API server places events on a message broker and workers process them, so tasks survive worker failures.
“So a very normal one o one architecture is just putting a message queue, a message broker in the middle of that.”
Tahir says agents that execute code need sandboxes, which explains the popularity of providers such as E2B and Daytona.
“it obviously has to execute code, right? So it needs a sandbox, and this is why the sandbox providers like E2B, Daytona model are so popular nowadays”
Tahir says Kitaru aims to be an open runtime that can deploy any agent harness.
“So our our goal is to build an open runtime that allows you to take any harness, any and and deploy it in a way”
Kitaru's first priority was building adapters for popular harnesses such as the Anthropic Agents SDK and OpenAI Agents SDK.
“how do we get the best world class adapters for all the popular harnesses like Anthropic Agents SDK, OpenAI Agents SDK?”
Kitaru makes agent runs resilient to failed tool calls by storing run state in an external database or blob storage.
“by storing that state in an external database or or blob storage.”
Kitaru shipped with an MCP command line interface on day one so other agents can eventually analyze and optimize runs.
“We shipped an MCP CLI day one of Kitaru because we know that eventually that problem needs to be solved by other agents.”
Tahir advises Kitaru users to run it for a week, then filter for the most expensive successful traces and inspect checkpoints for bottlenecks.
“run it for a week and then after a week, just filter for the most expensive traces.”
Tahir compares the current agent tooling boom to the 2021 MLOps period, when many tools appeared and investor money flowed in.
“when we had an explosion of tools, when we had these ML Ops problems and investor money came in.”
Tahir says the open model GLM reached roughly 95 percent of the performance of Opus 4.8, and that this was about two weeks old news at recording.
“The GLM is as basically 95 of Opus 4.8, which is just phenomenal.”
Tahir cites MiniMax, Gemini and GLM, plus Mistral in Europe, as models making open or alternative options economically viable for enterprises.
“Take min, like Minimax, or or like, take the Gemini models, or or, or, or, or take something like GLM coming out of, um, like China right now”
Tahir credits Peter Steinberger, Mario and Armin with better harness ideas behind Pi and OpenClaw, which became popular around December 2025.
“Peter Steinberger and, uh, Mario and a Armin, like those guys, they had better ideas how to manage that program, which just caught fire.”
Tahir explains how ZenML's workflow background led to agents, and why MLOps principles still apply.
“it's like ML Ops reinventing itself”
Agents loop rather than run in fixed order, so ZenML added a dynamic mode where graphs are defined at runtime.
“in the world of agents, the acyclic part gets very tricky because it cycles all the way down”
Defines the harness as the program that gives a model a body, and explains how it became coupled to models.
“it's basically the thing that that gives your brain a hands like a body”
Describes the industry tension between provider-controlled harnesses and open, portable ones.
“has been an underlying tension in the industry for the last year”
Walks through task queues, brokers, long-running tasks and code versioning that make agents fragile in production.
“These are very stateful processes that run for a long time, so they can't run in process”
Introduces Kitaru's approach of snapshotting state so runs can be replayed with different models or tools.
“there's certain checkpoints in state that you can snapshot”
Tahir closes with concerns about tool sprawl and optimism that open models and internal platforms will differentiate enterprises.
“investing in internal infrastructure at the enterprise level is probably going to be the competitive differentiator”
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 Bluesky to stay up to date with episode drops, behind the scenes content and AI insights.
You can learn more at practicalai. fm. Now on to the show.
Welcome to another episode of the Practical AI podcast. This is Daniel Whitenack. I am CEO at Prediction Guard and 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. Um, and they they have a new, uh, product, a new project, uh, out, Kitaru, who, who, uh, which is focused on agents and making agents durable, which is is super interesting.
And Hamza is joining us. Uh, today. I I think you're out at the AI Engineers World Fair, right?
Yeah, I am, uh, it's like seven zero, zero people, all of our crowd gathered in one small, uh, like big hallway. So it's it's just fantastic to be in San Francisco when the energy is so high.
yeah, that's, that's awesome, always, always inspiring and and really cool to see. Also growth in that from Swix and and others who who've really built up an amazing community over time. Friend, friends of the friends of the show. So if you haven't checked it out, go ahead and and check out what they're doing over there. But yeah, exci excited to dig in today. Uh, Hamza may maybe just uh to to set the stage. Um, I I know, uh, your co founder of ZenML is kind of some background with that uh, project and product around ML Ops.
Now you're getting into agent agentic, uh, things, uh, I. I'd love your perspective on, maybe 1st off, kind of the the world that you have been inhabiting around ML and ML pipelines. A As now, we're all thinking about agents and generative AI and all of these things, like, what, from your perspective, before we get into agents specifically? W Like, what role does the more traditional ML, uh, models, training pipelines, et cetera, uh, play in in our world?
Moving moving forward? From your perspective?
awesome, that's, I think, a great one to start with, uh, and thank you for for like, inviting me on the show. Um, appreciate the opportunity. I. So I co founded ZenML about five years ago, so this was really, almost, um, at a point where ML Ops was really reaching fever pitch on, um, you know. But there was all sorts of chatter about how to productionalize AI and machine learning workloads. And I had done four or five years of that in my previous job, where I was co founding um, another company, uh, trying to deploy ML models in disparate, you know, compute backends and all over, especially out of Germany, where I'm based.
So, um, the like that led me to, you know, like having a a framework internally that we used that you could write workflows and Dags and you could deploy them on these different backends. And that turned out to be ZenML. We open sourced it, we got a bit of traction at the beginning and a few projects and and revenue, and we raised and and that's been the story so far. And and smack dab in the middle of this, from from then, from then to today, we have.
We had the agent uh renaissance, and um, it felt like it felt a bit, a bit funny because in ML Ops, it was like DevOps reinventing itself, and with A agents, it's like ML Ops reinventing itself. And at the end of the day, it comes down to these very basic principles of how to write good software engineering code that runs non deterministic code, uh, in a way that's safe and reliable and retryable. So I think, if anything, even if you throw away every other tool that we ever used in ML Ops.
The principles and the learnings that we took from productionalizing these applications at scale still translate and are being rediscovered. Even at the AI E world sphere, I sometimes hear talks, I'm like, I, I seem to remember I've heard this talk before in the ML Ops conferences. Um, so yeah, I, uh, happy to chat deeper if you're, if you're interested in a particular
I it, it's interesting, like you're talking about the workflows, DAG, DAG pipelines. There was very much this phase, um, at least this is how how it occurred to me. I don't know if everyone had this perspective, but there was this phase with, uh, generative AI around, like workflow automation. And there was this very much workflow focus for some time. With things like, n8n or or whatever, and those tools, still very useful, of course, but there was like this, this DAG focus.
And now it seems like people have thought, well, I. I remember, um, having Jeffrey from News Research on the show. And he's like, well, with like their Hermes agent or or whatever. It's like, Well, I d. I don't want to impose my workflow into this. But there's still a there's still a workflow under the hood, like there's decisions made, there's a workflow executed. It's just like you're not not defining it. And so from the human perspective, you actually don't see that that workflow in like a visualized DAG, but it, it sort of exists under there.
Is that partially why you think, like some of these principles carry carry over or are reinvented in a new way? Because, like, at the end of the day, there is some flow of things being executed, right?
yeah. I mean, a graph, like all software, is essentially a graph, right? When you write code, you have if this, else that, execute this, execute that. That's like the sequence of steps you're doing in a graph. I think the the way we thought about, uh, workflows before were more deterministic, obviously. Um, for example, I come from the world of machine learning pipelines. So it's like, load your data, pre process your data, um, train your model, evaluate your model.
So, you know, we, we sort of knew the steps ahead of time, and, uh, that lent itself to a graph structure. Um, and you know, graphs introduced order to the chaos of just willy Nilly scripting things. Um, 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, um, in the world of agents, the acyclic part gets very tricky because it cycles all the way down, right?
It loops, so it's so, it's, uh, it's, um, it's, it's where we had to reinvent ourselves as well. So back in, like, 2023, four users started ha hack hacking our pipeline engine to run agents like dynamic steps, conditional branching, state to artifact, store workarounds. Um, and then, you know, we were like, Okay, they're, they're starting to find our abstraction, um, and um, we, so we. We introduced a new dynamic mode. And I think the main the key difference here is really, a, as you said, everything is a workflow, um, everything is a an.
An agent in in. In my opinion, is just an unrolled graph, so it's like LLM call, to L call, LLM call, to L call. Sometimes you do the two calls together, so you're just. It's like a tree structure, so the trace, I guess, is a graph. And and we just needed to make our system, uh, more capable of having graphs that are de defined in real time versus statically def compiled at the beginning. Um, and and we did that quite early, and and since then, the same abstractions have worked.
Uh, except, yeah, and we can get into this. There's these whole new workload that we need to think about different things about, like durability, state management, retries and how, how those things work, and replays. Um, and those are the things I've been working on in the last two years.
y. yeah. I. I would be curious to know, maybe, but a as we get into to those things, maybe just some of the I, I, I guess, some of the the stories or types of failures that you that you see there. There's like one one piece, which is like how, 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 not durable.
Um, they're, they're fragile, right? So, uh, so what are the c, I, I guess, uh? Help the audience understand some of those main categories of why agents in in our world today are are not, um, durable, or re reliable, or or however you define that.
yeah. So I think in order to, um, in order to to follow that thread, we need to see where the world is going, right? So if you, if you look at how agents, most people when they think of agents, honestly, still, uh, outside of our little bubble of these seven zero zero0 people in the Moscone Center. Um, they, they think that agents are these local cloud code instances, or, you know, the, you know, or like Hermes or something.
Um, and I think that because we come from this revolution of local local um processes that run on your computer and you're token, maxing your, uh, you know, at in your local machine. I think that it's very hard to then understand durability, because that d durability, I guess, and recovering from failure in your local machine is is. Turns 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, controlled by your company that are executing arbitrary code and doing all sorts of things like MCP calls and and and, you know, like loading skills.
it it. And would this be like to, uh, to kind of go off of your point? This would be, uh, certainly. People are running cloud code or whatever on their local machine, like, like you're talking about. But ultimately, at at least the way I've heard companies express this is to really lean into this element of how the future is gonna play out. There, there will be this, uh, uh, digital workforce, however you wanna think about it, uh, a agents, uh, uh.
Agents that are operating and actually taking, taking action within your enterprise infrastructure, right? That aren't tied to someone's laptop. And they maybe then eventually are not just, uh, acting, you know, in 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, the multi agent architectures that that that we that keep coming up. I I think they're getting very real now. So I I mean, uh, the companies certainly that we work with are deploying these things. And what ends up happening once you do that is there is no limit to the scale that you can reach. Technically, right? Um, disregarding token spend, um, and you, I mean, why would you not arbitrarily scale that to 100 agent executions per, I don't know, hour?
Um, if you could afford it, um, once that you loosen the yoke of the laptop, right? Um, so I, I have the I have the feeling that, you know, as things as infrastructure, um, gets more and more mature, and architectural practices get more mature. Um, w we, we. I. We can't really predict how much, um, volume of agents would be running once they're not running locally, and that migration has is well and truly underway right this year.
And people who get there tend to just. It's 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, uh, and I guess that's what we we can spend a bit of so time, uh, talking about,
I. And and these agents that would run in your, 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 claw, or what, whatever we're talking about. What could you give us some examples of? Kind of the the the other ty type
that's the page.
of type of agent, like, what, what are they built on top of, like, what, what? Uh, are, are these? Do you envision these as mostly kind of S software vendors that are building vertical focused agents? And they're deploying, you know, I into companies, or companies building them themselves? I I'm just trying to get like a a bit of a vi, 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 who owns that part of the stack? So you, you know, you, you. Let's start with the most easiest part of the stack. It's the the harness, right? So the the harness and the model providers have been for the last year tightly coupled. And um, I like, maybe we should spend a little bit of time talking about what the harness yeah, yeah, go ahead, is.
If, please. Yeah, if, if, if, that's we we've mentioned interesting to,
it on the show, but I think always it's like. This is one of those concepts that it has popped up and it m is often very subtle for people like, what we're, what we're talking about, right?
it's very ephemeral anyway, because what used to be an agent is now a harness. So, uh, the definition I cling onto in um, July 2026 is is basically, um, you know, we, we. We had this, uh, 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 outputs and tool calling?
That's simply, uh, 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 it you can ahead of time, you give it like five tools and you say, hey, um, you have get weather, or you have, uh, like, ping Hamza, or uh, like, ping Dan. And like, 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 want, 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, like, 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. It's, uh, I mean it, I.
I still remember when I did it the 1st time, like three years ago, it was like, so you literally have to literally do a exec, like an eval or in Python, which converts the string into code and and runs it. I guess that's still what's happening under the, uh, under the hood. 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, you know, st things like, uh, compaction when the context window gets too big, or things like ensuring that the tool calls, um, are, you know, have the right parameters.
Um, Indexing in theory, memory, yeah, indexing and memory. So that that software program is called the harness. Um, so it's basically the thing that that gives your brain a hands like a body. So your brain is just spewing out tokens and you're converting those tokens into actions. And the 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 s obviously be very embarrassed in a year when I'm listening back to this and for for the definitions,
for what it's worth. I, I mentioned Jeffrey and and uh, news, uh, like he gave the same, uh, a very I get, similar metaphor of like, brain and body. So at okay, awesome, least we're in, yeah, we're, we're, we're in safe, safe we're in safe, company. Yeah,
safe territory for now. Then, uh, until the industry decides to flip this. Um, so so. Obviously, the most famous harness is being, um, like, s. Some. Some interesting phenomena started to happen because what we ended up figuring out is that the models started to asymptote in 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 um, therefore, you could just make a better program, right? The better program will win given given the model stays static. And and then they this started a weird RL loop, so what they, what they did was they, uh, like, CloudCode, for instance, has a very, um, you know, CloudCode is the harness. And underlying it is Opus 4.8, and um, Opus 4.8. By now, unlike Opus 3.5, understands what CloudCode itself is, so it's self aware in the way it's that it's running inside CloudCode.
So when it calls a tool like edit file it, 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 have coupled together. So, um, the harness, uh, with with the reinforcement learning through loop that has gone on for the last year and a half, uh, has coupled deeply with the with the models.
Now, on the same time, there has been this re, uh, renaissance of open harnesses, right? So we had Pi, we have frameworks like LangGraph or Pyantic AI, and those harnesses, uh, are of the opposite opinion. That we should have an open standard that shouldn't be tied to the model, because we don't wanna be tied to the model. I mean, if the US. government decides to ban and unban models, that shouldn't affect our business outcomes. Um, and uh, th.
That has been an underlying tension in the industry for the last year, um, and it hasn't resolved yet. So we I don't. I wouldn't know whether my intuition says then open harness will win, uh, which standardizes those things. But on the other side, I mean, y, y, you know better than most people that I mean, cloud code works, right? So why would I want to use anything else? So that that's y another thing.
yeah, I, I. I would guess that there's, there's gonna be a mix for for some time. You see this also with the I, you know, existing software vendors who are trying to figure out how they show up within within agents, like a NetSuite or a Salesforce or whatever you see on. On the one side, them officially supporting MCP interaction with their platform, cause they they see, maybe well. The value of our platform is how we manage this data, how we create a functions 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, we're are. Are. The value is in the 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, y, you know, the same companies creating proprietary agentic things in their web, uh, you know, web app, which you you can't swap out. To your point, you can't swap out the, uh, you know.
tomorrow, In many cases, you can't swap out the underlying endpoint to change out the brain to to to your point.
yeah, yeah, because the brain ultimately is commoditized. It's like, uh, uh, electricity. So w What el, what else are you gonna make? The next? Whatever? $1 1 trillion on? Um, and and that's the whole stack, right? And we we haven't even gotten to the point where? So this is all local, right? So this this revolution is happening. December 2025, we we come into this era of suddenly this works, right? Excuse me for the language. Um, and then it's like, Okay, so what?
What has started working? Ah, so we have Pi and we 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? What did we actually change? Or we changed the harness? So we so the the somehow, like Peter Steinberger and, uh, Mario and a Armin, like those guys, they had better ideas how to manage that program, which just caught fire.
And um, 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 Kubernetes cluster 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 Framer is doing with the way they're integrating agents into their website platform. Agents work in the same place where the real site is designed, managed, reviewed and published. It lands on the 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. 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, uh, uh, it. It was really good intro to I, I guess, just how to think about or or categorize some of these things and the shifts that we're seeing in our in our mind.
Uh, let let's go under the assumption that, you know, maybe there's even people listening to this podcast that have envisioned, uh, products that have agents in them. They're. They're maybe building agents that they intend to sell into, um, sell into the enterprise. Or maybe it's part of, uh, people in a larger company that are building their own agents for operational efficiencies or internal tools. And they are picturing that, that future that you described, which is, hey, I actually want these things to run off my laptop.
I wanna be able to take my laptop, go into a meeting and not, you know, have to keep it up all the time for for my agent. So in that sense, then assume we have some of those agents running in in that type of environment. What are some of these, I guess, fragilities or or points about agents in? In terms of how people are architecting them now, how they're building the agent? Harness piece that make them, that make them fragile, not not durable.
yeah, so so I think, f um, 1st, we have to understand the different types of like agent workflows that can run in the background. So if you're talking about a chatbot interface, which is, or a voice agent. That's largely different from a personal assistant that's running and or, or a deep research or an auto research that's just doing a single loop. Um, in and you know, g always on, and and you know, achieving, uh, achieving some outcome.
So I think that for all of those different types of use cases, uh, there's different infrastructural pieces and different ways to think about it. So I would say that if it's a simple um agent that's running, you know, online somewhere. I I think that I would personally default to something which is, uh, very easy. Whether that's using the model providers like Anthropic has, Anthropic managed agents, they have inbuilt like routines and all those things inside the harness now.
So that you can, that you can deploy, and they take care of all of that infrastructure for you. Um, now, when it starts getting more complex, where your workflows start looking a little bit more business processy, uh, meaning you have a workflow, um, which is doing things like, okay, fetch an order here, and uh, do some processing, uh, with an LLM, which is an agentic 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 wanna own that infrastructure. So the 1st thing you do is sort of have an agent platform internally as an enterprise, uh, and this. I highly encourage people who are scaling, uh, beyond single teams, um, to really invest in. Like similar to ML Ops, where the people who build the best ML Ops platforms like Uber, they won them, their their markets. Um, I'm not saying the ML platform was the reason Uber won the taxi game.
But it was a big reason that they made, you know, things like surge pricing. And and you know, 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.
yeah, in I in that, I, I guess, the the set of things that you need to have in place to support. That's, let's say, I did wanna go down that path, I wanna own it, the uh, like, what are some of the main sets of things that, like, need I I need to be thinking about? I guess,
yeah, yeah. So so the 1st thing is you need to pick your harness, or you need to give your teams the ability to create, you know, using an agentic framework. Uh, whatever, let's say you're using LangGraph or Pyantic AI or something like that. Um, then you need to deploy it onto some compute target. Um, let's say you picked something. Probably you have other applications running, so probably you use the same thing. Whether that's ECS on AWS or whether that's a Kubernetes cluster running somewhere.
Um, and now you have an API, so you have a REST API. So I, I'm more of a Python guy, so I'm gonna give Python analogies. So let's let's say you have a fast API application, you have a post REST call that kicks off an agent. And obviously the f the the 1st failure mode that will happen is that, you know, you can. These these things are not quick requests, restful, that just, you know, execute in milliseconds.
These are very stateful processes that run for a long time, so they can't run in process, right? So this is this is where you start to farm farm out things architecturally to things like workers and task queues. And when you, when you start thinking infrastructurally like that, then you need to think about, Okay, what is a task queue? How do I? Is it a pull based system? is it a push based system? Um, so this is just we're in the realm of how do we?
how do we actually execute this? So that at a certain scale, it keeps working. Um, then obviously you have this, you know, a very simple task queue would be, uh, so, so, imagine you have, you have an API, um, and you just directly from the API, you spin up a worker, uh, that, you know, like a cellular worker. Um, well, you don't wanna be doing that, because what if the worker goes down? Because at scale, the workers can go down for a number of reasons, like network failures, or or maybe the pod didn't exist at that point.
Because somebody was using your underlying compute for for something else. So a very normal one o one architecture is just putting a message queue, a message broker in the middle of that. So you have a bus and the fast API server, which is the entry point, puts events on a bus. And then these events are durably persisted. And then you have you have workers that can spin up and down. Um, and uh, you know, you can do an intensive task like a F agentic loop inside that worker.
From there, you have this problem that, oh, this system is very hard to update. It's it's, uh, you know, you have to ensure things like idempotency, um, and you know you. You need to make that system more observable. So, for for example, if you're, um, processing a file upload and suddenly you have a multi workflow system. Like your task consists of two steps, rather than just one thing. Like, maybe you're calling something at the beginning and then you're doing something else.
So 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 a DAG, uh, like a workflow execution thing, right? And then and then you're like, looking at it, like, Okay, how do I make this DAG orchestration thing work with my harness? And how do I? S Um, how do I make things like in flight updates?
Like, what if I my agent up? Like, what if there's a long running task for 30 days, right? And you know, 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 then the the next person kicks off another 30 day task? Um, but that's a different, you've updated the code, so what happens in the 31st day? Should I use the latest code or should I use the old code that's versioned to that agent system?
And you know what happens in within the 30 days? Uh, the LLM model gets banned by the US. government. I'm I'm gonna keep saying that because I'm in the US. now, so it's it's, uh, so, yeah, I mean, uh. There's a whole plethora of problems that start happening, uh, from the infrastructure perspective, to make things really reliable. And that you don't just write defensive code all the time, like you don't, you don't want your developers to be writing defensive code, you want them on the offense, writing use cases.
yeah. And what about, I guess the a and I? I really liked how you framed this when I was looking through the uh, Kitaru, um, uh pages and and docs. Is like, there there's a lot of questions that you could could be asking, like, what if the tool calls time out? Uh, what if I don't use a a re ranker? can I use a cheaper model for? There? There's a lot of, I guess, developer side questions that that come up.
Um, certainly related to some of those things, like the supply chain thing you mentioned about, you know, a model being all of a sudden identified as a supply chain risk, which I think is a very is a very real one. But there's all these other things, the uh, there's so many possibilities of how you could update your agent harness. It it's very much. Um, I, I mean, I remember just when I would teach workshops and just talking about ML models or L single LLM calls.
I would get pushback saying, like, Well, how do we test these things? Like, rigorously, right? They're non deterministic and they like I, they could return anything. And you know, I, uh, having a background in physics, I, I was like it, it, it's, uh, hey it. We wouldn't know a lot about the universe if we weren't able to test things that were were non deterministic, right? So
I, uh, look, 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 factum that once those things are running, so you have some notion of state, then you have this whole it's a multi bunch of questions.
layered problem. Yeah, yeah, there there is the infrastructure, and there it's like both interact in interesting ways. Like in 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, yeah, I'll give you a good example. I mean, imagine you have a coding factory like this is the buzzword for AI, right now, right? Coding factories. So we're gonna automate software engineering and imagine that, uh, an agent is running in such a system that I described in workers. And suddenly, um, it obviously has to execute code, right? So it needs a sandbox, and this is why the sandbox providers like E2B, Daytona model are so popular nowadays, because you need a sandbox to execute arbitrary code.
So that's another problem suddenly that appeared on the infrastructure side. And now, what? What if the file system that you're editing the code you fail before you can commit the code? Like, how do you? how do you get back to that state? Um, when you know, 20 zero tool calls in cloud 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?
This like, typically when pods die, and 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 like this is not what I wanted? So how can I go back and evaluate to your point, like, how can I go back and evaluate? Hey, could I have done this faster, cheaper, better if I had done an experiment of using GLM, maybe instead of GPT?
Or maybe I? I wanted a different tool call, maybe I should have given it so many tool calls, it got confused, maybe just let's give it two calls and start again. So
yeah, yeah, it's uh. A. 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, 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, this is. 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 on how to do these, these things in this vertical that operate better. Because I'm infusing actual opinions into the harness, right?
yeah, actually, that is the biggest unsolved problem, right? Then, like, I, 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. A adding a word to the system prompt, what would 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. And it's a very stateful application. And try to make an educated guess as to how to update this system in a way that it wouldn't break for all your customers. It's almost impossible, right? Without given the right observability, given the right ability to go back in time and introspect. And, uh, you know, try to run some of these experiments.
I, it's like, you, you need to have some sort of a simulated, uh, I keep saying, the physics word, uh, entropy, it's just uh, simulation. Um, so yeah,
and and and that's some of what you're doing with the Kitaru, right? Which is, uh, this, uh, could you explain? kind of, uh, m, maybe just introduce a little bit of the the idea behind that? And I, I know there's some really interesting things around, uh, replay, for for example. But yeah, uh, would love to hear more about that.
so yeah, um, Kitaru comes from this concept of, um, you know, so it. It still uses ZenML, so Zenml is our open source UM product that's been running in production for enterprises for five years now. So we've 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 answer, try to take opinions on some of the things that we just spoke about.
So Kitaru is is built on top of Zenml, it's a new SDK and a new, 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 as we just talked about in this episode, they do matter a lot at the infrastructure layer. So our our goal is to build an open runtime that allows you to take any harness, any and 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, um, turns out, if you hook into the harnesses. There's certain checkpoints in state that you can snapshot, um, 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 do kick in. Um, so the 1st 1st order of business was, how do we get the best world class adapters for all the popular harnesses like Anthropic Agents SDK, OpenAI Agents SDK?
That you can just drop Kitaru as a runtime in and it gets it from your laptop out to the production. And then when it's once, it's running, it makes it resilient to, uh, tool calls failing in the middle of an agentic loop, uh, by storing that state in an external database or or blob storage. Um, and once we have that state, then we have all sorts of interesting questions like, um, you know, like, like, we already talked about, what if you wanna mock a tool call, or if you wanna change uh, the replay, um, like, replay a different model, uh, 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 a multi turn situation, then what ends up happening is that you never really know. Um, that the model that the agent would have ever gotten to that point if you had started with a different model anyway. So it's it's anyway a broken experiment. And also the problem is that when you replay from the middle, um, you have certain like, if you swap out GLM with Cloud Code.
Like, the the harness differences also make it just hard to just start again from that point anyway. So so there's a lot of code that we have to write in order to make that experiment somewhat, you know, feasible. And again, it's not perfect, and we're still working with our customers to 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.
I should have just swapped out some of the tool calls, uh, and made it a bit easier, and I would have gotten a better and cheaper result. Um, in, um, in place of that,
Yeah, do you do you view this as, um, what's the way to put this? So, like, I think of, you know, taking it out of the AI agent world and into, like, manufacturing, you have like a pipeline, uh, in in your manufacturing, or uh, uh, a line in your manufacturing plant. There's always gonna 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, that way you could also approach this and look at, well, there's all these things happening, right? A And it's really, yeah, it there. 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 into what's happening. But then comes the next question of, well, uh, now, now, what, right? Like, what are, what are the best? And maybe it's a a part of, like, we don't know the best practices around addressing some of these things yet. But
yeah, yeah, I mean, exactly like, exactly how I have imagined it as well. It's like playing a game of whack a mole and trying to sort things out. So when when you fix one thing, another thing breaks. I I think the 1st order of business, as I said, 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 gotta get agents doing that right. So I 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 a cheaper, better, faster model agent at the end of the day. So we have the production executions, the traces, and the 1st thing I ask people to do when they're using Kitaru.
I'm like, run it for a week and then after a week, just filter for the most expensive traces. Um, which were successful, voted by your customers. Go through the checkpoints and see the bottlenecks, just like you said, um, and figure out the common failure modes, and and then, you know, go from there. But obviously, my goal is not that humans do this. Our, you know, we. We shipped an MCP CLI day one of Kitaru because we know that eventually that problem needs to be solved by other agents.
That sort of, uh, are embedded in that loop. So my ultimate goal is you. Ha, have every time you launch an agent, you have a companion. Um, like a, like a companion, a nurse agent. trainer, or, yeah, Yeah,
well, it's a loaded term, but yeah,
I mean, I mean, something like a trainer. That's, you know, that's constantly looking at, Okay, what? What is this guy doing wrong? And then running experiments in the back, replaying things and constantly editing that thing. I mean, we're very far. I mean, to be clear, this is a, this is a distro. This is a dream. Because then, you know, your agent builders can start from a really state and get to a very efficient state very quickly.
Um, but I think we need more tooling and infrastructure to make that possible, because that is eventually the future.
yeah, and 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, may maybe on on both sides of this. Like, what's one area where you're really encouraged? And you know it, it, it excites you of, like, hey, things are going in this direction. And I, I'm really happy about that. And this is maybe what we could expect.
And then maybe something like you said, oh, if if we could solve this, if we could move this big rock like that would open up a lot of, a lot of opportunities, any, any thoughts?
So I, I'll start with the the thing I'm, um, less optimistic about for now as an industry. Because, and you know, I'm, you catch me at a very opportune time, right after this. I'm gonna go to the AI conference, right? So I'm gonna be at the World's Fair and walking 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 were in ML Ops in 2021.
When chip, you and, uh, like, maybe we can drop that article in the in the show notes. It's a very good, it's, it's, it's a very good.
it's great.
Um, yeah, yeah, like when we had an explosion of tools, when we had these ML Ops problems and investor money came in. And then, you know, it was just extremely confusing to figure out the modern ML Ops stack, or on top of the modern data stack. And I think that this is why, I mean, we're sort of contributing to that noise, right, by being 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 for other vendors to, you know, be interoperable. Although there are some good signs sometimes, but you know, it's just they're pushed into the harness, and when you're pushed into the harness, you want everything running on your infra. And I I think there this is, this is, this is a slight negative economical impact.
But on the other side, okay, here here are things where I'm, where I'm, uh, very optimistic. We have amazing open efforts with open source models. Um, take min, like Minimax, or or like, take the Gemini models, or or take something like GLM coming out of, um, like China right now, but hopefully also, uh, the US. and and Europe. Um, with Mistral, that that have made it, uh, very economically viable to start, exper, like, start ex i i like it.
The the enterprises have started to really take it seriously to replace that, the 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 and start playing around with and fiddling with the other pieces, like the harness and the durable runtime. And I'm very encouraged by by the fact that we have now performing models that are just.
This is like two weeks old, right? The GLM is as basically 95 of Opus 4.8, which is just phenomenal. Like we, 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 Pi or a thing like, uh, open code or something like that, um, or even specific harnesses for law or for science or something, will probably explode in 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, um, uh, regress down to the cost of electricity and the models become commoditized. And and and this is, I'm extremely, extremely encouraged by by the recent progresses around that.
Yeah, that's, that's, I think, a great perspective, and I think it encourages people also that are listening to the show. Please check out these, these open, uh projects around, uh, open harnesses, uh. A lot of them are even linked in, uh, uh, the ZenML website and and integrations that they have. I encourage you to check out the ZenML website, you know, try some things in in your own environment. It's it's never been easier to to spin up some of your your own tools and and infrastructure, and and try things and would encourage that.
You'll, you'll find some links in the show notes. Uh, thank you so much for joining us, Hamza. 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 Bluesky. 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 Cylinder for the beats and to you for listening.
That's all for now, but you'll hear from us again next week.