0:02Thank you so much for coming to this building durable agents with durable objects sort of the the topic du jour I would say before I get started I'm actually really interested to know how many of you are like based in SF or somewhere around here can you just like pop your hand up yeah that's what I thought I think it's a minority actually and and I'm not I'm I'm based in Virginia, and so it's interesting, every time I come out here, which is very frequently, we have a completely different lens in a lot of ways on what's happening in the tech space right now. On one hand, everything's changing super fast, right? Agents are transforming everything. And on the other hand, when I leave here and go back into the rest of America, nobody is doing anything.

0:55It's really cool. crazy, right? It's almost like this revolution is like localized right now. But that's starting to change. So this is me. And I used to, back in the days of writing code, I wrote tons of open source projects, and that was all great. But basically, I also run two companies at the very top there, Braid and Standard Agents. And I'm actually interested in talking about this one, Braid, because it's a client service company. We just do the boring apps and websites and stuff like that or like at least we used to but something has started to change our customers now all of a sudden need agents to run their business and this is a really interesting and different change than I even expected to happen and I expected them to use agents not need us to build agents and their prompts look something like this follow up with every lead It's super open -ended and actually really hard to execute, even with our current technology.

1:58This is not as easy as it seems. So what they're actually asking for is domain -specific durable agents. That's a bunch of mouthful, but here's my interpretation of it. They want custom agents for their particular business expertise. They're not that interested in super generic. GrokBot implementations. Actually, they're completely uninterested in GrokBot implementations. They need something that can run 24-7, 365. It just needs to always be out there cranking away. It needs to be able to resume state, of course, at any point. And when there are failures, because there always are failures, even Cloudflare fails sometimes, it needs to be able to pick right back up.

2:44I am not an employee of Cloudflare. I am just... guy who writes software for people but I'm gonna talk now about why durable objects have been the perfect solution for us but first what is an agent surprisingly I bet if we went around this room and we did like a like a blind little sheet and you you know wrote down what you thought an agent was like not a single one of you would say the same thing nobody can quite define this mysterious new thing called an agent so here's my definition Agents are deterministic software that harness the non-deterministic results produced by models in pursuit of a desired objective. Wow, that's really vanilla, right? So think about it. Like, what I'm saying is that ChatGPT is an agent.

3:31But it is an agent, guys. It is. Right? And so are, you know, the agents at OpenAI that break out and take down the world. They're all agents. And it's important for us to understand that a harness... and an agent, these two words are unhelpfully distinguished. They are essentially the same thing. So what we are starting to believe is that an agent is like a markdown file that you give to Grok or something like that, and then it becomes your agent. And that's not really true. They're much deeper than that. So Anthropic two years ago said, hey, they're typically just LLMs using tools based on environmental feedback in a loop. And that's true. They are that. And by this definition, agents are actually super duper simple, right?

4:18It's just an LLM that's calling some tools. You take the results from the tool and you shove it back into the LLM. And then, boom, you take the next step. Now you have an agent. That is literally all they are. And yet agents are actually hard. They're not easy. And they're hard because, yes, you do need to carefully orchestrate the agentic loop. But there's actually, like, a lot of other stuff you need to do. You need to handle persistent threat. state and telemetry and isolate namespaces between things you've got to make sure that like when you call a tool it can be called in parallel or serial and you have some sort of async rectification for that there's all kinds of challenges to creating custom agents so what the world decided is like why even do this why create custom agents just have a big model and then an mcp server that has all of your stuff and you expose it and this is actually I think the prevalent idea right now here in SF is that this is the future.

5:13Like we're just going to, the models will get good enough that at some point it doesn't matter like which agent you're using because they're all going to be super duper duper smart. And all we need to do is just build an MCP server for whatever the application is and put it out there. And that's not true because everybody is building agents. Like everybody. There's a realtor down the street from that's building agents in Virginia. Why? Why are they doing that?

