The Changelog: Software Development, Open Source - From zero to NanoClaw (Interview)

Episode Date: October 9, 2026

Gavriel Cohen, creator of NanoClaw and co-founder of NanoCo, joins Adam to explain how a 40-hour weekend project became a viral open source hit and the foundation of an enterprise AI company. Gavriel describes the security concerns that led him to build a small, container-isolated alternative to OpenClaw, why he released it under the MIT license, and why the project's community and credibility are more valuable than keeping its code private. They explore the shift from writing code to architecting the environments in which agents work, NanoClaw's "skills over features" approach, the approval and governance layers required inside large companies, and a future where every worker manages agents without surrendering human judgment. They close with the technical simplicity behind NanoClaw, containers, TypeScript, SQLite, and a two-database design, and Adam's case for durable Agent Flow artifacts that keep organizational context from disappearing into chat.

What's up, friends, welcome back. This is the change log. What of the most important, viable 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 Gabrielle Cohen, the creator of Nanoclaw, about exactly that bet. We discussed why restrictive open source licenses are pointless in a world where agents can rewrite any codebase in 12 languages overnight. How he sat down with a cloud code that didn't even know open source licenses are pointless. Claw existed and built nanoclaw from a blank slate.

The moment Carpathie tweeted and shut down a marketing agency doing hundreds of thousands in A.R. And Gavriel'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 slash Forward. And I hope to see you there. A massive thank you to our friends and our partners at Fly.

dot i.o that is the home of changelob.com your agents need a computer and that is what they built. Learn more at fly dot i.o. Okay, let's do this. Well friends, this episode is brought to you by

our friends at coter.com secure environments where developers and agents work in parallel. And I'm joined by Nikki Pike, field CTO for Coder. Nikki, what is the 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 dev rel 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. Okay. 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 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 the 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 time 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 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 shy hulud, you know, that virus that went out not long ago. This was a compromise of the MPM public repositories. They went and downloaded things. MPM 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 it 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 back in the day, Claude Bot 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. That's 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 course. Claws. Yeah, it's an interesting name. I don't know. There's something about it that's a little bit, 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 names 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? And then 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 a. just running background cloud code tasks on it. But I was looking for something that gave me a bit more of like the 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 my 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 basically that's it. And then I connected it to a WhatsApp group with myself and my co-founder. And it started to send us morning sales briefings, sales standups each morning. and updates and whatnot. And I was like, this is wild.

Like 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've been using cloud code for a year then and, you know, coding agents for a little bit longer than that. And I didn't really initially understand, like, what's actually new here that?

that I didn't have before. And it took a little while. I spent like a week trying to figure it out. But I saw some security issues. I saw some problems that concerned me as I was setting it up and started to use it. And I didn't feel like it was production, it was production ready, open claw. 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 nanoclo.

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? Like, were you deep in development? Did you learn on the job? Did you learn as you built an antaclaw? Like, what's your developer journey when it comes to this? Yeah. I was full developer before this. I, so I studied physics and computer science. By hand, right? You wrote code by hand yourself? I wrote many, many lines of code with these fingers. Yeah. I studied physics.

I studied physics and computer science at Tel Aviv University. I didn't learn how to code in university. I just learned like, you know, 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. took off from development. 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 like doing something I was supposed to be doing. And it wasn't as much fun anymore. So I took some time off. I spent like 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 to open claw and then nano claw. 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 we 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 whatever you want 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 it's, 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, you know,

taking their time off and how they're feeling and like motivation levels. I do like to get my agents, motivated. I like to be like great job guys. Like we're really on a role here. But, 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, you know, 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. 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 that's what I do a lot is, 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? You know, what are the things that are untrue about that world? You know, 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.

I think a lot of that stems from like understanding user experience or even just workflows and problem solving. I feel that's the world we're in now. I was like, 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 five in many cases you give it a very basic direction and it goes off for hours and it's managing all the agents and orchestrating them.

So I do think that the engineering and architecting probably is shifting to like you're mentioning the um i'm architecting 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 i'm telling it how to build the software um and and i think that's the next evolution to me the when people are

