NanoClaw and the Rise of Personal AI Agents

Summary

Podcast Summary: NanoClaw and the Rise of Personal AI Agents

Podcast: Software Engineering Daily
Host: Kevin Ball (K. Ball)
Guest: Gavriel Cohen (Founder, NanoClaw)
Date: July 21, 2026

---

Episode Overview

This episode explores the growing landscape of autonomous personal AI agents, focusing on NanoClaw—an open-source project designed for securely orchestrating long-lived AI agents. Host Kevin Ball and guest Gavriel Cohen, founder of NanoClaw, discuss the project's origins, security architecture, technical design choices, agent interactions, and the philosophy underpinning its modular, fork-friendly open source model.

---

Key Discussion Points & Insights

1. Background & Motivation for NanoClaw

• Gavriel's Journey: Gavriel comes from a background in physics and computer science, with years at Wix as a dev, team lead, a brief PR stint, and then a return to the engineering world inspired by the emergence of advanced coding AI agents. ([02:09])
• From OpenClaw to NanoClaw: Inspired by OpenClaw’s promise, Gavriel saw firsthand how much value persistent AI agents offered, but also identified critical security shortcomings (exposed credentials, over-broad access). NanoClaw was born to address these.

  “I saw these massive security issues. So that’s why I sat down to build Nano Claw, so I can get the value that I saw in OpenClaw, but without compromising on safety and security.” – Gavriel Cohen ([03:54])

2. NanoClaw’s Security Model

• Zero Trust Mindset:

  “Agents can’t be trusted...treat the agent as if it’s malicious.” – Gavriel Cohen ([04:36])

• Key Security Features:
  • Agent Isolation: Each AI agent runs in its own Docker container, isolated from the host machine and other agents.
  • No Embedded Credentials: Credentials/API keys never exposed to the agent; instead, outbound requests are proxied and credentials injected outside the agent’s env.
  • Proxy with Human-in-the-Loop: Sensitive actions (like sending/deleting emails) require human approval through enforced policies at the proxy.
  • Sandboxing and Permissions: Only specific data and communication channels are exposed to the agent.

3. Technical Architecture

• Sandboxing Explained:

  “Let the agent run wild within its environment and then enforce things on the boundary of that environment.” – Gavriel Cohen ([07:47])

• Agent Environment:
  • Agents run in Docker containers or Docker sandboxes.
  • Each agent has a mounted file system folder.
  • Communication between host and agents is via SQLite DBs—one for inbox, one for outbox.
• Agent Orchestration:
  • Host Process: Orchestrates agents, routes messages, and controls agent lifecycles (spin up/down based on need).
  • Everything as Messages: All interactions, tasks, approval requests, and scheduled jobs are modeled as messages.

    "Everything is messages. Approval requests are responses to approval requests...all of that is just messages." ([10:22])

4. Lifecycle and Resource Management

• Persistence & Context Rotation:
  • Set up for long-lived sessions; folders and session files ensure durability.
  • Context compaction is handled minimally, relying on agent model features to summarize and manage context—as Gavriel explains:

    "We take a very simplistic approach and try to not reinvent the wheel..." ([26:01])

• Resource Management:
  • Agent containers spin up and down according to resource availability and task scheduling.
  • Scheduling uses host-managed cron-like jobs (with details written into the agent inbox).

5. Agent Communication & Multi-Agent Systems

• Inter-Agent Messaging:
  • Agents can talk to each other and even create other agents.

    "Your agent has an MCP tool create agent...that creates a second agent in its own container..." ([29:51])

  • Messages between agents are routed by the host via inbox/outboxes.
  • Human-in-the-loop or approval gates between agents are essential, especially in cross-user contexts.
• Multi-user Scenarios:
  • Advocates for transparent forums (like Slack channels) when multiple people interact with a shared agent, to avoid a false sense of privacy.

6. Artifacts & Workflows

• Engineering Productivity:
  • Example: Agent factory automatically reviews pull requests, writes test plans, spins up test VMs, runs QA, writes markdown files, and routes artifacts between agents and host.
  • Human Approval: Final actions (like merging code) always require explicit human approval.
  • Artifacts are exchanged via standard locations in agent environments; host-only accesses agreed paths for security.

7. Product Philosophy & Open Source Model

• Minimalism is Key:

  "Keeping it small, keeping it simple...in order for it to be auditable, it has to be small." ([40:57])

• 80/20 Rule for Features: Merge features only if they’re broadly useful; niche needs are for personal forks.
• Fork-Friendly by Design:
  • Encourages users to fork and customize, similar to shadcn in frontend development.
  • Integration points should be minimal to make pulling upstream changes painless.
• Skills System:
  • Users can share/extend NanoClaw via “skills”—self-contained, scriptable mods that provide deterministic, easily replicable ways to extend base functionality.
  • Skills can script integrations (ex: Spotify), guide code changes, and package instructions for coding agents to enact.

8. Plugin & Model-Agnostic Support

• Agent Provider Abstraction:
  • NanoClaw supports integrating new coding agents (Opus, Codex, PI, etc.) via a registry and reference implementations.
  • This helps keep the project greenfield for new capabilities.
• Supporting Rapidly Evolving AI Landscape:
  • Avoids building elaborate, static systems; instead, leverages evolving agent SDKs and models, trusting their improvements will benefit NanoClaw's agents.

9. Customizability & Future-Proofing

• Per-Agent Customization:
  • Currently, most configurations are global, but forking enables per-agent tweaks, including tool prompts or definitions.
  • The team is moving towards CLI tool abstractions for more flexible interactions.
• Legacy & Memory Management:
  • Keeps memory systems simple, leveraging agent instructions rather than hard-coded, brittle solutions.

---

Notable Quotes & Moments

• On trusting LLM Agents:

  “As long as your agent is able to interact with any kind of unsanitized data...it can act against you. It can end up turning out to be malicious...” – Gavriel Cohen ([04:36])

• On Approval Gates for Safety:

  “If it tries to send an email or delete an email, that requires my approval and then an approval request gets sent to me and I need to approve each action.” – Gavriel Cohen ([06:45])

• On Open Source Philosophy:

  “I think people should be looking at it themselves and verifying that it’s okay. So in order for it to be auditable, it has to be small.” – Gavriel Cohen ([41:02])

• Shadcn and Fork-first Model Comparison:

  “You’re kind of taking that at the whole project level here of saying, hey, copy this and then make it yours.” – Kevin Ball ([48:46])

• On leveraging external agent SDKs:

  “If some people out there are still in that place where they’re going, maybe I’ll use LangChain...my advice to you is don’t do that. Save yourself the work...Focus on unlocking the value over there rather than re-implementing the basic element, basic building block of an agent.” – Gavriel Cohen ([61:01])

---

Timestamps for Key Segments

