I built your personal software ecosystem

Oh, I'm so thrilled to be here. This is going to be so much fun. I have been working on this project since March, and it's now 1.3 million lines of code, and I just can't believe that I can say that. I've been working on this primarily solo, and it's an open source project, but I've been doing most of it myself. 1.3 million lines of code. It's wild. What a cool time to live, and I want to tell you about what this is and how I built it on Cloudflare, how Cloudflare makes it possible for me to do what I'm doing. So, here's the problem that we're trying to save. You live in your agent's house. You don't use warp. That's okay. It doesn't matter. Every one of these agents has their own little walled garden that they want to build that's full of things like memory and packages or scripts, automations, triggers and credentials, and even apps built right into the chat, right? They're all doing this. Canvases from cursor or sites in chat GPT. They're all building these wonderful things, and you love it there because it's so powerful and awesome, but there are two significant problems. If you decide you want to switch from one house to another, that's too bad. All of that stuff lives inside of that house, and it's a pain, and it's not like a huge deal, right? You just say, well, okay, I'll wire all my MCP servers again. Lots of my tokens are saved in .env file in the repo anyway, and I've got skills or whatever, but if that's the way you're living, you're living beneath the power of these agents because the more that you put into these agents, the more powerful that they can be, but you don't want to put it into the agent because it traps it inside of that ecosystem, and that's a problem. The other thing is you're working on a team with other engineers, and they have their own preferences on the agents that they are using, and you can't share the things that you have inside of one walled garden with another. They're not incentivized to make it easy for you to share these things between the walled gardens, right? And so you're stuck. Kodi is about making a common platform regardless of the agent you're using. So everybody on your team can use any agent. You can swap out the agents as you like, and you can share pieces of what you're creating with not only the agent, but with your team as well. And so here we've got the green user, and they've got this app. We'll talk about what an app is in Kodi, but these other teammates can make a fork of that app and have their own copy, and they can modify and do whatever they want to with it. Or you can make a package and have that be a shared resource that as I make updates to it, everybody else gets the benefits of those updates. We're going to talk about each one of these primitives, but this is the core thing that Kodi does, is it makes it so that regardless of the agent you're using or the agent that your team is using, you are able to share the things that are created, the automations, the scripts, the apps, everything, and the credentials, which actually is a really tricky one. So let's talk about how Kodi enables this. There are two tools, three doors, and a number of primitives that are inside of Kodi's home. So let's start with the tools, with search. So agents drown in tools, and lots of different agents have their own solutions to this. Most of it involves some sort of mechanism for searching at the time of need, and Kodi does this as well. That's an agent -agnostic solution. So when you ask your agent to email my team the weekly PR summary, this goes into Kodi through one of those doors, the MCP or the CLI or whatever, and it surfaces the different things that are inside of Kodi that enable this, whatever it is that you're asking. And the way that that works is all built on Cloudflare. So we've got workers AI for the embeddings and vectorize, and the details are stored in D1, as well as even in durable objects, and we index everything that's in Kodi so that your agents can find what we're looking for. And like I said, we'll talk about some of these things too, but like documentation, the other MCP servers that you have inside of Kodi that are connected, the capabilities that Kodi has, your secrets, your credentials, packages, all of that. And then once the agent finds what it's looking for, then it can execute on those things. And the way that this works is the agent will just call functions in Kodi to say, hey, I want you to get me the repos, I want you to get the pull requests, I want you to get me the reviews off of those, and I want you to send the email, right? And you have complete control over what these tools are and what they do through the packages that we'll talk about a little bit. So these are just some examples, but they're not built into Kodi, you build those. So this is what it looks like for an agent to do that. It literally just writes code and it's living inside of the Kodi runtime. And so there are a bunch of utilities like sending emails or creating workflows or publishing a package or a large number of things, all built into Kodi, all documented and they have type definitions as well. And with that, we're able to do literally anything. Code is the most composable thing, primitive, that we can give our agents. And so the agent writes the code, it sends it to Kodi, Kodi runs it in an isolate worker, in a dynamic worker within the Kodi runtime, and any fetch requests that need to go to a third-party service go through Kodi's fetch gateway. And that's really important for the credentials and how you access securely these third-party services, which we'll dive into here in a bit. So that's search and execute. Now the doors, starting with MCP, pretty like standard thing. There's a CLI to install it in whatever client or agent you have. And it's inside of many of the marketplaces for the agents that you're using, like Grokbot and Codex and pretty much all of them. If it's missing, just let me know. And then you can use that MCP to actually bootstrap the CLI, because the CLI is a little bit more effective. So once you connect the MCP server, then you can have your agent be authenticated. And what's cool about this is if you're using cloud agents, you have your cloud agent connected to MCP. And then the first thing that the cloud agent does is it authenticates the CLI, and now it can work through the CLI really efficiently. It's pretty cool. So then on the CLI side of things, Kodi's sandbox runs inside of Cloudflare, right? But that only has access to the things that are in the cloud. It doesn't have access to the stuff that's on your machine. And this is one of the reasons that the CLI is so great, because the CLI running on your machine is able to access everything else that's on your machine, right? But the problem with that is now to be able to talk to third parties, you have to have those secrets on your machine. And that might not be a great thing if you don't want agents to go rogue and do whatever it is that they want to do, like drop the production database, which did happen to a poor company in April and was terrible. It not only dropped the production database, but also deleted all the backups. So bad. And this does happen. And so what you can do with Kodi is you say, let's run execute locally. And so then it proxies everything here. Let's just skip here. There we go. It will proxy all third party calls and everything through Kodi. And it runs like a mini Cloudflare using WorkerD locally on the machine. And so you're running in the same environment. Everything works exactly the same as if it was running remotely, except it also has access to everything that is on your local box, which is really powerful. And the entire package graph of all the different packages you have in Kodi are accessible there as well. And fetches will still go through the Kodi gateway for security reasons. So then the API is like pretty boring. It's just what you would expect. It's like an API to those things. Really good for scripts and other automations that you want to live outside of the Kodi ecosystem. Okay. Now the primitives. We'll start with memory. That one's pretty straightforward, I think, for most people. So the different agents, you have to remind them every single time what your time zone is, because when you say, could you please schedule a thing at six o'clock, it doesn't know what time zone you're in. You stick that in memory, and now that's not a problem. Every single agent knows what time zone you're in and whatever else. I actually think that people put too much weight on memory because what's better than saying, like, remember to never include an em dash in an email that you draft for me is to instead make a deterministic script that will fail if an em dash exists in what the agent wrote. Or to have documentation on that script. And so it's progressively discovered at the time that it's actually doing that. So memory is cool. And Kodi has it. And actually, the mechanism for storing memories is pretty cool as well. So it vectorizes everything, and every single tool call that's made surfaces the relevant memories for the agent. So every call includes a memory context, which the agent just says, this is what I'm trying to do. That's why I'm searching for this. Or that's why I'm writing this code and everything. So I'm just trying to accomplish this thing. And that is used to surface the most appropriate memories for the agent at that time. And when it's creating and saving new memories, it also verifies that the new memory it's about to save does not conflict with any existing memories that are already in the system. Because otherwise you end up with, like, sometimes he feels this way, sometimes he doesn't. I don't know what to believe. And so there's a whole process to make sure that the memories don't conflict. All right. Packages. This is where things start to get really interesting. How many of you have published a package on NPM before? Okay. A handful of you. Or anything like NPM, like a registry for shared code. Okay. So a package is effectively that. It's a repository of code that has been packaged up and made accessible by other pieces of code. This is extremely composable and is the foundation for all the software that we are using everywhere. And so the problem that packages solve is that if my agent is going to write some code for me to answer a question, like summarizing my PRs every Monday or whatever, like give me a PR summary, then that agent is going to write that code, but then that code disappears if I'm not like if I don't persist it anywhere. So package is the persistence layer. And once you have that, and it's a full Git repo as well. It's running on Cloudflare artifacts. But once you have that, then you can actually use it anywhere else. So the agent, when it does its search, it's like, oh, he wants me to summarize this PR. Let me go and do a search and see if Cody has something in there that makes that easy. Oh, great. There's a PR summary package. I will use that instead of having to write it all out myself. This is useful for something like this. It's like a couple lines long, but it's extremely useful if it's a really complicated process that like typically lots of us would think, oh, I'll just write a big skill that says do these steps. Those skills you can just convert into deterministic code so often. And so make it or even at least pieces of it, turn it into deterministic code, then it's safer, faster, more reliable, more durable, and it will do the same thing correctly every time. So it's all backed by repo sessions running in durable objects that go into an artifact. One, you get a repo for every package. And then there's a publish step that's similar to like if you think of the repos as your GitHub, it's like your own little GitHub for you and your organization. Then the publish step is like now we're publishing it from GitHub to NPM as an example. So it does type checking, double checks the exports are all correct, all of that on publish. And that actually creates a bundle of that and sticks that bundled code inside of KV so it's easily accessed. And then it is eventually run inside of a dynamic worker in that isolated environment. All right. So then triggers. If you want to be able to, well, yeah, here's the general problem that this solves. When you schedule something with an agent, every one of the agents you can do this, remind me on Monday to do such and such or whatever. It's non -deterministic by design. And so every time it's going to be different. And, of course, you can tell the agent, well, no, every time let me make you a skill and I'll tell you exactly what to do. But it's non-deterministic. Okay, great. I'll write a script. Well, you're on your road to inventing Kodi, except now you have to think about credentials, which we'll talk here in a second. So what Kodi gives you is instead of triggering an inference call, you trigger deterministic code. And maybe there's something that you can do inside of that deterministic code that calls out to Clef or Jev or some decision model that then determines some way to route this trigger. So on Mondays, I want this. Or when Stripe gets a purchase, I want this. Or when I can send an email, like I'll forward an email to Kodi and it will have some sort of logic that tells it what to do with that email. Or even events. Inside of Kodi, your packages can emit events. And there are events that Kodi emits itself. So lots of different mechanisms by which you can start this deterministic code that might end in handing something over to an agent. And often for me, it does. But it's just a powerful mechanism for getting deterministic code kicked off. And all based on packages as well. So the way that that works on Clonflare, we've got a job manager and a durable object. And we have workflows for durability, retries, item potency. There's an item potency key. And then that runs as you in your package. And there's also email. So there's email routing from Clonflare. And the mailbox is durable objects in R2. It's pretty cool. All right. So credentials. This is the big one. So, so far you're like, Kent, I can like do all of this with my existing system. Like much of this with just like GitHub and my existing system. Credentials is the part that is a lot harder to do. You absolutely, you could do this at Kodi, by the way, it's open source. And even there's a self-hosted version of Kodi using CELDI, which is so cool. Congratulations, Dino and all of that. But credentials is tricky. So the way that credentials works or the problem that it solves is that you do not want to be pasting these kinds of keys into your chat. Like just don't do it. If you're doing that, I'm not going to have anybody raise their hands because it would be shameful. Don't do it. Stop pasting secrets into your chats. That when you do that, it lives in the transcript and the context and logs, it just sits there forever. So instead what you all do is you put those keys in a .env file, right? In your project root level .env. That's even worse. Because now not only is it accessible to every session that just decides to cat your .env file, but it's just, well, that's it. That's the problem. It's available to every agent. And this is exactly what caused that data loss problem that I referenced earlier that happened back in April. So it's not good. Do not be putting your stuff in .env files. Here's what you do instead. Instead, you make it so that agents can reference the secrets or the credentials that you have that are available. And in Kodi's system, Kodi holds the keys for that. So when the agent says, I need to be able to talk to Stripe, it does the search. It finds that there is a secret for Stripe. And it says, okay, great. I know how to integrate with Stripe. I've got the authorization. And Kodi ensures that that secret is swapped out at the time the actual fetch happens inside of its own fetch gateway. And it also ensures that you're not trying to send a secret to the wrong domain. So it just will not allow a secret to be sent to a domain that's not been approved. And if that does happen, then you're going to get an error message back and the agent will give you a link that you can go and approve it. So you can do that manually if you like. But the other thing is it also ensures that it's only placed inside of the fetch request in an appropriate spot. So here in the authorization header. If you try to put it in the body or something, you're not going to succeed. So the agent, it's impossible for the agent to get access to that secret unless you give it to the agent, which you should not do. So the way that that works is when the isolate sees a secret or a fetch request, then that's going to hop out into the fetch gateway and that's living inside of Kodi that has access to the secrets. So it pulls them out of D1, but not just the value and it's encrypted in D1, but it pulls it and decrypts it out of D1. But it also pulls the metadata to know whether it's approved to go to this particular domain. And if it is, then it will go. And if it's not, then it will return an error. And the credentials are org supported. So you can have a credential that like, there are lots of services that have service level accounts and you have a shared credential for your team or for the entire organization. And so you can have anybody on your team have access to that credential and they can run packages and automations with that credential. But then you can also have your own credentials. So, okay, I've got my linear personal access token. I'll stick it in my Kodi and only I am able to use that credential when I'm talking to a linear. But I have this linear package that does all this cool stuff with linear the way that I like it. My coworkers can also use that package, but they have to use their own credentials for that. It's a really awesome system for sharing. And then apps. So here's the thing. And by the way, I think that this timer text in the back, I think the timer started at the wrong time. Because I'm pretty sure I've got quite a bit more time. So if you could get that updated, it'd be helpful. So here's the thing with apps. Text is great, but it is super not great for a lot of things that we want to use agents for. We're not just asking it questions and getting back a yes or a no. Sometimes or telling it to do a thing and having it do something. Sometimes we actually want to have some sort of visual feedback. And every agent is building that capability in them already. So Cursor, a long time ago, added Canvas support. That's very cool. And Cloud has its artifacts. And ChatGPT is doing its sites thing. Everybody is doing this. So this is not like a unique thing to Kodi. What's different about Kodi is that, and so yeah, let's just continue with the example. So merge number 4131. Wait, which one? And so Kodi can also host your applications. It executes those inside of the Kodi context. And so what's special about this that's different from what is available now is that this is hooked up to all of your everything else that lives inside of Kodi. So any other package that you have access to, all the credentials that you have access to, and you can wire that into your software. And that's cool. Like, okay, I've wired up integrations to software before. But what's really neat about this is now you can wire up another app and still access those same credentials, and another app, and another app. And you don't have to wire them up for every single app that you're creating. They're already wired into Kodi. So you make any number of apps that you want, and they can be yours. And other people can fork them and be like, I like this, but I don't like this other thing about it. And so they'll just fork it and make their own version of that using their credentials. And you can also make it an interactive thing. So it can not just be a dashboard, but an actual control center. And you can customize the domain as well. Now, there was one thing that I forgot to mention earlier on credentials that I want to bring up here too. And that is, one problem with credentials is that they are often overscoped or underscoped for what they should or should not be able to do. And so an example of this is Gmail. If you want to have your bot draft emails for you, but never send an email because you want to always be able to review that, that's not possible with the Gmail scopes. The same scope that gives you draftability also gives you sendability. But with Kodi, you can make a God-level token for your Google account, and then say, I've locked this token down to this package. So only this package has permission to use this token. And then you make the package do deterministically exactly what you want it to be able to do. It can do nothing else. It can only draft emails. That's it. And even though the token that it's using is a God-level token, all it can do is what is deterministic in that package. And then you can lock that package down so agents can't even change it if they decide they want to try and do something nefarious. So really, really powerful credentials story there. So for apps, they are also running inside of a dynamic worker. And they all have their own storage too. So you can build a full app that has a SQLite database that every single package has access to. Whether it has a UI or not, you can do this with all packages. And real time as well. So packages have those triggers with webhooks. So you can say, hey, Stripe, let me know whenever this thing happens. And you can update your app in real time. And all is supported on the platform. And what is so cool about all of this is, oh, yeah, sorry. The sharing piece, of course, I talked about that throughout. You can share. You have really granular controls over everything inside the system. And yeah. And everything's namespace. It's cool. Whatever. We don't have a whole lot of time. And it's all built on Cloudflare, of course. Why am I here? It's because we're built on Cloudflare. And honestly, I don't think that I could build Kodi and have it be an affordable thing without Cloudflare. It's just insane what they have done. So absolutely love Cloudflare. So here's one thing I want to leave you with. I'm almost done. And this is like my vision. This is why I think Kodi is so critical to the world. Or something like Kodi, at least. So right now, there are tens of millions of developers and we've got, who knows, hundreds of agents all running in our pockets right now. Right. How many of you are running an agent right now? Yeah. Yeah. So like this is just we're constantly building software and it's like, wow, what scale? That's amazing. But as software continues to get easier and easier to build, you're going to have more and more people building software. Now, I know that a lot of you are like, no, we've thought about this already. And it's like the Walmart greeter does not want to build an app to solve whatever problems they have. They just want to ask the question and get the answer. Right. They want their problem solved. So that's what's going to happen, though, is we all of the people outside of this room are going to get used to the idea that they can talk to an agent and have their problem solved. And and they won't know how that problem is solved. But guess how it's it's solved by that agent writing code to build them an app or to some one off thing. It's going to be software that does that for them. So we're going from millions, tens of millions of developers to billions of people all over the world, orders of magnitude, more code being created. And I call this invisible software. So we we just ask for the thing to happen. Software is the thing that's powering it. Custom software is the thing that's powering it. And we don't know or care. They just we just get on with our lives. So I made a video just published this week if you want a deeper dive on that idea. But yeah, if you're building a SaaS application that relies on like consumers, you really need to be thinking about this and how to make your offering attractive to their agents. So that's everything that I have to share with you. Thank you so much for giving me some of your time and attention. I know that this was really fast. Thank you so much for coming to my presentation.