ゼロから NanoClaw へ：40時間の週末プロジェクトが企業向けAI事業になるまで（Changelog Interviews #686）

What's up, friends? Welcome back. This is the changelog. What if the most important, valuable thing you own, your crown jewels, was code you just gave away for free the same weekend that you wrote it? Well, this week I'm talking to Gabriel Cohen, the creator of NanoClaw, about exactly that bet. We discuss why restrictive open source licenses are pointless in a world where agents can rewrite any code base in 12 languages overnight. How he sat down with a cloud code that didn't even know OpenClaw existed and built NanoClaw from a blank slate. The moment Carpathia tweeted and shut down a marketing agency doing hundreds of thousands in ARR. And Gabrielle's vision for a human-centered future where every knowledge worker becomes a manager of hundreds of agents. Heads up, I'm doing a live show with Taylor Otwell at Resend Forward. Check it out at Resend.com forward. And I hope to see you there. A massive thank you to our friends and our partners at Fly.io.

That is the home of changelove.com, your agents in a computer, and that is what they've built. Learn more at Fly.io. Okay, let's do this. Well, friends, this episode is brought to you by our friends at Coder.com, secure environments where developers and agents work in parallel. And I'm joined by Nicky Pike, Field CTO, Forecoder. Nicky, what is a Field CTO? So I get that question a lot, and it's, you know, half the people understand it, half the people don't. So a Field CTO, I describe it very simply as we're DevRel for the C-suite. So we provide a bridge between the customer voice, between the C-suite and the managers and the leadership teams of our customers back into our product. And then we go through and we help enable our teams to have the same message to make sure that the message is correct and that we're building on something that people actually want, not just something that we think they want. OK, so we're taking the laptop away from the developer.

Not really, though. We're putting them in a cloud development environment, a secure environment where they can work with their agents in parallel. These are blessed environments. What's wrong with the laptop? The laptop is the is the trap here. And not only because the fact that it could be stolen, you could lose it, it breaks and you're out of work while you're waiting for a new one. But there's also just the consistency that you got there. We all know developers. Developers are going to be looking for some of the latest and greatest. And if you're not really controlling how they get out there, that's where you get this. It works on my machine. It doesn't work in production. It doesn't work anywhere else because you don't have that consistency. You don't have that ability to really standardize what that environment looks like. And this is a problem not only for new people coming in. You know, the onboarding statement is average, I think, is like four to five weeks for a new employee to really get their local laptops set up and ready to start doing their first type of code. And, you know, the time to first commit is a metric that almost everybody knows. And the reason they can't do that is because there's a lot of tribal knowledge out there. They've got to go talk to other developers. What are we using? Where do we get our dependencies? Are we getting them from public? Are we getting them from private repositories? But there's also the security and the supply chain aspect of this.

When you have local machines out there, look at like the Shai Halud, you know, that virus that went out not long ago. This was a compromise of the NPM public repositories. They went and downloaded things. NPM did what it did. Next thing you know, you're compromised. But when you use something like what we're doing with cloud development environments, then you can mandate and you can put restrictions on there to say, hey, you can only go get your packages from our private repo. Those packages are expected to have been thoroughly vetted. We know that they're clean. Now, does this stop everything like Shai Halud? No. If that compromised package gets into your private repo, you can still have that. But it really reduces the surface area of the attack. And it also reduces the blast area of the compromise should it happen, because if your laptop gets compromised and you have to kill the laptop for whatever reason, that's weeks out of work while you're either fixing that or you're getting a new laptop in. The cloud development environments allows you to kill that, start back up fresh, and you're back and running in five minutes. You don't have to wait all that time. Well, friends, the first step is to go to Coder.com, install Coder, self-hosted environments for your teams to enjoy, to standardize around, and it's open source, so you can try it out today.

Once again, Coder.com. So we're here with Gabrielle Cohen, creator of NanoClaw, one of the many claws. And you might even say from back in the day, ClaudeBot started this all, right? Like it was a pretty interesting time. Wasn't it called ClaudeBot? Wasn't that what it was called initially? It sort of set this all off back in like January, February this time? Yeah, when I found the project, it was called ClaudeBot. and then it became MaltBot for like two days. Right. And then OpenGlo. What do you think about the, I guess, the direction of the name even? Like just getting to the world of claws. Yeah, it's an interesting name.

I don't know. There's something about it that's a little bit playful, maybe a little bit aggressive. but I think with NanoClaw I tried to take it into a more friendly side and I think the name does that a little bit but also our logo this little blue lobster cute guy instead of an angry red guy. Yeah, I know. The red is kind of angry, isn't it? Blue is a bit more color science, right? Like soothing. Aren't most things that are blue kind of soothing? water soothing, right? How that gets associated, something like that? I think so. I think brands that want you to trust them, go with Blue. What do you think about the state we're in with? I guess how drastically things have changed, and at what point

did you get inspired by the work of Peter Steinberg and what was going on there to then create NanoClaw? How did this trail in for you? What's your journey here? So I actually started to play around with OpenClaw in early January. I downloaded it. I set it up. It didn't stick for some reason. And then end of January, I came back to it. I had been messing around with – I actually got a Mac Mini and was just running background claw to code tasks on it. And then, but I was looking for something that gave me a bit more of like ability to schedule tasks in a nicer way and a cleaner way. And then, so I came back to OpenClaw, set it up. I was building at the time an AI native marketing agency. So using agents for all kinds of stuff, content optimization and whatnot. And then I just set it up and gave it access to an Obsidian drive that had files for each of the customers that I was talking with and the customers that I had signed.

And I just set it up there and I said, you are my sales manager and you manage my sales pipeline. And just figure out a system for doing it. And, you know, basically that's it. And then I connected it to a WhatsApp group with myself and my co-founder. and they started to send us morning sales briefings, sales stand-ups each morning and updates and whatnot. And I was like, this is wild. Within a day, it was doing the work of a person, doing it quite well. Interesting. Yeah. And then, I mean, that was working and I was like, wow, okay, there's actually real value here, which was surprising to me because I was like, it's just, I'd been using Cloud Code for a year then and coding agents for a little bit longer than that. And I didn't really initially understand what's actually new here that I didn't have before. And it took a little while. I spent like a week trying to figure it out. But I still have some security issues.

I still have some problems that concern me as I was setting it up and started to use it. And I didn't feel like it was production ready, OpenClaw. And I wanted to build a business with lots of agents running on top of it. So I just sat down and decided to build my own project, which became NanoClaw. What was that process for you where you, I'm not familiar with your full history. You mentioned marketing agency. Help me understand how, and don't take this as a pejorative, but how developer were you prior to this? Were you deep in development? Did you learn on the job? Did you learn as you built NanoClaw? What's your developer journey when it comes to this? Yeah, I was full developer before this. So I studied physics and computer science. By hand, right? You wrote code by hand yourself? I wrote many lines of code with these fingers, yeah. I studied physics and computer science at Tel Aviv University. I didn't learn how to code in university. I just learned how to reverse trees and stuff like that.

But I worked at Wix.com. I was there for seven years and was a front-end developer, full-stack developer, and led a team of developers there. and I so I'd actually stopped doing development for about four years I took off from development when you work I'm sure you've seen this you work as a developer for a while at some point you start managing people and then it stops becoming software development and it just becomes managing people and I got to a point where I felt like anytime I was writing code It was because I was procrastinating from doing something I was supposed to be doing. And it wasn't as much fun anymore. So I took some time off. I spent four years doing public relations, working with tech startups, a lot of cybersecurity, AI, ML, and dev startups, and helping them, really, really technical companies, helping them talk about super in-the-weed stuff

in a way that would be understandable by a wider audience and would resonate and get reporters interested and whatnot. So I spent time doing that and then started to build an AI native marketing agency as a new business, and that's how I got to OpenClaw and then NanoClaw. Yeah, it's a real bummer that that's how the arc was, I suppose. I'm not sure what the arc is now. Do you do software development now? I mean, you're kind of back in the same realm, right? You're sort of managing agents, which are like people, so you end up managing things or entities or what you're going to call them to do the coding work, right? And so you're kind of back in this manager job. Do you feel that, or do you feel like you're still close to the middle? I feel now, I mean, it's a really good question, and I think we're still figuring it out, right, where this is all going. Definitely not at the end point yet. But the way I feel now is not like a manager because I don't have to talk to people about taking their time off and how they're feeling and motivation levels.

I do like to get my agents motivated. I like to be like, great job, guys. We're really on a roll here. And I think there is a little bit of that management thing that works with agents. But it's more my role as a software developer, I feel, is more of an architect. So I'm giving the big vision and the design, and they're implementing it. And I know, I guess for some developers, I don't know how you feel about it. For me, it wasn't so much about the, you know, writing the code, typing out the code. I never got really good with 150 or whatever words per minute. I was always a bit slow with the typing and took time to think about things. And I think where I brought the most value was in figuring out what we can cut out and how we can simplify things and write less code. So I like the role of being an architect rather than typing out code.

Yeah. Yeah. Let's dig into that because I feel like that's what we're all kind of moving towards, right? And for those who don't really have that architect brain or just like the natural tendency to like architect things, that's what I naturally do. I think anybody who's been in a product manager role, anybody who's been in a UX designer type role, front end role, I suppose many developers too, you're problem solving, but are you always architecting? I think a lot of those roles really lean into this architectural kind of feel. I feel like that's what I do a lot. It's like I suggest intent. I suggest not every single detail of what I'm trying to build with an agent, for example. But I end up kind of giving the world I want it to live in. What are some of the things that are true about the world?

What are the things that are untrue about that world? What are the do's and don'ts? And it's kind of like taste. But I think it's more like architect and intent and what should happen. And I think a lot of that stems from understanding user experience or even just workflows and problem solving. I feel like that's the world we're in now is that the majority of folks are building that way. They're becoming an architect versus maybe a manager. I hate being a manager of things. I'd rather architect things. What about you? Yeah, I think there are, I guess, like you're saying, multiple roles in managing agents. I think the baseline is you have to be able to manage them, but then there's the role of the architect, there's the role of the UX engineer and product. And I think you have to have another kind of like to stand on besides just I know how to manage coding agents.

I think you've got to bring something else to it. But it could be, it maybe doesn't have to be the architect. I think, yeah, the agent manager, I mean, we're going to a place where it's like agents managing agents. When you kick off a workflow with Fable 5, in many cases, you give it a very basic direction and it goes off for hours. Oh, my gosh. managing all the agents and orchestrating them. So I do think that the engineering and architecting probably is shifting to, like you're mentioning, I'm architecting the world that this agent lives in and the feedback that it gets and what's true for it and what it knows and sees rather than telling it how to build the software.

and I think that's the next evolution to me when people are talking about loops and building loops and whatnot for me it's not about a while loop, it's about orchestrating or engineering some kind of architecting, some kind of feedback loop that gives the agent signal and information about what to do and what to build Yeah. That's kind of funny. I still haven't perfected, and maybe you have with your work, this idea of loops and this idea of cues. You've heard lots of things with folks suggesting this is the era of cues and loops now. That's what we should focus on, not prompts or prompt engineering, more like context engineering. Do I have enough context to build up so I can just say, go and do it, And that small go-and-do-it phrase actually has so much context behind it. I feel like something I experienced recently was just having one agent talk to another agent

and how that agent's context and its role as a reviewer, maybe a PR, maybe it's a code review, something like that, kind of re-prompts the initial agent that's actually leading most of the work, the one that I'm architecting with, the one that has the majority of the plan's context, and the one that's in charge, so to speak, of the one or many sub-agents. Like that whole loop of not just the context you build up by documenting what you're building or thinking about it and architecting it like that, but that a sub-agent or a side agent can then go into a code review or a pull request review or something like that, which reprompts the main agent. It's like almost a yin and yang in a way where it's the fish eating the fish tail kind of thing, where it's like if you kind of keep this dance going with one prompting another, as long as your context is true with what you were trying to architect, well, it's on mission. You don't need to course correct it really at all. It just goes.

I think that's even more true or maybe more true now with Fable 5 five and this new class of models where they seem to be more capable now of open-ended kind of work where the task isn't very well defined and it requires decisions and judgment. And I think that is starting to become the reality where you can give it maybe more like values and principles of what your preferences are and your tastes and your choices. and then let it reason from those principles and values about how the stuff should be designed. I think it probably will become more important for projects to have those kinds of documents. Like ClaudeMD, I think, is probably going to go away in terms of like use this kind of linting thing or use this pattern when you're writing out functions. And instead it's more like what's the ethos and values and principles

behind how I want to build and what we're trying to do. Yeah. How long did it take you to get to something that was usable? Like, how long did you not sleep? Did your family miss you? Did you stop eating? What did you turn into an AI vampire? Like, this famous or infamous phrase comes out, like, what were the initial nanoclaw days for you when it came to building it? and how did you, I don't want to say this negatively, did you copy ideas from OpenClaw or did you say, you know what, I've got my own ideas. There's some good ideas out there, but I have a plan that I think will work better. How did it begin for you? So firstly, I took five days, roughly, where I had OpenClaw running and I had seen what it could do. And I spent like five days, I was going to work, taking showers, walking the dog,