| Time | Segment/Topic | |-------------|--------------------------------------------------------------------------------------| | [02:09] | Gavriel’s background and how NanoClaw was started | | [03:54] | Security issues with OpenClaw; motivation for NanoClaw | | [04:36] | The zero trust security model; agent isolation and proxy approach | | [07:47] | Technical details: Docker containerization, message routing via SQLite | | [10:22] | “Everything is messages” paradigm | | [16:24] | Task scheduling, agent lifecycles, resource constraints | | [26:01] | Context compaction and session management | | [29:51] | Multi-agent communication, agent creation and interaction | | [35:44] | Workflow for artifact generation and multi-agent handling of PRs and tests | | [40:57] | Product philosophy: minimalism, fork-friendliness, open source strategy | | [48:46] | Comparing project customization to shadcn front-end component libraries | | [51:00] | Skills system for distributed, scriptable integrations | | [54:19] | Plugging in new agent harnesses (Codex, PI, etc.) | | [60:52] | Final advice: leverage agent SDKs, don't reinvent the wheel, focus on value |

---

Memorable Anecdotes

• Testing with Family: Gavriel gave his wife a personal WhatsApp agent (“Andy”) and, after some skepticism, observed it autonomously scraping price data to notify her about sales. This illustrated the practical persistence and scheduling abilities enabled by secure agent orchestration. ([16:24])
• Andrej Karpathy’s Endorsement: Gavriel recounts that Karpathy highlighted NanoClaw’s “skills” system as “slightly mind blowing,” considering it a high compliment. ([50:01])

---

Closing Advice

• Use agents as composable building blocks; don’t try to build your own agent framework from scratch.
• Focus engineering effort on delivering high-value use cases and products leveraging existing agent SDKs.
• Embrace a minimal, auditable, fork-friendly open source ethos; customize as needed but keep core code lean.

---

For more technical details or to contribute, check out the [NanoClaw GitHub] and follow K. Ball or Gavriel Cohen on social.

Transcript

[Narrator]

AI agents have shown remarkable potential to function as persistent digital assistants that are capable of monitoring data, managing communications, and taking action autonomously over long periods. Openclaw was one of the first serious attempts to fulfill that vision, connecting frontier coding agents to messaging platforms like Slack and WhatsApp and letting them run continuously in the background. However, OpenClaw largely set aside questions of security to pursue that vision, leaving credentials exposed in the agent's environment and giving agents broad access to data and services far beyond what any given task required. Nanoclaw is an open source project that takes a zero trust approach to agent orchestration. Rather than relying on instructions to constrain agent behavior, it isolates each agent in its own Docker container, keeps credentials entirely outside the agent's environment, and enforces human in the loop approval for sensitive actions. Gavriel Cohen is the founder of Nanoclaw, and he joins Kevin Ball to discuss the security architecture behind Nanoclaw, how the agent sandbox and proxy model work in practice, how agents communicate with each other and with the host orchestration process, how the project approaches context, window management and long lived agent sessions, and more. Kevin Ball, or K. Ball, is the Vice President of Engineering at Mento and an independent coach for engineers and engineering leaders. He co founded and served as CTO for two companies, founded the San Diego JavaScript Meetup, and organizes the AI in Action discussion group through Latent Space. Check out the show notes to follow K. Ball on Twitter or LinkedIn or visit his website K Ball LLC.

[Kevin Ball]

Gavriel, welcome to the show.

[Gavriel Cohen]

Thank you. Great to be here.

[Kevin Ball]

Yeah, I'm excited to dig in with you. This is a topic I was very excited to get the opportunity to discuss. But before we do, let's start with you a little bit. Can you share just a quick overview of your background and how you came to build nanoclaw?

[Gavriel Cohen]

Absolutely. I studied physics and computer science at Tel Aviv University and actually during university I started to [e-mail] as a student. I worked there as a software developer, started in front end, moved over to Full Stack and then led a team of developers there. Spent a total of about seven years. Actually stopped programming for a few years and took a break and worked in public relations and promoted tech companies and then jumped back in about a year and a half ago or a year and two months ago, right around when cloud code came out, I felt like there was this huge opportunity, you got to dive back in, started building things and that's when I got to nanoclaw.

[Kevin Ball]

So for those who may not be familiar, I Think a lot more folks have heard of OpenClaw at this point, but what is Nano Claw? Let's just give the quick tldr.

[Gavriel Cohen]

So nanoclaw is an open source project and it is a safe, secure alternative to openclaw. So openclaw is this wild experiment. The way I see it, it's this wild experiment of if I put aside all of the security, safety and even software quality concerns, I just put them aside and try to see can I get a lot of value if I just take Frontier coding agents and connect them to everything. And the answer is, you can get a ton of value. I used OpenClaw. I was building an AI native marketing agency and I set up OpenClaw in a chat with me and my co founder and told it, you've got the sales data from our company mounted in your environment. Look at that. And you're managing our sales pipeline. You're now our sales manager. And it very quickly started to do the work of an employee. And what that means is giving us a morning briefing. Here are the deals, here are the things you need to follow up on. Setting reminders. We're just dumping raw data at it and it's making sense of it and updating files. But then very quickly I saw these massive security issues. So that's why I sat down to build Nano Claw, so I can get the value that I saw in openclaw, but without compromising on safety and security.

[Kevin Ball]

I think this is something I've definitely had on my eye since openclaw came out. I was like, oh, this is a disaster waiting to happen. It's like, fascinating. And I think we've seen some of that played out. But let's talk about the approach you take in nanoclaw. Like, how do you make it secure? What is the security model that makes this work better?

[Gavriel Cohen]

Yeah, openclaw is definitely this disaster unfolding that you can't look away. But for nanoclaw, the mindset is, first of all, agents can't be trusted. AI in general, it's non deterministic. No matter how many exclamation points you put after the big bold instruction saying don't delete my production database. I've joked that if you're digging through a code base and you see in the Claude MD file at the top, in big bold letters, it says never, never run drop production db, then you know that that agent has deleted a DB before and that it's going to do it again because it still can if the instructions here. Right. So the idea is don't trust agents actually approach it with a zero trust mindset of saying as long as your agent is able to interact with any kind of unsanitized data, if it's looking at emails, if it's looking at pull requests, that's unsanitized data. People can stick in their prompt injections and it means that your agent can be prompt, injected and it can act against you. It can end up turning out to be malicious, so you need to treat the agent as if it's malicious. So with nanoclaw, we isolate the agents. Each agent is running in its own sandbox, isolated from the host machine, isolated from other agents, and we're very intentional about what we put in the agent's environment. So first step is isolated. Second step, don't put any credentials, secrets, API keys, tokens into the agent's environment. Now you do want to give the agent the ability to interact with credentialed services and APIs. So the credentials, tokens, API keys sit outside of the agent's environment. All requests that are leaving the agent's environment get proxied through a small vault that sits next to the agent and credentials get injected outside of the agent's environment. So that's the second part. No credentials or secrets in the agent's environment. And then the third part is enforcing policies and access control at that proxy gateway point and including human in the loop approval. So I can connect my agent to my email, for example. The agent doesn't hold the actual credentials that allow it to access the email, but its requests get proxy credentials get added and I can set a policy saying it can read my emails freely, but if it tries to send an email or delete an email that requires my approval and then an approval request gets sent to me and I need to approve each action.

[Kevin Ball]

