# Brief 45 — founder memo: what a workflow is, and turn this memo into a source document **Date:** 28 August 2026 **Source:** a voice memo (Otter transcription, speaker label and timestamp preserved). It sets a multi-phase experiment, states plainly what the founder means by *workflow*, adds the measure of success he judges maturity by, and asks for a version diff the agent had not built. Reproduced verbatim below. The numbered reading beneath it is the agent's. --- ## The memo, verbatim > Dinis Cruz 0:07 > Okay, so here's an experiment to do. See if this works, right? So one of the comments you made was that there wasn't a lot of workflows, documents, and reference material, right? So let's add it. I'm going to record next what I mean by that. And but what I would like us to try to do is: can you do this in multiple phases? So the first phase, like you do, you grab the transcription and you extract stuff. Then can you actually write one of the documents, like a source document based on this, so this is like the sometimes I give this to you on already a massage document, like one of the documents I created earlier. You know, in a way, it's like a source document, like the the thinking and graphs document, one of the other 25 documents that we have put it on the graphs, right? So transform that into such a document. So you now have a reference document that talks about workflows. Then, can you create transform that file? Again, remember this file has to be on the reference part or the docs folder or whatever. It has to have its own folder, and inside its own folder, we're going to create the materials for it. So inside of it, you're going to create the JSON transformation of the file. We can't need a name for this process, and you're going to extract the key concepts, and basically you're going to create the graph elements and the tissaurus and the semantic graph and the ontologies. Basically, you're going to create the elements that we were defining on the thinking and graphs document, and once you have those, you then can connect them to are making the book, and you can update the content using that as reference. So let's figure out how that workflow works in there. Actually, one more thing that I'm not sure you've been doing it, but it's very important is that if you have started to make changes to the book, it's very important that we now go back to that diff view that we had before, and every time there's those changes, I should be able to read the changes between the two versions of the book and between two particular versions of a book. So my logic here is that I've already read, so this is the thing. I've read the full book that we published, the first version of it, right? Which is basically the the first release that we did for the making the book, right? So I now need a delta, a diff, with that, and ideally we need to be backed by graphs too. But even if initially just text based, but eventually should be a diff created from the graphs, right? Because you need the two graphs, because you should be delting the diffs of the graphs, not of the markdown. That would be the really test measurement of our success here. Is when we are delting and we are manipulating the JSON structure programmatically instead of having to do text comparison on Markdown, which is much more fragile, also allows to detect things like formatting changes and and other other concepts, etc. Okay, so that's the introduction bit. So the the workflow part, which is what I want to talk about, is is fundamental here because ultimately it goes to the heart of what we're doing, right? So what we're doing here is a workflow, right? So what I call a workflow is fundamentally is how you operate. You know, is the the steps that you have is a different workflow. So you can argue that when you're normally editing a book, you your workflow is you open up Word or open up Google Docs or you open up a document, you write it down, and then you save it, and you send it to somebody else. Well, that's the workflow, or the workflow I used on Linpub. I actually was editing in Markdown, which is very empowering, much easier to copy and paste, much easier to diff, much easier to sieve. And then I would basically press save, and then I had a workflow to create and to trigger an update of a PDF that was then created, and LinPub helped a little bit with that. So that's the workflow. So ultimately, and in fact, even what I just described just now in the early part of the demo, that's the workflow. So the power I, you know, what I've been trying to say in in the previous memo and in the positioning, etc. is the power in 2026 with this agentic world. Is actually the agentic workflows that we can have, which is the workflows that allows us to change the tooling and to change the visualisation and to change the comprehension and to change the context. I guess frame sets that we have to allow the author to stay in the zone. We're not fully there yet, but we're starting to get close because that's the core idea. The core idea is that if I'm editing a book, I want to make sure that I'm in the zone. I want to make sure that I edit things and I manipulate things, and sometimes I operate on meta structures where I'm operate on. He had the concepts that I want to do. Like for example, here I'm describing the sort of the universe, that kind of level two, level three key concepts that we have. That when we then put the the book together in a kind of Lego-like structure, eventually even drag and drop would be quite awesome because this goes back. Sorry, this goes back to that whole whodunit storyline. It goes back to this book has a narrative, has a set of punchlines, has a set of pacing, has a a set of introduction, has a kind of like a you know it's almost like let's try to stick up it as a three-dimensional flow that our job here is to visualise it, and I'm quite a visual person, and that's what I want to see here. So that's that's kind of big, and this is what I mean by workflows. And workflows goes to the point where I'm not just given a workflow to to operate. I can impact the workflow. In fact, let me clarify one of the things that I mentioned. I think you picked up, which is depending on your programming skills and depending on your programming ability and experience in developing and experience in engineering, you can have more or less impact on the workflows that you have. And that's where I'm saying that depends where you're operating more on the explorer, or the villager phase. The villager phase consumes stuff. The explorer also will create workflows. Will customise workflows. Will fine-tune the workflows, and it's important because there's there's always a point of diminishing returns here, right? Like the point here is that we want to make sure that we are productive all the time. We are improving, in this case the book narrative, and you could see that even me, like you know, I go on some tangents, but I don't just keep going. I go on tangents to find the sweet spot, to find almost like to move the needle a little bit further. So you could see that even now we we didn't finish all the workflows that we were doing before, but we matured them to a point where now in here we can now reuse some of them. It's like the worldly maps component, right? Where all of this becomes little piece of the puzzle. If you think about like development, you you create classes, you create structures, you create web services, you create these reusable modules. That's kind of what I do, and that's kind of how I think, right? So, the the concept then is, you know, where do you want to be as a consumer? But but also take into account that it's not because I can do all of this, for example, or even an advanced user can do even more. That that's what's needed at a particular moment in time. You know, in a weird way, my instinct is always not to change the workflow. My instinct is always, I want to be productive. I don't want to be, in a way, spending a lot of time improving the tooling. But what I do is I allow myself to go there. I I also know the point of inefficiencies where I'm like, oh, I'm doing something that is actually quite manual. I'm doing something that it can be done better, so I allow myself to go into that explorer mode because I believe you know it's it's all a cost benefit, right? I believe that with the hours or days I get back to a point where I'm now in a better state. So it's kind of like imagine you you want to cross a bridge, or when I cross something, and you you realise, oh, I need a better tool to build this. I go, okay, let me go and build the tool. Let me sharpen the saw, and using that analogy, because I believe that in two years, two hours, or two days from now, I'm going to have a better saw or a better tool to do what I want to do better. But the logic, in a way, and and for me also the ultimate measure of success is: Can I do a process without making any changes to the workflow? If I can do that, that's a major success, and and that tells me that is always the metric that I take on maturing, and that's how I know something's been productized or commoditized. Is when I do, I use it, and I don't want to change it, or changing is now past the point of you know hits the point of diminishing returns, and is not effective or productive to do it right. So and but but the logic here is, and this is why the book you know you know in a way this book could be used by somebody with the same or more technical engineering skills than I do, but all they want to do is to just use the villager part of it, right? Because you have to remember that sometimes the difference between somebody with more or less experience is just that they consume materials faster, but they still go to the same steps. Which is why I think the first book should start by the Art of the Possible, which basically means that a less experienced or less sort of used to these kind of workflows, user might consume that slower, and the more experience might consume that faster because he already has all the paradigms. Cool. All right, let's see what we can do with this. > > Transcribed by https://otter.ai --- ## The agent's reading ### What the memo asks for, in the order it asks 1. **The experiment is the phasing, not the subject.** The founder is testing whether a memo can be walked through the estate's own layers one step at a time: *"can you do this in multiple phases? So the first phase, like you do, you grab the transcription and you extract stuff. Then can you actually write one of the documents, like a source document based on this."* Phase one is this brief. Phase two is a source document written from it. Phase three transforms that document the way the pilot was transformed. Phase four connects the result to the book. 2. **Why he wants it: his own comment, quoted back.** *"one of the comments you made was that there wasn't a lot of workflows, documents, and reference material, right? So let's add it."* The gap is real and it is now measurable. The book's graph counts **27,002 words** of prose across seventeen chapters, and in them *workflow* and *workflows* together appear **6 times**. The book is titled *Creating a Book Using Agentic Workflows* and has almost no text about workflows in it. 3. **The folder shape is specified, not left open.** *"It has to have its own folder, and inside its own folder, we're going to create the materials for it… you're going to create the JSON transformation of the file… you're going to extract the key concepts, and basically you're going to create the graph elements and the tissaurus and the semantic graph and the ontologies."* That is the pilot's folder, item for item: a source, a JSON decomposition, an anchored extraction, and the dictionary, thesaurus and ontology views projected from it. The instruction is *do to this what you did to Thinking in Graphs*. 4. **He asks for a name and the transcription hides it.** *"We can't need a name for this process"* is *we also need a name for this process*. The process is the one in point 3: a document arrives, gets a folder, and comes out as a graph. Two halves of it already have names in this estate and the whole does not. ### The definition, which is the reason the document is worth writing 5. **A workflow is how you operate.** *"what I call a workflow is fundamentally is how you operate. You know, is the the steps that you have."* Deliberately mundane, and the examples make the point: opening Word, writing, saving, sending is a workflow. So is markdown plus a save that triggers a PDF. So is this estate. The word is not reserved for automation. 6. **The 2026 claim, which is the document's central claim.** *"the power in 2026 with this agentic world. Is actually the agentic workflows that we can have, which is the workflows that allows us to change the tooling and to change the visualisation and to change the comprehension and to change the context."* Four things a workflow can now change that it could not change cheaply before, and one purpose for changing them: *"to allow the author to stay in the zone."* 7. **The measure of success, stated flatly, and it is a good one.** *"the ultimate measure of success is: Can I do a process without making any changes to the workflow? If I can do that, that's a major success… that's how I know something's been productized or commoditized."* A workflow is mature when you stop wanting to change it. This inverts the usual read of the six days: the releases that changed the machinery are not the achievement, they are the cost, and the achievement is the day the machinery is left alone. 8. **Explorer and villager are about impact on the workflow, not about skill.** *"depending on your programming skills and… experience in engineering, you can have more or less impact on the workflows that you have… The villager phase consumes stuff. The explorer also will create workflows. Will customise workflows. Will fine-tune the workflows."* The pair is a **phase** a person is in, not a class of person: he says *phase* both times. The same reader can be a villager on Monday and an explorer on Friday. 9. **The instinct is not to change the workflow.** *"my instinct is always not to change the workflow. My instinct is always, I want to be productive… But what I do is I allow myself to go there."* The trigger is noticing a manual step: *"I'm doing something that is actually quite manual… so I allow myself to go into that explorer mode."* And the bound is cost, both ways: *"there's always a point of diminishing returns here."* 10. **Sharpen the saw, with the payback period named.** *"you want to cross a bridge… and you realise, oh, I need a better tool to build this… Let me sharpen the saw… because I believe that in two years, two hours, or two days from now, I'm going to have a better saw."* The transcription's *"two years, two hours, or two days"* is a spoken correction landing on hours and days, and it is the honest range for a tooling detour in this estate. 11. **Maturing beats finishing.** *"we didn't finish all the workflows that we were doing before, but we matured them to a point where now in here we can now reuse some of them."* The WCLM is parked, not abandoned, and this is the memo that says why that is a normal state rather than a failure. 12. **The reusable-module analogy is the founder's own.** *"If you think about like development, you create classes, you create structures, you create web services, you create these reusable modules. That's kind of what I do, and that's kind of how I think."* Worth keeping because it is the clearest statement of why the estate is built as folders that can be lifted out. ### The book asks 13. **The Lego structure and the three-dimensional flow.** *"sometimes I operate on meta structures… That when we then put the the book together in a kind of Lego-like structure, eventually even drag and drop would be quite awesome… this book has a narrative, has a set of punchlines, has a set of pacing, has a set of introduction… almost like let's try to stick it up as a three-dimensional flow that our job here is to visualise it."* This is a **product ask**, not a document ask, and it is the first time pacing and punchlines are named as things to see rather than things to feel. The book graph shipped at v0.6.10 is the data this would need; nothing renders it that way yet. 14. **Art of the possible first, restated with a reason.** *"the first book should start by the Art of the Possible, which basically means that a less experienced or less sort of used to these kind of workflows, user might consume that slower, and the more experience might consume that faster because he already has all the paradigms."* Brief 42 asked for the same opening; this memo adds *why*, and the reason is about reading speed, not about what a reader is capable of. **The same content serves both audiences at different speeds.** That is a stronger argument for one book than the one the record held. 15. **The villager can be an expert.** *"this book could be used by somebody with the same or more technical engineering skills than I do, but all they want to do is to just use the villager part of it… sometimes the difference between somebody with more or less experience is just that they consume materials faster, but they still go to the same steps."* This settles a disagreement on the record. The researcher's map found the book leans villager while brief 40 judged it explorer, and treated that as a contradiction to resolve. It is not one: the book is villager-shaped by design and an explorer reads it faster. ### The diff, which is a requirement and is not built 16. **The ask.** *"if you have started to make changes to the book, it's very important that we now go back to that diff view that we had before, and every time there's those changes, I should be able to read the changes between the two versions of the book and between two particular versions of a book."* He has read the published first version; what he needs now is the delta. 17. **The bar he sets for it, and it is the harder one.** *"ideally we need to be backed by graphs too. But even if initially just text based, but eventually should be a diff created from the graphs… because you should be delting the diffs of the graphs, not of the markdown. That would be the really test measurement of our success here."* Named reasons: markdown comparison is *"much more fragile"*, and a graph diff can tell a formatting change from a content change. 18. **What exists and what does not, checked.** A version diff exists for the **first edition** at `/v1/book/changes/`, built by `gen_changes.py` from the release tags, and it diffs extracted **text**. Nothing diffs the three v2 books, and nothing diffs graphs. The book graph that would make a graph diff possible landed one release ago at v0.6.10: seventeen chapters decomposed to 27,002 word nodes with a per-chapter identity ledger. The ledger is the piece that matters, because it carries an identity across an edit, and a diff of identified nodes is a different object from a diff of lines. 19. **The honest state of the ask.** The founder wants v0.1.0 against v0.2.0 of this book. Between those two versions **four files changed** — the front matter, the colophon, chapter 4 and appendix C — 30 lines added and 14 removed. A text diff of that is available from the tags today. The graph diff he actually wants needs a graph stored per book version, and only the current version has one. That is the gap, and it names a piece of work rather than an omission. ### One thing the memo does not settle 20. **Which book part one belongs to.** Point 14 says *"the first book"*. In this estate *the first book* has meant the first edition at `/v1/`, and brief 42 asked for the same opening in *this* book, the making-of. The reading taken here is that he means the first book a new reader picks up, which is the making-of, because that is the book brief 42 was about. If that is wrong, part one is being planned for the wrong volume.