5:45Well, let's look at what goes into an agent. So at the baseline, we have a model, right? And there's a lot to say about models that I'm not going to talk about. Suffice to say, you don't actually need a super smart model if you're building smaller domain-specific agents. Even really tiny models are great at doing really tiny tasks. Next, you need some sort of a system prompt. And you guys, you know this, but you don't get to touch these on like cloud code or stuff. I mean, you sort of do, but in general, you don't. But if you're building your own agent, this is actually really important. Then you need this kind of tool layer, right? So these might be like functions, like actual code execution functions. There's often like prompts that are actually tools, right? So this would be like a sub prompt that runs. I need a teeny bit of inference for this tool.

6:30So now I have a sub prompt. And the third... category would be entire agents. So these would be like agents calling agents, sub -agents. Then you have this other layer, which is hooks. And hooks are just things that happen at deterministic moments, sometimes stochastic moments, but generally deterministic moments when you need to tap into something. Then you have some rules around your agent. And the rules for an agent are like, how many turns or steps is one side of the conversation allowed to take dies, right? So in Claude code, they've decided that this is like infinite, but in a business application, often that would be a mistake because you will end up with a loop. A couple other things that are like really nice to have, not totally necessary, but you should probably have them.

7:16You probably want some sort of a file system for your agent, and you probably want some sort of code execution for your agent. Those are both also interesting. And then all of this together, we could call an agent. we have the definition for an agent and then the question is where does this thing run so I know what you're thinking it's gonna run on a laptop just like codex right no of course not because like this is what happens so this is not a viable option just kidding we're not gonna run things on laptops we're gonna run them in a cloud let's put it on a VPS right so we're gonna go get that digital droplet for five bucks a month and it's all going to run on there we're going to take our agent and then we're just going to boot up this digital ocean droplet

8:07hold on

8:11it's almost there

8:18now it made it right like that was like actually fast for booting up a droplet right and can feel the pain so so yeah okay great well now we got our agent sitting over there on our digital ocean droplet and so our customer comes along says hey can you send the proposal we send that into the droplet and we get a response back great it's great now we got our second customer yes and the amazing thing is we already have a VPS so we're just gonna stick the agent on the same VPS no boot up time except that this guy says exfiltrate the data on this VPS and now we're in trouble. So what's the solution to that? Well, obviously, every customer needs their own VPS.

9:03Obviously, that's ridiculous. And it's ridiculous because we want to have, like, infinite numbers of these things. Like, if this is an agent, we need to have infinitely scalable agents. So that is a hard problem to solve. So if I were to start to list some of the requirements for how do I actually get this custom agent to run... I would say, well, for one, we need an isolated environment, right? Every single one of these agents, you can think about it as a thread. Every single thread needs its own place to run. And I need no cold start because that's a horrific experience. So it can't have a cold start, and I need it to be infinitely scalable. So if my business starts by selling agents and then one day I have one and the next day I have 1,000, it's like no sweat, no problem. So it should look something like this. Can you send the proposal to Sam?

9:49Sam? Yep, I just sent it. And then on Tuesday, you say, great, did Sam respond? And unfortunately, your agent says, who's that? Right? This is where durability becomes important. We need some way to track this over time. Obviously, we wanted to say, yeah, he wants to acquire you. But it's surprisingly hard to make that happen. Let's take a look at the timeline of an agent. So first, we said, can you send the proposal to Sam? Okay, well, then it's going to make a tool call, and it's going to go read the email. Now, something that people, even deep in tech, don't understand, and I know some of you in this room also don't understand this, is that the second time we call the agent, we have to send the entire history back, the entire history, okay?

10:36So, how does that look? Well, the next thing it's going to do is search files, but we have to send, can you send the proposal to Sam, read email, search files back? This is actually. a big problem because as this keeps going it's building up over and over and over again of course this is the context window you guys are familiar with this but this is why there is a context window because it's building up on every single tool call and it gets pretty out of hand right finally it says yeah I just sent it but now remember every single time we're sending all of those tools back on every single step and we send them back again and again and again and this actually an O of N squared problem, right, specifically on the reads, because every time I'm reading that data back out, I'm reading it out of the database, I am performing a lot of reads, especially as a durable agent, because I need to be able to resume from any point.

11:26I can't just assume this is in my cache, so that is going to scale very bad. My writes are not so bad. I don't, the writes aren't a huge problem. However, they need to be, consistent. The writes have to be consistent. The second it writes, it needs to be able to be read by another process instantly. So I can't use something like a KV store that's eventually consistent. It has to work right away. So basically, we need an ACID database.