This sandboxing and proxy approach is something I feel like I've seen bubbling up in a number of places as people grapple with, yeah, this core problem that agents cannot be trusted, LLMs on their own can only sort of be trusted. But then once you introduce any sort of outside influence, it's like dealing with user generated content again, right? Like you can't trust it. You've got to sanitize in some form. And here sanitization looks like it's isolated. Can we dive into the details? How do you isolate it? You said it's in its own container. But like what does that end up looking? Like what is the interface to the proxy? Like, how do all those pieces work?

[Gavriel Cohen]

So we have the agents running in Docker Containers. There's also an option to run it in Docker sandboxes, which is a new thing that Docker has been working on specifically for running agents, and that has some extra hardening. And the agent runs in that environment, it gets a folder mounted, and that's its file system. So it can create files, it can create folders, it can organize them in all kinds of ways, it can manipulate its environment in any way. The approach that we took with nanoclaw is not trying to inspect every action and every request, but let the agent run wild within its environment and then enforce things on the boundary of that environment. So you mount a file system. One nanoclo instance can run on a machine in a vm, say, and have many agents running in that one instance. There's a host process that's responsible for orchestrating the different agents and containers and routing the messages to the right container with the right agent with the right session. And then the way it's implemented, there are two files that are two SQLite SQLite DBs, one for the agent's inbox and one for the agent's outbox. So the host process, when it gets a message and determines that it's supposed to be routed to an agent agent A, it writes the message into the DB that's mounted for that agent, and the agent is pulling the DB for new messages every time. It's actually not the agent, to be more precise, it's a loop. There's a little process running inside the sandbox, it's pulling the inbox. Every time a new message arrives, it just pushes it to the agent. And that's by default agent SDK. It Claudes Anthropics Agent SDK can also run codecs or open code. Agent does its thing, uses tools, bash commands, whatever it wants to do. Going wild. It can do all kinds of wild stuff in its environment, but it can't access the host machine or other agents environments. And then when the agent finishes and outputs a response, the little process running in the sandbox with the agent writes that to the agent's outbox and the host process is pulling the outbox, gets the response and routes it to the correct chat. Or that could be a slack channel, it could be a Slack DM, it could be a WhatsApp group, wherever it's supposed to go to. Interesting.

[Kevin Ball]

So those input and output SQLites, they're only used for input messages in both directions?

[Gavriel Cohen]

Yes, and made a decision that everything is messages. So there are a couple environment variables that are injected into the container. Besides that Everything going into the agent's environment, everything coming out is set as messages. So for example, if I want to do a schedule task, have the agent run at a certain time every day and send me a briefing of my sales data, my sales pipeline. So that's a message with a process after time. And if I want it to be a recurring task, then it's a message with process after and a certain recurrence set to it. So everything is messages. Approval requests are responses to approval requests. All of that is just messages or system messages or regular messages, but everything is messages.

[Kevin Ball]

Fascinating. And why have the external process managing that rather than the agent directly sending messages?

[Gavriel Cohen]

You want to be able to enforce what the agent can message and where it can get messages from. So you've got, for example, a WhatsApp or Telegram. WhatsApp is maybe the most clear example of that. You have a WhatsApp bridge, WhatsApp connector. If you're connecting with normal WhatsApp, not a business WhatsApp. So most people are using a package called Bailey's. It kind of reverse engineer the API that WhatsApp Desktop uses and that connects using that same API. So it's a non sanctioned, let's say, community connection to WhatsApp. That connection connects to your WhatsApp account, your WhatsApp identity, and that same connection can connect to every WhatsApp group that you're in. Every contact, every message. It just downloads everything. When I started to use openclaw, one of the things that I noticed that made me go, okay, wait a second, I can't actually use this for a real use case, for a business, for a production use case is I started to dig through the logs, debugging something, and I saw that OpenCloud was actually downloading and storing every single message from every single WhatsApp group and every contact in plain text in a file on my computer. Not just the one group that I had added it to, but every single group. Now with Nano Claw, by default, when I connected to a group, it only stores messages from that one specific group. Any message that comes in, it just ignores. So now if the agent is directly connecting with WhatsApp and sending messages directly to WhatsApp, it can message any group and it can change any kinds of configurations to get messages from any group totally.

[Kevin Ball]

So it makes 100% sense to me why this would be outside in the host, outside of the container. Right. You don't want to give the agent direct access to WhatsApp. The thing that I was curious about is once you're Inside of the container, you've passed it through SQLite, you've already got your past your like, proxy boundary. Essentially you're past your moment of control. But you mentioned there's still a separate process that is like polling the input and passing it to the agent or vice versa, translating from the agent into the output. And I was curious about that inside of the proxy boundary separation.

[Gavriel Cohen]

Yeah, that's not part of the security model. That's part of the assumption is anything within the agent's environment is the agent will be able to get access to it no matter how hard I try to prevent it. That's for better quality, better quality output from the agent and save tokens. It's all about the tokens. So for the agent to pull the database itself constantly and then have whatever comes into that database just pipe straight into the agent. You can do that. You can implement an agent loop like that and it works. You can do that. And I've implemented these really minimal versions of clause that just do that. The agent just gets whatever data gets pushed in. But that's not very efficient. So we could take it a step further. For the scheduled tasks. If I set a scheduled job to run, say I want an agent to check my email and process, you know, email, send me a message on WhatsApp. If an email came in from a specific thing that I'm waiting for. So the agent is kind of polling. It's got a tool it can use to read my email. It's polling my email inbox and checking for new messages coming in. That burns through tokens like crazy. If I'm having it polling every five minutes or 10 minutes, that's going to burn through tokens. And that's actually the kind of stuff that Anthropic was banning accounts for or blocking accounts from using their subscriptions for. So we went and implemented, I think it's about a month and a half or two months ago, the ability for the agent to set a script that runs before a scheduled task. So instead of the agent waking up with a prompt that says, go check the inbox and see if there's new messages and send a WhatsApp message if there are. Instead, there's a little script that runs. The agent writes a script. When I tell the agent, hey, do this for me, it's got an instruction saying, if this is really frequent, write a script first. Have the script run and the script runs, check something, and programmatically decides whether to wake the agent or not. And that's both for tokens and also for Context windows. So we're not standing the agent with all kinds of inputs, messages that come in to the agent's environment. We want to wrap them in a specific way. So each message gets wrapped saying who this came from, what's the timestamp, and gets presented nicely to the agent in a way that packs are immediately and nicely into this context window.

[Kevin Ball]

Okay, so I want to dig more on this. This is great. I'm loving this. So these scripts that the agent runs or is able to schedule, I presume those run inside of the container so that they're in the free for all security model. I don't know. Do you have names for these two security models like the outside and inside?

[Gavriel Cohen]

Yeah, I call them the host. Now the host process or orchestration and the agent. It's the agent runtime.

[Kevin Ball]

Okay, so I'll use those. I think the free for all is a little more fun as a term, but. Okay, so these are running in the agent runtime. Agent can write scripts. Now those get triggered based on messages or you have. It sounds like, like a cron or something like that. Or is the cron managed outside in the host and triggers an inbox message of some.

[Gavriel Cohen]