but all the time in the back of my head I was thinking, like, what is this new thing? Like, what did it unlock? Why is this interesting? Why is it suddenly bringing all this value when it's just running a coding agent? I already had the coding agent. Like, what's the unlock here? And I spent a lot of time thinking about that and then sat down to write the project once I felt like I had a thesis, let's say, about what those things are. And it was like, I don't even know if I remember now, but it was like I need memory, I need a persistent session, I need it to be connected to a browser. I think it turns out browser is probably not that critical. And I need it to be in a messaging app. It's like a big, I think, psychological shift when you're talking within a messaging app instead of in a terminal. and it's just also the availability, it's always there. There was maybe, and then the extensibility, the fact that it could add things, and the schedule tasks, so being able to schedule jobs for itself,

that makes it feel at least proactive. Like it's coming to you to update you about stuff instead of you always going to prompt it. So I had this thesis, and then I did do one of those crazy marathon coding sessions. I sat down Friday night in my sweatpants on the couch and this couch here behind me and basically like melted into the couch for the entire weekend till Sunday night. I think probably about 40 hours of coding. And my wife was like, I haven't seen you like this for like 10 years since you were in university. This is like something wild is going on. But to her credit, she let me go down this rabbit hole and something's going on and left me to it. And then I came out on the other side, so it was Sunday, and I was like, if I don't release this now, I'm going to spend the whole week on this instead of doing my real work, which is building my AI native agency.

So I just said I just got to release it, put it out there. mostly AI generated read me which I got a lot of grief about on Hacker News but I published it and people it took off pretty much immediately I just posted on Hacker News and it started to take off and shot up to like 1,000 2,000 stars within the first day I'd seen projects go on Hacker News and I knew normally they'd shoot up it's like the reverse hockey stick. So they like take off and then they just flatline. But this kind of kept going and it went, you know, 500, 400, 500 stars per day. And it just kept going to 8K, 10K stars. And then a couple, so spent like two weeks back and forth with my co-founder going, should we keep building this AI marketing agency that we built or should we become the Nanoclaw company and going back and forth on it and deciding together that,

okay, let's give Nanoclaw another two days. Let's invest a little bit more in it and kind of kick the count down the road and see where we're at in a few days. And then about two weeks late after the initial launch, Carpathi, Andre Carpathi, did this whole post about claws, his claw post, and half of the post was about Nanoclaw. and how I thought it was mind-blowing or slightly blew his mind. And then it just went to another level. And it was like clear, all right, we got to do this. So we went, called our customers at the AI Native Marketing Agency and said, sorry, guys, we've got to drop you. We've got this new thing. And just shut down. We were ramping up very quickly. We were at a few hundred thousand in ARR and like really good ramp. and we shut it down and created NanoCo as the company building NanoClaw. Wow. You knew right away you would build a business around this. This wasn't by accident.

This was totally what they would call premeditated? No, not at all premeditated. So I built it just to use it for myself. So I put it out, MIT license. I would probably make that decision again if I came to it. But I didn't even think about it because this was just, it wasn't even a thing. I spent two days building it. I was like, there's nothing special here. If I spent two days, anybody else could. So I just put it out and thought, maybe people will find it useful, and maybe they'll contribute to it, and then it will make it better, and I could use it for our own business, get it more robust, more stable. and I thought it would be good for our reputation as an AI native agency to have created a successful AI agent project. So that was my thinking, but it was totally just going to be this side project. I put it out on my personal GitHub user and only moved it to our company's GitHub after it took off.

This was just a weekend project. So you shut down the agency pretty abruptly though, right? Right. NanoCo, you and your co-founder. Did you, I guess there's a lot of context I need to build up to ask this question properly. There's a concern, I suppose, at least I know I have the concern, and I hear other people having similar concerns around open source. And then you mentioned you open source right away as MIT, which is the most liberal open source license. Like, you would actually say that is truly in the spirit of open source. That is open source. Just having the code open, visible, is not obviously open source. It's about a license, a license that gives you permission, unfettered permission to do what you want. And so here's you. You got this, you know, Friday to Sunday 40-hour marathon. You release it on Monday because you're concerned about how you would actually do your job Monday through Friday,

which I totally empathize with because it's so tantalizing when you can just do so much and your ideas just come to life in front of you. It's kind of wild. You said you would consider or do that again with the MIT license. How do you think about or reason about open source in this world now where even if you've written, let's just say you've written something in TypeScript and I want to borrow an ID and I have a Go program. I can easily look at, given with agencies days, just look at what you're doing and graft intent off of that. Not so much take your code or take something like that that would have normally been licensed, intellectual property, et cetera. Even if it's open source, it's still some version of an IP. Even if it's permissively open IP, it's still IP. How do you feel about that decision to go the MIT route? How do you feel about the state of open source?

And is your position currently in any way hindered? And maybe you can't even say yes or no to this because you're already on this road, man. You can't put the cat back in the bag, so to speak, because you've already open sourced and MIT-licensed Nanoclaw. How does that sit with you when it comes to you building a business around a code repository that's fully open? with fully permissive to any degree. How do you feel about that? Yeah, that gets right to the heart of, I think, the difficulty that's going on. Yeah, I think it's not a difficulty for us, surprisingly. And I'll explain why. But it's clear that open source, I've heard people saying open source is dead. I wouldn't necessarily agree with that. I think, though, it needs to evolve, kind of metamorphosize into something else. I don't think open source, the way we knew it before, works anymore or is going to continue.

But I think there is a new way of doing open source, a new model for it. Um, I, yeah, the, the project, I put it out there, um, and people started to use it and teams started to use it, um, and companies started to use it. So there are companies that I know of and I've been in contact with that are building their own internal agent platforms on, on Nanoclaw and using it as infrastructure. There are teams building on it. There are companies who are building products on top of it and providing services with it. And all of that is fully allowed with the MIT license. And I actually am happy about it and endorse it all. And I saw even within a few weeks of launching it, there were these sites popping up like host your own nanoclaw and providing hosted nanoclaws. And I'm fine with that. we're not going after that kind of business.

I think even if you chose a different license today, you choose the most restrictive license, once the code is open source, like you said, you could just tell it to rewrite it in a different language. And people did that with the, I think it was cloud code, source code that leaked, allegedly, or that's what people were saying anyways, it was cloud code, source code, so it leaks. and people posted it on GitHub and then there were all these takedown requests. So then people had AI coding agents just rewrite the entire thing in Python, in Rust, in 12 other languages. And that actually, once you rewrite it in another language, the original license doesn't apply anymore. So you can look at a project and rewrite it and that's fully allowed by licensing. So I think it doesn't really help you to have open source that's restrictively licensed. You might as well just go all the way with MIT license and get maximum reach.

I don't think the model of building an open source project and then trying to monetize your own user base works because it's so easy to host stuff. It's so easy to fork it. I think the new model is the open source project is just about building up a brand, getting a community, getting distribution. So that's the way we're looking at it for Nanoclaw. So we've got people building on Nanoclaw, individuals, businesses. That's all great. Only 1%, probably much less, probably a tenth of a percent of companies are going to build their own internal agent platform. on top of an open source project. Even if they have the engineers in the company who could, in theory, do it, they don't want to take their best four engineers and put them on building an agent platform for marketing and for sales. They want their best four engineers building their own product, their core product.

And we've had those conversations with companies, and they're very clear about that. So what we're focused on is providing exactly that and agents built on top of the Nanocle open source project, but with a lot more going on on top of that, for the 99-plus percent of companies that are not going to build their own internal agent platform. So you can't just put agents in a sandbox and connect it to a messaging app, even if it's a really good sandbox and great orchestration and great project, and roll it out in enterprise in a Fortune 500 company. You need to be connected to identity. You need governance. You need audit. You need to be deployed into the customers, into the company's own cloud environment with retention policies on logs and a whole host of other things. So that's what we're doing. We're providing for them together with services, actually, going back to where we started of AI native services business.

So providing the services of figuring out what they need, what do the agents need to look like? what should the policies be around what they can and can't do, and helping the company, guiding them through the process of rolling out agents that are really powerful and connect to everything like we know about OpenClaw, but controlled, safe, secure, and doing it in a responsible way. I like your view on open source. It's intriguing at least. I want to hear more. And so if I understand correctly, your position is that open source has obviously changed. Even if the license is not permissive, the fact that it's there might as well be permissive. Because anybody who has any sort of ill feeling, whether it's like towards you personally, towards the project, or just like, you know what? I'm going to take what's here and just kind of run with it and build my own. That was never really a customer potentially anyways. Or I never really thought about it like that.

Like it used to be, open source used to be about sharing an idea, getting people together around it. I suppose that's still the same if your view on open source is true, which is it's about building a brand, about building community. And then, but then how do you then say to that community, well, I've been giving you this software for free. I and any other contributors, whether it's with skills, we can talk about it later, or actual code. but I think it's cool to contribute via skills. You were contributing, you were using for free, and now here's a paid product that I want to sell you, or I think gives you value, so therefore, because you accept the value, maybe you'll also accept giving me the exchange of value, which is monetary value. That's how commerce works. That's how capitalism works, if you didn't know that. I'm sure you do. that's not drastically different than the original

basis that I've been kind of operating on around open source but it's uniquely different because it seems like you just have no fear on the exposure of let's just say your crown jewels nanoclaw right you gave away the most important I'm air quoting by the way the most important asset how do you then take that and commercialize that in a way that doesn't hinder you? I guess maybe you haven't gotten there yet, or maybe you have. It doesn't seem so from the outside, but how do you reconcile MIT open source, build a community, build a brand, and then find a way to commercialize on top of that without your crown jewel MIT licensed project sucking the life out of you in the process? We have, so we're commercializing. We have customers, we have paying customers. And I don't know if the same will hold true for every project. I think a claw type of project, personal agent, it's a unique, it's a bit of a unique thing.

It's not a developer tool, right, which most open source projects are. It's mostly tools for developers, platforms for developers, infrastructure for developers. this is something that anybody can use and you don't use it for building software you use it for for your personal stuff and so we've got this big user base we've got tens of thousands of people that have set up their own personal assistant their second brain the minister of foreign affairs of singapore has been very public about being the user of nanoclaw he's described this whole setup and published about it. And many executives at large corporations, large companies, are users and are posting about it on LinkedIn and posting about it on X. And then what's happening is those users, they're seeing a lot of value, like other people have seen from OpenClaw. But for them, being a bit more security conscious or wary, they decided to go with NanoClaw.

They see the value, and they're saying, I want to give this to every person on my team, every person in my organization, so they get the same 2X, 3X boost in productivity that I saw, actually outside of work mostly in my personal life, because they weren't able to bring it into work. They didn't have all the compliance stuff and other things they needed to be able to bring it into the company. But they set it up on their personal email. They see the unlock. They want to bring it into business. and then they started to reach out to us saying, hey, how can I roll this out of my company? And the same thing was happening with individuals on a team, smaller teams who were able to set it up within their own team. This one guy, he's an investor at a VC firm. He set it up for himself. He's using it. And then other people at the firm are coming to him and saying, hey, can you set me up with an agent as well? And he approached us and said, hey, I don't want to be the IT guy for my company now who's helping everybody set up their agents.

I want you guys to do that. So the open source project, the open source user base and community becomes a pipeline for deal flow, but it's not us sort of cannibalizing or monetizing or extracting value from those same people who are using it. If you're using the open source project, I'm not trying to turn that into a paying customer. If you've seen it, you've seen the value, you love it, you like it, now you want help bringing it into your business or your company, and you don't want to do that yourself. If you're using it as an individual user and you want to be the IT guy for the company who builds everyone's agents, go do that as well. I don't want to monetize that either. I think at some point we may start to feel a pull from companies saying, hey, we built our own internal agent platform and we want some form of support or some form of this or that. But for right now, I think the biggest opportunity for us is actually 99% of the world that is not going to use the open source.

Interesting. So is that the kind of business – so while I recognize the commercial opportunity here, and maybe that's just the surface that we're scratching and that's what you can share here now, Is that the business you want to run? Because, I mean, to start out, you began as an engineer, building software, kind of ejected from that, did something different for a bit, came back to it. I'm paraphrasing a lot of your story, so fill in the blanks. And one of your angst was managing people and not architecting software. It seemed like that was, if I'm grokking your story, that's what your angst was. And now here you are running NanoCo, which largely seems support-esque. Like, let me help you set up the thing I made inside your company. And maybe that is architecting. Help me understand what's interesting about the potential future you can forge and clear out with Nanoco. Is it just support? What are the bigger opportunities here? It goes beyond support and it goes beyond the services around the setup.

Each, when you look at a large enterprise, Fortune 500 company, so they need to connect to their identity provider. So they can define rules and policies not only for users but for groups, and those need to match up with the groups they have set up in their IDP. They need to be able to set policies. So they can't just let each individual user decide what their agent can do and can't do. They want to set it up in a controlled way across the organization, access control policies of what each agent can do. So, for example, we're going to let everybody in the company connect their emails. We gonna let everybody agents if people want read their emails search their emails But if the agents want to send an email across the whole company that requires human-in-the-loop approvals, right? And then we set a policy in our organization, agents can't delete emails. You want to keep the information you don't want to delete.