talking about um about loops and and building loops and whatnot for me it's about it's about it's not about a while loop. It's about orchestrating or engineering some kind of architecting, some kind of feedback loop. Right. 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. And you've heard lots of things with folks suggesting this is the era of cues and loops now. Like that's what we should focus on not to prime. And I'm, you've heard lots of things with folks suggesting, not prompts or prompt engineering, more like context engineering. Like, do I have enough context build up so I could 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 a, or maybe it's a code review, something like that, kind of repromps 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 plans context, and the one that's in charge, so to speak, of the one or many subagents, 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 subagent or a side agent can then go

into a code review or a pool request review or something like that, which repromps the main agent. It's like almost the 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 goes. I think that's even more true or maybe more true now with,

Fable, 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 preferences are and your taste and your choices and then let it reason from those principles and values about how the software should be designed. I think it probably will become more important for projects to have those kinds of documents. Like is Claude MD, 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, 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 OpenClawer 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, 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 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 like 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, you know, 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 um and basically like melted into the couch for the entire weekend till Sunday night. Um, I think probably about 40 hours of, of like, of coding. Um, and my wife was like, I haven't seen you like this for like 10 years since you were in university. This like something is wild is going on. But to her credit, she like let me go down this rabbit hole. And, and, and,

And it's just like something's going on. Yeah. 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, on hack. Hacker News. But, but I published it and people, you know, it took off. Like pretty much immediately, I just posted on Hacker News and it started to take off and shot up to like thousand, 2,000 stars within the first day. And I, you know, I had seen projects go on Hacker News and I knew normally they go, they'll 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 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, Carpathie, Andrei, Andre Carpathie tweet did this whole post about claws, his, you know, 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. Right. 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 licensed. 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'd 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 people will find, 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? 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, or at least I know I had 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. The 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,

a 40-hour marathon. You released 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'd written it something in TypeScript and I want to borrow an ID and I have a Go program. I can easily look at, given with agencies these 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 the speak, because you've already open source 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. Something big that's going on. Yeah, yeah, I think it's not a difficulty for us, surprisingly. And I'll explain why, but it's clear that open source, I don't, I've heard people saying open source is dead.

I wouldn't necessarily agree with that. I think, though, it needs to evolve, you know, kind of, metamorphosize into something else. I don't think open source, the way we knew it before, works anymore, is going to continue. But I think there is a new way of doing open source,

a new model for it. I, yeah, the project, I put it out there, and people started to use it, and teams started to use it, 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 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 that 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 and you know 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. 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 for nanoclaw. So you've got people building on nanoclaw, individuals, businesses.

That's all great. Only 1% probably much less, probably a 10th of a percent of companies are going to build their own internal agent platform on top of an open source project. Like 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 nano-clo 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 are the agency to look like, what should the policies be around what they can and can 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. 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 could talk about it later

or actual code that's cool to contribute via skills you were contributing you are 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 which that's how commerce works if you didn't know that I'm sure you do um 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, 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, doesn't seem so from the outside, but how do you, how do you, 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 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 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 a 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 the 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 you know he's an investor and 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 from my company now who's helping everybody set up their agents I want you guys to do that so so the 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. It's if you've seen it, you've seen the value, you love it, you like it, and 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 ITI 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. people and not architecting software. It seemed like that was, if I'm grok in 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.

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 that 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 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're going to let everybody's agents, if people want, read their emails, search through 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 organization, agents can't delete emails. You know, you want the, you want to keep the information you don't want it 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 going to have, marketing agents, sales agents, engineering agents. They need to have instructions, skills, policies, tools are connected to recurring jobs. You want to give people an agent that's valuable on day one. And so there's, there is software there. There's a platform. And then there's the services around getting it set up and around managing, 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 are 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 and 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 to 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,

their agents within their 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 cocklist 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 spent 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 ahead 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 you 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 and what you know that really defines what our agent factory looks like so when i sat down to build nanoclaw i was i was really um i'd gone down this rabbit hole

of ai native and like ai changes everything a i changes how software is built and written and a lot of the old rules maybe don't apply and we 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 Claude in the project directory. So clone the project, run Claude 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. Like 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, you know, 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 Grinich. 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?

