The Adam Sand Report - Thursday, August 13, 2026
Adam Sand demonstrates his agentic engineering workflow using Claude, CMUX, and multiple AI models working in parallel. A planner agent creates contracts stored in Linear, builder agents execute code in parallel, and a verification step runs independent checks before feeding results back to an orchestrator. He achieves 80-90 daily GitHub contributions by managing token limits and model selection across planner, orchestrator, and builder roles.
Chapters
Hello everybody, welcome to another late night livestream. I do these things late at night because I don't doubt that they will suck. I am not the primo livestreamer. What I do like to do is meet and connect with other people who are working on cool stuff and hopefully just have some people to vibe with late at night while I'm working on things. And what I'm working on is slowly improving my abilities in the agentic engineering world and trying to build the stuff that I think needs to exist. And so I more or less just do these kind of co-working sessions, um, and it's a way to give myself that extra kick in the pants on Thursday to work late to get more of the stuff that I want to get done done and hopefully meet some other people. And I've shared all kinds of collaborative ideas, I've learned things I've taught others, and we tend to just go down creative rabbit holes. And I generally get an unlock every time I do this. And this week, I, as you might see on the screen, I've had a pretty big unlock in terms of my ability to kind of accelerate my pace, if it were. And it is through using, um, uh, right, through using Cmux and I really enjoyed their, their canvas mode. So the ability to just have multiple sessions going. And this week Claude released a feature called send message. And so essentially it can send messages to other sessions, which if you're like following any of this stuff about loop engineering and graphs, which is all just hype around the software development lifecycle, um, you have heard about the idea of like The agent— you build the system that builds the system. You don't, you don't build it yourself. And so that is kind of what's happening, is this main session, uh, runs the other sessions. So this is wave 3. And so essentially, my— about my context limit has always been about 3 waves on my own. So previously I would have like 3 Claude codes, or a Claude code and 2 Codex, or, you know, some variation there within. And I would be using my coding assistant, if you would, coding coach, you might say, to help me. And that coding coach came in the form of a Slack agent that is connected to a Hermes agent. And so I would use this channel and Linear to communicate with Marcus. And so you would see where I would have— I'm still actually operating 2, I would say, kind of 2 waves or 2 loops at once. I'm still doing one the old way on 2 different, on 2 different projects. So essentially, as you'll see here, it's like I will set up a wave and then I have, okay, this is like wave 1, or kind of, and wave 2 and wave 3, kind of like these would be individual sessions that I'm running manually. And Claude Code or Codex, or, you know, any split therein. And, and as you can see here, like, I initiated 3 and then eventually rolled in a 4th once one of the 3 was done. This is kind of how I was doing it. Now I'm doing it a new way, which has allowed me to kind of stretch cognitively to 5 and then eventually 6, because I found out that I could initiate opening a new session from Cmux using the Cmux CLI. So then it was actually able to just initiate another session for me. And so this builder session ran it for me, right? It built, it built it up for me. And if this doesn't make sense, I could probably wire something up in Lucidchart to kind of show you visually what I've been working on. And so I'll do it this way. And hopefully this will help make sense of what I'm doing. Continue. Let's go. I built a boatload of lucid charts in my time, so forgive me if it takes a second for this account to load up, but I'll kind of explain how I've been doing it. All right, we're gonna go home and we will start a new one. So this is how my machine has essentially been running. So previously I would have Marcus, right, which is Hermes agent. It's like the, uh, he is essentially aware of the business. If you see over here, you can see his whole Obsidian second brain deal, right? So You've probably heard a lot about this kind of concept of a second brain. And so you can see here, like, he's got all those relationships and, and everything like that. There's actually multiple— there's an OpenClock connected to this as well. And so there's all these nodes of files, attachments, then all of these interconnected relationships, and then a file for basically everything that's happening across this brain. And that's about a year worth, and I have 3 of those across 3 different machines. So going back to, you know, what is Marcus? Well, Marcus can code by himself. Like, I can just basically say, hey Marcus, go write— like, go like basically, um, do a feature, right? And then he can go and then pull the PR And I can basically get another session open up to basically verify and then merge. Like, I can do everything, I can do everything in, in here, but it kind of just gobbles through tokens. And so what ended up happening was I went a new way. I said, okay, Marcus, I want you to essentially build a plan, right? And then what I would do is I would say, okay, Build a plan, and that would be like session 1. And then I would say, okay, now what I want you to do is go through and write me— I'll kind of put it down here. I'll say I want you to essentially create a spine and a contract, right? And he would put that in linear, and I would do this 3 times. He would write 3 spines, 3 contracts. So then I would end up with, uh, with 3 spine 3 contracts in Linear, right? And then I would take those to Claude Code or Codex depending on which one is better this week. Actually, I'll delete this. Claude or Codex. Duplicate this. So this has been— this is where it was a little while ago, and it was— and, and this was working good because then they— I would then, um, I would use— if I was using Claude, then I would— I created a skill called the independent validation, so I have IV, and then I would run this with the opposite. So I would say, okay, if I'm in— I'll kind of say We'll see. Me. And I would have— so I would do an independent validation with the opposite. And then what would happen is that these would go back to the build, the plan building, right? And he would verify the pull request against the plan, and then I would then go and I would do Oopsies. I would then trying to— here we go. And then I would basically jump in at this stage and verify and merge. That would be my next plan. And this was a cool process. I enjoyed this process and I was able to get consistently, you know, if I go to my GitHub profile, If you go to my profile, this phase was allowed— was allowing me to get, you know, 3, 19, 6, 15. I was doing good. Now when I was letting my Marcus or any of my other agents do it— so if I go to who I'm following, if I go to look at Vito, you can see that Vito was able to do more contributions and like a kind of stopped using my OpenClaws and Hermes to do contributions, but for a period I had several of them doing it, and it was trying to find— there's one. Actually, I can get to it this way. So just to give you kind of perspective, so click that one, click that one. So if I go here, you'll see this one, right? Again, when I was letting them code, they could get more contributions. 31, 35, right? 19. Like, that's what, what they were able to do. Same thing. So I would have several of these agents running at once. Like, you can see this one, 45 contributions. 36. So using the agents to code, right, in that— in this original— in this original thing, this worked well. You can replace Marcus with Claudio, with Vito, with Devin Prod. Like, we had all these other agents doing it, and this was— this was fast, and it was— it was enjoyable. But since then, I went to this process where Marcus would build a plan, then he would write the spine and the contract. So spine is like the initiation prompt, the contract is what existed in Linear, and then take— basically copy-pasting those, um, spines into CloudCoder Codex, telling them to point back at the contract, go do the work, understand the guardrails to do the work, and then using the opposite agent or the opposite coding platform to do the independent validation. They would essentially either verify, refute um, or cosine, and then that would come back to the planner, and then the planner would say, yep, that's what we wanted, I would verify and merge, right? That worked well. And that's where I was starting to get my own days of 30, 30 and 40 contributions. And my kind of my peak was here, 69 contributions on July 12th. That was like my best day. So then I went back and I'm like, okay, and, but then this is how it would go. I was still hand rolling this. So I would have days where I would be making a lot of contributions, I'd be getting lots done, and then there'd be days where I'd be building and planning and business would come up and I'd still trickle out contributions. Then, um, and then what happened was on Saturday of last week is when I figured this out and I got to 86 contributions and that felt really good. So Sunday took off, church, Monday I came back and it was again— this is like, this first time was like 16 hours. I was still watching this thing. I was like 8 hours on, 4 hours off, 8 hours on. Then I took Sunday off. This day I started at 3 o'clock, went till midnight, 9 hours, got the same number of contributions done. And then the other time I did this at like from like 6 o'clock till midnight and I was able to do 83. And then I had a slow day, right? Because then I'm like, I'm like kind of like I've been hammering away. I'm going back to building and planning, and then here we are today. So what have I done since this plan? So the new plan has been, okay, I've now— it's similar to this, except I guess the easiest way to say it is it's kind of the in the sandbox and outside the sandbox. So I kind of have to say, okay, let's draw a sandbox of sorts. And so this will be our sandbox. Okay, so say dev sandbox. And let's put this up here. And so this is where the work is being done. So outside the sandbox, right, there will be— in this, I've been doing this with Cloud Code, so I have the Cloud Code desktop app. And this would be where I would essentially put together a plan. So if I pull up CloudFirst here, so this is where I've been running this wave from. Okay. And so I would say, okay, I want to review the handoff. And the handoff was essentially a— I guess what happened, I got to say what happened outside the sandbox versus what happened inside the sandbox. That's probably the best way to explain it. So coming back over here, so in Claude Code, I'm going through what's what is called Matt Pocock skills. So we'll just kind of put this as this. This is a skill, Matt Pocock skills. And to accomplish this, I've followed a process of first using what's called a Wayfinder. So there's the /wayfinder skill, and the Wayfinder skill is largely a process of, as it says, kind of finding your way. And so it's to take a big chunk of work or a big idea and helping me to work through it. So the idea here is like, okay, I don't— like, I have this like big idea of something I want to do I don't know exactly how I would approach tackling this problem. Walk me through that. Walk me through how I'm going to do this. This is typically something that I'm going to do with a high frontier model. I'll be honest, I use Fable a lot for this one. I've heard that you don't necessarily need to, like Luna Max is pretty smart. I have my Hermes agent and OpenCLAWS running on Groq 4.6 now. It's super smart. Um, I've done Wayfinders with less, but like, let's just say that you just want like a million tokens and, and a big model for this, right? And so the Wayfinder session, the whole idea is that it, it has a couple of sub-skills that it uses, um, which is Grill, right? So it's a grilling session. So grill me with docs, and you can look up Matt Pocock skills, they're free. And, um, And then the domain modeling. So these, these 2 skills essentially help you to walk away with a big piece of, big piece of context, right, about what— like, it asks you questions so that you can clarify your thoughts, end up with something that you actually want. Now, what ends— tends to happen from there is there's kind of a main pathway with a sub-pathway, okay? And so you might go to a prototype, so /prototype. Now this isn't going to happen every time. Essentially, if it's visual, if it's front end, if it's a function, if it's a workflow, if it's something where you need to see it to like know if it's going to be what you want, then you're going to prototype. So this is not a mandatory Not a mandatory step. And so this here will actually design a prototype. I should say, um, it will build an ugly version of your thing. So the idea here is like you don't necessarily want to go fully into production and building something inside your code base before you even know like Would I like this if it existed? And so to kind of show you what that translates into in reality, if I go here, this was the prototype. I don't— is this server up? Okay, so this is the prototype that I was building, right? It's not very pretty. It's not the way, like it's not even like the actual environment. Like if I go here, oh. here, here, here, and here. This is what this looks like, right? Like this, if I go schedule this week's jobs— actually, this is now since moved closer to the prototype. Like, this is kind of like what this would look like. So the fonts are proper, everything like that. So if you go to the prototype that I was just showing you, um, this does not look like that. These little emojis Stuff like this, you know, this like kind of status thing here, you know, these pills down here. So this is not what it actually looks like, but what it allows you to do is to kind of like say, okay, I want to see what this would roughly look and feel like if I was to do this stuff, right? If I was to make this, would this work and function the way I would want to? And you can iterate through this, right? So if you go back to this, this Claude Code session, right, this was a long iterative process of going through all of this prototype. And this is after doing the, after doing the process of the Wayfinder skill. But you get an ugly version of your thing. And again, you don't always have to do this. But then if you do like your prototype, then it becomes a PRD section. So /to-spec. And what this does is it allows you to build essentially a product requirements document. So PRD, product requirements document. So essentially, it's like your spec, your scope of work, right? And allows you to kind of say at a high level, get everything into one thing. So you're going to have intentions, user stories, epics. Epics are like, we'll call them epic features, things that you really want. Functions, design, guardrails, the math behind something, the scope of functions it has access to, the database model, database or data model. Like, this is where everything exists to kind of say what good looks like or what done looks like. So I will typically go, this will be one session, right? So I can say, okay, this is one session and then this is the Whoa, that color as a second session. And then this will be a third session. And again, these are manual. And within this session, I will tend to have another— and like, I'll, I'll continue that conversation. Usually I'll keep the same conversation for my 2 issues. step. Right? And so the to issues is where you can then break this down into a number of steps. I can already tell I'm gonna need more room here. And so what to issues does is allows you to break down the PRD into developer sprints or waves or sessions or sessions. or like milestones. However, whatever language you want to use, it essentially breaks it down into chunks that would be roughly the size of a context window. Yeah, that's the main goal here, is to say like, what is the size of, or the slice of work that would fit into an approximately into a context window and would be a meaningful place to stop so that the next thing, right? So that the next thing would— you wouldn't want to start the next thing until this thing is done, if that makes sense, right? Well, how do you define that? You break that down to issues, and then it can put this anywhere. It can put this in a Markdown document, it can put it into GitHub issues, it can put this into— it can put this in ClickUp, it could put this into where I put it, My like place of choice is Linear, right? I like putting it into Linear. And essentially, if you look at it, the spec is the project and the issues are the— are the— like in Linear, they call them issues. You have a project and then inside of a project you have issues. There's a natural hierarchy that makes sense. You can have this live as part of a higher level thing, which is an initiative, right? So you can have an initiative that that has projects within it that have issues and then issues and sub-issues, and issues can block issues or issues can ungate issues, and issues can be dependent on each other. Linear is a really great software development lifecycle tool I found that allows me to carry context and shift the— make sure that we're not ever exceeding the size of a context window, but we're always making sure we're maximizing the ability to create good documentation. All of this is done in Cloud Code with these Matt Polkock skills. So then once my issues are created, right, then what I have is the desire to start moving towards the sandbox. So then essentially what you end up with is a We're going to say a planner agent, and then that is outside the sandbox. Okay, then we're going to go inside the sandbox where we're going to have a— come up with a different shape for this. We will have an orchestrator agent. Then this is going to need to be bigger. We're going to have an orchestrator agent that essentially fires into builder agents. We will make our builder agents the pentagon. Then you have a builder agent. We'll go builder. 1, and we'll have several of these. And I found that my context limit is about 5. So I'll have builder 2 and then builder 3. And I know this is slow to focus on while you're watching it, and this might be better to like cut up into clips for you guys, but essentially once we get builder 4 And you guys, I know you guys can already know what I'm doing, and so you're going to have to watch it. This is like neat, that needs to be neat and tidy. And we'll go Builder 5. So I kind of have— all right, so now this one, I've gone through 3 waves of building this. So the first time I had my Planner agent, and he built a plan, and then that plan was stored in Claude's scratchpad. Like, it's stored in a temporary file on my desktop. I eventually want to move this to an actual sandbox, which then is how you get to this coveted software factory thing. And, um, and that is pretty cool if I get there. That's like kind of the next step. And then what happened is The, the orchestrator agent then said, okay, we're gonna run this across these 5 builders, 'cause the, the reason that I started with 5 was I asked the planner agent to look at my spec and my 2 issues, and I told it that I wanted to run the next skill in the Matt Pocock skill library, which is the /implement skill. And so this is gonna have a number of sections. Right? So these would be builders, right? And this would be the /implement skill. And you can equate this to somewhat like the goal skill. You can, you can run the /goal/implement, and that's how it runs. And then what it does is it builds the issue assigned, which is coming from, in my case, linear, until completion, right? And you get to define Completion, and in my case, I will show you what completion looks like. And it the planner agent knows about the dev sandbox. It's aware of what exists inside this thing and what I want to exist. So the planner is aware of the sandbox, but it's outside the sandbox, if that makes any sense. So it knows what's going to exist. So then it writes the plan, and I take the plan. So I basically copy paste a prompt that it tells the orchestrator agent where the planner agent put the plan. And I asked the planner agent to look at my skills and say, hey, how many mutually exclusive or collectively exhaustive lanes can I run? Essentially, how many agents can I run in parallel given these 17 issues that came from this spec, you know, can I run 3 at a time or would they create conflicts? Can I run 5 at a time or would they create conflicts? And it said you could run these 5 lanes and they wouldn't impose upon each other's work, so they could build without breaking or making assumptions about what the other is building. Essentially, you could have 5 people working on this project and what they're building wouldn't, like, wouldn't cross lines or boundaries or conflict with what they're doing. So I was like, okay, so build the plan for that. And then it built the plan for that, and then I copy-pasted that plan into here. So I said, okay, I said I should probably leave the note behind here. Plan out how many non-conflicting lanes could work at a time. Without breaking what each other are working on according to my spec and issues. And so the output of that is a plan and a handoff. So we have a handoff.md and a plan.md, essentially. It gives it its own name. And output is a plan and a handoff. And so I then hand the plan to this guy. So if I put it here, so at first I gave the plan to, to To org. And then it would also, in this plan, I would have the 5 startup prompts. It'll be aware of the 5 startup prompts for the 5 lanes. So then again, me manually, I was then saying, okay, you understand the plan? Yep. Okay, I'm going to start. These 5 sessions, right? I told it like, I'm gonna go create— I'm gonna basically go into, um, my CMUX window and I'm going to start 5 cloud sessions. So coming back here, I basically have my plan here and then I would say, okay, I'm going to start 5 sessions. So if I had a new I've created a new workspace. I would basically just go Claude, and I would give it— it would fire up Claude, and then I would say, okay, I'm gonna go— I would give it its handoff prompt, and I would go split window, and I would go Claude, and then I just put another one, Claude, and I'd split it again. And I go Claude, and I come down here, this one, I'm going to split it again, and I go Claude. And then I come down here, I go split it again, I go Claude. And now I have 5 sessions, right? And then I could switch my view to this, uh, to this canvas layout, and then I could move these around and resize them however I wanted so I could make them bigger or smaller. But I would basically do that and I would say, hey, you have these 5 sessions and it does this process where it, it inspects what sessions are available and it connects those sessions. And then I would paste the 5 startup prompts, right, for each of these. So I can already see that this should be resized a little bit to look a little nicer. And then this could come down here, and this could come down here, move this down here, and I would paste the prompts right now. This has since improved, so I would then paste 5 startup prompts. Now what happened here is when I did this, for some reason it couldn't find my Builder 1 session, and I had to do some Banging around. So on wave 2, what we did is we said, okay, I want— I'm going to first initiate the 5 sessions, connect the 5 sessions, and then you're gonna use your new send message feature to send the startup prompts to the 5 agents. And then by wave 3, what we figured out was that we would just tell it to open up its 5 sessions and paste the 5 startup prompts. So I got to the point where I didn't have to go split, split, split, split, Claude, Claude, Claude, Claude, Claude, paste, paste, paste, paste, paste. I just went, here's the plan, use the CMUX CLI to start up your 3 builder agents. And it did. And so the builder agent, it functions in a way that it's building towards— it's using the /implement /goal essentially. So it's doing the /implement itself, and then these agents are building away. Now in wave 2, I would then say, okay, when these are done, tell me. And I would tell the builder agent, I would say, hey, give me my independent verifier prompts. So I'll say, give me my IV prompts. And I have a skill called independent verification, and I would go into Codex so that I would come over to Codex. And you'd see, you see here, verify, verify, verify, verify, verify, re-verify, re-verify, re-verify, verify, verify, right? And that was running the independent verification because my old way, right, is I would run Codex, I would let it run and do its job, and then I would— if I'm in Codex, I would pop up a terminal session. So I would click this button right here, and then I would run my independent verification skill Independent verification, and then I would essentially take something from here to tell it to go independently verify that what was done was done. By wave 3, the orchestrator agent would then run its own independent verification sessions. I would say, okay, well, within the sandbox, I probably have to create them first. So I'm going to say, okay, I need to do my independent verification section. So it would have a verifier and it would prompt the independent verifications on its own. So essentially making it so that I didn't have to do it. Right? It would do it by itself for me, and the— and it would always use a different model. So it would use something like Codex CLI to do that. So Claude Code would be running Codex CLI for me. Now that is very token expensive, so there's a cheaper way to do it, which we started— which we were doing back before, which is using something called Greptile. And Greptile is a code reviewer, and it essentially reviews your code for you. And so it reviews your PRs, and it basically gives you a response of like, oh, how good was this? So it'll— it will review your code for you, and it'll give you a confidence score. And this one obviously did a 5 out of 5. So let's go to one that's Not perfect yet. And so this one here, right, will actually tell you what was wrong with your code. So it will— and again, essentially there's something called a grep loop, right? So it'll tell you, it'll run through logs of what it did to try and verify your code. And this costs like $1 or $3 each time. So it's fairly affordable. When each builder gets to the point of pulling up a pull request, it would then run its own grep tile review. It would say, okay, your instructions that you were given by the orchestrator agent is to run the grep loop. Essentially, when you finish building, make a pull request, create a pull request, And then let Greptile review it. And so each time it does this, and this is where the loop part comes in, is essentially it's saying, okay, well, you go figure out if you did a good job because the Greptile looks at your issue essentially and says, was this what it was supposed to be? Right? And so it will then loop back to the builder agent, actually to the orchestrator agent. Now this is starting to get ugly. Maybe I should not use this one. I'll use this one. That's where it would loop back and say, all right, I want you to— it would say, hey, you got a 4 out of 5. Then the orchestrator agent would go back to builder 5, and say, hey, this is what you have to do because grep loop, the greptile review said that it wasn't right. The greptile will even load up a browser window and test your app for you. Now, that's not the only test we do. We run linters, there's GitHub CI Actions. You'll see when I click on a given pull request like this 4 out of 5 one, you'll see that there's more to it than just greptile. There's multiple loops that run Because you also have Vercel agents. There's— if we come down here, there's all these checkers that will, that will run, and sometimes it's 3, sometimes it's 8, but all of these checks run. There's also Claude code review, so it goes through and cycles itself, right? I'm not sitting there copy-pasting or anything like that. It's just running through the grep tile loop, which includes the CI/CD gates, which includes the Claude code reviews, it includes any Vercel comments. from the Vercel coding agent, and it cycles and cycles and cycles until it thinks it's done, right? So then when it thinks it's done, that's when it gets a response. I can just go back here. So then when it thinks it's done, it then goes out to the independent verifier. Same thing, it's kind of saying, okay, now I'm the final say on this whole thing, and it's going to say, do I think it's done? So this is like verification 1, right? And this is verification 2. 2. So this saves me hours and hours and hours of checking diffs and essentially quality checking what is done because you just can't— why did I do that? You know, perfection is the enemy of progress. Whatever, it's not perfectly aligned. So what happens is verification 2 happens. This saves me from jumping in and reading endless diffs where I have to go, okay, this is the file that changed. And I have to go through and try and read this. And again, think about this. This is like hundreds and hundreds and hundreds of lines of code, it's very, very difficult to say, read this and imagine in your head to say, okay, what is like, what is the genre of what I am trying to do here, right? Like, what is, what is it that I'm really trying to accomplish? This is like kind of step one of trying to understand what you're kind of what you're trying to build, right? And then once you've got your genre, then you're kind of going down another, another layer of like, okay, let's read, let's read the functions, not the, not the labels, if it were, right? And so you're trying to say, okay, well, what was asked of this? Like, what was, what, what did it try to do, right? And then like, you can't keep this much context in your head. If I give you a phone number, right, you're going to struggle to remember a phone number. Like, if I give you 10 digits, say remember 780-553-1724, and I tell you to remember that phone number, tomorrow you're going to forget. But yet AI, large language models, these coding agents have a context window of a million tokens. Like, it's like, it's like they can remember 3 Harry Potter books. It's just smarter. It just can hold more context in its head. The orchestrator agent, and again, this is all within this one dev sandbox. This is all living inside of this dev sandbox. It even had the ability to open up a new seat. Still inside the sandbox in this workflow, It still was able to open up another seat, a 6th seat, because it kind of said, okay, seat D2, right? So I'd see A, B, C, D, E. It opened up seat D2 and did some work. And so, and that was in wave 3. We're moving into wave 4. And so once the independent verifier says that it's good, the independent verifier essentially has, uh, some of— some states, uh, like it essentially has The skill outputs a few different options, so it can have not verified, so it couldn't verify it. It'll have verified not done. It'll have verified. Oh my goodness! Sorry. It'll have verified not done. Verified done. verify, it'll have, um, refuted, and it'll have cosigned. Those are essentially the statuses that come out of the independent verifier. Depending on the status, it goes back to the orchestrator agent, who then goes back to the builder agent and does it. And then usually it'll run through a grep loop, and then it'll come— the grep loop will come back and it'll say, okay, grep loops of this builder agent, grep loop, come back. Thinks it's done. Okay, out to the independent verifier, come back, and it moves to verified done. But it couldn't co-sign because of a reason, goes back to the orchestrator agent, back to the builder agent, back to the grep loop, you know, quality code comes back, says it's done, goes up to the verifier. Verifier says, yep, I've co-signed. At that point, it then merges the PR for me. Right. And so at this point, it then takes that and very— I'll put it— well, actually, it goes back to the orchestrator, which I'm just going to duplicate at this point because it's getting messy. It'll go back to the orchestrator agent who will then merge. There we go. Who will then merge. The PR. And now what happens is once that's happened for all 5 builder agents, I can then go back to the planner agent, right? Who will then— like, so this then comes out of the sandbox and back to the planner agent, who then cleans up the desk. It basically prunes the work trees. It makes it so that everything is nice and clean again. So then we can— so when the Planner agent's done, I can then say, okay, oh, we're going to start up another wave, right? So then it can say, okay, well, we finished that wave, let's go start another wave. And so then my Planner agent usually at this point has like 120,000 tokens of its million-token context window because it just gets the ledger from the orchestrator agent which tells it the brief summary. So like this one will be at a million tokens. This one, this one here, like this is a million tokens. And this will probably be like, this one will probably like Opus 5 Extra High, right? So I guess maybe that might be helpful is to know like what are the models here. So Planner Agent, Fable 5 High, right? Then this one here, the Orchestrator Agent, will be like Opus, um, extra high. Now the, the individual builder agents, it depends on what the plan is. So it will say, you know what, this is a simple task, um, this could be done with like Sonnet on medium. And then it'll say— Oh shoot. Why'd I do that? Oh, that was dumb. I'm gonna delete that. So we're gonna say this one says Sonnet 5 medium, and then it might say, you know what, for this Builder 2, you should be using Fable 5 Hi. And it'll give you models for each of these. Now, grep loop runs on its own models, right? Um, so it basically— grep loop runs on its own thing. And then there's Cloud Code Review. The independent verifier, it uses a completely separate model. So it says, I'm going to go to our completely different LLM. So it says, I'm going to go totally outside the box. It's going to go Codex CLI. Luna Max, right? And that's what's going to run the independent verifier. And then again, going back to the orchestrator, so this is just like a clone. I should just make these a similar color so you kind of know that this is again same color. This guy, right, is still that Opus High, and then it goes back to the planner agent. So this guy is usually full. by the time I'm done. Like, this is 1.25 million tokens sometimes. Like, this thing's full, right? And then these ones here are probably going to go, you know, let's say 500,000 to 800,000 tokens. Like, though, if I go back over to here, you'll, you'll probably see— it'll see, okay, clear to save 930,000 tokens, clear to save 678,000, clear to save 405,000. Clear to save 600, clear to save 384. So you'll see that like each of these agents is going to fill up reasonably high, right? And then there's these Codex CLI ones. I mean, they probably burn— they probably burned like 200,000 tokens, um, inside that one. But again, it just fires up the independent verifier. This one fires up, you know, this one could fire up 25 times. You know what I mean? Like, this could go 25 times depending on how many times it gets out of the grep loop, thinks it's done, and then goes back to the orchestrator agent who then kicks off the independent verifier, and then back to the orchestrator who's full, and then goes back to Fable 5 High Planner agent, which again is living at the project level, right? The to-spec. So it's aware of the Wayfinder, the prototype, and the to-spec. Right? And it's got the 2 issues, which has then created the plan, which goes to the planning agent. So in a way, you can say that it links down to this. Be the best way to do this, like this, like this, like this. And essentially, the /implement sessions is kind of going in, is housed inside here. So I should make this this color so it kind of makes some sense, right? This guy, like, this color so it makes some sense. So it's not the same agent, but it's a different agent, um, but it's like it's aware of the plan. And so this has been allowing me to essentially get a far better output. Now what I'm excited to do, what I'm excited to be able to do next is to essentially fire these dev sandboxes up on their own machines. Because then what you could do is you can— I mean, I don't even know if I need to go this far. I really don't. It really comes up in, like, when you actually have, like, customers using a system, because then you can technically duplicate this sandbox And you can say, I wanna pick— if I have a bug, right? Well, then you can run multiple sessions of this to say, hey, go fix this bug or make this feature and roll it out 3 times, right? And roll it out to each potential solution to a third of our customers and see which customers like it the best, use it the most, seems most performant. So like, this is like where this can go. Like, once you— once I nail this, I know that I get to the point where then in a production environment you can have staging, production, development, and you can start to really build the software factory, as it were, which is really exciting and has been really fun for me. So there's probably a ton that could be made better. About this. No doubt I'm probably not doing this as well as it could be done, but it's kind of what's been exciting me a ton lately, and I wanted to share it with you, and I really wanted to get it down on paper how I'm doing it. So I hope that makes sense. So I'm going to finish up a few things here. I'm going to make these builder agents I don't need these builder agents. We'll make these, these agents red. Yeah, because then grep loops will be green because grep tile is green. And then make the independent verifier, make him. Yeah, so I think that makes some sense. Yeah, that makes some sense to me. Yeah, so that's kind of it. I don't really know where else to go from here. I think that makes for a good live stream. If you guys have any questions, reach out to me. I talk about this stuff every Wednesday on a podcast— on a podcast, a, uh, a webinar. It's live, unscripted, Winning Wednesday. You can find it on roofingbusinesspartner.com, and, uh, we do those things every Wednesday. It's completely unscripted. You can join us I love to talk to people about this kind of stuff. Love to collaborate and connect. And, uh, thank you so much for watching. Bye.