So that's something that you can't do just having the open source project and deploying it for individual users. There's another level on top of that, which is really about governance. And beyond that, there's the process of rolling out agents for an organization. You need to have templates for what kind of agents are we going to have, marketing agents, sales agents, engineering agents. They need to have instructions, skills, policies, tools they're connected to, recurring jobs. You want to give people an agent that's valuable on day one. And so there is software there. There's a platform. And then there's the services around getting it set up and around managing and maintaining it in the long term. But with coding agents, there's a new opportunity here because things that used to be really intensive, labor intensive, and require a lot of human hours of work can now be done by agents and be automated.

So a lot of those services, for example, when we're rolling this out to a company, we're going to roll it out to say start with a small group of 200 people in the company. We want to gather information for them about what their workflows look like, what tools do they use, how do they use those tools so that we can set up the templates, set up the policies. We need to gather a lot of information. So rather than doing human interviews with people or sending them forms to fill out that they're never going to fill out, we put them all in a big group, in a big Slack channel, and then each person gets a DM from an agent, our interview agent, and it starts asking them some questions about what AI tools do you use, how are you using them, and it gathers some information from them. And then based on that information, we're able to come back to executives, leadership in the company and say, here are the templates of agents that we think you should have and here is a reasonable starting point for your policies. Here are the tools we think you should connect them to and you shouldn't connect them to and some more workflows will build.

And then I think fundamentally what we're building is not, what we're doing is not providing a service for a company to deploy their agents within the company and then maintain them over time. What we're building is a factory, an agent factory, and the output of that factory is custom deployments for large enterprises. It does change the calculus quite a bit. I mean, when you were saying about interviewing people and getting into the details, I was thinking, like, gosh, you must be spending a lot of time on site talking to Sally or talking to Bob about their red stapler or whatever, you know. And then here you just go and change it and flip the script and say, let's just put them on a Slack channel and have the agent DM each person who matters and interview them. That's a different thing. Tell me about this agent factory. What are your big ideas here for agent factories? What is the status quo currently and what is the future we're driving towards?

I think it comes back a little bit to the skills thing of contribution and what that really defines what our agent factory looks like. So when I sat down to build NanoClaw, I was really – I'd gone down this rabbit hole of AI native. And like AI changes everything. AI changes how software is built and written. And a lot of the old rules maybe don't apply. And we've got to rethink everything. So I sat down to build it and I thought I'm going to build this as an AI native open source project or AI native software. So part of that was initially when you want to set up NanoClaw, there was no wizard, there was no installer, there wasn't any documentation even for humans of how to set it up. There was just a skill slash setup and you run clawed in the project directory. So clone the project, run clawed in the directory and do slash setup. and then Claude sets it up for you.

And if you wanted to, I shipped it initially just with WhatsApp. And in the readme, it said, hey, I shipped it with WhatsApp because I'm using WhatsApp and this is my agent, but you're welcome to use it. And if you use a different messaging app, then just run Claude and tell Claude to change WhatsApp for another messaging app. That's the way to customize. And I said, don't open PRs for adding Slack and adding Discord. I don't want to have all this bloat in my project. but if you figured out how to make it work for yourself with Slack, your coding agent has figured that out for you, instead of everybody figuring it out from scratch, ask your agent to kind of put together the steps that it did to get Slack working, to rip out WhatsApp, put Slack in instead. Write those up and contribute those and just put it in the format of a skill because why not? You can just run it. So contribute back the information that teaches a different coding agent how to follow that same process and how to customize this project so that it supports now Slack instead of WhatsApp.

So rather, I said rather than features, contribute skills. And we'll be able to keep the code base really small. If it's small, agents can work in it really well. They can one-shot things, and then we'll be able to support everything by having lots of skills. and that I think a lot of people caught a lot of people's attention because that's just something different that is leveraging agents and the new capabilities that AI brings to just do things in a totally different way. Well friends, I'm back with a good friend of mine, Michael Greenwich. Michael, I know that I love WorkOS. Our audience may not know about WorkOS, but what are the challenges developers face starting a new project? Choosing the right tools, choosing the right database, choosing the right auth. Take me there. When a developer starts a new project, the decisions that they make at the very beginning end up having long-lasting consequences.

What language you build in, what platform you build on top of, what database you choose, these are things that are very hard to change later on. So they have major consequences. And especially if they limit your ability to grow and scale, at some point as the product starts to take off, you're going to have to stop developing new product features and go re-architect or rebuild your system. And that might be a killing blow right at the moment you need to accelerate. So these decisions early on are really, really important. And I think that's why developers gravitate towards solutions that are mature, things that they know that will scale, even things that are open source. You're going to pick something like PlanetScale for your database provider, not because it's the cheapest or because it's the most fun to use, but because you know it's going to be a durable provider that you can scale on for years. And WorkWest is like that for auth. At the earliest, earliest days, if you look across all these different services, they kind of look very similar, but at day 1,000 or day 2,000 or day 10,000, you're going to want to have made sure that you pick the platform that could scale with you. And today WorkWest is powering auth

and identity and security and permissions for all of these AI companies, literally the fastest growing companies in the world, like OpenAI and Anthropic, Converser, Perplexity, WorkOS is under the hood there. So I think when people pick WorkOS early on, really what they're doing is trying to pick the defaults to allow them to grow and rapidly scale. And there's no platform other than us that's done that at that same level. Well, friends, the next step is to go to WorkOS.com, sign up today, check it out, free for a million active users. Try it today. There's no excuse not to. It is your default. You should choose it. So do so. WorkOS.com. Once again, WorkOS.com. It's a different world when you think about even where you began with like AI changes everything. And I don't want to like just gloss over that phrase because it really does change everything.

Whenever you think about just the flow of information, like even initially you mentioned that you had Claude set it up, right, slash that up, for example. Whereas in today's world, the setup is largely human-facing, which I think is an interesting choice. You run Bash, and then I believe it's like nanoclaw.sh, if I recall correctly, in the process to setting up nanoclaw. And that's very much a human-facing choice process script. One, it's just a simple bash script. Quite beautiful. You got your, I guess it's a lobster. Is it a lobster with a claw? Is that what everybody's using? It's a lobster, right? A little blue lobster, yeah. A little blue lobster. A little cute little blue lobster. I like that lobster. You know, you got this flash. What I'm trying to say is that flow is not human. or sorry, it's totally human. It's not agent. Although you can eject out of it into an agent,

into Claude helping you. Like in my case, whenever I set it up, it had an issue. Like one of the containers timed out, and thankfully, you know, your script wasn't just like, oh, well, it was more like, seems like something's wrong here. Do you want to have Claude troubleshoot it for you? And so I ejected out of the script into Claude, and it began to troubleshoot. It looked at the logs and turned out I was on a headless Mac where I wasn't looking at the screen and Docker wasn't installed yet. And so as I'm trying to figure out what's going on here, then I'm like, oh, let me actually remote desktop into this headless Mac mini and take a peek at what's going on here. Lo and behold, it's asking me to approve via the GUI, the graphical user interface, to approve Docker being installed or whatever it was. I think the Mac OS was actually stopping the agent from installing Docker because it required that permission.

And so those are all normal things. But that flow is largely human. And it's even weird to even still say that. I mean, it's not quite – it's weird to see it on a podcast, I suppose, but it's not weird to think that in my, like, brain, so my own thoughts. But to say that this is a human flow, not an agent flow, because it is still sort of getting into the world of agents, like, this becoming real. Like, 2026 is the year – I'd say, like, 25 began it, and it was, like, right at the tail end. So I feel like 26 gets to own the year of agents. I could be wrong, but I don't think so. but you get in this position where you're like this is a human flow or this is an agent flow and you start to think about AI native and even how I would interface with a particular software that only has human focused flows, that has no agent flows, so I can't have my agents automated. So much changes whenever you think about this idea that you have AI native ways and that AI

changes everything. When you zoom out from that phrase AI changes everything, how has not just your software development life changed, but how has life changed for you in every way from how you interact with your wife and your family or whatever? Like how has AI changed everything for you? So with the family, you know, we're keeping it pretty human. And I know people are using agents to help them manage things at home. But, you know, my daughter loves Nanoclaw. She's four, and she doesn't really know what it is. But I got lucky, and I chose a cute little lobster as the logo. So she knows the lobster. She loves it. She goes, Nanoclaw. And, you know, when I'm home late, and she's like, why are you coming home late? And I was like, because people want to talk. What do they want to talk about? Nanoclaw. So it's good. I'd recommend if you're going to start a company, choose a cute logo so that your child can connect with it.

But it's changed things really profoundly, I think, in work for a lot of people in personal life, for me more so in professional life. I had a bunch of people join our team. So we're building on a team. We've got 15 people on the team now at Nanoco. Nanoco is our company that's providing Nanoco-type agents for large companies. I have had a lot of people joining the team. juggling a lot of different things. So someone who was joining the team to pick up partnerships for us. And I had been having calls for three months with all kinds of companies and people, and I barely remembered any of it. It's all just this kind of haze. So he came in, and realistically, I needed to spend like two weeks sitting with him and getting him up to speed on everything and onboarding him and digging through call notes and emails to try to find all this information for him.

And instead I said, look, I don't really have the time for this. I sat with him for like 20, 30 minutes to kind of get him up to speed on how I was thinking about stuff as best as I could. And then I put him in a chat with one of my agents. So it's like my second brain that's connected to all the call notes, emails, everything. and I just said, actually the night before, I spent like 45 minutes with the agent saying like, search for this email thread, like just trying to remember what had happened and asking it to go through my calendar and look for stuff. So I pointed it at a lot of the information that I knew was relevant, which would have been maybe a bit difficult for him because he doesn't know what's there. So I said, okay, look at the email threads and then I said, this calendar event, there's no email thread, but you'll find the Slack DM thing and this one, there's a call. and then so it loaded up lots of information into its context and then I put him in the channel with it and I said, hey Andy, this is Asaf. He manages partnerships.

Help him out. And then he just started chatting with it and he's still chatting with it until now, until recently. It's still one of the agents that he works with and he was able to get information about communications, about calls, about meetings that I wouldn't have even been able to provide to him because this is just a blur of things that happened. I barely remember it. And he was able to get exact information with the notes, with transcripts of some conversations. So that is, you know, and the same thing with our head of operations, same thing with go to market. So that's just a totally different process. and work for a lot of people on our team has been primarily managing agents. It's definitely that for developers, but for non-developers as well, for go-to-market, partnerships, operations, people on the team, managing community.

It's just become a process of working with agents. And I think that process is really powerful when you bring them in on day one and you say, here's an agent and they're going to help you with the onboarding, people start to think about work and approaching things in a totally different way. And I think there is that shift of first thinking about how can my agent do this and then first going to an agent and saying, hey, can you do this for me? And then if the agent can't do it, stopping to think, why can't it do it? Do I need to give it access to a new tool? Do I need to give it more information? Wow. Wow. That's wild to hand, if I understand correctly, your agent's named Andy. Is that right? That is. All of my agents are named Andy, yeah. It's like from the guy in the office, Andy from the office. Oh, that makes sense. I was thinking Andy from Toy Story, but okay. Andy from the office is fine, too. I like Andy. Andrew Bernard. He's the best. So you're talking to Andy, and you're like, hey, I've got to onboard somebody.

I'm going to paraphrase what you just shared back, but you basically gave the agent the context and permission and authority to go and research and find and discover and pull back a layer of information. And then you gave it access or you allowed somebody else to talk to Andy on your behalf with that envelope, right, with that authorization envelope. So was there parameters? How do you set those parameters? Is that what you did there where you sort of like primed it, so to speak, and said, hey, Andy, go talk to so-and-so about this. And then they can go and keep talking to them as if they're talking to any given chatbot. But the context or I guess the knowledge base they're pulling from is these email threads and the background story and the details that you don't want to give them access to your inbox. You want to give them access to the information in your inbox. And so Andy did that. Is that right? Is that what happened here? Yeah, that is. So I put the agent in a group where I was in the group and the person who joined the team was in the group and the agent's in the group, so all three of us. So it's a little group chat. I'm not really engaging in this group, but I am there.

and every once in a while I take a quick look and jump in and correct things if they're not accurate. So, for example, in the first day, he was asking about one of our partners and he asked for information and I shared with him like two recordings and I was like, no, there's like 12, sorry, two transcripts or notes from calls. And I was like, no, there were 12 different meetings with this company. You've got to go search via email in my calendar to find all of them. And if you're missing notes from any of them, let me know, and I'll pull them up from somewhere and find them. And so that's – we had a discussion internally about access control, right, data, like who should access what, and are we okay with each of these people accessing the information that we were sharing. And we made a decision to go pretty permissive with access to data,

maybe a little bit, meaning not sharing with them everything, but sharing with them an agent that we knew full and well that the agent may share with them certain information that is suboptimal to be sharing. But we made the decision that in order to be able to move quick, it made sense to be much more free with information than we would have probably been by default not information that's super sensitive customer information or something but just you've got different people on the team and you think a little bit about what each person should have access to for large enterprises that's a non-starter they cannot have people and agents have access to information they shouldn't have. So actually some of the capabilities that we built more recently into Nanoclaw are for solving those problems. So we've added capabilities into Nanoclaw.