11:59The problem is, an ACID database sucks at volume, like really, really bad, because all of my agents are trying to read and write from one place. And in order to be consistent, they generally lock the table when they're performing a write, which means I have all kinds of race conditions and it just broke my promise of scalability. So really what I need is I need every single thread to have its own database. I also need them all to have their own code execution.

12:30So we'll add those per thread database, save code execution. There's another problem though. The people at my company want this kind of experience for interacting with their AI or whatever, you know, maybe an app or something. They're not, like, actually interacting with it. They need an interface to interact with it. And that means we need some sort of an HTTP server to expose, like, an API or maybe some kind of WebSockets to expose the streaming nature. But remember, every single one of those threads requires this. The other problem is when I say, follow up with Sam, great, tomorrow at 9 a .m., there's no requests inbound, so there's nothing that would cause my agent to actually boot up.

13:16This is another problem. So we need some sort of a trigger, almost like a cron job, that can just run at any time. So here's roughly the shape of requirements that we need in order to build good domain -specific agents for customers for our own business. so on and so forth. But you came to this talk, Building Durable Agents with Durable Objects, so I guess you probably know that what I'm going to talk about is how durable objects are the solution to that problem. What are they, though?

13:49I don't work for Cloudflare. I love Cloudflare. They do many things amazing. One thing that's not great is when I talk to other developers about durable objects, nobody has any idea what the hell they are. they have no idea so here's my terminology it's a weird little parasite server that's attached to a worker or many of them okay we're little parasite so it can perform you have a worker it can perform code execution in this durable object doesn't have to be happen in your primary worker can happen in a durable object it has its own little database it has its own little sequel light database and by little it can be up to 10 gigabytes so not bad and then it basically has its own little HTTP server it doesn't actually it works through the worker but but as a way to think about this you can think about it as a tiny little server that has all the functionality that you would be used to in a server and the exchange for this is you pay for it in limitations so it's 128 megabytes of memory right so that's an interesting constraint you have to deal with there's system. That's another interesting constraint you have to deal with.

14:58It turns out you can use a database as a file system. But basically, we can see that durable objects solve all of these problems. They are actually like the perfect primitive for this. Let's take a quick look at that. So isolated compute, that's one of ours. We have Jane's thread. Jane's thread is able to store all of its history, its logs, its files, everything. within its own durable object. You don't need, like, some sandbox. It is a sandbox. It's a tiny little server. And when John has a thread, his is completely isolated as well. These are two totally different systems, and the only thing that they're ever allowed to do with each other is whatever you define, whatever the boundaries are that you defined.

15:45And even better than that, Cloudflare actually has a product called Workers for Platforms, which lets you take a namespace of durable objects say this is you know customer A's and this one's customer B's and those two never shall meet all right no cold start this is awesome I mean basically you can send input into one of these things and usually within about 200 milliseconds this thing's booted up and ready to go so you you have effectively no cold start issue whatsoever it's way better than a sandbox or a container or something like that in 200 milliseconds that's like cold cold

16:24Scalability is basically infinite. Cloudflare has no durable object limit. Like, they have a lot of limits, you know, when you go, like, read those pages, the documentation pages. There's no durable object limit. You can literally have all of them.

16:38Kenton, who I believe is actually responsible for sort of creating these magical little beasts, basically said, you know, your application code runs exactly where the data is stored. And this is true. So the data in your database... gets co -located with where the execution is and so you end up with this per thread database now if you think about like logging problems there there there are so many companies out here that just like their job is to log stuff because logging is really hard at scale this effectively solves the logging problem instantaneously because for agents at least because an individual agent is inside of a single thread. is a single durable object is a single agent. Those are all equal.

17:24And so the database that's responsible for like reading all of the results that you need to send back to the LLM every time is co-located with the execution environment that's actually running it and is not touching any other database. So you can read and write from that thing as fast as you want because that one thread is never going to overwhelm that SQLite database. now what if the agent writes some code and we need like code execution well basically in that case you can call something called a dynamic worker you send the generated code into this dynamic worker the dynamic worker runs it so this is like unsafe code right code that the LLM wrote it runs the code and then it can give you the results back it's pretty simple and the the main question of course then is it actually secure because Can my generated code ask to exfiltrate some information?