Some sort? Yeah, so the agent can schedule tasks for itself, schedule recurring tasks. So I gave an agent to my wife and she just put her in a WhatsApp group with an agent. Said, hey, this is Andy. He's your personal assistant. Good luck. And I left. And then she's, you know, in the beginning it's just like questions like you would ask chat GPT. But then she started to go like, wait, Andy, what can you actually do? Like, what capabilities do you have? And then gave her all these explanations about scheduling jobs and stuff. And then she said, okay, can you tell me when a certain item goes on sale? And he was like, yeah. And then she came to me and was like, hey, and he's going to update me when this pair of jeans is on sale. And I was like, a bit skeptical. And I was like, is he really though, or is your agent just hallucinating? A lot of times you can tell an agent something, be like, remember this. And I'll be like, great, note it. And then you come back to it and you're like, wait, what did you do with that information? And it's just like, I'm just remembering it, just noting it. Mental note. And you're like, no, you got to write that somewhere. Put it in your memory or something. Right. So I was like, is he really going to. Or is he just like, yep, I'll do that and then the next turn, whatever. So then I we asked Andy, how are you going to notify Julia if jeans are on sale? And he said, yeah, I have a list of websites that sell this product and list of product pages. And I've set for myself a recurring job every morning 9am so to visit each of the websites using the browser that I have in my environment, and I check the price and then I compare it to the previous prices. And then if it's on sale, I'm going to update you by sending you a message in WhatsApp. So the agent schedules for itself. It has these tools of scheduling tasks and it uses them at its own discretion to accomplish a task that the user asks it to do. So the agent does that by setting. It can set a cron schedule and it can set set a one off root task by just setting the time when that task should run. And then the agent actually has an MCP tool to schedule a task that the agent calls the tool. And then that process that runs inside the agent's environment sends it as a system message to the host process and the host process writes it into the agent's inbox. The reason why the agent can't just write it to its own inbox is because it's a SQLite little database. And because we've got the host process and the agent they're running in different processes, the SQLite DB doesn't actually sync between them necessarily. And you get conflicts. So you have to use a specific mode to read, and then you get conflicts and you start getting all kinds of errors if they're both reading and writing from the same db. So that's why you've got an inbox that only the host writes to and only the agent reads from. And then you've got the outbox that only the agent writes to, only the host reads from. So that's why it kind of has to do this whole loop and the agent can't write its own inbox.

[Kevin Ball]

So to make sure, I understand, for recurring tasks, the agent is essentially just scheduling a cron in its own agent runtime. But for one off tasks it calls an MCP that go out to the host process. The host process then writes a message to the inbox.

[Gavriel Cohen]

So the agent doesn't actually schedule cron in its own environment. The reason is because the agent's environment isn't always up or isn't always running.

[Kevin Ball]

Okay, this is another good question. So, yeah, okay, so they're both going through the same flow, which actually I'm guessing you then use in other types of contexts where essentially you have a tool that wraps around here is a deterministic way that I want to send a particular message to my host system. Message sends that the host schedules either on a cron or if it's a one off via a message with a timestamp, then it triggers the agent by sending it to its inbox. And then at whatever time the polling process inside the agent runtime will take say oh, it's ready and hand it to the agent.

[Gavriel Cohen]

That's very close. So there's another detail there though that the agent container spin up and spin down based on when the agent needs to be active. So when a message comes in the I can have in one nanoclaw instance running on a machine and actually we stress tested this last week or two weeks ago, one machine with 16 CPUs, 64 gigabytes RAM can run about 200 containers. Agent containers, like containers running agents running Cloud SDK in parallel at the same moment concurrently. But on a smaller machine, if I only have two CPUs, eight gig RAM, I'm only going to be able to run eight or ten agents containers in parallel. So if I have an instance and I have a whole bunch of different agents, because I've got different agents and different groups and different people, I don't want to have those containers running and up all the time. Very quickly I run out of CPUs, run out of RAM, run out of space. So the containers spin up and spin down. The persistency is in the mounted folders and in the container images. So the agent can't write something in the future, for example future cron job in its own environment that has to be written to the host. Now the way it's implemented, just to keep everything modular and have each agent, each session managing its own things and keep the host process relatively simple. The agent calls the tool. Like you said, it's a message that's sent to the host process saying this agent wants to schedule a task for this time. The host process immediately writes it to the agent's inbox, but with a process after timestamp and then the container will spin down after some period of idle by default, 30 minutes, no messages coming out from the agent, no activity. The container spins down and then the host process is doing this sweep over all the agent outboxes and inboxes, looking for messages that need to be processed. And when it sees a message that has its process after timestamp set for the current time, it spins up that container and then the agent, the loop running inside the container by default, immediately when it starts up, just starts pulling. The inbox, sees the message there, pushes it into the agent SDK. So that's the process there.

[Kevin Ball]

Awesome. Agents are getting smarter every day. But even the smartest agents get stuck without the right context and the right tools. That's where Notion comes in. With the recent launch of custom agents, Notion became the collaborative AI workspace where teams and agents work side by side. And now their new developer platform is turning that workspace into infrastructure developers can build on. What stands out to me about Notion's developer platform is how much they've built underneath the surface. The platform ships with a set of new primitives that change what you can actually do. Workers are Notion hosted sandboxes where you run custom code, database syncs, agent tools, webhook triggers without spinning up your own infrastructure. The CLI lets developers and coding agents read from Notion, take actions and deploy workers through one interface. And with the external Agent API, you can bring agents like Claude or Codex into Notion as workspace participants with real permissions and triggers, not just a sidecar tab you're copying from, pulling in research sources tracked externally, syncing them into Notion, and having an agent help triage what is worth covering. All all in the same place the team already works. Learn more about Notion's developer platform today at notion.com sed that's all lowercase letters notion.com sed to try Notion's developer platform today and when you use our link, you're Supporting our show notion.com Sed

[Narrator]

your

[Kevin Ball]

customer lives in the real world, and it's messy, intermittent connections, mid onboarding, drop offs, edge cases on devices you've never tested. Mobile apps reflect reality in a way no other Surface does. Yet from an engineering perspective, they're the hardest to understand. It's common for mobile engineers to see green backend dashboards, normal error rates, no crashes. But inevitably, somewhere there's a frustrated user watching your app spin. After a few seconds, they'll lose patience, close the app and turn their attention somewhere else. They may never come back. The worst part? Most observability tools never see any of it. Bitdrift, on the other hand, captures 100% of mobile data unsampled and in real time, so it's immediately queryable by engineers and AI agents. It's mobile observability built for the real world. Try Bitdrift today. Bitdrift IO signup Think about your mobile

[Narrator]

app source code once it hits the App Store it's out in the wild and without the right protection. Decompiling is easy for malicious actors looking to steal your IP or tamper with your software. That's where Guard Square comes in. Guardquare provides the highest level of mobile app security for Android and iOS applications and SDKs. Their advanced tools integrate seamlessly into your CI CD pipeline. We're talking polymorphic multilayered code hardening techniques and automated runtime application self protection paired with mobile application security testing and real time threat monitoring to deliver the highest level of mobile app security without compromise. Don't leave your hard work exposed. Secure your mobile applications today. Go to guardsquare.com to learn more.

[Kevin Ball]