You have agent-to-agent communication. So I could define, by default, one Nanoclaw deployment, one instance of Nanoclaw running in a VM can run many different agents, and each of those agents are segregated and isolated in their own sandbox. which is a hardened Docker container, and they don't have any access to the information that other agents have access to, then I can, by default, they can't talk to each other. They just happen to be running in the same box, in the same VM, say the same machine, but they have no visibility into the fact that there are any other agents running in this VM. But you can wire them up and say, this agent can talk to this agent. And then they get injected into their context, the name of an agent that they can talk to, and then they can send messages back and forth. And the orchestration layer of NanoClaw checks if they're supposed to be able to talk to each other. Something that we added recently is adding an approval gate on that action. So I can set a gate, a rule saying that when my agent is talking to someone on my team's agent,

I need to be asked. I get shown the message that it's going to send and I need to approve it. That approval is not a prompt for the agent saying you need to ask for approval. The agent doesn't even know that there's an approval process. It just sends messages back and forth the way it normally does. Outside of the agent's environment, in the orchestration layer, the code, non-agentic, non-AI code that's responsible for taking messages from one agent and pushing it to another agent, that code enforces these policies and shows me what the agent is trying to send, and then I can approve or reject. So with those wirings of which agent can talk to which agent and where there are these approval gates, you can enforce data access policies and control and prevent an agent that has access to really sensitive data from sharing that information with an agent that has access to the Internet. You're getting some weeds there, I'm sure, right? Like how do you manage the itis that you might get from that,

the fatigue you might get from approving or having to review a policy or look at different stuff? I mean, it feels like an onion, like in terms of layers. There's so many layers. And how do you navigate with Nanoclaw? how to deal with such a complex multi-layer kind of scenario like that. That seems hard to put it the most frank way. Totally, yeah. I think the onion analogy is correct. There's so many layers to it. And the way with my architect brain and way of thinking about things, looking at the problem of how do you build in such a complex space where there's so many unknowns, it's moving so quickly, and it's so complicated. And every rock you turn over, it's just this whole new world.

It's like, yeah, ever doing a rock and finding a whole world ecosystem is pretty accurate. Go ahead. Yeah. Yeah. So my approach has been to kind of put these blinders on and say I'm going to tackle one little problem at a time, and I know that there's this bigger, there's another layer, and then I'll add that, but I'll get to that layer once I've unwrapped this layer. And the thing with AI and AI agents is there is so much value to unlock. There's like the way I visualized it as it started to kind of become real for me was like we're walking on the street and there's just piles and piles of like value, right? You think of it however you want, candy, gold, whatever your favorite analogy is, your favorite thing is. And it's just lying there. And in that kind of state world, reality that we're operating in where there's so much value, it's so easy to take an agent and make it do something that used to take lots of time or lots of money,

have an agent do something that used to be a whole product category, and now it's just like a prompt that you give an agent and it runs and it does it for you. So, I mean, my sister is non-technical. She's building NanoClaw to find, she runs all these shopping groups with deals and she's using NanoClaw to find deals for her and send them into the shopping groups with affiliate links and stuff. That used to be a whole SaaS product that someone would pay like 200 bucks a month for. And now it's like agents give them the right prompt and they'll go and do those things for you. So how do you build in this space? You got to focus on not on solving the whole thing, but on solving one piece that's going to unlock some chunk of value. And then once I can do that, it doesn't solve all the use cases, but if I can solve one use case, then I can start giving to people, getting them using it, unlock that value. and then I'll hit the next one and I'll build another piece and the next one I'll build another piece.

So that's how we're building it. So I added agent to agent, realized this doesn't actually work unless you've got the ability to set rules between agents talking with each other, set those rules, we're setting rules. And there are certain workflows where it won't work because permission fatigue. The agent's going to be pinging you every 10 seconds for approval, and you just shut it off. But it does unlock certain workflows where the agent can do a bunch of work and then you put an approval gate at one or two key points and it's able to show you certain contexts you can approve and it carries on. So we haven't unlocked everything, but even if we only unlocked 1% or 5% of workflows or the work that people do, we can start to bring tremendous value and grow from there. It sounds like you might have the same philosophy I have, which is to build the thing you're building, the thing you said you're focused on. Because you said you uncover this rock, you find this ecosystem, you're like, oh, my gosh. Behind this major thing I'm building is another major thing that has five tentacles that I can go down.

I can just get overwhelmed as an individual human with a brain, a human brain that gets cognitively overloaded fairly easily if I let it. Do you think in terms of like, okay, I'm going to build the simplest focused thing I can do right now, not this complex thing, but the most simplest initial version of it, because we can kind of predict this future in a way and get overly complicated. But until we've actually used it, put it into practice and learn like, hey, actually agent to agent is actually pretty cool, except we need policies around which agents can talk to which agents. And then maybe just because Andy can talk to Dave or maybe it should be Jim. Sorry about that. or maybe what's the most famous? Dwight. Maybe it's Andy and Dwight. Maybe Agent Andy can talk to Agent Dwight, but maybe they can't talk about sales data, for example, like sales numbers.

They can talk about potential deals, but they can't talk about the actual numbers because that gets into gray area. The point I'm trying to make is this. I'm getting the details and just fantasizing about this. We're all just great on Andy and Dwight. is when you are focused on a thing you're actually building, do you have the mind of let me build the simplest thing first, play with it and see how it needs to change and fit and grow and morph? Or how do you approach agent-to-agent messaging, for example, and then go from there? Yeah, it is a combination, right? There's certain points where you want to stop and think deeply about what you're trying to build and what's the right way to approach it. when it comes, for example, to policies and rules and enforcement of policies. So we built it quite simply saying, okay, we need to add a policy here. We need to add the ability to gate over here, agent-to-agent communication,

network requests, creating an agent, a new agent, adding new NPM packages into the agent's environment. Those things, we need to have approvals, and we added more and more. And then we got to this point where it's, okay, we've got eight different places where we have these approval flows that are being enforced by lines of code and all kinds of places in the project. And there's a point where now we're working on how do we create enforcement of policies and rules as enforced by the architecture and not enforced by a random line of code there and a random line of code here. And that is, I guess, coming from a need. Like we look at it and we say, okay, there's a need here. We got to tackle that. I think when it comes to the security side, that's where we're being a lot more careful and thoughtful about things. In general, yeah, it's build the smallest version.

So we write our kind of what we're building. You've got the P1, P2, P3, and kind of milestones. And I find myself going to P0, and then I'm doing P00 and P000 and just scoping down. So like what is the absolute minimum thing we can do here that's going to make this work? And then let's start adding on gradually as we go. I think it comes from let's figure out if this is something we need at all. But also it helps to focus the development. It's so easy to write code now, right, or send an agent off to write code. So you can get a lot of code and it just becomes bloat. So scoping it down to the absolute minimum and kind of crafting on little pieces that you need helps control the scope. Agents will just suggest, oh, why don't we add this? Why don't we add that? Let's add a defensive mechanism here and validation here. And I think as architects, we have to keep them focused.

It comes down to attention, right? Human attention, agent attention, and pointing it in the right place. but I think also it's about collecting requirements. So build it, get people using it, and then figure out what do they actually really need. And even just using it yourself, have an agent build a prototype for you, hacky, dirty prototype in a half hour, play around with it, and then feel how does it work? Is this what I really want? So yeah, build the simplest thing, generally, as a general rule, 100%. What are your thoughts on creating an agent in terms of does an agent get, I know you named it Andy, right? So it has an identity in terms of a name. But how much further beyond Andy is, and maybe for Nanoclaw it's one way, and in your mind and how you feel about other agents is different, but help me understand what you think about agent identity. Like what exactly is an agent identity?

Should it get an SSH key? Should it have key-like things so it could be its own thing? Should it, when it commits to your repository or, you know, wherever there needs to be an audit of a log of who did it, it can't be, you know, you everywhere. It's got to be probably, like, your sub-agent, Andy. Like, how do you think about identity and what exactly meant an identity for you and Nanoclaw? I don't I think it's a little bit of a not fully solved problem yet I think it goes yeah I think it goes back to that thing of how can we unlock some value, do something with the primitives that we have knowing that we don't have all the pieces in place yet all the cards haven't been turned over yet So I think what we can do now is actions that require approval, so actions that are sensitive, need to be – so what we have, for example, we have agents that are reviewing code, testing it, and then making a suggestion of this is good to merge, right?

And then we as a team are looking over their suggestions, and this is in our Slack. It's one of our agent factories for reviewing code. We look it over, and it's got this command that is saying, okay, this could be merged. So it writes out a command for us, and then the agent can't actually run it. It doesn't have any credentials in its sandbox, but it writes out the command, and the orchestration part of NanoClaw we've customized so that it gets that command and shows us this card saying approve, reject. and then we have in the credential vault each person in the team's credentials and the orchestration layer when someone clicks approve it looks at who clicked approve and then uses their credentials and that's very intentional the agent can't merge code and we don't want our agent merging code it can do a review, it can give us context, it can surface things and point to our attention that here's what's worth looking at and here's how you can know this is mergeable.

But in the end of the day, the people are the ones who are merging code and it's with our credentials. It gets a bit more complicated when it comes to read actions where you also need audit and logs. In that case, I think you do need to have the human identity but delegated to an agent. and I don't think we have the mechanism fully in place yet for that, but there are some great companies and projects, like one of the ones we partnered with, which is called OneCLI, and they are building that identity for agents so that you can express those kinds of concepts. Yeah. That's interesting to make it on approval. And this is a nanoclop thing. And this is like maybe your thoughts, but also I imagine most of your thoughts you're baking into, your ideas, your DNA, how you think about things are being baked into Nanaclaw.

You said that agents don't merge code, but they can do all the things that surface intent. And you'll hear a bunch of other people say, oh, my gosh, if I had to merge every, you know, if it's a pull request, sure, if it's a merge request, sure, whatever you want to call these things these days, I'm sure it will change soon because maybe GitHub's going down and something else is coming up. I don't mean like going down like negative, but just more like in terms of usage. A lot of people have said with GitHub, man, gosh. It sounds like you want the human in this policy-driven world that is inside a NanoClaw, if I understand correctly, that you don't want an agent to merge the code. You want a human to approve it, and the merge is accredited to that person. and their credential versus the agent who, in quotes, actually did the work. Is that right? Yeah, and I guess you could zoom out a bit and think about it

on more of the abstract or philosophical level of the world that I want to see evolving and developing is one where humans are still at the center and stay at the center. And agents are amplifiers and they amplify what humans can do. So using agents, humans can do 10 times, 100 times, 1,000 times. We're probably reaching a point where there are 10,000 X developers out there who are doing rewrites of massive open source projects in a matter of weeks. and building out successful projects in days. But we want it to be the person who's now 10,000x and not just an agent that brings all this value. But the humans should be at the center. And I don't know necessarily if we have to be.

Maybe you could build things in a way where we remove agents, We remove humans from this process and companies just become a whole bunch of agents. That's not the world that I want to build. I want to try to build things in a way that humans stay at the center. We have our place. We are the ones who are giving the directions and making the important decisions and staying in control. So that's the way we're building it. When we're bringing it to companies, it's the same approach. we're saying we're going to give each person in your team an agent, an assistant that's going to help the person do their work, going to make them more effective, two, three times more effective. And the people in your team need to become managers of agents. That's where the world is going. If you've got 10,000 people in your organization, fast forward two years, you're going to have 100,000 agents in your organization. So every human has to become a manager of agents. And

that's a big transition for people who have never done managerial work before. They have to learn a lot of new skills, like clearly communicating what they want and what their intent is, giving feedback, taking responsibility, reviewing other work of other people, or in this case, other agents. So it's a whole new skill set. And the way we're approaching it is the starting point is give each person an agent where it's one-to-one. They take responsibility for it. They give it feedback. They kind of train it and tell it what they need and what they want. And that's going to get them started on this path where they're then going to manage a second and a third and a fourth and a fifth. And I think organizations that are able to do that process effectively, there's going to be a place and value. All the people who are in the organization who have a lot of tribal knowledge and all this expertise that they've built up over a long time, there will be a place for them and they will be able to bring value fast forward a year, two years.

And they won't need to lay off 90% of their team because the people are going to be able to come along with them into this value generation that agents are creating. Organizations that aren't able to bring the people along, they're going to end up doing mass layoffs. So I think that the responsible, ethical, secure way of doing AI is along that path of thinking how do we bring everyone along with us and don't just focus on the super users and the 10,000 Xers, but make sure that the average person is able to, has a place and is able to bring value in the future. I guess it makes sense too that Nanoclaw is not a developer tool to create more software. It is more of a business-focused tool to, as you said before, amplify humans' output, which makes more sense because when you think about agents and loops, I'm a developer.

I'm actually thinking about how I'm going to help you make more software, right? But everybody else who is not a developer is like, what's software? Like, you know, not really that, but about six months ago, maybe eight months ago, my wife, I'll share a quick aside on this and go back into our real conversation. But we were driving in the car, I think. And I think I said to her and I driving and I think I said to her I forget the exact conversation but the important point is that I was making a remark about Linux powering the Internet And I said something like babe you know people have to know right that Linux is what powers the Internet, right? And she's like, no. No one in the world besides people like you, Adam, know that Linux exists. No one. Your average person who just doesn't know anything about software or software development, And maybe they've heard of it.