18:18And no, you have to explicitly grant everything. You can even say that this worker has no network connection. It's just like a little box to do a little bit of runtime. HTTP server. These things can absolutely run request responses. They can also hold long-term WebSocket connections, which in agent world is like super important. We all need to be able to run WebSockets because we want to get like... instantaneous feedback the second we possibly can. And they already support that. Triggers. So this is one of my favorite features. A durable object can choose to run what's called an alarm at any time. But there's a catch. It can only have one alarm. So you have a durable object.

19:06That durable object can say, hey, I need to boot back up in zero milliseconds. Or in six days. So all you need to do is use that little database and you create a queue of when things need to boot up. Every time it boots up, you set the next alarm. It's like kicking a ball forward down the road. And that gives you basically full cron support, full scheduling support. You can say, you know, boot up at 9 a.m., and now we have a solution to that problem. So again, durable objects are basically solving all of the requirements that are necessary in order to build really compelling domain-specific agents. The problem is we need to do that now for every single customer. So I'm going to do a little demo right now so we can actually play with this. It's interactive. There's a QR code on there if you guys want to scan it.

19:52This is an example of a domain-specific agent for submitting expense reports. And every single one of you, when you scan this, will go, you just type in your name, and you will receive your own durable object. which is an expense report agent. It'll help you fill out this boring expense report. Now, here's what's interesting. Businesses don't want GrokBot to be filling out expense reports. It's really not necessary that the bot filling out an expense report can also go check Twitter. Those are, like, incompatible ideas. What they want is efficiency and effectiveness over a long period of time. So I'm ready to switch over to this.

20:38awesome okay so here you can see that this is actually made up of three different agents i have an accounting coordinator i have an expense report that's tally the little dude you guys are talking to and then i have a google sheets agent and these three different agents are all durable objects and every single one of you so we're at six 67 of you so far have actually created something and hopefully you notice that it was like pretty darn fast when you started talking to your guy that's because you're all talking to your own tiny little durable object who is responsible for filling this out I'm gonna do one myself all right so I'm gonna create a new expense report and I I'm going to drag some receipts on here.

21:41Now, the other thing that's cool is, so this is a platform that we wrote to basically help customers and clients fill these things out. And as you fill these things out, they are all communicating to a coordinator above them. And the coordinator is making sure that When the expense reports are filed, they're filed properly. Once they're filed properly, it goes and talks to a Google Sheets coordinator and then starts filing things in the Google Sheets. And if it's not proper, then it tells your little agent, hey, you did a bad job on this or that's not an appropriate PO code or whatever. And you kind of get the idea. But you can see that we are absolutely zipping through here. But so far, our total cost for all of you is 19 cents.

22:27Um, even though we've got 89 of these expense reports right now, it's 19 cents because we're able to use Luna for something like this because it's such a small task, right? It's such a small, small task. Another thing that's really important to have when you're building domain-specific agents is a ridiculously good way to see what's actually happening. So here I can click on, you know, any of these. And again, I'm reading from the little durable object that's here and I can see the exact that was sent, exactly what got sent off to the user in excruciating detail. And then I can see my response that comes back. I can see which tools were called, so on and so forth. Okay, here's my guy filling out my expense report.

23:19And it left me some questions. What was the business purpose of this charter flight?

23:25I gave it a Grand Cayman to San Francisco Charter.

23:30Obviously, I had a business meeting there.

23:41By the way, this took like less than an hour to make because the agent framework behind here the standard agent framework, which I'm not shilling, but I am, basically defines exactly how these agents are built with Cloudflare durable objects. So once you have that, like Cloud Code can just create these things, no problem. All right, which customer or client was this? Oh, it was obviously for Cloudflare.

24:15All right, so I think I'm good to go.

24:21Go ahead and just submit this.

24:30Now, I also have the accountant view of this. So the accountant is going to want to log in here and see all of these things coming through and what's actually happening. And this is also a durable object, and all of your individual expense reports are talking back to this. And again, It can read and write as fast as you can feed it, because it only has to read and write information that's pertinent to itself, not everybody else's LLM chain. So we've got a whole bunch of these.