Choose the right tools, choosing right database, choosing right off. 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 Planet Scale 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 Workless is like that for off. You know, 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 2000 or day 10,000, you're going to want to have made sure that you picked a platform that could scale with you. And today, WorkOS is powering off and identity and security and permissions for all these AI companies, literally the fastest growing companies in the world like OpenEI and Anthropic and cursor and 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 in rapidly scale. And there's no platform other than us that's done that at the other.

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.os.com. It's a different world when you think about even where you began there 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 like you mentioned that you had, uh, Claude set it up, right? Slash set up, for example. Whereas in today's world, the setup is largely human

facing, which I think is a an interesting choice. You know, you run bash and then I believe it's like nanoclaw.sh, if I recall correctly in the process, to sitting 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. A little cute little blue lobster. I like that lobster. You know, you got this splice. 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 was 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, you know, 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, you know, headless Mac Mini and take a peek what's going on here. Lo and behold, it's asking me to approve via the GUI, the graphical user interface, to approve, you know, like Docker being installed or whatever it was, you know, like, I think the Mac OS was actually stopping the agent from installing Docker because it required a 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, my own thoughts.

But to say that this is a human flow, not an agent flow, because this 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, you know, AI native and even how I would interface with a particular software that only has human focus flows, that it 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. thing. 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 nanococe.

She's four and she doesn't really know what it is, but I got lucky and I chose a cute little lobster as a logo. So she knows the lobster. She loves it. He goes, Natalclaw. And, you know, when I can't, when I'm home late and she's like, why are you coming home late?

Yeah, 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 out a team. We've got 15 people on the team now at Nanoco. Nanocco is our company that's providing nanoclaw 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 and 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 going through

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 you know slack dm thing and this one there's a call and then um so it loaded up lots of information into its context um and then i put him in the channel with it and i said hey Andy this is Asaf he manages partnerships you know

help him out and then he just started chatting with it and he's still chatting with it till now till um till recently he's you know 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 even 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 in 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. That's wild to hand. If I understand correctly, your agents named Andy, is that right?

That is. All of my agents are named Andy. Yeah. It's like from the guy. guy in the office, Andy from the office. That's my right. 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 got to onboard somebody. I got to talk. I'm paraphrase what you just share it 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.

Yeah, that is. So it's I put the agent in a group where I was in the group and the person who joined the team is in the group and the agent's. 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 if they're not accurate so for example um in in the first day he was asking it about one of our our partners um and he asked it for information and i share with him like two recordings and i was like no there's like 12 uh sorry two transcripts uh or notes from calls and i have like, no, there were 12 different meetings with this company.

You 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 or 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 maybe meaning not

sharing with them everything but sharing with them an agent that we knew full like full and well that the agent may share with them certain information that is suboptimal for to be sharing but we made the decision that in in order to be able to move quick it's 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 in and isolated in their own sandbox, which is a hardened Docker container. and they don't have any access to 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 of 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,

it's 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 wiring, 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 get into some weeds there, I'm sure, right? Like, how do you manage the idas that you might get from that, the fatigue you might get from approving or having to review a policy or look at different stuff like i mean it feels like an onion like in terms of layers there's so many layers and and that how do you navigate with nanoclaw

how to manage how to deal with such a complex multi-layer kind of scenario like that that seems hard to put it to put it the most frank way totally yeah Yeah. I think the onion analogy is correct. There's so many layers to it. And the way with my like architect brain, right, and way of thinking about things, looking at the problem of how do you, 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 is just this, you know, there's so many other world. It's like, yeah, overdoing a rock and finding a whole world ecosystem, it's pretty accurate. Go ahead. Yeah. Yeah. So I, 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 I started to 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, you know, candy, gold, whatever your favorite analogy is, your favorite thing is. And it's just lying there.

