Ergonomics, reliability, durability

Welcome to the Bug Bash Podcast, where we talk about all things software correctness and reliability. I'm your host, David Nguyen. Integrating non-deterministic and non-durable elements like AI agents into our workflows tends to lead to a lot of do-overs. But restarting AI processes can be costly, burning through tokens and losing valuable progress. Wouldn't it be easier if there was always a clear checkpoint to restart a task from? Today I talk with Chen Li. co-founder of the Dboss Durable Execution Engine, about reliability, ergonomics, and actually understanding your software. We discuss the long history of checkpointing, mental models, and how using durable execution allows systems to resume right where they left off after a crash. It makes your software resilient by default. Stay tuned to learn how this architectural pattern can impact an AI-assisted or any other complex system that could use a little improvement in how developers work with it. Ken, thank you so much for joining the show. Tell us a little bit about yourself. Thanks, David and DW for inviting me. So I'm Chen Li, the co-founder of Dboss. Dboss means doable backends, observable and simple. Before that, I was a PhD student at Stanford where I work on the real DbOS project where we're trying to build an operating system on top of database. But as soon as we graduated, we co-founded the company and then we decided we want to work on application reliability and how to use database to make it really easy for applications to become reliable by default. What kicked off your interest in that? Academia is obviously driven by a lot of people's different interests. It started on the operating system side. It's drifted into focusing more on durable execution. Why there? Yeah, so that's actually a really good question. Until today, I'm still correcting people that DbOS is not an operating system. So why do we switch? Well, it's actually not a switch. So if you think about it, an application framework or application runtime is really a meta operating system. where you process your code, you run your code. So why we are no longer working on the traditional form of operating system is that nobody's going to switch their operating system, but they are always building new things like building new applications. They are always building, especially with today's AI, they're generating tons of code. You can generate thousands of lines of code within an hour or so. So like people are constantly building applications and in order to make applications reliable, we think it's more valuable to work on the application layer, like to provide a library on top of the database to make applications reliable rather than just reinventing a new operating system and letting everyone to switch their operating system to the new one. I, I definitely have a bad habit of changing my operating system. Not quite as often as I change my socks, but it's. it's not infrequently let's put it that way um you mentioned as we talk about ai having an impact on where we're thinking about this in terms of durable execution i've heard a lot of different thoughts about where llms and coding uh augmented coding approaches are taking us how do you see that playing out in the durable execution space because i can't get it to tell me the same thing twice ever durably or not Yeah, I guess in terms of AI world, we're seeing a lot of use cases where people are using AI, integrating AI to make decisions and using their agentic workflows to actually managing their critical data, like their credit cards or their subscriptions, their reservations. One crazy thing I've heard about is that one person was using this AI agent, like AI assistant. And then one day she found that that AI secretly or silently swap out her Xfinity subscription with AT&T because the AI decided that, okay, there's a better deal with AT&T. So the AI called the customer service of Xfinity to cancel the subscription and then contact AT&T to make a new subscription. So I'm saying that, yes, people are trusting AI. or maybe more than they should, but AI is managing a lot of critical piece of data. And so the thing is how to make that traceable, observable and reliable is becoming more and more important. Yeah, because if you're going to call to cancel your Xfinity subscription, you got to hang up and recall at least twice in order to make it work, right? Yeah. And also like if someone says, oh, what happened to my subscription? Who canceled it? You want it to be traceable and say like, every part of your execution should leave a trace behind so that for auditing, you know, for debugging, all sorts of things. Okay. Okay. So you mean the actual, you mean not the jokey parts, you mean actually being able to rewind time and to play things back forward in a way that would make sense? Sometimes you can't always play backward, but it I think we should make it easy, for example, to provide a full log of what happened and then provide a path for people to recover saying like, okay, now I screw up my subscription, I should probably write some code to roll back or what we call compensating path to roll back what happened before. So yeah, and I think if you look at those AI frameworks, they are all adding durable execution. So like, it's like a trendy word recently. Yeah, well, how would you explain it for those that are unfamiliar with the subject? How would you explain it? Oh, so to explain durable execution, I would usually like, I usually like to say it's like a video game. So you all play video games. When you play the video games, you want to auto save. in the middle, you want to have checkpoints or autosave as you play the game so that if you go for a launch or if you accidentally push a shutdown button for your computer, when you come back, you don't want to play from the beginning. You want to load from the save point. so that you don't lose your progress of what you've done. So I'd say durable execution is like that. It automatically checkpoints your program's execution so that if something happens, if there's a bug or if your process crashes because someone accidentally pulled a plug of your computer, then you don't lose your progress. Once you reboot, you can just say, hey, here is what I've done and I'm going to continue from my last checkpoint. Gotcha. Yeah, we've experienced the same thing at Antithesis when we are testing out different types of Nintendo games, which is a way that we like to flex different aspects of the fuzzer. And a key component of the platform is making sure that we can checkpoint at different points in time, different points in time, several points in time, all the time. The best way to move forward with a random exploration or a guided exploration of the state space is definitely to make sure you can always rewind a little bit and then try again, just because you never know what you're going to find. Awesome. So how you guys use a database in order to make this work, right? So why choose a database? You know, there's other implementation routes that you can take. What is helpful to developers in terms of how the interaction model works for choosing a database to try and make durable execution a thing? Yeah. Actually, the fun thing is every doable execution implementation uses a database somewhere. But in the DBOS case, we just reduce the number of layers you have to worry about. I can give you a little bit background of all sorts of different models of doable execution. Sure. Well, one typical model, what we call is external orchestration. It's a very popular model. It's used by say AWS Step Functions and Azure Doable Functions, where you have a database somewhere, but users or applications don't directly talk to a database. Whenever an application receives a request, it will say, I want to kick up this workflow. The application is not going to execute that workflow. It's going to shovel the workflow to an external service called workflow service, for example, AWS Step Functions. Then that workflow service will figure out which step to execute next. Then when it needs to execute a step, it will talk to another worker, say, AWS Lambda or another set of serverless workers or your long-running worker, say, please execute this task. Then it will send the task through a queue or RPC. Then the worker will receive the signal and say, I'm going to execute it. Then after execution, it will send back to the workflow service and say, I'm done. The workflow service will checkpoint to the database. Then after it's checkpointed, it makes sure the data is durable. It will just check, what is the next step and so on and so forth talk back and forth with a worker and finally after workflow finish it will get back to your application server said okay my workflow is done okay that's the external configuration yes this is our external configuration and you can see that there are a lot of like round trips and talking to your app server talking to your worker server talking to your database so like there are a lot of like moving parts in this model And I guess why, I guess I know why it happened because the model came up around 2015 or so, like where everyone was so crazy about microservices and everything has to be distributed in order to be like, I don't know, isolated, reliable, stuff like that. But now, like recent years, people are actually moving from this microservice world back to like monolith, but not like a traditional monolith. but people call it micromonolith. I think that's where DBOS comes in. I can talk a bit about a DBOS model. In DBOS, we also have a database, but we just remove the actual layers, the actual communication overhead between your workers and your servers and the database. Essentially, we implement durable workflows and queues all in the library that you can embed. in your application so that in your application, when you need to execute a workflow, it would just be a normal function call. Then the library would just say, the workflow has started, I'll checkpoint the inputs to the database. Then when it hits a step, it would just be another normal function call. Then the library will again wrap around the step function and then checkpoint the step outputs to the database. Then so on and so forth and after the workflow finishes, you just return normally from a normal function call, and then DevOps will also checkpoint the workflow status and execution results to a database. You can see that after all, it's equivalent to external orchestration, but it gives you much better performance because it reduces. overhead of communicating with external services, but also gives you flexibility because yes, you can make things distributed if you need by going through the database. If I want to execute a task on another service, I can by just writing a record in the database and then the other server will pick up the work to do so. I think the philosophy here is that don't add unnecessary overhead unless you mean to do so. All right, you're gonna have to expand on that for me because I was taught that all problems in computer science can be solved with an additional layer of indirection. And, and I just heard you say, don't overcomplicate things, because we've already given you a list of cues, circuit breakers, retries in a database layer that you can just go boop and is right in there. So you don't worry about it. Talk, talk to me about how the ergonomics of that because it feels like I might be it's not as bad as like, importing like left pad, let's say, but it's it feels like I might be signing up for a lot there. How does that play out from an ergonomic perspective of when I am writing the program? What am I thinking about in terms of who boy straight into async and everything all the fun stuff that comes with it? Yeah, so I think, yeah, it's fun to talk about ergonomics. Because I've been thinking about that a lot these days. And I'm thinking I see you're sitting on the ergonomic chair, right? Oh, you noticed. How nice. Yeah. So I think like dual execution essentially will give you, provide you a similar set of functionalities. And you can argue that they are all similar. But I think from my point of view, I really hope developers will feel refreshed and happy after using dual execution tool. Not like, I mean, if I give you a. very uncomfortable chair you can still sit on it it will give you the same functionality but you will feel tired or like uncomfortable after sitting on it for a while so what i'm thinking about ergonomics is that like yes you can use any tool to implement anything but some tools will give you headache you have to tweak your head around and think and learn how it works and study like um some of them have very like a steep learning curve. So you have to kind of torture your brain to figure out what things are actually, how to actually use the tool instead of doing your day job of making your application work. And then I think for an ergonomic design, people would just say, okay, it feels pretty natural. When I call a function, it is a function. When I want to send a message to a remote service, it is a remote service. It's like, it fits the expectation of how people normally process how things should work. Yeah. Gotcha. So, all right, so this brings it kind of feels to me like cognitive load sort of stuff, right? Like, yes, there is a domain in the problem that we are trying to focus on and trying to model appropriately in such a way that we can apply the computational resources at our disposal in order to fix it. And that the goal of a durable execution engine like DBOSS is to make sure that we can abstract away some of the parts that are non domain specific, but are often very useful to have. Yep. How do you decide what goes into D boss and what goes out? I mean, going back again to we decided that we didn't need to reimplement Linux again, because Linus is fine. But we we think that this why these things that we we hung on to in order to make programming a little bit more nice. Yeah. I think it really depends on what people really need. We build our system and we also listen to developers and hear their main pain points. For example, for doable workflows, we build this this way that when we talk to people, especially from enterprises or finance companies, they are already doing that. But it is that without DevOps, they have to manually checkpoint. Like every single part of their service, for example, when they transfer money, they have to write down, okay, I've done this step. So next time when you invoke me again with this specific key, I'm not going to repeat the work. So I'm not, so people are already doing that. You mean like with a database backup or with a database actually? So like it's that people are already doing that, but in a more of like ad hoc way. they were actually complaining about every time they build a new application, they have to rethink how to make things durable and how to checkpoint things properly, how to trace things, trace the execution. We think, well, that's actually a good point. Why don't we provide a general purpose library to solve that problem? Instead of manually writing to the database, figuring out what is the schema in the database, what worked best for my application. They can just say, here's a library, it's a mature solution, I can use it, and then I don't need to worry about all sorts of stuff. That's the workflow part. Another part is actually doable queues. People are using queue services a lot, like RabbitMQ, BullMQ, Amazon SQS, Salary, stuff like that. But the problem is that most of the time you just fire and forget. You put things to the queue and then there's no proper ways to track what is going on, like what task has failed. And if a task has multiple steps, then how am I going to make sure that if one step fails, I don't need to repeat all the previous. all previous work how can i continue from where i left off stuff like that and we actually we add a queue because we've heard a lot of people complaining about their experience using the queues and then when people come like when developers complain about something repeatedly then you know that that's something we should support and that's something that's a feature we must have we must include in the library which is probably a strength of the open approach right yes yeah so that's why like all of our um libraries are open source and people can see it and yeah well what surprised you as you have listened to feedback from developers as you guys have been implementing the engine what's something that was a maybe the project took a turn that you did not expect if i had asked you x number of years ago and then x minus one you were like oh yeah we definitely clearly a queue was added later or what have you Yeah, I think in terms of there are two parts. One is about the use case and the other part is mostly about like developer education. So for the use case, I mean, I guess it's a surprise, but it's not really a surprise that we're seeing a lot of AI use cases. When I first developed Dboss, we were thinking. oh, we should talk to banks, we should talk to those people who are managing re-transactional data. So initially we call ourselves transactional serverless or something like that because we thought only those people should care about durable execution. And then we really focused on that. But then people just came in saying, hey, I want to write an AI scraper. I want to scrape the web. And I don't want to scrape things again if something goes out of memory. I want to have checkpoints for those data pipelines. And I think, okay, that sounds like interesting use case. And then recently people came in and say like, I want to build AI agents and I want my agents to be reliable. And another thing is that reliability comes with cost savings. That's something I was, that was kind of unexpected because people are saying, oh, you know, each LLM call will burn several tokens. sometimes thousands of tokens, and they can be expensive. And if I'm in a long loop, like a long agent loop, if something crashes, I don't want to burn all those tokens again. Instead, they want to have some checkpoint or some memory, source of memory for their program so that they can continue from the last checkpoint instead of calling all the LLMs and burning all the money again. And that's kind of... interesting perspective like reliability means money for yeah it's cost saving yeah well well as i talk to different development teams like one of the things that's striking is how teams are using context management more and more intensely as as means of cost saving as means of also solving the problem as acutely as possible right because if yes we could take the perhaps at this point in time the big data approach is something that a lot of us feel very intuitively it's like wow we'll throw the whole thing in it and it'll do the whole thing and if you threw a whole small code base at me a human i would eventually get it but not very fast and not necessarily very well uh and it seems that llms suffer from a similar sort of problem so what i hear you describing and correct me if i'm wrong is the nature of I would even expand it beyond durable execution because it's really more about a checkpointed history of what the execution is allows AI agent developers to selectively bring in the right context. Retry is obviously in the case of failure, a very important thing, but also my mind immediately goes to different explorations in terms of we can roll back and retry a couple of things. with different temperatures or with slightly different system prompts or what have you, where we can pull it forward again. Is that sort of the idea? Yeah, actually, that came up a lot. I think people like to call it like branching or forking. So basically, you have one execution tree, but at some point, you want to explore different paths. But instead of exploring from the beginning, because it's really hard to control where the LLMs will go, you want to fork it in the middle. for bug fixes or like just want to explore different paths. I think that's something, yeah, that's kind of unexpected too. Like that's, I think that's a fun of like building a project or building a system. You will never know how people will use it. That's true. All we're doing is implementing general services for storing data and executing Turing complete languages. How, what could possibly be surprising about this, right? Yeah. Is there... Have you not supported Java yet because you're worried that someone's going to come up with a workflow, workflow service, service factory, and that just feels like too much? Actually, we are actively developing the Java support. It's taking a bit longer because Java is kind of heavyweight, and in general, it's like older language where there are a lot of... legacy things in that, like, we have to decide what to support, like which language, which version we want to support, which kind of frameworks like Spring Boot we want to support. So it's coming up actually next month. Yeah, it's taken slightly longer. But we're getting there. I mean, it's 3 billion devices. It's a lot of devices to support. You got to be careful, right? Yeah. But I also mean, that's good opportunity because there are a lot of Java applications there. So Talk to me a little bit about what you think the implications are with improving the ergonomics of some of these more difficult things and abstracting that into a library rather than having that be re-implemented in every application. Because you hear this perhaps for some of your more esoteric programming languages. that where the framing of the language will help you or the rules of the language or the borrow checker or whatever it may be is definitely going to make you better because of X, Y, or Z, right? And it puts your mind in the right space and everything else. Do you think that improving the ergonomics through this layer of abstraction helps? reliability helps correctness? Like what impact on the program do you think it has as people think about modeling their domain? Yeah, that's a really good question. So I think better economics means better reliability for several reasons. So first, if it's economic, it's actually fits what people are thinking. So naturally, people will make fewer mistakes. And of course, people will definitely make mistakes. That's why we have emphasis to help them find bugs. But even with emphasis, bugs will still happen. So once they write their code, bugs will happen. They need a way to quickly figure out what's going on. They need a way to quickly troubleshoot what's going on. And I think ergonomics played a huge role here because if you get an on-call message 3 a.m. in the morning, you wake up and you feel grumpy. And you don't want to log into five or six different services, and here's a message queue, here's my configuration file, here's my workflow service, and here I distribute logs spreading across everywhere. You really want a clear error message, a clear observability platform, a clear understanding of what's going on. So I think economics meaning you can quickly figure out what's wrong. And you can quickly roll back and recover from your failures. And I think maybe people can say that with LLMs, with AI, a lot of things can be automated. But based on our experience, the more ergonomics, meaning the easier to understand, the easier to describe to those LLMs, and the easier for those AIs to follow the rules and then fix things. Yeah. Never mind that having a checkpointed history. I don't think there's there's a command that I run more often when I'm working on a project, augmented vibe, however you want to describe it, then maybe get reset, because it's like, No, that didn't do it. redo it, start over again. And try it again with maybe, maybe an extra doc that it's like, Okay, so we tried this this one time, definitely don't do that again, and then try and dial this in a different way. For sure. Let's see. Git is a great example. It's like dual execution, but you do it manually. When you git commit, you can save points, everything I've done. Then if you change your mind, you can always branch out. You can create a branch based on the prefix of this history, and then I will explore some alternative implementation. Then if I decide, I should go back to original, you can always jump back. That's a benefit of recording everything happened. Fraser Cain- Git also famously does not use a database. Well, it uses the disk, and you can think of it as a abstract database somewhere. Fraser Cain- Well, I mean, if you want to get really technical, all databases is just some level of files on the disk. Now, what is the database? Yeah, I mean, that's fair. That's fair. But I think in for Git, you can still manage it manually. But like, in terms of execution, sometimes we see like a workflow with hundreds of steps. And sometimes a lot of branches are dynamically created based on the LLM responses. So that's why I like agents are really, really difficult to manage manually. And that's why people are looking for more of like automated solution. And like more of more and more AI frameworks are looking to doable execution. All right. So Chen, tell me a little bit about how we got here in terms of durable execution. We talked a little bit about AI agents and some of the things that people are doing on the bleeding edge. Even just a few years ago, that obviously wasn't on the table. So how did we get here exactly? Yep. So I mean, this is a really long history and I mean it. So the other day I was reading online and I saw someone posted the first recorded transaction in the world was from 3100 BC, like 5,000 years ago. it was some records written on a clay tablet. So basically people have been doing this for thousands of years. They record what they've done, what they've sold, right? On the paper, on clay tablets whatsoever. And then when people have computers, then we have databases and the main job of databases is to like record. what changes and what is the state of like people, credit cards, stuff like that. And I guess back in like 80s and 90s, like most applications are like single monolith. So they can just rely on the single database and checkpoints. Okay, whatever we need to the database and everything can be done kind of within that single monolith. It was a simpler time. Yep, that was a simpler time. And then like... people started having distributed systems and sometimes when you need to transfer money, you can't always implement everything in your own service. You start talking to other services, you start breaking up into smaller services. People develop distributed transaction protocols like XA and others. But there are still like between databases, I'd say it's also difficult to implement. So that period of time was like around maybe 2000. And then came in microservices. And for microservices, people are just saying, okay, each microservice will manage their own database. They don't even have to be the same database. And sometimes the microservice will talk to third-party service, stuff like that. So they need to figure out a way to, how do we support transactions? Essentially, people want to support transactions, especially if they want atomicity and durability. They want to make sure if there are sequence of tasks, sequence of updates, if all updates go through, they'll all go through. If there's some failure in the middle, they want everything to roll back. Then if the transaction goes through, they want it to be durable so that the next time when you invoke the same transaction, it will not be duplicated. So that's the main goal of that. So in the distributed setting, people figure that they can't really enforce a single protocol across all sorts of services because it's not realistic to do that. So actually, SAGAPatter was proposed back in 1987. It was a paper called SAGAS, but it was more popular in the in the age of microservices, where a saga means you define your forward transactions, like I want to update record A, B, C. But if something happens, like something crashes in the middle, you want to do compensating transaction in the reverse order. You're like, okay, I've updated B, but maybe C crashes, so I have to undo B and then undo A. And then that's a good abstraction to to handle distributed transactions in the microservices world. Then I think things are getting more and more dynamic and a lot of applications are basically API wrappers talking to other services. Around 2015, 2017, Uber open-sourced their internal implementation called Cadence Service and Cadence later became temporal where they first actually used the word. do about execution. And I think I really thank them for doing developer education for the word, do about execution. So that's how do about execution started to become popular and to become like something people think about when they build application. And now like, I think I guess why they, I get why they designed that way because like everything was so distributed, everything like people were crazy about microservices. You saw some memes, like meme videos online where they said, I need to call this function, but wait, I'm not going to call this function. I'm going to wrap it into a microservice and call it to remote procedure call through RPCs or HTTP. I think around that area, a lot of microservices or dual execution engine came out of that in that flavor. That's what we introduced earlier called external orchestration. Recently, we're seeing a lot more people saying, actually monolithic architecture is good. So they're moving back in some sense. And then people are trying to say, okay, maybe we don't need to add too many microservices. Maybe we should consolidate them into smaller chunks and manageable. And then that comes to Dboss. We think we should not make things distributed or asynchronous by default. We should be natural about this is just a function call, this is just your normal definition of your app. And then if you need dual execution, if you need dual queues, if you need distributed task or parallel task, then you will explicitly send it over to some other services. Yeah, so that's a short history of what I understand. That's good. That's a good recap. It makes me wonder, so as we think about the way this is evolved sort of at the application layer, are there other areas that we might want to apply some of these lessons to? Assuming that we've always gotten better. Trendy and popular is not always better, of course. But assuming that we've gently arced history in a way that's a bit better for at least the development process or are... our sanity, perhaps. Are there other lessons that we can take from these patterns that we might want to apply to somewhere like infrastructure or some of our overloading the term workflow is always tough for me, but I'm thinking more like the DevOps process or something along those lines. Yeah, I think one big lesson I've learned is that kind of kind of I observe is that workflow as code or infrastructure as code is really important. I think back in the day, actually, there were a lot of like to workflow engine, but they require you to write the YAML file or JSON file to define steps. Oh, I remember those JSON files. They were so bad. Oh, yeah. So like, for example, when we talked to a developer, they were using step functions. And I mean, it's a great service and don't want to bash. them too hard, but it is like they do require you to either drag and draw on their web UI or you write kind of their domain specific language or you write JSON definition. So the developer came to us and complained that they couldn't really do code review on 3000 lines of change for the JSON file. And it's impossible to test too. So I think those are the main issues with like domain specific or local no code platform. It's almost impossible to do version control, it's impossible to do unit testing or integration tests. It's painful. I think it's actually true for dual execution engines too. More and more engines are moving towards workflow as code. Dboss, for example, you just write your code and then it's normal function, you decorate, hey, this is the workflow, here's one step within the workflow. Instead of saying, I'm going to write a YAML file, the workflow definition will be like, it's no longer the case. I think the lesson people have learned is that developers like writing code. Nowadays with AI, they're not going to parse your web UI with this drag and draw boxes, but AI is really good at coding. I think that's a big lesson we've learned. And then in terms of other areas, I've seen this trend too. For example, many new frameworks or new tools are allowing you to directly define your resource requirements in your code instead of having a separate YAML file to define resources. Like some new projects like, you know, model or bar plan, they would just say, write normal Python function, then decorate your function with, I want to run this on like four CPUs, 100 gigs of memory, stuff like that. And then the framework will automatically provision resources based on specification in code. And by co-locating your specification with your actual function definition, I can get them. it makes it really clear for development and for debugging purposes. That feels like that would get really cluttered to me. Is that just a bad intuition on my part? When I'm thinking things through at the application layer, I'm often not thinking about how things should be deployed. And that feels like two halves of my brain. Do I need to get good or is there something there that I... that I need to reconcile. Right. I think recently we've seen that a lot of, it's like, I think development and deployment cannot be separated because, for example, for developers, you know your code is going to consume, for example, like one gig of memory. Then if you don't get a hint, your deployment can easily fail and say, like, I run out of memory. So I think in this case, especially with AI and others, you want to consolidate all your knowledge in one place, so it will be easy to deploy and maintain. Otherwise, if something crashes, you have to figure out, is this a bug in the code, or is it because I didn't allocate my memory or disk enough? And if that's the case, I have to jump to another file, and maybe that file is not enough, I have to jump and not. into like multiple layers of logs and configuration stuff like that too. So I think like infrastructure as code, workflow as code, blah, blah, blah, code is the future and it's the lesson we've learned. All right. Well, it's been a fascinating discussion. Chan, is there anything else that you would like to impart to the audience before we call it a day? I would say thanks a lot for having me in the podcast. And we're definitely looking for more feedback for Dbos. So if you're interested in learning more about Dbos, please visit our website. It's dbos.dev. Happy to take questions and feel free to reach out to me on LinkedIn, social media. Awesome. Well, thank you so much for the conversation today. And to everyone listening, have a good day. Thanks for checking out the Bug Bash podcast. If you want to reach out, maybe with an idea for the show, or maybe you want to be on it, send us an email at bugbash at antithesis.com. Or if chat's more your style, head over to antithesis.com and scroll to the bottom where you'll find the link to our Discord. Until next time.

Integrating non-deterministic, non-durable elements like AI agents into our workflows tends to lead to a lot of do-overs. But restarting AI processes can be costly, burning through tokens and losing valuable progress. Wouldn’t it be easier if there was always a clear checkpoint to restart a task from? 

Today I talk with Qian Li, co-founder of the DBOS durable execution engine, about reliability, ergonomics, and actually understanding your software. We discuss the long history of checkpointing, mental models, and how using durable execution allows systems to resume right where they left off after a crash. It makes your software resilient by default.

Learn how this architectural pattern can impact an AI-assisted or any complex system that could use a little improvement in how developers work with it.


http://antithesis.com/