The brief · 2026-10-31__rc1-paper-review · briefs/2026-10-31__rc1-paper-review/batch-07-pages-22-to-32.md

Batch 7: pages 22 to 32: why the team really stopped, constraints, the site as scaffolding

The editor, in the conductor's session, 31 October 2026. Kept as he gave it.

Okay, on page 22, yeah, as before, this content and maps are a great for a dedicated article about worldly maps. And again, like the whole, the map still to come, that's all logistics, right? That's just stuff that it doesn't make sense to that user at that moment in time. In fact, we need to really get our synthetic users to be brutal here, right? It's like, you always need to ask me, why do I need to know this? Do I understand the context? Why is this here? Like, does this make any sense for me right now, right? So the page 29, what I have, it's a weird place to start telling this story. Because again, and also like the 95%, it's an interesting point, but it's just a footnote, right? Like it's just the fact that, you know, we have some restrictions, and actually the main reason we stopped was because the main reason we stopped because I could have jumped to another session, right? You know, that had more credits, right? The reason we stopped was I was about to go on stage and we hadn't had a good way and tested way to dynamically consume what would have been changed during that. So in a way, this was a good example of me coming up with an idea that was far too advanced for the tech stack that we had. Because my idea would be, hey, if I'm presenting for an hour and a half, you know, why can't you just be working on my slides an hour, half an hour in or an hour in, so by the time I get there, there's new things changed. But that's a good example. For that to work, I needed a UX that showed me the delta, a UX that allowed me to see, you know, when something appeared, what was new, what was not new, to have a UX that, and the workflow that makes sure that you couldn't break anything, right? Because again, the reason why I was thinking about let's lock V1 is because I want to keep making changes, but I don't want to have a bug that suddenly when I go to present, it's not there. So this is a good example of how I kind of was a bit ahead of myself. I was like actually almost trying to use something as a product that was still very Genesis. But, and that's why we stopped, right? Because we didn't have the idea to do that. But the interesting point of the 95% is not that one. The interesting point is that constraint of having to jump from a couple of Claude sessions, which what I have now, when I have a couple of Claude sessions that I need to move because I sometimes max them out, right? What is good about that is actually forcing me to do better engineering. It's forcing me to onboard agents now. So we now got, for example, a much better onboarding process where the new agent comes along, you know, shuts down the previous one, wraps it up, connects everything, seals it, and then replaces the public key. And then we say, from now on, nobody else can be this user apart from me. Now, nobody else can be this agent without from me. That, in a way, that only happened because we didn't have, you know, bazillions of millions of tokens to blow. We didn't have just unlimited token storage. So in a way, this is a good example of constraints are very important. And everywhere you work without constraints is actually very dangerous because you get away with a lot of stuff that sometimes you want to figure out better ways to do it. So I agree that a lot of the advantage of that is actually good engineering and the quality of the setup because I have to now onboard agentic teams very fast. So, and again, that's one of the advantages of open source, right? And okay, so now on page 30, I like the whole concept. It's important to understand, but that's is too much to show here. Also, I think I mentioned that a bit later, but that's a different concept. That's on a concept of the techniques that we use to orchestrate, the techniques that we use to control, the breaks that we put into the system, the fact that I can go, you know, and this is the power of the GitHub repo, right? Once you have a GitHub repo that is communicating, and again, we should be explaining to the user how it communicates to GitHub messages, communicates to email FS in the file system, or issues FS, etc. So again, we should be showing examples, we should be showing quotes. In fact, that's a big thing. Like, we should be going back to the history, and you should be showing comments and things and messages from one agent to another agent and observations that, like, interesting moments in time, which is actually why I think the historian is the one that really should be digging this out, because the historian should be the one that's reconnecting this and creating some of these mappings. Okay, page 31, another massive picture that missed QA. And page 32 is where I basically have that wrong break analogy, right? Because in a way, we don't trust breaks, right? Because they're great. We trust breaks because we use them all the time, right? And actually here, we could introduce... So I think here we can introduce a new type of screenshot, which is the sort of like the companion, right? And sort of the idea that, you know, we explain these concepts, right? In this sort of more rich kind of infographics, right, that we have here. And because in a way, I feel that the story here is the story of the site. The site is the scaffolding. The site is what enables all of this to happen. Is the workflow, is the memory. You know, how come our agents are so productive? Well, they're so productive because they have focus. They can read context. All of that stuff comes from this site that we created that, in a way, is what gives everything power.