Let's talk a little bit about Lifecycle. Right, so you've already talked about how you'll spin up, spin down. You're managing persistence. It's in the mounted folder and in the inbox outbox. So presumably these things could be as long lived as you want. They can be quite durable. How do you deal with things like context, window compaction, those types of things for one of these agents?

[Gavriel Cohen]

Yeah, the compaction and how we do that is we take a very simplistic approach and try to not reinvent the wheel and try to not build in a way where code is going to be redundant with the next update of Agent SDK, the next model release, the next version of clock code. So we're actually just using cloud code default compaction with just some instructions, minimal instructions, telling the agent what's important to retain in the context. And what's really important to retain is the sequence of messages going in and out from the user. And the agent tool calls you can drop. And actually the content of the message can be summarized and the instructions tell the agent to summarize the content of the message if it's long. But the sequence of messages saying the sequence, the order who the messages are from, the timestamps that needs to be preserved, and not necessarily all of them. You can summarize and say there's this whole beginning of the conversation that happened and then here's the last 15 messages, and then one or two of those might be really long. Summarize the actual content of the messages, but keep the wrapper saying, here was a message from the user at this timestamp and here's a response from me at this timestamp. So compaction, we let the model Opus, Claude or Codex GP 5.5, we let them handle that. And in terms of the session, it's actually just one session that keeps going by default. So the session just goes on and on and it auto compacts when it hits the limit. We set the limit a little bit below the default. So default for agent SDK is 200k at the moment. And it's kind of maybe a little bit solved with the last couple models. But the models used to get really, I think they get some kind of like context anxiety when they would get close to their context window threshold or compaction threshold. So they start to get kind of dumb, try to finish things really quick and take shortcuts. So we set it a little bit lower and set the compaction threshold at 165k and then by default it just keeps going. Same session endlessly. That works quite well. When it compacts, there's a pre compact hook that takes the full session and puts it in the agent's environment. And there are instructions in CLAUDE MD saying you've got the full context of conversations from before compactions in the conversations folder. So the agent can look through previous sessions if it needs to pull in previous context. And the agent has instructions saying save things. Kind of the LLM wiki model of just save things in your environment, create files, create folders, create indexes that specify what you have in your environment, what different files and folders have in them, and update your cloth MD to reflect what are in those files and folders and even create systems for tracking things and systems for your own memory and then just designate what that system is. And that works quite well. The issue is that at some point the actual CLAUDE code session file, the JSON L file, just starts to get really, really big. It can get to be fifty hundred few hundred megabytes and at some point it starts to break down a bit. So that's something that we need to add to at some point rotate that session and pull in some context to the new session. But actually just compacting three sessions for that chat assistant use case, it works really well.

[Kevin Ball]

Let's talk a little bit about interaction models. So you mentioned you can spin up a whole bunch of different agents. Can they talk to each other? Like what does that end up looking like? I know a lot of folks who are way down in this are like, oh yeah, I have my product manager and my sales manager and my this and my that. So how does the multi agent story work within Nanoclaw?

[Gavriel Cohen]

Yes, your agents can talk to each other and your agents can actually create other agents. So your agent has an MCP tool create agent and it can give a definition, name, instructions, what that agent is supposed to look like. And that creates a second agent in its own container, with its own file system, its own environment, own memory. And then when your agent creates an agent, it now has in addition to destination of the Slack channel you're talking to it from, and maybe your WhatsApp group that you connected to, the same agent now has another destination of Agent B. And agent A can send messages to Agent B. And that just means it can write a message that it wraps in a little XML tag saying to Agent B. And so just like it can send you a message in slack and in WhatsApp, it can send a message to Agent B. That's again just a message coming out of the agent's environment. It gets put into its outbox. The host process picks that up and routes it, instead of to a messaging app, it just routes it to the other agent and puts it in its inbox. And that's agent to agent communication. Within one Nanocla instance, it's just messages in the outbox going into the other agents inbox. And in order for me to allow agents to speak one to each other, I just need to configure them so that they have the other agent in their list of known and approved destinations. So that's both for permissions and for discovery. So the agent knows who it can talk to. The other mode is just putting them in the same channel and then just having them speak to each other through whatever messaging app. So if you want to have visibility into what they're saying and you want to have a conversation where you're part of the conversation, then you just add two different agents to the same Slack channel. They talk to each other the same way you do. One thing that is missing in order to make the agent to agent direct communication outside of the channels really useful is an approval gate. So the same way I can put an approval gate on the agent sending a message, sending an email, I really need to have the ability to have an approval gate between agents talking to each other. And a really powerful use case for agent to agent is having two different agents that belong to two different people. So I've got my agent, you've got your agent. And I can ask my agent a question, ask it to do something as part of doing that task, it can reach out to your agent and ask it a question, ask it to grab some information. If we trust each other with all of our information, then we can just let that happen, let our agents chatter behind our backs and maybe that's okay. But if you're talking to your agent about some Private things that you wouldn't want to be shared with other people. So then you want to have an approval gate before your agent sends a response and you want to see what that response is and, and verify that it's not sharing something that you wouldn't want being sent out when you have

[Kevin Ball]

that type of multi person, multi agent. And this is fascinating because we're getting into a question that everybody's grappling with now, which is multiplayer AI, does that need to be through an external channel like a Slack or something like that? Do you have a peer to peer model in this? Like how is that working?

[Gavriel Cohen]

So I think if multiple people are going to be talking to the same agent, it does make sense to have that happening in like a Slack channel. I think there's a false sense of, and this is just from like the psychology of the end user. If I'm talking to an agent in a dm, that feels like a private conversation and if somebody else is speaking to that same agent in a dm, then that gives me a false sense of privacy because that agent could just be sharing everything I'm telling it with another person in a different vms. So I think the right way to do it is if we're all speaking to the same agent, probably have that in the group and have that visible and immediately apparent to all the users. So everybody's aligned that this is a public forum and anything I share with this agent is public information. Where it gets interesting is I'm chatting with my agent. It's got all this information, very useful information that's really useful to people on my team. And the same way people on my team can come and ask me questions and I can share with them some of that information, but not share other pieces of information that I've got in my head. You do want to have your agents as they're building up this LLM wiki, this knowledge graph of everything they know, a Wikipedia of you and everything you know and everything you're working on. You want them to be able to share some of that information with other people and not share other parts. And that's where I think approval gates are interesting and are useful. I think the first step is an approval gate where every single message going out. I see. And I have to approve. And then you can start playing around with maybe classifiers. So maybe a model, a smart model. It doesn't have to necessarily be an agent. Maybe it's just an LLM call that looks at what's being shared and looks at a set of instructions and makes a call on whether this is blatantly safe and innocent information or if it should be routed to me to get my approval. And that's obviously going to be trading off a little bit of safety for convenience. So you got to make sure you shouldn't be doing that with highly sensitive information and anonymous users from the public engaging with it. But if it's for someone on my team, and I know that some of the information maybe isn't ideal for other people to have, but it isn't going to cause a real crisis. So maybe I'll allow an LLM to look at some of the responses and auto approve some of them.

[Kevin Ball]