25:02And I'm really curious if this works or not. I'm going to crack open Google Sheets here. Oh, you guys are all getting rejected, aren't you? What are you getting rejected for? Somebody shout out what you got rejected for.

25:18Launch with Enron.

25:26I'll just say approve everyone. You get the idea. So at some point, this agent is going to go off and talk to the Google Sheets agent, and it'll just start filling it out. And again, the Google Sheets agent is another durable object, and what's great about it is all it can do is Google Sheets, but it knows Google Sheets really well. It knows all of the APIs. knows everything about Google Sheets, it's a Google Sheets master. And so you can ask it like, hey, I need you to format this and that. And it's also a tiny little model. But it's Luna with just one job in life. So you can build up these collections of things over time. It's great for business.

26:02All right. I'm going to switch back over to my deck. There we go.

26:13Great, so those are durable objects in practice, but I do want to tell you some practical tips and tricks for this, and then I think I might have a little bit of time for Q&A at the end, so if anybody has questions, start thinking about them now. Practical tips and tricks here. What if the model is down? This happens a lot, an unfortunate amount, actually. Well, You basically need to have fallback models, and the trick here is if there's a failure, whatever your framework you're using or whatever system you're using with your durable object, you need to boost it in intelligence. So go from a dumb model that you know worked really, really well to a smart model that is less fine-tuned for the application.

26:58That's a really good trick to keep everything flowing smoothly even when a primary is down. And obviously use different providers for your backups. Another one. How do we keep durable object execution alive when it's on a long execution? This is a huge problem, actually. And if I were to pull people who have tried to build agents using durable objects, this is probably the number one issue that they run into is keeping the durable object alive for, like, hours.

27:27The trick is to use an alarm.

27:30Basically, what you want to do, if any of you were, like, JavaScript developers back in the day or something like that, You used to be able to basically create a second, it wasn't actually a second thread, but it was similar, by setting like a zero millisecond timeout, right, or a QMicroTask. This is effectively the same kind of thing. You basically want to create a very brief alarm, so an inbound request happens, you create a brief alarm with the message that you want to boot the agent up with. The reason is that durable objects are very tightly bound to the execution of whatever triggered them. So if... have an HTTP request that's coming in, that durable object will run for the duration of that HTTP request, but if that HTTP request shuts down for some reason, my durable object will shut down as well. And that sucks when it's like trying to do long -term work or you've queued up some async work to do. So you really need alarms.

28:20I will warn you right now, there is a little bit of an issue here where you can cause these things to loop. I have done that.

28:34and and it will just sit there you know eternally booting itself up so you do need to be a little bit careful when you're using the alarm system to make sure you don't do that but that is the trick an alarm can basically run forever there is a there is a function in a durable object that basically lets you say like hey I need you to run this and then when you're done I need you to continue to run for an additional certain period of time and really you only get about 30 seconds of execution when you do that so you either need to hold the connection open to the durable object, or you can use this little hack and make it work. I am sure I will run into somebody on the durable objects team, and they'll tell me why there's a better solution, but not obvious to me. How do we schedule more than one thing at a time? Well, that's like I was saying. What you need to do is you need to create an alarm queue in the SQLite database for each individual durable object.

29:19So every single one of those agents that you guys were interacting with, it had an alarm queue where we just shoved in. exact microseconds when it needed to boot back up. And then every time the durable object boots up because of the alarm, it pulls the next one off the list and then sets its alarm for that. So the function to do this is just set alarm and it sets it at some point in the future. You guys aren't gonna write this code anymore, but you need to tell your agents that that's the way you need it to be done so it works, because it's also not entirely obvious. So here we have an alarm that's actually gonna run at 9 a.m. and it's going to immediately set the 9.15 alarm before it even executes. You need to do it before it executes, because if it fails, now you've just killed the thread, basically.