And in that kind of space, 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 to be a whole SaaS product that someone would pay like 200 bucks a month for. And now it's like agents, give them a 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 you the 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 will build another piece. So that's how we're building it. So I added agent to agent, realize 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. You just shut it off. But it does unlock certain workflows where the agent could 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 one or two percent or five percent of workflows or the work that people do we can start to bring tremendous value and grow from there do you 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 know you uncover this rock you find this eco stuff 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 could 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 learned 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 other, what's the most favorite Dwight? Maybe it's Andy and Dwight. Maybe, you know, Agent Andy can talk to Agent Dwight, but maybe they can't talk about sales data, for example, like sales numbers. They could 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 world that's created with you on Andy and Dwight is when you are focused on the 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 how do you approach you know 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 to policies, right, 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 agents 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 I, you know, we write our kind of what we're building. You've got the P1, P2, P3 and, you know, kind of milestones. and I find myself going to P0 and then I'm doing P00 and P0-0-0-0 and just scoping down to like,

what is the absolute minimum thing we could 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 a lot of code and 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 what don't we add this why don't we add that let's add a you know defensive

mechanism here and validation here and I think as architects we have to keep them keep them focused you know, 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 Nanaclaw, 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 agents. 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 subagent, Andy. Like, how do you think about identity and what exactly meant an identity for you and Nanoclaw? I don't remember. I think it's a little bit of an not fully solved problem yet.

Okay. Yeah. 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. 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, this is good to merge. 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 it's saying, okay, this could be merged. So it writes out a command for us. And then the agent can't actually run. 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. Right. 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. Right. And that's very intentional. It's, yeah, that's cool. The agent can't merge code and we're, 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. 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 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 one CLA. 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 nanoclaw thing. This is like maybe your thoughts, but also I imagine most of your thoughts you're baking into your ideas, your DNA and how you think about things are being baked into nanoclaw. 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. Not going down like negative,

but just more like in terms of usage. A lot of people upset with GitHub, man. Gosh. it sounds like you want the human in your 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 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 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 a hundred times a thousand times, we're probably reaching a point where there are 10,000 X developers out there who are doing, you know, rewrites of massive open source projects in a matter of weeks and building out, you know, successful projects and days, right? And it's, but we want it to be the person who's now 10,000 X 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. Like 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 and 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. Like 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 are 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 or 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 you know, they're going to end up doing mass layoffs. So I think that the responsible, you know, 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, you know, it 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 naturally think about how's it going to help you make more software, right? But everybody else who's not a developer is like, what's software? Like, you know, not really that, but about six months ago, maybe, 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'm 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, 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 like 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, the 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 will 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 NANLLA, 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 them. 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 NinaClaw on a Mac Mini, you know, 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 know, can deploy to Azure,

connecting, integrating with their IDP, Octa, 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. 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 and places where the agent stores information um and you get the the idis 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 companies uh in the company's environment there's also a uh 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, yeah, 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 proxy through the agent gateway and are then, that's where policies are enforced and credentials are injected. So the agent gateway holds secrets, the credentialing 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 goes back to what we're 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-up EC2 instance. Data is stored in EBS volume. encrypted, checkpointed, backed up, and keep 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, you know, all this inference and whatnot. 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, a 16 CPUs. use 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 a thousand, maybe a couple thousand users.

So a big machine in the cloud, take the biggest machine you can get standard on AWS. You can run tens and tens, maybe 100,000 agents when you're thinking that they're not all active at the same time. 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. It's 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. It doesn't really matter.

Yeah. Well, that's interesting. So how and 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 enterprising things. Like packages type things. Yeah, yeah. Extensions 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 co-based, then you get 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 codebase and add all kinds of custom functionality, don't just go wild in the codebase. 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 a function and then wiring it in one specific place. So by keeping added files, but then for the upstream files, I keep a 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 like you want to write tests for your own code. That's great.

But part of this or 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, just have a test that like 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 recipe that explains the skill that explains how I customize it. And then have one meta skill, which we're calling a recipe, that just list 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 upstream 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, yeah, so we're building all these. customized versions of Nano Club, 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's certain processes you need to do to keep those forks up to date and to them be able to build them into images and push those images out to customers accounts. So that's our agent factory. 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. What do you, how do you keep it, I guess the easiest way to say is how do you keep it all together? But you got more than you building this. You 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 in how you described it. Hey, I'm just paraphrasing. We're here working on customer X, Y, Z's custom NinoClaw. 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 in the claw for you or with you for a client?

