I'm not crazy and that's not dangerous. Throughout this talk, I want to explain a few concepts about Nanoclaw that make it safe. To demonstrate these concepts, I'm going to talk about our agent factory that we built, and along the way, I'll share some interesting things about the choices we made while building it.
First of all, Nanoclaw is an open source framework for building secure autonomous assistants, or claw assistants. In just three months, we have over 30,000 stars on GitHub and many thousands of users all over the world, including Dr. Vivian Balakrishnan, Foreign Minister of Singapore. More importantly, over 12,000 people have forked the repository—that's the main way people are using it. They're forking it, experimenting with it, and making their own autonomous agents based on it. Along with that, we have over two and a half thousand pull requests and issues.
Maintaining an open source project today is better than ever, but at the same time, there are new challenges. With coding agents, it's easier than ever to open a pull request. Many thousands of people are making great contributions to the project, but there are frankly also spam pull requests. People will point their coding agent at your repo and say, contribute something here. It's very difficult to tell the difference between a spam pull request and a good pull request today. They look the same and can have similar amounts of code. Telling the difference comes down to a deep understanding of the project and the project's direction.
To help us sort through these pull requests, we built an agent factory that helps us review every single contribution. Our agent factory is in our Slack, hosted on an xe.dev virtual machine. Every pull request that's opened in GitHub fires a webhook that creates a new thread in our Slack. A review agent first triages and then does an in-depth review. It then gets passed on to testing, where it creates a testing plan for in-depth, real-life testing, not just automated tests. Once we approve the plan, a new VM is spun up, and it goes through a whole series of tests. Once it's done, we can merge it directly within the factory and it goes live.
Half of you are probably looking at this and thinking, amazing, I want to build a factory like this myself. The other half are thinking about the security implications and wondering if this is crazy, reckless, or unsafe. Pull requests, of course, are unsanitized input. Anybody can open a pull request and put things in there. You can't really sanitize a pull request, because I don't want to remove information from it—there are going to be false positives in everything. You can imagine a pull request that's open to harden security to defend against prompt injections; it would trigger any kind of detection. This goes way beyond the people perspective.