Interesting. Okay, another slightly different topic. So I'm an engineer. First thing I think with agents is I'm like, okay, I want it to build things for me. Maybe I want to use multiple agents, you know, one that builds and one is a code review agent or things like that. But the only inputs and outputs here are messages. How do I navigate the creation of artifacts using these agents or how getting those in and out of those kind of local container agent runtimes.

[Gavriel Cohen]

So we've built internally and will likely open source this soon, maybe mid June or maybe recently, not sure. But we created our own agent factory. And you know, I know everybody's doing that. Every company that's worth its, you know, or if it's weight, it's got their own agent factory. Our agent factory reviews pull requests to the Nanoco open source project. It reviews. But the most useful part of what it does isn't actually the review. The review is somewhat useful, maybe we'll catch some edge cases. But I think the core part of the review in an open source project is really about is this aligned with the project philosophy approach where we're going. And that is a lot of taste and judgment and agents aren't very good at that, even with instructions. So they're doing the security review, code quality review. But then the agent creates a testing plan and then the testing plan goes to a testing agent. The testing agent gets a VM that's been spun up for it with the pull request branch checked out in that VM. The agent testing agent SSH into the VM runs the nano claw instance of this PR with the PR's code changes and then actually runs it. It runs some automated tests, but it actually runs it and then starts sending messages via telegram and reading out the responses. So doing real kind of QA testing, you would do manual testing just before you deploy something and it does that in a Real environment, checks results, sees first of all, I sent it a message in telegram. Did I get a response? What is the response? And then can actually also look through the logs and look through the DB and see that everything makes sense and is as it should be. And it can improvise. So if the environment doesn't have the necessary dependencies for whatever reason, it can install them, it can add test cases, and then it writes out testing results. And then those everything gets posted. The whole process of triage, review, test plan, test results, decision. At the end it all gets written out to a channel. And then at the end the first agent gets the test results and then has a tool where it can write a GitHub CLI command. It doesn't have credentials in its environment, so it just writes the command as sort of a draft and that command gets presented to us in the slack channel and then we can approve or reject. And then if we approve the command, it gets run with our credentials. So if I approve it, it gets run with my credentials. If Daniel proves it gets run with his credentials. So that's us taking the action. It's not the agents just automatically merging pull requests, it's the agents going through this process. We look at the work they've done, ask some follow up questions, do some tests ourselves, and decide to merge or crest changes or close or whatever those artifacts. So the agent is running in its environment. It writes a test plan markdown file to a specific location and then sends a message to the host saying, I've done the test plan, this is ready for testing. The host process. Orchestration, non AI process, purely deterministic, Gets the agent's message and then grabs the test file and then we'll put it in the, say, the test plan. It grabs it from the agent, the review agent that writes the plan, puts it into a location in the environment of the agent that runs the tests, and then sends that agent a message going, hey, you've got a test plan in your environment, do something with it.

[Kevin Ball]

So if I'm hearing you properly, essentially the agent is writing artifacts, whether it's a markdown file or code or whatever, it's writing that locally in a location. It sends a message to the host saying, hey, I've got this artifact here, I'd like this other agent potentially to take a look at it. And the host then either copies it or does something to pull it out of that environment and puts it over in the other agent's environment and sends it a input message saying, hey, you have this new stuff go and look at it. Is that correct?

[Gavriel Cohen]

Yeah, that's exactly correct. We, rather than having the agent write arbitrary messages to the host host, we have it. We give it a tool that it calls saying send to testing. And then it calls a send to testing tool. And then the send to testing tool writes a deterministically writes a message out to the outbox that the host gets. And the agent has to put the message in a specific location. It can't just arbitrarily write locations for the host process to read because there's all kinds of security issues with that. So there's a specific location. The agent has to put the message in its environment, the file, the artifact, the host process only grabs it from that specific location. If it's not in that location, the host returns an error message to the agent.

[Kevin Ball]

Okay, let's shift direction a little bit. I want to ask you about some of the sort of product philosophy you mentioned, Judgment for where the open source project is going. And I think you've taken a few, like, very deliberate choices in how you architect and of the forking model is very interesting. So maybe give me the big overview or the like, quick tldr and then we can dive into details of like, what is your product philosophy, what belongs in this open source project and what does not. How do you approach it?

[Gavriel Cohen]

So the product philosophy is about minimalism. There are prerequisites, it has to be secure, it's got to follow the security model. But then a key part is minimalism. Keeping it small, keeping it simple. I think this whole world, the wild west of running autonomous agents that can run bash commands and write arbitrary code, it's something that everybody should be a bit nervous about. Right? That shouldn't. For developers, for security experts, that should give you a bit of pause. Right? So I don't think when I sat down to write this, I said, okay, this is inherently something that is worrying. In order for me to be confident that when I'm adding new capabilities, new features, the project is evolving, it's staying secure. In order for other people to be confident running it, I don't think they should just assume that it's okay because it's got a bunch of stars or, you know, some other people looked at it and thought it was okay. I think people should be looking at it themselves and verifying that it's okay. So in order for it to be auditable, it has to be small. So keeping it small, keeping it minimal, that's a core part of the philosophy of the project. Small and minimal, though means that it doesn't have everything that everybody needs. So my sort of rule of thumb is I'm only going to merge something or add something if I think it's relevant for 80 to 90% of users. So if something's a bit niche, it's a very specific environment, it's a very specific use case. Even if it makes sense for that use case and it's clean, I'm likely not going to merge it. Maybe if it's really minimal, if it's only a couple lines of code and it adds something, great, I'll merge it. But if it's adding hundreds of lines of code and it's something that's a bit niche, even if everything is fine, it makes sense, it adds value for certain users. I would emerge that very intentionally trying to keep the code base small. So then if it's minimal, if it's small, it's got 80, 90% of what people need. And it means that there might be a small subset, 20% of users, that it's got everything they need and they don't need to customize it. But actually for most users, it only gets them 90% of the way there and everybody's got to add a couple things to make it work for their use case. And I think though, that that's true for any tool you use. Every tool that you use, you wish there was just that one thing that worked a little bit differently or it just had that extra capability. So the approach that we took with Nanoclaw is customization on the code level. Changing the code is supported. We're trying to support that as a first class capability. So everybody can get exactly what they want and only what you want. You can get rid of the things you don't want. So if you want it to run on Telegram, on Signal, and not have WhatsApp, then your fork only has Signal, it only has a code related to Signal, it doesn't have any code related to WhatsApp, it doesn't have dependencies from WhatsApp. And then if you want yours to format the messages in a different way, if you're using it as a purely as a coding agent and you don't want it to have messages wrapped with timestamps or some other stuff, you can change the formatter and change how messages are piped into the agent and all of those things kind of work together. If it's really minimal and really small, then people can customize it and it's we're not going to be constantly pushing out new updates and New versions that are going to break their customizations and it can stay maintainable. What it does mean though, in order to be able to customize it in a way that upstream changes are not going to break you and you'll be able to pull them in you, you have to follow a sort of modular way of coding, which is in a way, kind of just coding best practices. But you do have to code in a clean way and add things in a clean way. What that means is essentially add as many files as you want. But if you're changing existing files and you will need to, you're going to have to integrate somewhere, keep your integration points really minimal. So have 1, 2 line integration. You import something, you call it in one place, and then all of your other customizations should be in new files. And if you follow that, you're going to be pretty safe. There are going to be minimal conflicts when you're pulling in upstream changes. One thing that we haven't done a good enough job with is communicating that in the documentation, in the instructions for coding agents, communicating that to the community, to the people who are using it. There's definitely been some frustration and some challenges with people updating their versions, pulling in upstream changes when they've actually forked the repository and diverged from upstream. That's actually something that we've been working on in the last few days of just defining what is our contract with the open source community, with fork maintainers, people who have their own forks, what's our responsibility towards them and what do they have to abide by if they want to ensure that we're not going to break their fork with every new update? And what are the things, what's the surface area of the project that we can commit to? And if we do change it, we'll consider it a breaking change and we'll provide a clear, well defined migration path. So that's something that we're defining now. But I think there's a huge advantage to this approach. Ultimately we've got Nano Claw open source, and then we've got nanoco, which is a company, it's our company, we raise capital, raised $12 million. That positions us really well to continue to build and maintain Nano Claw as a free open source, MIT licensed project. Make sure that that's not going to kind of drop off and be abandoned. We're going to be able to continue to maintain it and build it as infrastructure that people can build on as a free project. People can use for their own personal use as something to use in your company in your business for your team, build services, products, platforms on top of it. As a commercial entity, we're focused on bringing agents to companies. So companies that are not building their own internal agent platform on top of nanofla, but they just say, I don't want to build it myself, I don't know how to build it myself. I do know how, but I don't want to dedicate the engineering hours to building our own internal agent platform for the market, marketing team, for the sales team. So for those companies, we're going in and helping them get set up with agents. And it means we're doing some services, FD's creating a custom deployment for each company and then managing and maintaining those agents over time. So that means that we have a lot of forks ourselves and you're incented