Like, how do you keep everybody in the loop and do you? Do you actually do it well? It's, 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, you know,

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, meaning rather than just pushing code, pushing code, pushing code, invest in the, the instructions in 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, you know, weeks and months. And then 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 this up properly and commit it to the code base and push it out there and link to it and 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 got to follow, you know, 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 the same way. And it seems to be working so far. We can check back in like six months. Yeah, right. Well, that's cool. So I mean, it's It's burgeoning this new movement of skills, recipes, contribution. It's not the way it was for open source. You've 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 nanoclaw for enterprise

you're building for, you know, as you're saying that, I was just thinking to myself, okay, so you're, you're tethered to the open source version the community uses. And if it's not working for them, it's not working for them. for you or it you know that there's a symbiosis there that's happening but i think it's kind of interesting yeah i do think about going back to the open source model uh 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 there's a project and it it is you know legally uh owned by by our company nanoco

but it is its own thing it has a community um 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 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 in flourish in the long term, they do seem to be connected to a very successful commercial business that that is funding it and

maintaining it. Yeah, I mean, because you've got to fund the future of it. And you're not taking code contributions, right? Like, do you not, 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 note everybody Yeah yeah 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'd be weird It's like this is my agent don't don't use my agent like fork it and do something with that different But um

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, 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, this kind of little equation, which is like lines, it's, it's functionality, right? So I, when I'm looking at a contribution, the functionality that it adds times like the target market is a super niche or, I would say not functionality, utility times like target market, how broad

it is divided by lines of code. So, and that's got to be maximized. So if you're making a really small, you know, 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 like 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 the code base And 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 build kite and one of the most challenging problems of modern era software development is continuous integration and continuous delivery. And so Lockland Donald, Bill Kite, 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 the question everyone's asking right now. All of our big customers are asking us at the minute, Like, you know, if we five or 10x are throughput this year or a thousand exit, what breaks and when? And, you know, my answer is kind of same as it's been for the past 20 years, which is 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. Sure. Okay. So where does Bill Kite thrive? What particular type of team or enterprise do you thrive in? The area that Bill Kite 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, Open AI class of folks that have this key problem around iterating really, really fast. And, you know, the thing about all of 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 results 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 ten agents next week. Well, friends go to buildkite.com. That's buildkitekite, kite.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 stop someone from nano-coing 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 the 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. NanoCo's 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 nanoclaw, right? We're the company that created it. We're the company that built it 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, 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. The community that's built, the Minister of Foreign Affairs of Singapore using it, and Andrei 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 co-pilot 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 would,

then feels like their 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 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 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, you know, 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, you know, 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, I've got people because of who I am and what I do and what I know, um, asking me to help them, right?

And I've, 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, uh, their 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 it's going to be like,

Adam, can you help me put nanoclaw in 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, potentially, in my quest to help these folks. Isn't my main business? Am I trying to build a capitalized, you know, 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. And so that's why I ask that question. because you've got more and more people, maybe even more people in the nanoclaw world,

there 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 permissively 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 are serving. So, like, we're in this really world where, like, 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-advisorial approach to, how can I actually add benefit to the nanoclaw world by helping my, 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 a reality because a while back you spent 40 hours straight going blind, producing code to turn into NinoClaw? I feel great about that. It makes me happy every time I hear about someone using NanoClau, 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 for 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 1,000, 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, you know, 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, you know, 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 just 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, you know, 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, you know, a message at like 3 a.m. going like, hey, dude, this thing isn't working. and you know, you're going to, you know, 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

to grow and there's more people in here. And it's not just us with our, you know, 12 million in seed funding, trying to push this community up the 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 poll becomes 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 nanoclaw 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 do the, 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, will 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 for getting things and they'll go and play the agent doctor and like help you know figure it out and fix it up but the more infrastructure type of maintenance will be able to do for them this whole conversation has got me thinking especially when you talked 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 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 why 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. Remixes it. I'm remix 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, a nanoclaw can exist