They have no idea what it is. And the fact that it runs most of the Internet, a large majority of it, is lost on most people. And I was like, that can't be true. That can't be true. So she goes home and she hops on Facebook, which is the place you talk to most normal folks, Facebook, Instagram. And she puts this post out. And it's one of those banner posts. It's got, I don't know, I guess a banner image and a big text kind of thing. It's not like this little text where it's her prose, like a post might be. It's more like an image. And I think it said something like probing her people, her friend groups, about this subject. And the comments were hilarious that this thing even exists, that Linux exists. Like, what? There's something that powers the Internet? Not a hamster wheel with hamsters running the Internet? Like, there was a bunch of jokes. And so egg on my face, I had no idea that the rest of the world didn't know that Linux runs the Internet. Okay, so that being said, back to NanoClaw, and in its case, the case is largely focused on amplifying business output.

So it makes sense, you know, some of the choices you've made and how you've made them, because it's not a developer tool to make more software. It's a different tool for people to use to amplify. When you think about that, like that kind of installation is uniquely different, maybe not uniquely different, but potentially uniquely different than developer tooling is installed in an enterprise. I just installed Neniclaw on a Mac Mini, and I'm not worried about business continuity. I'm not worried about the databases that it's making because of these agent-to-agent conversations. and this, as you mentioned before, one of several agents. Now, you know, Adam has four or five agents because I work, you know, in accounting or whatever. And the next year I have 100 agents. Like that begins to become like business critical, right? You think business continuity, disaster recovery, like these are all phrases that come up in this world.

How does Nanoclaw fit into that world? Take me through what it might be like to instantiate NanoClaw in an enterprise that you're consulting for and with to build out their agent fleets, et cetera. How does it work? Give me a zoom into that world. So the first thing is, like you're saying, it's business critical. In some ways, the agents become the whole company. It's kind of their workforce. and for any kind of large company, that has to be in their cloud environment, right? In their AWS account or GCP or Azure and starting to speak to some companies now that are even on-prem and they don't want and they can't have any of their data, their employee data, customer data, sensitive data leaving their cloud environment. So we do deployments fully into their cloud environment, into AWS, Bedrock, GCP with Vertex, or you can deploy to Azure.

Connecting, integrating with their IDP, Okta, Entra, whatever they're on. and it needs to be the continuity part. I mean, it is mission critical for the company. So I think the idea that this is going to be sending data externally or living externally, especially when you think about agents building up knowledge and memory, right? So, okay, you're sharing sensitive data with them, but then it's not just a file that can be deleted. That then gets added to all kinds of other files and places where the agent stores information. And you get the itis, like you're saying, of, you know, now everything that agent knows is sort of contaminated with sensitive data. So the whole thing just has to be in the company's environment.

There's also an element of this is so complex that you can't expect companies to look at a super complicated architecture where certain things are running on their cloud and certain things are running hosted and certain things are running somewhere else and expect them to look at that and go, okay, I get through this whole complicated architecture why this actually is safe and secure. So everything running in their account, there's a credential gateway where when employees sign in through SSO to authenticate with Google or other services they use, the credentials get stored in the credential gateway. Agents run in sandboxes. All requests are proxied through the agent gateway. And that's where policies are enforced and credentials are injected. So the agent gateway holds secrets.

The credential gateway holds secrets. It looks at each request and enforces policies of should AC group be injected here based on the policy set? Should this request be allowed through? Should we enforce human approval? In that case, send a message to the messaging app to the user asking for approval. And that gets sent just by the gateway without it going back to the agent. And then there's the data. I mean, the way we're deploying it is keep it really simple. So we're not going, and it goes back to what we were saying earlier, not jumping to Kubernetes and thinking about how do we scale this to 100,000 and a million agents. Maybe we get there, but for now it's just really simple. VMs in the cloud, spin-off EC2 instance. data is stored in EBS volume

encrypted, checkpointed backed up and keeps the architecture really simple. I think just the last point on the architecture I think people have maybe some wrong intuitions about what compute resources running agentic workloads takes. So they think oh it's agents, it's really heavy all this inference and what not but your machine isn't running the inference right? Inference is going to bedrock. Even if you have your own open source models running in GPUs, that's a separate GPU that's doing the inference. It's not just the machine that your agents are running on with their sandboxes. So actually it doesn't take much compute resources. They're mostly doing some, reading some files, writing some files occasionally, mostly doing network requests for inference for tool calls. A lot of time waiting for the LLM. So it's actually very compute, non-compute intensive. So you can run on a relatively small machine, 16 CPUs, 64 gig RAM,

and I've tested this. You can run 200 agents in each one in their own container and you set them off at the exact same instant. Go and do something. Do a research job. And then, yeah, and that's totally fine. They can handle that. And then if you think about staggering the starts, So I have active agents, but they're not starting at the exact same moment. You could probably get to 400 or 500. And then if you think about active users, one machine, small machine, that's probably 1,000, maybe a couple thousand users. So a big machine in the cloud, you know, take the biggest machine you can get standard on AWS, can run tens and tens, maybe 100,000 agents when you're thinking that they're not all active at the same time. Yeah. So I think people's intuition is a little bit off. Latency also isn't a major issue when it comes to agents. You don't need sandboxes that spin up in 12 milliseconds or 32 milliseconds or whatever.

You anyways wait multiple seconds, sometimes minutes, for the agents to do their work. So even an extra half a second or a second of latency. It doesn't matter, yeah. Really, yeah, it doesn't really matter. Yeah. Well, that's interesting. So everything you're doing is built on the open source version of Nanoclaw, or do you have a separate repository that you deploy into enterprises? What's the take there? A separate or same? So it's the same Nanoclaw. There are separate things that are not – it's not a different version of Nanoclaw. It's just separate pieces that you don't have in the open source, things related to connecting with identity providers and audit logs and governance, very enterprise-like things. Like packages type things. Yeah. Extend those packages. Yeah, it's kind of a whole separate service. So we pick up the NanoClaw service, which is just the open source, and then we raise the governance service.

And the two talk to each other. But it is very much a separate service, so it isn't like extending the open source. and then the open source itself is the, Nanoclaw is the open source version. We do need to customize it for different customers based on their needs. And that comes back to the skills approach. So we've really gone all in on this skills approach and we're building custom versions of Nanoclaw for customers. So I guess it's important to say there are tens of thousands of users of Nanoclaw. the project on GitHub has been forked something like 13,000 times. Many, probably most people using it have their own fork. So even if they haven't officially forked it on GitHub, they've cloned it and then pointed it to their own private upstream, their private repo. So there's tens of thousands of forks of Nanoclaw, and then each person is customizing it. And it's a pain in the ass to pull in updates, right?

because upstream is changing and then you want to pull in and you've made all these changes to the cobase, then you've got merge conflicts. So we've said, you know what, if you want to maintain a fork and you want that fork to be maintainable over time and to be able to pull in updates, we're going to do all these things on our side to try to minimize the amount of changes and make sure we ship migrations and keep a good change log that identifies breaking changes. Every breaking change, even if it's not like migration for the database, it will come with some kind of migration for your project. So saying maybe it's a skill, maybe it's a little read me that explains what the change was and what you got to do to maintain it and resolve conflicts. But then also saying if you want to customize the code base and add all kinds of custom functionality, don't just go wild in the code base. Do modular maintainable changes. So what that means is add files, right, that add functionality, and then have small integration points where you kind of create your own little hook in the code where you're integrating, but keep it a really small hook that's just two or three lines of importing function and then wiring it in one specific place.

So by keeping added files, but then for the upstream files, I keep really minimal integration surface that minimizes merge conflicts. And then every new capability you want to add to your project, create a little skill that documents what you added and how you added it. and create that skill should also have with it tests that don't necessarily test the code of the capability, but just test the integration. So you want to write tests for your own code, that's great. But part of the sort of the contract, if you want your fork to be maintainable, have a test for every single integration point. And it's got to be some kind of, sometimes the tests are like proper tests that are kind of testing functionality end to end. Sometimes if it can't be tested end to end, and just have a test that AST looks if something exists in the code, so that if I pull an upstream changes and this thing gets wiped out by an upstream merge conflict,

I've got a test that's going to go red and tell me, hey, that thing got removed, and then I can rerun the skill that explains how I customize it. And then have one meta skill, which we're calling a recipe, that just lists the different skills that are applied to the project and any kind of bigger picture things you did so that you now have documentation of your fork and you've also did it in a way where you probably won't even need to go back to that documentation. Most of the time you can just pull in off-stream changes. If things go really bad and they break, you can always go back to that documentation and recreate your fork. And we're building all these customized versions of NanoClub, not for enterprises in general, but per customer, but following those same principles. So there are tens of thousands of forks out there. We're maintaining dozens, and we want to be maintaining hundreds and eventually maybe thousands of forks for different customers, and that goes back to our factory. There are certain processes you need to do to keep those forks up to date

and to then be able to build them into images and push those images out to customers' accounts. So that's our agent factory that we're building, to build software in this different way that's trying to be a bit more AI native and leverage the full capabilities of agents. That's interesting. How do you keep it? I guess the easiest way to say is how do you keep it all together? But you've got more than you building this. You've got more than you customizing this for enterprises. You have a good philosophy and a good process, it seems. but how the question mark here, I suppose, is the agent. Keeping that agent focused on your architecture and how you described it. Hey, I'm just paraphrasing. We're here working on, you know, customer XYZs, custom NanoClaw. Here's how we do it. How do you keep the agent from not, like, going back to traditional ways? How do you keep them in your world and the way you govern things?

and is that a problem, especially when it leaves your desk or your workstation and it goes to an employee's workstation who's building out an interclaw for you or with you for a client? How do you keep everybody in the loop and do you? Do you actually do it well? I think it's working pretty well so far. Some of it is sharing context with people, so communicating with people and having daily conversations about how to build things and why we're building, what we're building. Reviewing code, I'm looking at code. I know that's a bit taboo in 2026, but I look at code and talk sometimes about what a variable is named if it's something that's really important. It's on a critical path, and we know that that's going to be a hotspot. but I think for agents my perspective is

we need to be spending a big portion of the time maybe it's 50% maybe it's even more of setting up the right environment for the agent to be able to work effectively and that's not a one time setup it's on a continuous basis so rather than just pushing code pushing code, pushing code, invest in the instructions and the context, in the test suites, in the lints, in the hooks, in all the things that keep the agent on that straight and narrow path. And when it comes to a project, when it comes to that philosophy of create the skills, create the recipes, it was an idea that bounced around in my head for weeks and months. And then And eventually, and it's not that long ago, a month, month and a half ago, I said, you know, we're going to go down this path of building for our customers the same way the community is building. So we're really like tying our destiny in with the community.

And if this project isn't working for them, it's not going to work for us. And if it's working for them, it's going to work for us. And part of that process was saying, okay, I have this idea of how you can customize in a way that isn't going to be a pain in the ass to keep updating. and we're going to try to do that ourselves. And let me write this up properly and commit it to the code base and push it out there and link to it, reference it in the cloud.md that's committed with the project so that everybody else is aligned on how to do this and hopefully they start to build in the same way. And that, I think of it almost as like a contract between us as the maintainers of the project and the community saying, here's how we're going to be doing things going forward and we're going to try to make this work. And if you guys want to have some level of commitment from our side to not breaking your fork, then you've got to follow this set of things. But it's kind of a mutual responsibility.

You guys follow this side. We'll do our part to make sure we're developing in the same way. And it seems to be working so far. You can check back in in like six months. Yeah, right. Well, that's cool. So, I mean, it's burgeoning this new movement of skills, recipes, contribution. That's not the way it was for open source. You said that before, that if you're going to contribute, contribute a skill, not code. But this idea of having many forks, customized versions of NanoCloth or enterprise you're building for, you know, as you're saying that, I was just thinking to myself, okay, so you're tethered to the open source version the community uses, and if it's not working for them, it's not working for you, or, you know, there's a symbiosis there that's happening. I think it's kind of interesting. Yeah, I do think about going back to the open source model. I'm trying to think about it in a way where I don't want it to be an extractive relationship.

Like, there's two entities here. There's a project, and it is, you know, legally owned by our company, Nanoco, but it is its own thing. It has a community and it's got a user base and it's got its own identity. And that's a separate thing that stands kind of on its own separate from the company. And then I want the relationship between the two of them to be a symbiotic, mutually beneficial relationship. And I don't want the company and trying intentionally to not build a company in a way where it's extractive and kind of mining this community and the project for the value that's in it. but instead building its own value, but in a way that as the open source project succeeds and the community grows, that benefits NanoCo, the company, by people knowing about it, name recognition, validation, driving people who then say, hey, can you guys help me set this up for my company?

So that kind of inbound funnel. and then on the other side as NanoCo succeeds and we continue to build our team and develop we're going to be able to build the project better maintain it better over time and I think the best open source projects in the long run I wouldn't say best there are great small projects but projects that have made a real impact have longevity have big user bases that continue to succeed and flourish in the long term, they do seem to be connected to a very successful commercial business that is funding it and mutating it. Yeah, I mean, because you've got to fund the future of it, and you're not taking code contributions, right? Is it a rule, a policy, like we do not take code contributions? It isn't really a hard rule. It was kind of worded that way when I initially launched it. It was also like 40 hours of coding.