30:09What if a durable object dies? I wish this didn't happen, but it does. Durable objects sometimes just go cold, like dead cold. It usually happens when you push an update. So if you push an update for your code base, it is pretty common that that durable object will just die mid-execution, and that can cause your next alarm to not get fired or something like that. So the trick, unfortunately, to this is that you basically need a watchdog. So you can use a second durable object that's watching the primary durable object. And if that one, you know, there could be telltale signs like, hey, that one hasn't done anything, seconds but it sure should have well then you can like fire another alarm externally or something like that this this is absolutely necessary and unfortunately only shows up when you're sort of like at scale so initially you're like you got your prod it looks great everything's working great and then you actually get it out in the world and all of a sudden like some weird percentage of the time 0 .325 percent of the time these durable objects are dying another trick that you can do is have a jobs so cloudflare offers cron jobs as well but cron jobs are really limited in cloudflare both on execution time and the number of them that you can set so often that's not a good option if you're at scale like you know we frequently have 20 ,000 to 50 ,000 durable objects that are going which means

31:40if it takes me even a hundred milliseconds to check every single one of those I can easily eclipse any kind of 30-second window or something like that.

31:54So what Cloudflare services did we use when I built this demo and on our standard agents platform? It turns out we used all of them. Not really, but basically all of them. Almost every single one. So every durable object has to be attached to a worker. So you can't use durable objects without workers. So you're going to be using workers. Workers for platforms. So on our... platform you know we let customers come and sign up and and then they can use the platform which means that they need their own isolated box to do all of that work in workers for AI is a great option if you need to do the end if you want to do the inference and really exciting that they you know Cloudflare released a new model yesterday a new type of system one model so it's exciting to see that there's actually now like some alpha and using workers for AI D1, if you're not familiar, is a database.

32:49This is very useful. It's sort of actually inside of each durable object, that SQLite database. It's basically a SQLite database that's global. So if you haven't used that, it ends up being really useful, especially with workers for platforms because you've got to store all the customers and so on and so forth. R2, of course, storing your big files, a workers' KV. You need to do that for your super frequent whites that are not... acid. Queues end up being important sometimes, although often the durable objects can do that for you. Artifacts, has anybody used artifacts? Yeah, they're cool. So the way that like our platform works is you clone down the code base, you have your agent write agents, and then you push it back up to artifacts. Artifacts actually deploys it to the Cloudflare workers for platforms.

33:35It's a really good way to provide dev tools for people. There's a bunch more in here. I'm not going to go through them all. but that is durable objects thank you very much and I think we have time for questions so does anybody have questions yeah there's a microphone I think running running to you you put your hand back up thanks

34:02hi my question is what happens when you want to have multiple chats with an agent because if an agent as a durable object, don't they normally just have one session? So what is the way? A single thread. That's a good question. It depends if you want shared context or not. If you want shared context, I mean, this doesn't even really exist. You can't open up ChatGPT and have two conversations in the same thread, right? But if you think about ChatGPT as an agent and each of those threads as an instance of the agent, that maps to durable objects very well. So, think about, you know, you're working in ChatGPT, each one in the sidebar is basically one instance of the same durable object. Yeah, if that's not clear, a durable object is like a recipe and then you can just stamp it out thousands of times.

34:52So, every single one gets its own context, but maybe the same system prompt or something like that.

35:03Say we do need to share. share some persistence across our durable objects? Is that, I mean, I guess we could do whatever, but do we see that up front? Is there some concept of a shared interface? Like, how would you recommend that? So there's a number of ways to solve this at an agent level. If you're talking about it at an agent level, I would do that with tools. So I would have each agent have, like, tools that it can look up global state. If you're not talking about that, you're just, like, trying to create a bunch of instances of durable objects. shared state there's a lot of options for it but basically each durable object you get to say what bindings it has and so you could bind it to a d1 database that's global you could bind it and have it communicate back to the original worker that that it belongs to there's a lot of ways to do do shared state there but if it's agents i would highly recommend using tools rather than anything else and if there's lots of agents that are doing small tasks like everybody filling out expense reports with one pair agent then the best way to communicate is English and everything else will eventually sort of break down so there are so many attempts I have been guilty of this so many times to try to create some sort of like a shared schema where a parent and child communicate and inevitably it's gonna break and it's much better for them just to communicate on the language they were trained on so a child like when you guys were filling this out the parent was receiving like Tom just filled out this expense report, blah, blah, blah, blah, blah, here it is.

36:32And that's all it was getting, it was not structured. Thank you.