because you're built on containers, Linux containers. You may, on a Mac, install documents. but that Docker container is running some version of a Linux distribution. It could be opine. 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 know,

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's not available on any given M-series Apple Silicon Mac,

which I think is just amazing. It's like WSL for Windows has now come to Apple and come to Mac OS. And I tell you what, the audience may see me if they're on YouTube, but they can't see me, man, like 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 open claw. You've got nanoclaw. And maybe they're both claws, but they're not the same thing.

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 nano claw 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 are invests they have invested in uh nanoco so they invest in our seat around um so full disclosure i didn't know that yeah yeah so we had you're not a hater you're a lover then uh yeah a big fan of docker and and especially what they're doing recently with their sandboxes um which you know they're building for running agents and whatnot right so um yeah the the you know we got great

investors in see round vassel invested uh a docker uh hugging face uh cees Clem, he's part of the round. So Docker, you know, initially what's funny is that NanoCla actually ran initially on Apple containers. So when I launched a project, it was WhatsApp baked in and Apple containers baked in just because I had bought a Mac Mini and I had a MacBook and I had been meeting 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 Read Me, part of the Angry Notes and the Read Me was also like it runs on Apple containers. Why? Because I thought it would be cool. You know, what about supporting Docker containers? It was like just fork it and change it to Docker containers. And, you know, 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 were 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 like a contractual application 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 are, they have their own fork of nanoclaw. And they change 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 schedule 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 like kind of like Sunday when people go to church. So they created their own flavor of nanocloat. The only reason why I know about that fork is, because that's my brother-in-law happens to be using it. And he didn't create it, right?

So there's probably hundreds, maybe, you know, 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 could 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, it's really wild. Yeah, because I mean, you know, this is your world more than it. 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, 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, why can't use this because my agent has challenged 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,

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. And maybe I'm wrong, but I think you probably are in terms of like, especially lines of code. You're 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 OpenClawn, 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, that, that, that project now has like 200,000 stars, you know, massively successful. I think if you want, you know, evolving agent that's changing all the time, great project. If you want an agent that just is a bit more stable, reliable, I think nano claw 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 OpenClaw and Peter who created it because it, you know, it was, it did show what was possible. I think, you know, it isn't 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, you know, going wild with, let's connect everything and see what happens. But maybe it did require that in order to get to that point, right? Like 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 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? But I think there's definitely space for many. I think for businesses, I think NanoCla is really well positioned to be. be the solution and there's space for a lot of companies to take claws to businesses and to build

all kinds of products on top. We're positioned really well to take it 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. not, you know, building a nonprofit and building, we're trying to build a very, you know, large, successful company, um, relatively small. So, so that's sort of the nano company. It's like an AI native company that's, you know, small for, for what it's doing, but, but in absolute terms, I think we're going to have to grow. Um, and, and, and yeah, just, you know, to close the loop on the open claw 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, you know, 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, you know, 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, right, 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 cut off in January was like maybe June or July of 2025. So pre-open claw.

So it means that Claude didn't know, Cloud code that I was coding with, my coding partner, didn't know that OpenClaught existed when we're coding. And I didn't tell it that it existed. I didn't say there's this project called OpenClawe, 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. I want to run.

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 open code 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 things. 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 Olamma and local models and whatnot. But and now support like 15, 20 maybe messaging apps. So Slack teams, Discord, telegram, you know, you name it. But everything's kind of modular. But yeah, it evolved quite organically. and it's become its own thing and claw has become a category

and I'm happy to be part of that category. Yeah. Even as you're describing that category because I'm not as steeped as you are in the, you know, this claw does that and that claw does this and you would use nanoclaw in these ways and you would use open claw in those ways. 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 old day anybody like if claw is the uh 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 uh you know in a in a comparison here and nanoclaw is like a boon to and or maybe open clause more like a boon to and then the clause more like I don't know um a different flavor you know I'm trying to like I use like three Linuxes, maybe four. I know them all, but like, I'm familiar with Debian, Buntu, 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 like, is that the claw is kind of like synonymous with Linux and the various