It was late on Sunday night. I was feeling kind of almost like a little pissed off. I was like, get off my lawn. This is my agent. It said in the read me, I was like, you know, it runs. You can run it, but, like, don't run it as is. That would be weird. It's like, this is my agent. Don't use my agent. Like, fork it and do something with it different. But that's kind of what it said in the beginning. It said no code contributions, just skills. and like, okay, bug fixes, if you see security issue, but no actual source code changes. Now it's become a little bit looser because there are improvements to the code base that benefit everyone, that make it more maintainable, more robust. Not everything is a bug fix. Sometimes it's added capabilities. I have this kind of little equation, which is like Lime's functionality.

So when I'm looking at a contribution, the functionality that it adds times the target market is a super niche. or I would say not functionality, but utility times like target market, how broad it is, divided by lines of code. And that's got to be maximized. So if you're making a really small change and it's bringing a lot of utility for a lot of people, that's awesome. And then you've got to play around with those and try to make sure that you're not adding like 500 lines of code to handle some, Even if it's a bug, right, and you found it and you identified it and reported it and it's reproducible, but if this bug takes 500 lines of code to fix and it's affecting like a tiny, like you and three other people, we're not going to merge that into a code base. You can just fix it on your own fork, and the other three people can also fix it on their forks. Well, friends, I'm here with the CTO of BuildKite,

and one of the most challenging problems of modern era software development is continuous integration and continuous delivery. And so Lachlan Donald, BuildKite CTO, what are you thinking about today's teams, the challenges they face, the speeds at which they're developing new features, new code? It is just overwhelming. How do you all think about that? Such a good question. It's a question everyone's asking right now. All of our big customers are asking us at the minute, like, you know, If we 5 or 10x our throughput this year or 1,000x it, what breaks and when? And, you know, my answer is kind of same as it's been for the past 20 years, which is that the bottleneck is still trying to integrate those code changes in and then deploy them and check they work and then keep them working as you keep throwing more and more code at it. I think a lot of the fundamentals are the same, but we're just 1,000xing the speed of it, and, you know, that changes nearly every variable. Yeah, for sure. Okay, so where does BuildKite thrive?

What particular type of team or enterprise do you thrive in? The area that BuildKite has always thrived in is like this fastest moving tech companies of the world. Like we've been disproportionately successful in that small niche. The kind of Shopify class, Uber class, you know, OpenAI class of folks that have this key problem around iterating really, really fast. And, you know, the thing about all those folks is they all have subtly different needs, subtly different problems. And so we've tended historically towards building like really well engineered Lego blocks that scale like orders of magnitude more than what our nearest competitor does. So, you know, I think that that puts our system in this tension where, you know, you've got to spend some time assembling those building blocks, those Lego blocks to get the thing that you want. But the end result is far and away more performant and scalable and the experience is better than what you get from something that's off the shelf. So I think we've started from a position of really well-engineered logo blocks

and then are kind of working backwards towards kind of creating the thing that scales down to a startup that starts with one person and 10 agents next week. Well, friends, go to buildkite.com. That's buildkite, K-I-T-E dot com. You deserve better CI. Engineer for the frontier we are all facing, trusted by the teams setting the pace. Again, buildkite.com. Once again, buildkite.com. What stops someone from nanoco-ing you? It's open source. Great idea. This is all amazing. Let me just copy not so much your company, but copy your idea around a company to build above the layer of NanoClaw. Like, that's open, right? Anybody can do that, right? That doesn't change anything.

How would you feel about that? Are you like, hey, this is my lane. NanoClaw is our thing. We got funding. We got a mission. We got employees. We got businesses to serve. But, you know, can someone else, could someone else build their own services company, just like you, for the same user base? They can. I feel really good about our position competing against a company that decides to just go take Nanoclaw and go directly down our lane. because we, and it comes back to the brand, like we are Natumplaw, right? We're the company that created it. We're the company that built and maintained it. We're the people who are building and maintaining it. And the legitimacy, the credibility, the trust, that you can't just fork that, right? So that I think is what we gain

and it's not something that we extract, but it is something that we gain from the open source project. The trust, and I think that's huge now. When people realize how central agents are becoming, they're looking at each one of the companies that are providing AI models and agents and whatnot and going, do we trust them in the long term, like deeply? And so I think that's super important. There's the community that's built, the Minister of Foreign Affairs of Singapore using it, and Andre Karpathy kind of tweeting excitedly about it. that creates a lot of validation, a lot of trust. And then also we are building a team of real experts in building agents. So the people who are joining the team, the AI engineers that are joining the team, these have tended to be the people at a company who are like the number one person who's like pushing forward AI adoption in their company,

and they're doing the webinars and the sessions with everybody and the teams and the workshops about like, you know, you got to move off of Copilot and like it's now, you know, Cloud Code's a thing and you got to start using hooks and you got to start using that. And they're like up to date and they're posting about it on X and other places. So that person in the company who then feels like the company isn't moving fast enough for them, those are the people who have joined our team and we're building out this whole team of those people. so I think people can compete and you know I'd recommend not I'd say try to pick a bit of a different lane on top of the Nanoclaw but I feel like we have a really good position we had a head start and I think we still have a really good position but in the end of the day we have to move really fast execute really well in order to continue to continue to succeed I'm really motivated to succeed because I think beyond just like, oh, we've got great agents and they could automate work really well. I think the approach and the philosophy of keeping humans in the center

isn't, I don't think necessarily that things have to turn out that way. I just want them to. So I want to succeed for that reason, to make sure that we can advance the way that we think AI should look in the world and work in the coming years. You ask that question not even as an adversarial question. You know, like someone could be inspired, and there's only so much businesses that you can actually take on, right? Like you've got a finite amount of people to this point. There's a certain amount of bandwidth you can actually control as Nanoco. And the reason why I ask that question is like even me, like I've got people because of who I am and what I do and what I know asking me to help them, right? And I've started a small consultancy, let's just say, and it's really people I know.

It's not like I'm trying to advertise. I'm not advocating people to reach out to me to ask me to solve their problems. It's literally friends of friends that I know personally. They're a neighbor or I know their business or I'm a patron already or whatever it might be where I see they have a problem and I care about them as an individual human, like an individual person in my community. And so that's sort of my litmus on that. And so the reason I ask is, like, I know at least two people that want my help that's going to be like, Adam, can you help me put NanoClaw on my business? And I'm not going to turn into NanoCo, right? I'm not going to stomp on your lawn by any means, but I'm going to start growing similar grass, right, potentially. in my quest to help these folks. Is it my main business? Am I trying to build a capitalized services company? No. I'm probably more in that open source market where I want to leverage the tool you put out there,

free and open source for the world to use, MIT license for all the reasons you did it, and do the same thing you're doing with it, but not at scale. That's why I ask that question because you've got more and more people, maybe even more people in the NanoClaw world that are already users making their own agents, using it themselves, that people are saying, hey, can you give me what you got? Are they going to send them to Nanoco because they're a company? Probably not. Maybe, but unlikely. And you get in this kind of really weird world, as I'm even telling you about this, like this total remix. Like I know the fork idea was invented in 2009 or 2008 when GitHub created itself. and the idea of forking a code base was a brand new invention almost 20 years ago now, like 18 plus years ago now. But here we are talking about you putting out a project used by tens of thousands of folks with humans at the center, MIT, the most permissive way to license an open source project.

You're putting a company on it and you're advocating for essentially, and you're doing it, you're forking your own project for the benefit of the customers you're serving, the clients you're serving. So we're in this really weird world where everything literally now is a remix in some way, shape, or form, right? You're talking about upstream versus downstream, and even me asking you about this potentially non-adversarial approach to how can I actually add benefit to the NanoClaw world by helping my neighbors, essentially like not 20, not 30, not 50, more like three or four, you know, that I'm helping out. How do you feel about that? How do you feel about the fact that that's now reality? Because a while back you spent 40 hours straight going blind, producing code to turn into NanoClaw. I feel great about that. I, I, it makes me happy every time I hear about someone using NanoClaw, building a business on it, providing value, getting value out of it. I think, like I said

earlier, there's so much value just sitting there, heaps and heaps and piles of value. And when I see someone picking some of it up, I don't feel like they're taking it from me. I feel like there's just so much out there and we're all creating value. And I created a project and that created a lot of value, but you're setting up a company with that project, you're then creating even more value. And I set up five companies and I've created more. We're focused on Fortune 500, Fortune 1000, large corporations. They have very specific needs. I think we're really well positioned to provide this for them. And we're providing services, but I started building an AI native marketing agency. So the whole idea is provide what would traditionally be a service, but then do it in a way that's scalable and where you can use agents, automate certain parts of the process. So that's the approach that we're doing with NanoCo as well.

I don't see it as necessarily a services company. I think everything's kind of blurred now. Everything's remixed, so it's not necessarily services or I would say product company. It's an AI-native company. The model is deploy agents in a way that looks like a normal service, but then continue to maintain them over time and charge a monthly subscription for the agents. I think in the longer term I'd love for you to first of all for you to do deployments with Nanoclaw that's awesome, I would love to just on a personal level give advice, help in any way that I can I think as a company I think you'll manage but I'd love to also just hear about it get feedback from you, get input I think if you do deployments with Nanoclaw the community is now stronger because you're a really serious person. You know your stuff, and you're going to see some issues.

You're going to push back some bug fixes. You're going to send me a message at like 3 a.m. going like, hey, dude, this thing isn't working, and you're going to request different capabilities and features. So that's going to make the community stronger. the more people who have built real businesses and real services on top of it, the more I know this is a community that's going to survive and it's going to continue to grow and there's more people in here. And it's not just us with our $12 million in seed funding trying to push this community up a hill, but there's many, many other people in it involved building, creating, and maintaining and invested in it. and then I think that over time we're going to get more and more requests from people who are building on top of Nanoclaw, around Nanoclaw, under Nanoclaw, you know, using Nanoclaw. We're going to get those requests from them to provide some sort of support for them in different ways

and at some point we'll probably do that. It's not the focus at the moment but when that pull become strong enough where we just feel like this is needed, we'll do it. I think that the first step there will probably be bringing Nanoclub to a specific industry. So what you're talking about, but people who are focused on one vertical, so they're doing it for the construction industry or for retail. And that would be people who know that industry really well. So they're really well positioned to build out the agents and the skills and the instructions, the connectors. They know all the different tools and how to use them that the retail industry uses. And they're really well positioned. They also have the network already in that space, and they're connected with all the companies. They're really well positioned to sell to those companies, to support them, to go through

the process with the company of figuring out what exactly their needs are. But then they probably don't want to build their own factory to maintain a whole bunch of these deployments. So I think the model will be they make the sale, they sell to the company, we'll provide to them an easy way to do these deployments and maintain it over time where it's kind of like a multi-tenant type of setup where we can give them access as a partner and they can do really simple deployments for their customers and they probably earn a lot on the front end of the setup fees and then continue to get a share in the long term of the fees for managing and there probably won't be much work on their side for continuing to do a little bit of support and management here and there for like, hey, my agent, you know, retail assistant, it got really dumb and is forgetting things and they'll go and play the agent doctor and like help figure it out and fix it up. But the more infrastructure type of maintenance we'll be able to do for them.

This whole conversation has got me thinking, especially when you talk about agent factories and the nature of this towards business is like, I'm not really sure how to phrase it, but just kind of where I'm camping on it. And so, you know, entertain my idea here is the Linux of, is how I'm thinking of it. Like Linux, Linus Torvalds, back in the day, it was like, you know what, I'm going to put this out there. That was the beginning of open source, essentially, or at least some of the earliest days of open source. And, you know, people were like, wow, would you put that out there for free and anybody could use it? Well, for the same reasons that you embody, which is like I want the world to use it. I want the world to get benefit from it. I don't care who remixes it. I'm remixing it myself. And, you know, that's largely kind of how Linux became Linux. And now we have slews and slews of distributions. and the fact that Linux exists, NanoClaw can exist because you're built on containers, Linux containers.

You may, on a Mac, install Docker, but that Docker container is running some version of a Linux distribution. It could be Alpine. I don't know what you've chosen. I didn't go into the lines of code and you can share it here, but you've chosen Linux and Linux containers because you can spawn those easily. And like, thankfully, I don't know if this news is a big deal to you or not, and maybe it changes for you, is Apple containers. And the container command line tool that now available on any given you know N Apple Silicon Mac which I think is just amazing It like WSL for Windows has now come to Apple and come to Mac OS And I tell you what the audience may see me there on YouTube but they can see me man I am smiling about that, right? The fact that we now have – sure, we've always had Linux containers via Docker, but Docker's had some checkered past with rug-polling, licensing.