[Kevin Ball]

to make that easy.

[Gavriel Cohen]

Exactly. We will be the largest maintainer of nanoqlo forks going forward at some point. I mean we are already and we will be in the future. So that means we have to figure that out, we have to nail it. We have to figure out how to maintain a bunch of forks and not break those forks. And we're dedicated and that's a big focus right now, figuring out how to do that well so that we can do it for ourselves, we can do it for the community and we can have a big community around the open source project. And I think it's doable, but it is a different approach. I don't know of another project that's taken this approach before.

[Kevin Ball]

It's interesting to me. It is very AI forward. It's taking this model that we have now of software is this much more moldable, everybody can change it type of thing. I saw this change play out a little bit in the front end with the rise of things like shadcn, which is like the old model was, hey, you've got this library and maybe you extend it in some ways. And the new model is now just copy this component and then make it yours, yours, do whatever you want. And you're kind of taking that at the whole project level here of saying, hey, copy this and then make it yours.

[Gavriel Cohen]

Yeah, I love that you said Chad CN because that to me is an analogy that I have in my mind and something that I thought about and in some ways is one of the inspirations for it. And I haven't heard anybody else talk about that. I mean it's obviously super popular in front end, but it's. I don't know how well known it is more broadly, but yeah, it's it's sort of the Chad CN model. But there's a bit of a difference there because with your component library, you create your button. There isn't that much innovation happening on the HTML.

[Kevin Ball]

You copy once and you're done. You're not going to need to do the update. So you have another layer on top of that.

[Gavriel Cohen]

Because we're building on coding agents, and the coding agents are constantly changing multiple times a day. So we have to be able to pull in changes, we have to be able to expand and improve capabilities. Even if we said nanoflaw is perfect, it's complete, which it isn't, there's a lot to add. Even if coding agents were static, but the coding agents aren't static. They're constantly evolving and changing. So we have to be constantly updating. It means our users have to be able to be pulling in updates. So, yeah, it's a bit complicated, but the way we're doing it. And this was the thing. So Andre Karpathy tweeted about this big thread about claws, and he called out specifically Nano Claw and said it slightly blew his mind, which I think is the height of compliments from.

[Kevin Ball]

Yeah, you've made it now.

[Gavriel Cohen]

Yeah. And the thing that he specifically found mind blowing was this approach of using skills as the way to customize nanoclo to customize your fork. So if you add integration with Spotify, you go and modify your fork so that it connects to Spotify. So you make all these code changes, then you want to contribute it back to the project so other people can have their nanoflow agents talking to the their Spotify. The way to contribute that back. Spotify is not the kind of thing that's going to be merged into the core code base, because it isn't a capability that 80 to 90% of users need, but it's a great capability. It's really cool. Definitely the kind of thing you want to share and other people would find useful. So the way you do that is you create a skill. And this skill is not a sort of runtime skill that the agent uses to do some work for you. It's a skill that's telling the agent. Here's how you can modify Nano Claw to connect to Spotify.

[Kevin Ball]

Oh, fascinating.

[Gavriel Cohen]

Yeah. You think of that as a skill.

[Kevin Ball]

You're wrapping up, essentially the code changes necessary as a prompt and maybe a set of scripts or whatever, anything that can go into skill. And you're saying this is a modify nanoclaw to connect to Spotify skill, and it will change whatever's needed in the host process and communicate whatever's needed to the agent runtime and make it so your nanoclaw can talk to Spotify.

[Gavriel Cohen]

Exactly. So the skill standard includes with it the concept of having scripts, but it can actually have arbitrary files. So putting typescript files in the skill folder and saying this is a typescript file that you've got to add.

[Kevin Ball]

Oh, just copy this over here. Fascinating. Yeah, yeah, yeah, that's really interesting.

[Gavriel Cohen]

It's almost deterministic. I just need to copy it. But then it's not quite deterministic because I do need to integrate it in some place and that place is going to change. It's not an exact.

[Kevin Ball]

Because my nano claw is different than your nano claw. So it's going to be. Yeah, yeah, yeah. No, this makes a ton of sense.

[Gavriel Cohen]

Yeah. But we're communicating to the coding agent the intent of. Here's what we're trying to do. Here's how it's supposed to work. Go to this file, you'll need to import it there, and you'll need to add it somewhere within the function that handles the routing of the messages, but not an exact line number. And even the edit is not an exact edit. It might need to change it a little bit and add some profile parameters and the agent will be able to figure it out and do that almost deterministically. Some skills are deterministic. All I need to do so if there's a type of skill that is needed often enough, for example, adding messaging apps. So when I need to integrate with a new messaging app, those skills for the most part can be applied fully deterministically. And to do that, we just need to create a kind of barrel file. It's a registry. You add an import, you've got a little registry thing. Anything that's imported into that file gets registered and is available in runtime. So for skills like that, we add the extra overhead, the extra level of abstraction, because it's. It's a hotspot and it's needed. And there you've got a few files that you add and then you've got appends. So append only appending an import to a file and then you've got maybe something that you need to add add to a command you run. So NPM install, I need to install some dependencies. There's no conflicts there. And that can be done basically deterministically. And then, by the way, this. Most skills also have a certain amount of user instructions. So the coding agent runs all these things, adds all the Code integrates, it runs some tests to verify that the integration works. So integration tests together with the unit tests and then the agent is prompted to walk the user through authenticating with Spotify, getting the token, and it can guide you through.

