Syntax · Transcript · · Updated
You need to check out Pi Durable – Transcript
Video by Syntax · Watch the original on YouTube
Summary
AI-generated from the transcript. Verify details against the source video.
- Pi durable is a library from the same team as Pi for building your own durable agents by saving everything into storage as it goes.
- Pi durable can run anywhere JavaScript runs, such as entirely in the browser using indexed DB, on Node.js using SQLite, or in a durable object.
- Using durable agents allows work to pick up where it was after a process dies or crashes without repeating steps like sending a double email or pull request.
Use this video with Pro
Reading, copying and transcript downloads are free. Create saved AI results for this video with a signed-in Pro account ($9/month).
Transcript
Search ignores accents. All transcript text stays visible.
This is an agent that fixes software when I sleep. This is an agent that runs entirely in the browser using index DB and JavaScript with no server. This is an agent that runs directly on an Android phone. This is an agent that starts work on real life to-dos without me even asking using SQLite and Node.js. This is an agent running 100% on a cheap photo
frame. This is all possible because of something called PI durable. So, buckle up because if you're building agents of any kind, you're going to want to see this. So, let's think about how we use an agent today, right? You start it, you watch it, maybe it stalls, maybe you notice, maybe you you you've stopped the process. You got to come back in.
You're going to say, "Oh, keep going. You can do it." I've heard that you're not supposed to be mean to Claude anymore. So, I gave it some positive reinforcement. And that all works because, hey, we're sitting here, we're typing, we're going back and forth, and you know, maybe you get distracted, come back, and you notice that it died, and then you you get it going again. And these types of tasks, right, this is super common and not really a big deal at all, but agents are running longer and longer than ever these days. And not
only that, they're doing more, right? Maybe they're submitting a poll request or researching. Maybe they got to go check your bank account information to share it to a company Slack. And what about even like starting and stopping these agents, right? A lot of times if you're building agents and apps, they need to be long running and they need to exist and work even after they crash. Another thing that agents are doing more of these days is starting by themselves. Whether that's being initiated through some sort of uh action or automation or trigger or
something, the agent then gets to work producing several steps. People do this all the time with automations inside of like clawed code or anything like that or cron jobs or maybe it's triggered via web hook or something. And in that scenario, right, like a web hook hits an agent, it starts to do some work, it crashes, it fails. Uh how does it pick that work back up, right? You got to go back in there and check to see, ooh, did anything break overnight when this web
hook hit? So, if an agent is going to run for an hour, start on its own, and do things that can't happen twice, it needs to be durable, right? It needs to continue working. It needs to be resumable. It needs to know exactly what step it was on so that way it doesn't repeat steps, right? It doesn't like what if your agent is sending an email and then you start the whole process again. It sends a double email, sends a double pull request, who knows what, right? And this is really where durable agent shine. If you've ever written an
agent before, maybe you put it into an app, a support bot, an assistant, like a Slackbot, internal tool. I feel like I've written all of these at some point. Most of the time you've written kind of the same code, right? So you you have a table to save messages, maybe a cue for work to get done. You got a socket that streams to the UI. Uh something that for like if the user prompts in the middle, right? So, you need to be able to steer. Maybe fork a
conversation. Maybe wait for a pause for approval and then pick it back up again. Retries and repeats for things that should be retrieded and repeated or not if they're not. Summaries of old messages and those types of things and and keeping app state in sync with what your agents actually did. And when you do this, failures can be really super annoying to debug, right? There's a lot of stop and start. At least there was for me. So, a month ago when I showed you my prompt device that I had running
on my computer that was all built on a custom agent and honestly it was a pain. It took a long time and it was super brittle. So, when a library called Pi Durable was released, I made the jump and was able to delete about 8,000 lines of custom code and I basically got a better system for free. Look, I'm talking a much better system for free.
>> Trust me, she'll like it too. So, let's talk Pi durable. If you haven't heard of Pi, Pi is an awesome extendable agent harness from Arendelle. It powers things like OpenClaw and a ton of other developers agentic coding setups, mine included. I've been using Pi for a long time. I have a both minimal and a custom setup. I like tweaking it. I like not tweaking it. I like just using Pi. It's really great project. And so, it should
come as no surprise that Pi durable is also really cool. And pi durable is a library from the same team for building your own durable agents. That could be a coding agent, you know, a support bot, Slackbot, whatever, right? So the way it works is pretty simple. Pi durable saves everything into storage.
It's basically as it goes, what was said, the tool call, what it's waiting on, those types of things. And if if the process dies, right, a new one opens up the file and keeps going. So anything I connect to it like my phone, my browser, my Slack, they're all looking at the exact same agent. And on top of that, every tool says whether it's safe to run again. So like after a crash, right, you could think of like a search.
A search makes sense to rerun because maybe it wants to get fresh data on that search, right? Where if an agent is sending an email, like you don't want that whole process to get started again and send another email, right? So it it's pretty much this. It's a database file, a conversation. You submit it with an ID and your tools are just plain functions. Super simple, right? And and many people might be looking at this and saying like I mean I got a chat history.
I open up my agent. Maybe I just go to resume and it brings up my chat and then I just start prompting. And sometimes this is just totally fine, right? Especially in coding. But uh it's more than just like the text context and the test history going in with your prompt. It's like a whole list of every tool call, every tool call it was about to make, approval that it's waiting on, whether or not the deploy already happened, etc., et like all of the things that it did or didn't do are in that storage, right? So, when you come
back to a PI durable conversation, the work just picks up where it was, or maybe it resumed and it already finished while you were gone, right? I I think that's like the dream here. And I I'll show you a little bit about what I mean there, but like sometimes you want things to just work and if it fails, pick it up when it works. So you could reach for like a a workflow engine too, but like workflow engines are typically very kind of controlled steps, right? Where this is more of like the agent deciding what it's going to do next and what tool calls are available
for it, right? So this is using the agent's strength rather than some kind of like rigid workflow. Maybe that's versioned very specifically to the code that it's working on. So because it's all set up this way, you get a bunch of awesome stuff for free. One, every single time you build a screen for this thing, it's just a client, right? It could be your phone, it could be a terminal, could be your computer. Any way you interact with a durable agent, uh you can get in the middle of that process. You can steer it. You can
continue to work on the exact same process with all of the exact same history. Two, multiplayer comes for free from this. If people have access to the same agent, well, then they can actually work together on an agent, maybe even have multiple users steering the prompt at the same time. And likewise, uh, because you have this, you can change it while it runs, it makes building in steering super easy. It also
makes building in forking or sub agents to your agent flow also super easy. And likewise, just the the saved state of it all, right? Whether it's like waiting for an approval or a timer or any of that kind of stuff, it's the same for everybody using it. So you might be thinking, okay, durable agents, durable objects, they run on durable objects.
This must be a Cloudflare thing, right? Well, it actually runs anywhere that JavaScript runs. In Armen's version, he was running it entirely in browser, storing to indexed DB and running everything just straight up in the browser. On mine, I'm actually running it on a Mac Mini in just straight up node and using SQL light as the DB. But it's also perfectly suited for running in something like a durable object or even celld from the Dino team.
And you could connect it to any type of model you want, whether that's OpenAI or even something local or whatever, right? You can connect it in all kinds of ways. So, if you're building an agent system, you're not locked into one provider's way of doing things, right? Okay. So, now that you understand a little bit about durable agents, what makes them cool. I'm going to show you just a little bit of my self-healing setup. Okay. So, let's see this thing in action so we can walk through it. So, let's say I have a bug in my software, cuz let's face it, you
know, I got bugs, especially in this app, right? Because it's slop. So, I have this app here, and I'm going to hit a bug here. So, when I hit a bug, it's going to come into our Sentry, and this might be delayed uh compared to this just based on the flow of things. What happens is the bug comes into Sentry and then sends a web hook through a Cloudflare tunnel to my setup.
What that then does is then kind of kicks off the process. basically determines whether or not this is a bug or if it is something that it can't fix like uh synthetic worker failure or something like that. So you can see the bug comes in. I'm using uh some analysis here to determine whether or not this is a bug to fix and you can see it's gotten to work on it. If I click through, you can see right now it's determining the root cause of the bug and that's coming
in directly from Sentry's Seer agent. So it's going through and you can actually see what's happening at any given point. And if I want to stop this thing, I can stop it. And then at that point, you can see that the agent has stopped, right? So it's actually finished the root cause analysis. So we have that bit done and it's working on the fix. It even has the fix in here displayed as oh the root cause. The cart total reads item.isount.p% %
unconditionally, but the full price uh items like link cable and checkout cart have no discount. Uh the discount is undefined. Okay, cool. So, we have the root cause here. We have the exact flow of things. The the agent has been stopped. I can resume it and it can just pick up exactly where it was. It's going to get to work on the fix. It's then going to test it, do my normal flow of things, and then it's going to create a PR. An agent fix it, tests it, then creates the pull request. We have the
pull request right here. We can see the fix directly in GitHub. I can come in, I can see exactly this nice PR that has what changed, the checks and everything like that. I can look at this all. It's all running in my own setup.
And then I have the exact commit. You can check to see exactly what it did. Here's a nice little easy fix. All right, perfect. I would say looks good to me. I definitely reviewed all that code. Looks great. And then I can just click merge. Now, now the next part's really neat. It might take a minute or two, but it will close out and mark the issue as resolved and then mark it as resolved in my system. Therefore, giving me an awesome trail of exactly what
happened. And because this is a whole, you know, agent run and I can always just come back to here and message the agent that did the work directly in that exact flow with the exact record of everything that happened. So, I'm not pulling up a new agent with fresh context to be like, "Hey, what happened?
why didn't this work or I don't like this fix or I can even come in here after doing the code review and say hey I don't like this work. You don't have to do this through poll requests either. I have some software that I don't care as much about that will automatically merge PRs. Now this isn't userfacing software as in like this isn't public software. This is software that I work on for myself or my family or whatever.
To put more simply, the errors come into Sentry. We triage them. We then send them to get the root cause analysis from SEIR. Our agent picks up the work and starts to do the fix. Then it tests it, creates a pull request, [snorts] it merges it, and then marks it as resolved in our system as well as in Sentry. And this is just one small demo, right? Uh you can do so much with this. My entire system runs on durable agents. So
clearly in my example here, I did gloss over a lot of stuff like uh some protections I have against knowing if this is real work that it's supposed to do or not, whether or not this is an issue on software that I'm tracking specifically in this setup. There there's a lot here that I'm not talking about, you know, guards for making sure that I only have the same sentry issue for one pull request. That way, uh it's not going to go ahead and create multiple pull requests for the same issue if that issue comes in more than