Sure, they're a for-profit company. I get it. You've got to make money. nothing against them whatsoever with that, but they've had some checkered past. And having Apple support containers natively has got to be exciting. So I'll get off my soapbox to say that I'm really curious what you think about the Linux of. You've got OpenClaw, you've got NanoClaw, and maybe they're both claws, but they're not the same claw. They're cut from similar cloths. Gosh, so many puns here. I'm sorry about that. how do you feel about this idea of like is NanoClaw the Linux of agents for business like have you put some thought into that how do you feel about Apple containers how do you feel about being built on Linux take us into that thought I'll start with Docker I love Docker they have invested in NanoCo So they invested in our seed round.

What? Full disclosure. I didn't know that. Yeah. So you're not a hater. You're a lover then. Yeah. A big fan of Docker and especially what they're doing recently with their sandboxes, which they're building for running agents and whatnot. Right. So, yeah, we had great investors in the seed round for sale, invested a Docker, a Hugging Face CEO, Clem, and he's part of the round. So Docker, you know, initially what's funny is that Nanoclaw actually ran initially on Apple containers. So when I launched the project, it was WhatsApp baked in and Apple containers baked in just because I bought a Mac Mini and I had a MacBook and I had been meaning to check out Apple containers. And then I was like, I'm building this. I need containers. Let's give it a try. and I launched it knowing that most people probably want Docker containers. But in the readme part of the angry notes in the readme,

it was also like it runs on Apple containers. Why? Because I thought it would be cool. What about supporting Docker containers? It was like just fork it and change it to Docker containers and I won't accept a contribution of supporting Docker containers alongside. So it was very like, but the thing was after, you know, a few weeks, there were thousands and thousands of people using it. And everybody's, most people are changing it from Apple containers to Docker containers. And there was a certain point where I had to say, okay, this isn't my personal project anymore. This is actually, there's a community here and I need to be a bit more, you know, responsible and, you know, to that. and the default, the de facto container is Docker containers. It's what everybody uses. Everybody's run for many years. It works everywhere. So I moved it over to Docker containers. They're now building Docker sandboxes. They've got AI governance, a great product there,

and we're integrated with their sandbox as well, which is like a micro VM with containers inside. So, and yeah, I didn't have to, I don't have a contractual obligation to promote them, but I do like them. In terms of the Linux, yeah, I totally see it. So my brother-in-law is actually a rabbi, and he has a group of rabbis that have their own fork of Nanoclaw, and they changed the logo from a lobster to some other animal because lobsters aren't kosher. And part of their fork, their distro of Nanoclaw, is that it doesn't, like you do scheduled tasks that run, you know, every day at a certain time. So it runs those tasks, but then it won't run them between Friday night and Saturday night because that's the Jewish Shabbat where people don't work.

So that's kind of like Sunday when people go to church. So they created their own flavor of NanoClaw. The only reason why I know about that fork is because my brother-in-law happens to be using it, and he didn't create it, right? So there's probably hundreds, maybe more of these forks where there's a little tiny community that's gathered around the fork and is building their own flavor of NanoClaw. And so I totally see it, Linux for sure. Yeah. And that, I think, is the future of one of the pieces of the future of open source projects where it becomes distributed. So it isn't just one project. It's a whole bunch of forks, and each one can have their own community. And if you do it right, hopefully the forks can benefit the upstream, the main project, and the main project can push updates out to the forks as well. Yeah, that's really wild. Yeah, because, I mean, this is your world more than this. I mean, it's our world, but this is really like your world where you're building an agent factory.

I'm using agents to build a factory. I'm not building an agent factory. And I think most of us are. Any of us who are building software are sort of like building software to build software better, which is the whole AI changes everything we talked about before and AI native. So you start to question, okay, well, I can't use this because my agent has challenges with it. Or this isn't really agent friendly. This can be far more simple, whatever, for any of the reasons. Do you feel like, you know, in the Claw world, do you feel like OpenClaw is the Linux of agents? Do you feel like NanoClaw could be the Linux of agents? Like, what are your feels on something? You're smaller than OpenClaw, obviously. Maybe I'm wrong, but I think you probably are in terms of, like, especially lines of code. or super small in comparison, but you're kind of like not laser-focused on the same user base,

the same trajectory while doing very similar things and being conflated just by the nature of using the word claw, right? You chose to use the word claw because there was some brand equity to leverage there. How do you feel about OpenClaw, NanoClaw, Linux of, well, is it a winner-takes-all kind of thing, or is it you're all just flavors of the claw? I think it's pretty conclusive now that it's not winner-take-all. If you look at, for example, Hermes, that project now has like 200,000 stars, massively successful. I think if you want evolving agents, it's changing all the time, great project. If you want an agent that just is a bit more stable, reliable, I think Nanoclaw is a bit better in that front. Open Claw, you know, we all kind of owe the whole Claw community. We owe, you know, a debt of gratitude towards Open Claw and Peter who created it

because, you know, it did show what was possible. I think, you know, my kind of value system wouldn't allow me to create a project in that way of just putting aside initially security and safety concerns and just going wild with let's connect everything and see what happens. But maybe it did require that in order to get to that point. Maybe someone had to go and say, okay, we're going to put all the security, safety, software quality, put all that on the side. Let's just see what we can do. And maybe that's part of kind of how you build now with AI. for me that my my value system wouldn't you know wouldn't allow me to do that i had to think about how do i do this safely how do i do this in a secure way um but i think there there's definitely space for many i think for businesses i think nanoclaw is really well positioned to be to be the solution and there's space for a lot of companies to take clause to

businesses and to build all kinds of products on top, we're positioned really well to take effort to the largest companies. And with all those sort of philosophical stuff about wanting to just share and let everybody build on it and all that, in the end of the day, I'm not building a nonprofit. We're trying to build a very large, successful company. It's relatively small, so that's sort of the nano company. It's like an AI native company that's small for what it's doing, but in absolute terms, I think we're going to have to grow. And, yeah, just to close the loop on the OpenClaw and kind of the inspiration from it. So I looked at the code base initially of OpenClaw. I'd seen some security issues when I was setting it up, and I thought, okay, it's cool, I get the value, I want to build something that gives me that same value without the security issues.

And then I went and looked at the code base and I saw how big it was and how messy it was. And I was like, I'm not going to spend now days and days trying to sift through this code base and understand it and figure out how it works. And I don't think anybody really understands it and has sifted through it and knows how it works. It's just kind of this organic, wild thing that's evolved super quickly and became 500,000 lines of code within a matter of weeks. So I said, you know what, I'm going to start from scratch and just start with a coding agent, with Cloud Code, and prototyping with it and iterating and brainstorming and architecting together, and just start from a set of capabilities. This is what I want. And this is January. So Claude's knowledge cutoff in January was like maybe June or July of 2025, so pre-OpenClaw. So it means that Claude didn't know, Claude Code that I was coding with, my coding partner, didn't know that OpenClaw existed when we're coding.

And I didn't tell it that it existed. I didn't say there's this project called OpenClaw and I'm trying to build a new version of it. I just said I want to connect this thing to my messaging app. I want to have scheduled tasks. I want to have a persistent session. and critically I want to run it in containers rather than just running it bare metal and my Cloud Code in that coding session didn't know that OpenCloud existed it was just starting from a blank slate and so built it bit by bit it was like 500 lines of code before adding containerization and then with containerization it's like 2,000 lines of code today it's quite a bit bigger with all the approval policies and a lot of the other capabilities It also will be support now Codex and OpenCode, and you can run it with Olama and local models and whatnot. And now support like 15, 20 maybe messaging apps, so Slack, Teams, Discord, Telegram, you name it.

But everything's kind of modular. but yeah it evolved quite organically and it's you know become its own thing and and claws become a category and you know i'm happy to be part of that category yeah even as you're describing that category um because i'm not as steeped as you are in the you know this claw does that and that claw does this you would use nano claw in these ways and you would use open claw in those ways you know Or if you want this, then you would use that. I feel like there needs to be like a Claw matrix of sorts. You know, that would just be helpful to anybody. Like if Claw is the agent OS, the Linux of agents, let's just say, like the Claw, right? And you're a flavor. Let's just say Claw is Linux, you know, in a comparison here. And NanoClaw is like Ubuntu. Or maybe OpenClaw is more like Ubuntu. and then the claw is more like, I don't know, a different flavor.

I'm trying to like – I use like three Linuxes, maybe four. I know them all, but like I'm familiar with Debian, Ubuntu, Fedora, others. I'm trying to like do a great job here, but I'm not, obviously. But that's pretty interesting to me. is that the claw is kind of synonymous with Linux and the various distros, Nano, Open, Hermes. While it's not a Hermes claw, it still is. What is Hermes? It's a god? I think it's a god and a Greek god, right? You've all kind of operated around this claw movement and created flavors and distros that fit certain needs. You would use Debian if you got this desire, and if you really want to torture yourself, you know, you would use Nix or something else, you know, if you really want to go to the, like the Uber Linux nerd way, like I don't install packages, I compile packages, whatever it might be, right? You know what I mean?

Like that's kind of interesting to think about. And I think the claw movement is very much so the Linux for agents. Yeah. So, I mean, I guess, so we haven't shipped the binary yet. So we're, it's, It's just everybody's running it from source, so maybe we are, I don't know, maybe we're the Knicks. Yeah, maybe so. I mean, do you need to ship a binary? I suppose your TypeScript and BUN, right, so you could ship a binary, right? Well, so it depends. The orchestration layer is TypeScript, not BUN. It's just TypeScript. Okay. But what runs in the container, so the agent's environment, is TypeScript Bun. Yeah. So it's kind of two separate runtimes. It's two projects kind of. At some point, we probably need to split it up more cleanly as like monorepo with two separate projects in it.

But, yeah, there's the orchestration layer that handles routing of messages and spinning up and down the containers because they're not all up at the same, you know, all the time. They kind of spin up and then the agents idle, they go down. Handling the approvals, handling scheduled jobs, sending all of that, that's all in that orchestration layer. And then the agent's environment is just like the agent running in there, messages being pushed into it, and they talk to each other through these two databases where the orchestration layer pushes information into a SQLite database, just pushes messages in, and then the agent in its environment has a polling loop and pulls messages and sticks it into the agent. So, yeah, so it's – I think, yeah, I don't know where I was going with that. I suppose even SQLite 2 doesn't really have permissions, so you don't have to worry about like an ORM or access, right? You just open the file and read it, right?

And so for two different systems to – You don't really want both to write to it. That would be kind of bad. You can certainly wall it, but it still has some challenges with writes. So you probably should have one writer and one reader, which is what you're seeing. You know, the agent orchestration part of it is reading, while the orchestrator that's doing all the Linux containers is writing to the database. That totally makes sense. So it's actually, yeah, it's exactly right. Is it reverse? It's two databases for that reason. So it's each agent session has two databases. So one, the host, the orchestration part is writing and the agent is reading. And the second one, the agent is writing and the orchestration is reading. And yeah, it uses a wall journal with like timeout. And it's complicated because the agent is running in a container. So these are totally separate processes. and normal mode of rewrite doesn't work.

And, you know, when I was trying out that mechanism, because initially when I built Nanoclaw, there were like a whole bunch of different queues. And there was like a queue for messages coming in and then a queue inside the container and a queue for tasks. And it just got really complicated to do anything. and then I thought about this thing of like, what if we had this one shared database and then that's kind of all the queues is just the one database. Like a message comes and I stick it in that database and then the agent pulls it from there and that's just everybody's one place. And then I actually did a lot of profiling of running lots of reads and writes and stress testing and trying out all the different ways of it working and then settled on two databases, one writer, one reader, and stress tested that and verified that you could get to, like, insane, you know, 10,000 whatever operations and, you know, bursts and whatever, and you don't get corruption.

But with all the other modes that I tried, you get corruptions at some frequency where it's just like, yeah. Well, the beautiful thing is you've chosen, again, back to simplicity, right? You chose SQLite. You know, that you couldn't get more simple than SQLite, and you resisted probably vectorization in a database like PG Vector or Postgres or MySQL. You just avoided all that. I feel like almost everything I'm building is still running SQLite. Like, there hasn't been a reason to go to a real database. And I say that with a tongue-in-cheek smirk on my face because SQLite is awesome. Have you been considered, and we're getting close on time, but now we're into some technical bits, and I'm curious. Have you considered Terso and the reasons why they've decided to rewrite SQLite in Rust?

Are you familiar with Terso? Is this new to you? Yeah, it's new to me. So, yeah, tell me about it. It says it's a rewrite in Rust. Let me see. Terso. Okay. Terso.tech. What is Terso? Terso is an open source SQLite compatible database written in Rust that lets developers create millions of small file-based databases for AI agents, multi-tenant SaaS applications, and edge workloads. So a lot of what I'm familiar with, Glover is the CEO there for Terso. We've had him on the podcast before. The biggest challenge I think that they posed with betting on and leaning on SQLite, and I could be wrong. This is about a year back. This conversation, I'm even paraphrasing from my own memory, was that you couldn't call SQLite truly – gosh, somebody's going to get mad at this – truly open source because the tests aren't open source.