distros, nano, open, Hermes. While it's not a Hermes claw, it still is, what is Hermes? Is it, it, it's a god? I think it's a god in like a Greek god, right? you've all kind of like operate around this claw movement and created flavors and distros that fit certain needs like you would use debbie and 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 you 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, that's true. 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? Can't, I suppose your type script and bun, right? So you could ship a binary. Right. We're, well, it's so it depends. The, orchestration layer is TypeScript

not Bun. It's just TypeScript. Okay. But the what runs in the container, so the agent's environment is TypeScript Bun.

Yeah. So it's kind of two, 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 mono repo 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 but the same, you know, all the time. They kind of spin up and then the agent's idle, they go down. Handling the approvals, handling scheduled jobs, handing all of that. That's all in that orchestration layer. And then the agent's environment is just like the agent running in their 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, it's, I think, yeah, I don't know where I was going with that. I suppose even SQL Lite, too, 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 the right to it. That would be kind of bad. You can certainly wall it, but you still have some challenge with the rights. 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 interesting, yeah, it's exactly right there. Is it reverse? It's two databases for that reason. So each agent's 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. Interesting. And yeah, it uses a wall journal with like timeout. And, you know, it's complicated because, you know, the agent's running in a container.

So these are totally separate processes. and normal mode of regret doesn't work. And, you know, I had, when I was trying out that mechanism, because initially when I built Nanoclaw, there were like a whole bunch of different cues. 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 sheer database? And then that's kind of all the cues is just the one database. Like a message comes and I stick it in that database. And then the agent pulls are 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 stressed tested that and verified that you could get to like insane, you know, 10,000 whatever operations and, you know, bursts and whatever. And it, you don't, you don't get corruption.

But with all the other modes that I tried, you get, you get corruptions at some frequency where it's just. Yeah. 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 know you resisted probably vectorization in a database like pg vector or postgres or my sequel you just avoided all that i've 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 and i say that

with a tongue-and-cheek smirk on my face because escalate is awesome have you been consider i don't we're getting close on time, but I'm not we're into some technical bits. I'm curious, have you considered Tursa? And the reasons why they've decided to rewrite SQLite in Rust. Are you familiar with Terso? Is this new to you? Or you have a B on that? Yeah, it's new to me. So, yeah, tell me about it. It says a rewrite in Rust. Let me see. Terso. Okay. Turso.com. What is Terso? Terso is an open source SQLite compatible database written in Rust, unless developers creates millions of small file-based databases for AI agents,

multi-tenant SaaS applications, and edge workloads. So a lot of what that I'm familiar with, Glober is the CEO there for Turso. We've had him on the podcast before. The biggest challenge, I think, that they post. with betting on and leaning on SQLite. And I could be wrong. This is about a year back, this conversation,

I'm even paraphrase 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, 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 Glober on Tersome while 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 meet 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 SQLI. Now, they have Lipsq, which is like the lower level Rust Primitive that they built Tursu on top of. And they have a funding and a cloud, and so they have their own inertia. But I have yet to convince an agent that, and I have, 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 Turso? And so far, crickets, they don't want to do it. They're like, not, man. That's stupid. Like, so I don't know. Yeah, I wonder if, you know, we're just, everything's just going to become rust when it comes to agents at some point. There's the, you know, bun is now, well, I think they. release the version or about to release.

And I know there's rewrites of Chrome and Rust. And, you know, I'll check out, Terso. I mean, 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 forget it weird comments put weird comments like

right maybe it does something for you I don't know right you know so I stopped fighting it's a token waste that's for sure right yeah on the read and the right on the initial inference and then the you know even timing I think about that is like it's less about the messiness and more about while you just wasted an extra minute on this turn

and way more total tokens and necessary to put comments. I don't care about. Maybe you care about them, but whatever. Yeah. But it's like our, then we have to waste cycles, you know, our brain cycles, you know, our brain cycles deleting them and, and fighting them consistently to keep deleting them. And then there's the, I just gave up. I mean too. And I, and it's, 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. They need 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 0-0-0-1 or spec 0-0-2-0, for example. Like that's the one that governs this function, for example. Or this is actually from, you know, bug 0-0-1 or whatever number bug is in there. So I'm kind of revealing some implementation details into my frameworks, but it's called Agent Flow. And Agent Flow is how I build everything. and it governs all my governing. And without Agent Flow, I'd be lost.