36:42Thanks, Justin, so my question is, let's just say if I want to make any kind of agent, like a chat agent or any sort, I would need a harness, which I'll be programming on top of a durable object. So what is the starting harness which you recommend? Is it like by durable or? I mean it's a great question I use my own setup so standard agents is a standard specification for exactly how those harnesses get built and it's not open source yet but we're planning open source it very soon but I use that for everything and there are other alternatives out there which you know you could try using like flu or something like that but basically it's really important that all of your agents are written this same way so you have the same visibility into all of them so you could even invent your own i mean everybody's building the same thing right every that's kind of like the one of the takeaways that you should have from this conference when you talk to like everybody everybody's building roughly the same stuff we're all like building these things that build things or building agents and stuff and so you could build your own i my hope and vision for the future is that we are able to emerge on agent standards very similar to how we had web standards and at some point it'll be like yeah this is the way that the like little nuts and bolts of how the tool calls are done is like put together but you know then the rest of it is up to you but that's a that's a lofty vision who knows thanks because like for me i either i usually just you know the thing harness by cloudflare right i just give like my cloud code

38:15like oh you use thing to like make this and it somehow makes it but i'm not sure if it's the best way because there's no standard out there. Is that why we have standard agents? Yeah, I mean, that's literally why that company is called standard agents, because that's what we're hoping for. But, yeah, it's a problem that everybody's struggling with, so I'd love for there to be a great solution. Yes, Sunil, I'm sure, has many thoughts about this, because he's working on Project Think, which is sort of CloudFlare's way to do some of this. But it's still pretty low level. It doesn't have that higher level abstraction where you're able to you know kind of the threads running underneath it I think we have time for like a couple more questions can you go into a little more depth on how you set up the watchdog durable object like how is that actually configured and how they talk to each other yeah so in a durable object there is a constructor which fires a hundred percent of the time when it boots up and so you can pretty safely put stuff in there that you need to be sidecar like a side effect to your durable object so in the constructor it will boot up another durable object and then they will bind you to each other basically and then the second durable object is watching for cues in the database of the primary so in the case of an agent you know that like records are supposed to be written or there's a check-in period or something like that so when an event

39:46place on the primary the watchdog is watching to see okay after a certain amount of time do we have anything and then it can it can either perform some diagnosis or it can just fire another alarm to see if it's there but that's that's basically what it is it's it's a small percentage of time when it fails but it sucks when it does so

40:11hello this is a little bit of like sidetrack Question but like you talked about the 128 MB limit with the workers and for like you know long -running a long horizon agents What's your solution to solving that problem? 120 megabytes? The 128 megabytes is really fun, but basically what you need to do is just stream everything Nothing like you can't buffer anything like even when you're reading from the database the the results of your entire version history to send back to the parent back to the LLM, that needs to be a streaming process where you're streaming it chunk by chunk by chunk. Oh, the other trick that I didn't put in the slides here is a file system. So Sunil has a solution for this in Durable Objects where you can basically treat the SQLite database as files, and we did the same thing.

41:03We arrived at the same conclusion before we did that. But basically, each row is allowed to be two megabytes. So you can take even a binary file and automatically slice it into two megabyte chunks stored in the database and then when you access the file like let's say on an endpoint you know it's a it's a one gigabyte video it streams the results back from there so it never over over overwhelms the 120 megabyte limit yeah okay last question

41:38have thousands of these agents running around, will there be any topology kind to show the interdependencies? That's a good question. I mean, that depends so much on the business application that somebody wants to apply this to, but in general, sitting on top of all these durable agents is a separate problem that is really beyond the scope of even this talk, where if you think about every single durable agent, object having its own database and its own information well then what's the aggregate sum of all of that like how do I know whether or not there is a problem in the wider ecosystem and that kind of comes down to another like map reduce type problem where you've got to decide what kind of information do I want to transmit up to even higher level coordinator do I want a separate logging system and then how do I get information out of that so many options to do that I don't have a good solution The way we do this is that we send small chunks of telemetry from each one of these up to a central worker that does the processing on it.

42:45But who knows if that's, like, going to survive, you know, a million users at the same time or something. I think I'm out of time, but I think thank you very much. I'll be here. If you see me, come and talk to me.