Man, and this is like the biggest issue with open source. It's like every, you know, CVE has to be open, every this or that has to be in the open. I say no to that, right? I think open source, and we're kind of getting back to some degree potentially in philosophy here, is that I'm giving you an artifact, a product you can use freely. It doesn't mean that you get access to the back channels. It doesn't mean you get access to this or that. So I could be disagreeing with Terso on these fronts here, and maybe I'm even wrong with where their initial inception came from. But they wanted to make it faster. They wanted to write it in Rust. They wanted to leverage the SQLite kind of needs and be compatible. Man, I'm so due for a refresh with Glover on Terso and why they made it. But this has sort of been in my back pocket, as I'm similar to you, a very happy SQLite user. I'm not trying to make my database even more complex because I'm trying to keep things simple until they have to be complex.

And while Terso is adjacent to that simplicity, it is open source. It is SQL-compatible, but it is not SQL-like. Now, they have LibSQL, which is like the lower-level REST primitive that they built Terso on top of, and they have funding in the cloud, and so they have their own inertia, but I have yet to convince an agent that, and like you, I'm tantalized by the tech out there. And I'm like, I kind of just want to play with Terso, please, agent. Will you just say yes this one time to allow us to go off the beaten SQLite path and try Terso? And so far, crickets, they don't want to do it. They're like, nah, man, that's stupid. So I don't know. yeah I wonder if everything is just going to become Rust when it comes to agents at some point there's the Bun is now I think they released a version

or about to release and I know there's rewrites of Chrome and Rust and I'll check out Terso I think with agents I think there's the I try to let them stay in their lane on the path they want to be on I spent like six months deleting these ridiculous comments that agents were putting in the code and then at some point I just said you know what if you guys want to put weird comments put weird comments maybe it does something for you I don't know so I stopped fighting it that's for sure right? Yeah. On the read and the write, on the initial inference, and then the even timing, I think about that. It's less about the messiness and more about wow, you just wasted an extra minute on this turn and way more tokens than necessary to put comments I don't care about.

Maybe you care about them, but whatever. I feel like that. But it's like our, then we have to waste cycles, our brain cycles deleting them and fighting them consistently to keep deleting them. I just gave up. Me too. And I think, you know, maybe they know something. Like maybe it helps them when they're coming back to that code, gives them a bit of context. Some sprinkles, man. Like I don't know what they're commenting in yours, but I know in mine they're commenting governance. They're commenting spec 0001 or spec 0020, for example. Like that's the one that governs this function, for example. or this is actually from bug 0001 or whatever number bug is in there. So I'm kind of revealing some implementation details into my frameworks, but it's called AgentFlow, and AgentFlow is how I build everything, and it governs all my governing.

And without AgentFlow, I'd be lost. My projects would be lost. Every project uses AgentFlow. AgentFlow has become a hive mind. It's absolutely insane. But it's all about coordination and stuff like that. So my comments tend to be not like, oh, I like this, and here's some random agent thought. It's more like I'm putting this here because this reference goes back to the spec that governs this piece of code. Or we hit this issue and it caused this code review, which caused this bug report, which caused this PEP, this project enhancement proposal that's governed by this spec, you know, for example. And so you kind of have this trail of issue, bug, code review, agent, work, PEP, governing spec, right? This whole sort of audit trail of why does this exist, which is a hard thing for people to, you know, in the Vibe code world, right, is to, like, scrutinize why does this code exist? Because I was crazy three months ago.

I spent 40 hours on a weekend or on a Friday on my couch. To the opposite of that, which is, well, SPEC governed it, PEP implemented it, and there was a bug report against it in the code review from two agents. And then a pull request. So all this trail weaves back to intent. It weaves back to context. And so when an agent picks that up later on, they're like, totally know where I'm at. If I have access to all that world, they just painted in this comment. Well, now it gets a heck of a lot easier to grok why this code exists. And for me to delete it easily or augment it because our future has changed, whatever it might be. So I feel like, yeah, same thing with you. I'm like, comment away, whatever. I don't care anymore. Do what you got to do. Just make it awesome. Agent Flow sounds awesome, and people want Agent Flow. So I think they're out there. We'll have to talk. We'll have to talk. I need some help. I need some help.

I need a friend to say, just do it, Adam. Just do it. It's about packaging. That's probably the one I'm so close to. I'll have to circle back with you because there's so much you're doing with Nano Club that I'm just enamored by and we're in similar worlds. Like if you put agent flow on top of, you know, I'm not sure if you would call it a harness or not, but maybe something, right? If you put agent flow into Nanoclaw, like the world would just sing, you know? Actually, if you put agent flow in most things, it would just sing. but it's largely opinionated, largely focused on software development. NanoClaw is not focused on software development. You know, could AgentFlow fit anywhere? Actually, it could, but I think a lot of it is kind of geared towards and governed towards software development. So maybe I can pull back a layer and make it a little bit more, a little less focused on software only because it's really a way of thinking for me.

I couldn't imagine writing software without it. Like I would be personally totally lost. Like the very first thing that me and an agent do is we do research, and that entire research project is documented. It's not authoritative. It's not governing. It's all ideas. It's all possibility. It's all what's out there. It's not prescriptive. It's descriptive. What does the world look like? What is the world we're trying to build? And it's all questions and answers, but not this is what we're doing. It's this is what we could do. And so that is an artifact that gives me a chance to explore and unfettered and drop every transcript from me and an agent or an agent to agent into there for it to then take and say, okay, from this source of facts, not truth of our software, what is our extraction from that that makes this feature or that feature or the blanket statement for why this piece of code should exist or this software should exist? Like, if I didn't have that to operate from, I really wouldn't know how to do it.

And it all comes from the way I think, you know, the way I think about how I even jot down ideas and stuff like that. Like, agent flow is very much a manifestation of how I think. And so it's like Adam's brain as an operating system. It's a great software. That sounds awesome. Yeah, that sounds awesome. and it matches how we're doing software development now which is anything that's in any way interesting it starts with an exploration phase where you ask the questions about what's going on here what are the questions that need to be answered and what are the places where decisions need to be made and what are the choices that could be made what are the trade-offs what are the different possible paths and you go through that whole exploration and then we create an artifact which is an HTML artifact that has diagrams and visualizations and takes it and tries to not like an eight-page thing necessarily,

but try to make it pretty condensed, but just surface, put into attention the parts that are worth having attention put on them, which is the decision points or the key decision points and what do you need to know about this. And then we share it with the team and get some other people to look at it and chat about it, and then you go off. And that's really the whole thing after that. You just send off an agent to go and build what you decided to get and needs to be built. But that's, I think, the core of the architect's work now. Leaving things stuck in chat or Telegram or WhatsApp or wherever, that's not where that should live. That's ephemeral. That should be – you should feel unencumbered to have a deep conversation. but knowing that you have a system behind you that extracts all the good stuff into the system that allows you to create artifacts that share. It could be shared with an agent. It could be shared with coworkers. It could be shared with the client.

It could be shared with whomever really makes the most sense. But having that, I guess, that conversation, and you said something earlier too with the psychological change of going from terminal, and especially a developer gets this, like non-developers won't get this, but going from a terminal to a chat app of sorts. You feel like you're literally talking to something versus trying to command the world. Like we've all been trained as developers, when I'm in the command line, I am making, I am, you know, I don't know, doing things that are different than like talking to a human or talking to something. It's not a talking, it's an action. You're sort of like making things happen. It's a whole different scenario there. but if everything is locked in chat and you don't have this artifact system that actually has a system that connects to each other, that has governance, that has not so much policy but taste and sense, then your stuff is just stuck in chat and that's not where it's meant to be.

But when you have agents upon agents for every individual human and you've got so many humans doing work, gosh, you've got to find a system to get out of that to then create a memory system and all these other things. Like, that's, to me, I think, is where I'm most, what's the right way to say it? Like, the most excited, I suppose, and that's probably even not the best word, is I'm just so excited about what's possible there. Because you take this corpus, you take 17, 20, 30, 50 revolutions of that, let's do research, let's create that HTML artifact in your world, Let's go then share that with people. You do that over years even, and you've got this corpus of information that now is such an interesting substrate for the knowledge base of an organization, which is why when you deploy a nanoclaw, you've got to be pretty particular about it. Because as this database grows, I don't know if you're keeping one SQLite database in prod or not, but you've got to have some sort of plan, right?

and you've got so much growing and so much that can extract from that that it's this AI native world we're in and marching towards and running towards in lots of cases gets really, really interesting. 100%. I mean, I think a lot of people talk about their main assistant as the second brain. It just builds up this information. It's the LLM wiki patterns. Every bit of information you feed it, it goes into this type of Wikipedia. You share with it some brain dump, and it creates a Wikipedia article of what you share with links to other articles that are relevant. And then over time, it builds up all these articles and interconnected articles, and it becomes this kind of graph. But really, you can think of it as a Wikipedia of you and your projects and your world and your relationships and the people you work with. and that's this sort of second brain that knows what you know and knows your context.

And then in a company, you end up with many of those second brains. Each person in the company has got that second brain with all their information and context. And then you get the company's brain, which is this centralized place that some of these agents are able to push updates to and gather sort of the more general information that everybody needs to know. And, I mean, it's super interesting. You know, we've seen someone who went on, took maternity leave and gave their agent to someone else to continue their project. And it's just like a project that would have had this whole period of off-boarding and onboarding, and it was just zero downtime, just full continuity. Yeah. I'm really interested in that. And like just being able to have to swap out even a model. Let's just say I've hit my Fable 5 limit. Oh, my gosh, my world's collapsed.

No. While Codex 5.5 or as of today, 5.6 may not be quite Fable 5, at least I'm not down. And my context isn't trapped in Fable 5. That was my reasoning. maybe even my higher powered reasoning but I swapped the model out the context is still there the mission still continues nothing really changes that's where I'm really interested because even with even with chat history I spent a lot of time with anxiety of like oh my gosh my stuff is all stuck in these chat threads that gets compacted that gets erased that's why I got into this I've got to extract everything but then it's too much but I'm really interested in that world where we can be where you can send Sally on vacation happily. She goes totally on the beach drinking Mai Tais, no stress whatsoever. Meanwhile, back at the ranch or back at the enterprise would be the better way to say that. Work continues because the agent keeps the context.

And Sally left enough breadcrumbs in her agent, in her context loops, in her second brain to allow somebody to borrow with policy and with permissions what's necessary to keep that enterprise initiative going. That to me is like the ultimate business continuity satisfaction if I was like CEO or investor somewhere. Like that's the world I want to live in. As a knowledge worker, as a business owner, as an entrepreneur, that's what I want in the world. Yeah, yeah. And I think it's just, you know, the work, working with agents, right, it just doesn't feel like work. right? It's just like, they're going off. Yeah. They're doing things for you, you know? And, and it's, it's really empowering for people. I think, you know, we're, we're used to building, right? We're used to coming up with ideas and then you just get in front of a keyboard and make that happen. For, for most people, they don't, you know, they, they don't, uh, they

haven't experienced that of just thinking things up and making it happen. So I think this is a huge unlock and it's just it's really really really profound for for people who who you know get started with building with agents well friends listening to this podcast go to nano co or nano co dot ai and uh hire the the folks that made nano claw to build it for your enterprise or to fork it for your enterprise or customize it for your enterprise and for everyone else go to nano claw dot dev free as much as it possibly could be and open source MIT licensed. Thank you so much for being courageous enough to share that MIT and then still feel even after the fact no regrets. You've given me a new facet to consider around open source. I've been pretty sad. I wouldn't say like sad necessarily.

just bummed. Maybe that's a version of sad, but like some other adjective that describes sadness that isn't quite crying tears. I'm not crying tears, not yet at least, but I was really feeling down about open source and like the reasons to do it and how, you know, there's just so much threat, even from a security threat. Like you got tried and true open source out there that's now getting inundated with security issues because their code is open, right? And you got all sorts of like inbound threats to anybody who makes an open source project, whether it's commercialized or non-commercialized. And I was just feeling pretty down about it, but I like your lens. I think I like your altruistic tendencies when it comes to why you chose to do it initially and then why you haven't regretted it as part of and actually weaved it into the fabric of your business plan to use it as a benefit, not an Achilles heel. In any way, shape, or form. That's so cool. So friends go to those two places. Gabrielle, thank you so much for coming on the pod, man,

and sharing just your agent thinking, man, your thoughts. I really appreciate it. I enjoyed this conversation so much. Appreciate you. Thank you. Thank you. Okay, this is the end. You made it. You've arrived. This is the show where you can come for great, deep conversations about the changing environments we're all in, The embracing of this agent culture, the agentic world we're all living in, the replatforming of our entire industry as we speak. I'm both terrified and exhilarated at the exact same time. I don't know about you. Maybe that's true for you, too. You tell me. And the easy way to do that is to go to changelog.com slash community. It is free to join. Zulip is where it's at. Maybe changing soon. Who knows? Zulip has some changes. I'm still evaluating it. But for now, Zulip is our home, and you can chat with us and everyone else in the community right there. Of course, a big thank you to the sponsors of this show. Without them, this show would not be possible. We've got our friends over at BuildKite, our friends at WorkOS, and our friends at Coder.com.

And, of course, to our partners at Fly for giving our agents a home, giving our agents a computer. Learn more at Fly.io. and the Beat Freak in residence, Breakmaster Cylinder. Bring in those beats. I nod my head. I hope you do too. Thanks for tuning in, and we'll see you soon. Winner. Winner. It really whips though.