NanoClaw and the Rise of Personal AI Agents

27:32We 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.

28:17And there are instructions in claw.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 the different files and folders have in them, and update your Cloud.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.

29:00And that works quite well. The issue is that at some point, the actual cloud code session file, the JSON-L file, just starts to get really, really big. It can get to be 50, 100, 200 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, to 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. 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?

29:39Like, 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? 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've connected the same agent it 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 WhatsApp, they can send a message to Agent B.

30:41That'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 nanopah instance. It's just messages in the outbox going into the other agent's 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.

31:19So 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.

32:00And 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.

32:31So then you want to have an approval gate before your agent sends a response. And you want to see what that response is and verify that it's not sharing something that you wouldn't want being sent out. When you have 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? 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.

33:04I 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 VM. 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.

33:45Where 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.

34:17And 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.

34:56So 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-improve some of them. 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, one that builds and one is a code review agent or things like that.

35:32But the only inputs and outputs here are messages. How do I navigate the creation of artifacts using these agents or getting those in and out of those kind of local container agent runtimes? So we've built internally and will likely open source this soon, maybe mid-June or maybe recently. I'm not sure. But we created our own agent factory. And I know everybody's doing that. Every company that's worked or its way that's got their own agent factory, our agent factory reviews pull requests to the NanoCode open source project. It reviews, but the most useful part of what it does isn't actually the review.

36:12The review is somewhat useful. So 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 testing agent SSHs into the VM, runs the NanoClaw instance of this PR with the PR's code changes, and then actually runs it.

36:58It 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, you know, testing, you would do manual testing just before you deploy something. And it does that in a real environment, checks the results, sees, first of all, I sent in 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.

37:32It can add test cases and then it writes out testing results. And then 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.

38:12If Daniel approves, 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 press changes or close or whatever. Those artifacts, so the agent is running 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.

38:59It 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. 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.

39:40Is that correct? Yeah, that's exactly correct. We, rather than having the agent write arbitrary messages to the 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, you know, 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.

40:18The 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. 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 very deliberate choices in how you architect. And the forking model is very interesting. So maybe give me the big overview or the quick TLDR, and then we can dive into details of what is your product philosophy? What belongs in this open source project? And what does not?

40:55How do you approach it? 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. That shouldn't, for developers, for security experts, that should give you a bit of pause. 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 if it's okay so in order for it to be auditable it has to be small.

42:03So 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.

42:40But 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 merge that. I'm 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 of things to make it work for their use case.

43:14And 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.

43:55It 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 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 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 have to follow a sort of modular way of coding, which is in a way kind of just coding best practices.

44:45But 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 one two 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.

45:32There'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 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 will provide a clear, well-defined migration path.

46:17So that's something that we're defining now. But I think there's a huge advantage to this approach. Ultimately, we've got NanoClaw open source, and then we've got NanoCo, which is a company. It's our company. We've raised capital, raised$12 million. That positions us really well to continue to build and maintain NanoClaw as a free open source MIT license 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, you can build services, products, platforms on top of it.

46:59As 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 mouth off, 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 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, FBs, creating a custom deployment for each company, and then managing and maintaining agents over time.

47:32So that means that we have a lot of forks ourselves. And you're incented to make that easy. Exactly. We will be the largest maintainer of nano club 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.

48:12I don't know of another project that's taken this approach before. It's interesting to me, like it is very like AI forward. It's like 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 Shad CN, 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. 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.

48:46Yeah, I love that you said ChatCN because that to me is an analogy that I have in my mind and something that I've 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 sort of the Shadzian 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 level. You copy once and you're done. You're not going to need to do the update.

49:19So you have another layer on top of that. 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 Nanoclaw is perfect, it's complete, which it isn't. There's a lot to add, even if coding agents are 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.

49:50So Andre Carpathy tweeted this big thread about Claws, and he called out specifically Nanoclaw, and said it slightly blew his mind, which I think is the height of compliments from Project Propathia. Yeah, you've made it now. Yeah. And the thing that he specifically found mind-blowing was this approach of using skills as the way to customize Nanocl, 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 Nanocl agents talking to their Spotify.

50:27The 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 and 90 % of users need, but it's a great capability. It's really cool. It's 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 Nanoclaw to connect to Spotify. Oh, fascinating. Yeah, you think of that as a skill. You're wrapping up essentially the code changes necessary as a prompt and maybe a set of scripts or whatever, anything that can go in a skill.

51:07And 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. 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. Oh, just copy this over here. Fascinating. Yeah, yeah, yeah. That's really interesting. It's almost deterministic. I just need to copy it.

51:44But 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 line number. Right, right. Because my nanoclaw is different than your nanoclaw. So it's going to be, yeah, yeah, yeah. No, this makes a ton of sense. 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.

52:17It might need to change it a little bit and add some 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.

52:54time. So for skills like that, we add the extra overhead, the extra level of abstraction, because 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 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, 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.

53:35So 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. Yeah, yeah, 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 GPT-55. And you've talked about the way that the agent underlying 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 Codex? Or recently, I've been going deep on using Pi for things.

54:12Can I swap in Pi as the core agent harness? Or how does that layer of customization work? 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 the 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.

55:06And 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 1 ,000th 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 AdPy as a skill to the project. And there's a pull request open, and maybe we'll add it soon to add ACP, Aging 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 like llm and route api calls from cloud 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.

56:01They're being trained in Cloud Code. Yeah, and Codex. If you allow OpenCode and you allow Pi, they can handle the multiplexing to whatever model you want. Like that's not a big deal. Yeah, if you want to use all kinds of models, use Pi, use OpenCode. But also, I mean, the instructions don't really transfer over. There's a whole family of models that are like Cloud family of models that are distillations or whatever, Cloud. 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.

56:35Things don't just transfer over as well as people would like them to. Well, so in that domain, right? So I'm playing a lot. And 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, eviled 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?

57:14How 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 GPT-5 and this one's running Opus, and they need slightly different prompts to be able to use the tool properly? 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, models 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 you may not need to right it may be that everybody's running clod models and or clod 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 and as you say highlight they behave very differently we are moving towards CLI tools as well.

58:17So there's a whole set of tools for scheduling tasks, 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 a ridiculous amount of tools. And 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 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 Claude MD that are like system definitions about how to, you know, the environment that it's in and how to schedule things and instructions like that.

59:06Those are the kind of things you have to fork to adjust. In the end of the day, though, the harness, the orchestration, NanoClaw 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.

59:48So 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.

1:00:27And you can change this definition of the memory system in this actual file to make it more or less complicated. But it's your memory system to manage. as you see fit. And that guarantees us that as the models get better, they're going to manage memory better. So we're getting close to the end of our time. Is there anything we have not talked about that you think would be important to leave listeners with? 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 is also agents SDK.

1:01:11But 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 Claude Code has or that Codex has or that OpenCode has. So if some people out there are still in that place where they're going, maybe I'll use LangeChain or LangeGraph and I'm going to build an agent, my advice to you is don't do that.

1:01:50Save yourself the work. There's so much value that can be unlocked from using Cloud 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 instruction, agents using, you 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.

1:02:29And 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. Don't try to optimize for costs. If the thing you're building for doesn't make sense, unless it's super optimized for costs, it might not be a high enough value use case where it makes sense to dedicate your time 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, 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.

1:03:10And once you figure that out, then maybe think about the economics of it and how do you optimize low-women cost. Seems like a good place to wrap.

1:03:34Thank you.