[Kevin Ball]

Yeah, that's fascinating. One more direction I want to go down. So you referenced CLAUDE code a lot. You also threw in a line about being able to use GPT5 5 and you've talked about, you know, the way that the agent underlying like tool landscape is changing very quickly. So one of the things that I immediately wonder is can I plug in whatever agent harness I want? Can I use codecs? Or recently I've been going deep on using PI for things like can I swap in PI as the core agent harness? Or like, how does that layer of customization work?

[Gavriel Cohen]

Yes, we have a agent provider abstraction and that's another place where we have that registry model where you can plug in another coding agent without having to kind of mess with existing files, just add files, append to existing files and add dependencies. We have supported with skills codecs and open code because a project is really small, because you've got reference implementations there of how other coding agents were added. If you point PI at the project and say, add an integration for PI here, it will do it in like five minutes and you know, 50, whatever, a couple hundred K tokens. So it's a trivial kind of addition. It's very greenfield coding. And that's, I think, one of the ideas behind it that any capability you want to add, it doesn't matter if it's the 10th capability or the thousandth capability, it's always greenfield because the project stays really small, really minimal. So you can add that. If you add it, you can contribute, add PI as a skill to the project and there's a pull request open and maybe we'll add it soon to add ACP agent client protocol, which once we merge that, it will just support basically every coding agent. But we do integrate on the level of coding agents, so we don't integrate with light LLM and route API calls from CLAUDE codes to different LLMs. I think that isn't really working anymore. Probably hasn't worked well for a while, but in the, as we move forward, I think it's going to work. It's going to be worse and worse because the agents, the models are being trained in the harness, they're being trained in club code. Yeah, and Codex.

[Kevin Ball]

If you allow open code and you allow PI, they can handle the multiplexing to whatever model you want. Like that's not a big deal.

[Gavriel Cohen]

Yeah, if you want to use all kinds of models, use PI, use open code. But also, I mean the instructions don't really transfer over. There's a whole family of models that are like Claude. Family of models that are, you know, distillations or whatever. Claude and they probably there's some compatibility between them but when you go between Claude and Codex and Gemini, they're very different models, very different instructions, skills, tool definitions. Things don't just transfer over as. As well as. As people would like them to.

[Kevin Ball]

Well, so in that domain. Right. So I playing a lot and you know, there's a few things that Nanoclaw has done that I've stolen in different plays for some of my own play. Like you have a lot of really interesting stuff in here. But one of the things I've been thinking about is how do you create small custom agents with self tuned eval prompts for particular purposes and sometimes you want to do different models. So the thing I'm kind of wondering about is how much of the prompt of the different things of the skills, et cetera is kind of baked in to Nanoclaw. How much can you customize per agent? Where you say, for example, let's pick one of your tools. You had a messaging tool, right? That is how you send messages. Can I have a custom messaging tool per agent? Because I happen to know this one's running GPT5 and this one's running Opus and they need slightly different prompts to be able to use the tool properly.

[Gavriel Cohen]

Not by default, but you can fork the project and make that kind of change. So changing the instructions, the tool definitions of the default tools we have the ability you can set for each agent, instructions, skills, NPM packages and MCP servers and some other things, but the ability to tweak the tool definitions per agent don't have that. Maybe it's something we should add.

[Kevin Ball]

You may not need to. Right. It may be that everybody's running Claude models and or CLAUDE family models and they stay as the front runner. But yeah, thinking about this world of who knows which model is going to be best in a year and as you highlight they behave very differently.

[Gavriel Cohen]

We are moving towards CLI tools as well. So there's a whole set of tools for scheduling tasks. You got schedule, list, update, delete and we're moving towards having all of that as a CLI tool. As you start to add more and more it just gets to ridiculous amount of tools and you know, it's a big debate. But I think CLI is pretty safe. And then it starts to become less and less critical, I think, because it isn't always there in context, even with the MCP tools now that you're using, you know, tool search. So a lot of the tool definitions aren't actually in context by default. And you do have the ability to adjust your own instructions per agent. There's certain pieces of the Cloud MD that are like system definitions are about how to, you know, the environment that it's in and how to schedule things and instructions like that. Those are the kind of things you have to fork to adjust. In the end of the day though, the harness the orchestration nano clause as orchestration, it's trying to not do too much. So it isn't injecting a lot of messages, it isn't changing things, it formats the messages going in. It provides some instructions about how to use the tools. But we're building very intentionally in a way of assuming that models are going to get better, agents are going to get better. Let's leave as much as possible to the models and to the agents so that we benefit from the next update. And so the next update doesn't just make weeks of engineering work become redundant. So memory system, for example, I have no doubt that Anthropic has dozens, maybe more people on making the agent memory better. That's probably at every level from tuning the instructions to pre training to post training to everything. So we're not trying to build really elaborate memory systems that are kind of deterministic and all this kind of clever engineering. It's just a set of instructions that tells the model. Here's an idea, some guidelines about how you could save things in files and folders and move things from files to folders and reorganize them and keep an index of what files and folders you have. And you can change this definition of the memory system in this actual file to make it more or less complicated. And you know, but it's your memory system to manage as you see fit. And you know, that guarantees us that as the models get better, they're going to manage memory better.

[Kevin Ball]

So we're getting close to the end of our time and is there anything we have not talked about that you think would be important to leave listeners with?

[Gavriel Cohen]

I think one of the things I would say is last year I spent a lot of time building agents out of LLM calls in an agent framework. The one I was using was OpenAI's framework, which weirdly is also agents SDK. But that's where you're Building agents by you got an agent loop and you're defining everything and you got to deal with caching and you got to deal with the tool definitions and compaction and everything. That's really hard, right? Thinking about caching is hard. Thinking about compaction is hard. Session management there's months and months and months of work just to get yourself a basic agent that has the core capabilities that cloud code has or that Codex has or that open code has. So if, if some people out there are still in that place where they're going, maybe I'll use LangChain or Lane graph and I'm going to build an agent. My advice to you is don't do that. Save yourself the work. There's so much value that can be unlocked from using Claude code, from using codex, using their SDKs to build all kinds of wild agents on top of that with all kinds of orchestration and workflows, using skills, using instructions, using know regular good old engineering, building products and platforms on top of the existing agents. Focus on unlocking the value over there rather than re implementing the basic element, basic building block of an agent. Look at a coding agent as a building block and then build a product or a platform or something on top of that. And then in terms of I think a lot of people get stuck on which model, which agent. Don't get stuck there. Any of the frontier models are good enough. But use a frontier model when you're building. I don't try to optimize for cost if the thing you're building for doesn't make sense unless it's super optimized for cost, it might not be high enough value use case where it makes sense to dedicate your time towards building towards that. Find a use case where if you nail this, it's going to be worth spending tokens on a frontier model and there's definitely optimization to do do. But first focus on just nailing the thing, creating a lot of value, doing something that's really valuable using coding agent, using frontier model. And once you figure that out, then maybe think about the economics of it and how do you optimize a little bit.

[Kevin Ball]

Cost seems like a good place to wrap.

[Gavriel Cohen]

Sa.