My projects would be lost. Every project uses Agent Flow. Agent Flow 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. And 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, coderview, agent, work, PEP, governing spec, right? This whole sort of audit trail of why does this exist, which is a hardest 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. Pepin implemented it.

And there was a bug report against it and 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 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 augmented because our futures 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. I'll tell you what. Agent flow sounds awesome.

And, you know, people want agent flow. So I think you get paid out there. We'll have the talk. We'll have to talk. I need some help. I need some help on the front. I need a friend to say, just do it at him, 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 nanoclaw 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 Agent Flow fit anywhere? Actually, it could, but I think a lot of it is kind of geared towards, and govern 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 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, that feature, or the blanket statement for why this piece of code should exist or the 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 great software. That sounds awesome. Yeah, that sounds awesome. So, I mean, 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, you know, what are the different, 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, you know, an HTML and an artifact that has diagrams and visualizations and takes it and tries to, you know, not like a eight-page thing necessarily, but try to make it pretty condensed, but just surface, you know, put into attention the parts that are worth having attention put on them, which is the decision points. What are the key decision points? And what do you need to know about this?

And then we share it with the team and, you know, get some other people to look at it and chat about it. And then you go off and, you know, and that's really the, that's really the whole thing after that. You just send off an agent to go and build what you decided together needs to be built. But I mean, that's, I think, the core of the architects work now. Yeah. Leaving things stuck in chat or Telegram or WhatsApp or wherever.

Like, 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 sure with the client.

It could be sure with whomever really makes the most sense. But, like, having that, I guess, you know, 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 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 got so many humans doing work, gosh, you got to find a system to get out of that to then create a memory system and all these other things. That's, to me, I think, is where I'm most,

what's the right way to say? 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,000. 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 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, you know, the second brain. It just builds up this information. It's, you know, the LLM wiki patterns. Every

bit of information you feed it, it goes into this type of Wikipedia. You know, 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 this, you know, all these articles and interconnected articles and it becomes this kind of graph. But it's really, you could 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 you know many of those second brains so each person in the company's got that second brain with all their information in 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 and 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, took maternity leave and gave their agent to someone else to continue their project. And it just like a project that would have had this whole period of offboarding and onboarding and it was just zero down 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 55 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 swap the model out, the context is still there, the mission still continues, nothing really changes. That's where I'm really interested in that because even with chat history, I spent a lot of time with anxiety of like, oh my gosh, like my stuff is all stuck in these chat threads that gets compacted, that gets erased. And like, oh my, that's why I got into this, like, I've got to extract everything, but then it was 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 my tides, 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 salad enough breadcrumbs in her agent, in her context loops and 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 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 you're just telling me they're going off. Yeah. doing things for you, you know. And it's, it's really empowering for people. I think, you know, 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 them happen. For most people, they don't, you know, they don't, 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 people who, you know, get started building with Asians. Well, friends, listening to this podcast, go to nanoCo or nanoco.aI and hire the folks that made Nanoclaw 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 nanoclaw.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. Like I, you've given me a new, a new, a new, a new facet to consider run-up and source. I've been pretty sad, I would say, like, pretty nuts. I wouldn't say like sad necessarily, like, just bummed. Maybe that's a version of sad, but like some other adjective that describes sadness that isn't quite crying, 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, uh, your, uh, your, uh, your, uh, your office. 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 your business plan to use it as a as a benefit not an Achilles heel in any way shape or form that's so cool so friends go to those two places Gabriel thank you so much for coming on

the pod man and sharing just your agent thinking man your thoughts I really appreciate it I 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 changelaw.com slash community.

It is free to join. Zulip is where it's at maybe changing soon. Who knows? Zulip had 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 sponsor this show without them.

This show would not be possible. 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 agency computer. Learn more at Fly.io. And to the beat freak in residence breakmaster, bringing those beats. I nod my head. I hope you do too.

Thanks for tuning in and we'll see you soon.