The diff: v2.0.0-rc1 to v2.0.0-rc2

changed # Gen Z Generation ZX Developers (GenAI Startup Edition)

changed v2.0.0-rc1, v2.0.0-rc2, 2026-10-19. Release candidate 1 2 of the second edition: not signed off, not an official version.

changed Read it as a reader first. Then, if you are Dinis, read it with a pen. And if you started a company because of something in it, tell us: that is the first entry in the measure.

changed ## 1. 2. You are lucky to be here

changed I discover things I can do. That is the sentence I keep coming back to when someone asks what it is like to work the way I work now. I discover workflows. I follow an idea, and I can execute it, often the same afternoon. The feeling is not relief, and it is not fear. It is closer to wonder, and now that you know who this book is for, I want it to be the first thing in this book, it, because it is the first thing I would want you to feel.

changed I know that is not what you hear. What If you are starting out, what you hear is that AI took the jobs before you got there. If you are my age, what you hear is that it is too late for you. I tried to read one of those the first kind of essays this month, in Business Insider, under the headline "I thought working in AI would put me ahead of the curve. Two years in, I've never felt more behind and tired of the topic." I could not get past the paywall, so I cannot tell you what it argued. In Europe in particular, I think young people are being fed a lot of fear about AI, and are not embracing it the way they should. That is my reading, not a measurement, and this edition still owes you a proper answer to it.

changed I have seen several in my own lifetime, each a revolution that changed whole industries. industries, and if you are my generation you have seen most of them too. The dates are the commonly recorded ones.

changed A couple of years ago I wondered whether we had missed the boat; it felt as if all the big things had been done. Now the pieces of the puzzle are landing again. This is the biggest opportunity of your career: career, whether that career is starting or is twenty years in: the moment when you can still be a player, before things stabilise, as they always do, until the next big thing.

changed For a long time technology has not worked for you. Your generation If you are Generation Z, you in particular was were handed a technology stack designed to hook you, and to make you a passive user. There was some creating, but mostly you were a consumer, living in a world of advertising, attention and dopamine. I believe that will one day be treated the way tobacco is today; that is my belief, and the evidence is still being gathered. The 2018 book had a draft chapter on dopamine that already called phones' attention-grabbing activities "the new smoking".

changed Then use the rest of the book the way Where do you land? describes: find your centre of gravity first, and read the chapters marked for it before the others. If you are here to start a company, know where you are heading: the centre of the book is the part called Start the company, and the hands-on part at the end is where you form it, price it and ship it. The chapters before them are the ground those stand on, so do not skip them. Connect the dots backwards is about how to learn, and its first lesson is that your path will only make sense looking back, so you do not have to see it now. You have to start.

changed That, in the end, is why the title says developer. Craftspeople made their own tools. In the past they did it out of necessity; now you can do it again, because the tools can be made to fit you, and because, as Everyone who can brief an agent is a developer argues, the bar has dropped. The person who has spent twenty years inside a problem is the craftsperson here, and the first tool they make may be the first version of their company. It is still your name on the work, and it is still your thinking. You think with the AI; you do not delegate your thinking to it.

changed ## 2. 3. Everything is connected: graphs

changed The detective's board is the easiest way in, and it is why I think your generation a reader of Generation Z will find this chapter easier than mine my generation did. In Follow the rabbit holes I said that people underestimate you: you the young: they are very good at connecting the dots, very good at finding things, very good detectives. That is my experience, from my family and the young people I have worked with, not a study. But it is what thinking in graphs is: tracing what an unfamiliar thing connects to, trusting a claim because of where it came from, asking what else breaks if this one fails. The graphs book has a line for anyone who thinks this sounds exotic: "you may already think in graphs without ever having called it that."

changed If you want to own code in production and answer for it, this is your chapter as much as the detective's board is. And if you are a founder whose agents wrote most of the product, it is yours too: this is how you read what they made at the altitude you need, the stories at the top, without pretending you have read every line.

changed Here is the thing about graphs that I most want you to take from this chapter, because it is about how you feel when you look at everything there is to learn. learn, or at everything a company needs before it exists.

changed ## 3. 4. Where do you land?

changed Take someone's first job job, or the first product of a company that does not exist yet, and draw what it depends on. Put the person at the top, with the thing they need to get done. Under that, the things that serve the need: the way they work, the tools, the models those tools call, the computers the models run on. Now order it twice. Down the page, from what the person sees every day to what they never see. Across the page, from the brand new and badly understood on the left to the everyday thing everyone takes for granted on the right.

changed Why do I care so much? In 2022 I gave a talk for the Open Security Summit on why Wardley maps changed how I think, and listed eleven shifts they caused in me. The eleventh was: "Wardley Maps gives me inner peace (allowed me to understand why things happen)". Once a thing is on a map, placed and connected, I stop carrying it in my head. The map also tells you what to build and what to buy, and whether a market exists at all: a commodity layer is a hard sell, and the custom building on top of it is where the market is. If you are about to start a company, that last sentence is the first thing the map does for you.

changed This is a lens, not a label. A software vendor has spent thirty years trying to be all three for its users, and in Software vendors should become villagers and town planners I argued that users are now better explorers of their own needs than the company will ever be, so the company should let them explore on top and sell them the maintenance of what they build: "What stops me is not building it; it is maintaining it." The same handover, from the one who explores to the ones who maintain and own, is how a team works, how a career moves, and how a career moves. one-person company grows into one with a second person in it.

changed Work out your centre of gravity first, using the test above. Then read the chapters for everyone, and the chapters with your badge, before the others. An explorer will want the chapters on explorer coding and on building fast with agents early; a villager the ones on shipping shipping, on selling and on your own newsroom; a town planner the ones on controlling your agent, on the record, on serverless for real, and on reading code as a graph. Then come back for the rest; you will work with the other two every day. day, and if the company is yours, you will hire them.

changed The last part, dated 2026, is hands on: workflows you can set up this week. week, and the company you can form, price and ship this year. It will be renewed as the tools and the programmes change; the argument in the rest of the book should not need to be. Whether the book should one day be grouped by centre of gravity, rather than only marked, is a question I have not settled; for now, the badges carry it.

changed ## 4. 5. Connect the dots backwards

changed If you are coming to this from somewhere else, from running a team or team, from a job that never involved code, or from twenty years in a field whose software you are about to build yourself, that sentence is for you. You cannot see where this goes from here. Nobody can. So you have to trust that the dots will connect, and trust your gut.

changed For Dinis: your own dots, connected backwards. The article asks which three make the best story; this SG/Send above, and The Cyber Boardroom and MyFeeds below, are three candidates. Are they the ones, or is where they go. the story elsewhere?

changed If you have spent years doing something other than programming, that is not a gap in your CV. It is the discipline you are about to intersect. The 2018 chapter on learning said that "being a better musician, artist, athlete, car mechanic or philosopher will make you a better developer", and that is truer now, because the wall of syntax and setup has come down, and what is left is knowing what to build and for whom. That is what you bring. bring, and for a founder it is the advantage.

changed It is still your responsibility. It is still your name; the work is still done under you. you, and if the company is yours, so is everything the agents build in it. This is not you delegating your thinking to generative AI; it is you thinking with it. I do it when I write: I ask the agent helping me with this book to double-check my quotes, to make sure what I am saying is coherent, and to find the evidence behind every statement. The name of the author of A Mathematician's Lament, which I remembered wrongly in the memo behind this chapter, was corrected that way.

changed The frame the rest of the book hangs on. What generative AI is and is not, what happens between your prompt and the answer, why the word developer now means anyone who can brief an agent, and the kind founder's way of building this book is mostly about: building: explore first, call it what it is, then hand it over.

changed ## 5. 6. What generative AI is

changed I was right about the five years and wrong about where to look. What arrived was not the AI I was describing. So before this book says anything else about what you can do, or what you can build a company on, I want to be exact about what it is talking about.

changed In a talk I gave in Lisbon in June 2024 I said hallucinations "Are a FEATURE when creating content and when we want creativity, But are a BUG and PROBLEM when we want facts, evident and trust". I still think so. If you want a story, you want the model to wander across those connections. If you want a fact, you want it held to the ones you gave it. Most of the trouble people have comes from asking for the second while set up for the first. If what you build for your customers needs facts, build for the second from the first day.

changed Most of what this book says should say generative AI, not AI. For a while this edition was described as the AI edition; I decided, while the first draft of it was being written, that it is the GenAI Edition, because there is a play in it: Gen Z, Gen AI. And after After Gen Z comes Gen Alpha. Mark McCrindle, who named them, puts them as born from 2010 to 2024, so the oldest are sixteen in 2026, and after them Gen Beta, from 2025. The boundaries are not official; no body sets them. The two generations in the title are who the book is written for first, not who may read it. If you are sixteen and reading this and you are sixteen, the book is for you too. this, read on.

changed ## 6. 7. Lenses, roles and loops

changed What generative AI is explained what a language model is. This chapter is about what happens when you use one, from a single prompt to an agent that runs for hours. It is very important to understand this workflow, because once you understand it you see that it is not magic. And that is why you want this level of understanding: so that you can be the one who defines the constraints and how it works. Whether you are leaving university or leaving twenty-five years of a profession to start a company, this is the chapter to understand before you build anything on these tools.

changed The role description is the lens: who you are, what you care about, what you refuse, how you work. Every role on the site has a role.md that says exactly that. In the newsroom, in How I work with Claude, I put it this way: an agent is a session with a particular focus, and in practice it is three things: a few documents that explain the project, a role.md for this agent, and a session that reads those before it does anything, named for the role. That is enough to start. The same model sits behind every role; what changes is the description and the question. If your company's first team is a set of agents, this is what each of them is, and Controlling your agent: RiskMandate is about what each of them is allowed to do.

changed The point that matters most is this: the model never runs a tool. It writes a structured request, a tool name and its arguments. The program around it, often called the harness, decides whether to run it, runs it, and adds the result to the conversation. That is where the control lives, and it is why Controlling your agent, and security for the agent era agent: RiskMandate puts the rules there and not in the model's good intentions.

changed ## 7. 8. Everyone who can brief an agent is a developer

changed I was right about the direction and wrong about the door. In 2018 the way in was Git, version control, spreadsheets, automation, even Slack. I was giving advice, and the bar of entry was very high. Now it is very low. If you run a team, a ward, a shop or a department, and you have never written a line of code, this chapter is for you, because the you. So is it if you have spent twenty years inside a profession and are about to start a company on what you know. The definition of developer has widened and you are already inside it.

changed Now those same people can build full applications, with a real interface, real data and real logic. At a conference someone called them "citizen developers", with the tone people use for a problem: employees outside IT building things IT will have to clean up. I think it is one of the best things to happen to software in a long time. And it is not only citizens. It is the employee developer, the business owner developer, the expert in a domain that technology has served badly for decades, building the thing they actually need. That last one is the founder this book is for: the person who has spent twenty years inside a problem and can now build the first version of the answer themselves, with agents, instead of explaining it to a team they could never afford. As the newsroom put it in The expert founders, "Execution just got cheap." The citizen developer is the spreadsheet grown up.

changed That is why this edition kept the word developer in its title. When I planned it, I asked whether it should be Generation Z Developers or Generation AI Developers or Generation Z professionals. I like the word developer, and I think it is more right now than in 2018, because this generation all have to be developers: they all have to create. Then the readers became two generations. The entrepreneurs I see starting companies are mostly from my own generation, Generation X, the subject-matter experts, often the parents of the Generation Z readers I started with. They are developers too: they are coding, with agents. Together they are Generation ZX, which Gen ZX: who this book is for, and what it is for explains. The oldest of them the Z half were 22 when I wrote the first edition, and are 30 now. It is not only for them. Anyone who can brief an agent to build something is a developer, and developer: the graduate, the manager who has never coded but knows exactly what her team needs needs, and the expert of twenty-five years who knows exactly what the product should do and has been telling vendors so for a decade. The last two have the hard half of the skill already.

changed A working application built by the person who needs it is the best brief ever written. It says exactly what the user wants, what they do first, what they never use, and what matters to them, without anyone having to guess. But that is also where the mistake people make is: treating the brief as if it were already a product. A working app is not yet maintained, secured, documented, tested, versioned or able to scale. Those are the non-functional requirements, and the explorer who built it never had to think about them. Security, reliability, observability, cost, documentation, support: this is the work of the villagers and town planners, and Explorer coding, not vibe coding, and the handover is about getting it to them.

changed So here is what you cannot do if briefing is all you do. You cannot tell whether the thing you were handed is safe for other people to rely on, because you cannot read the record it left. You cannot tell a working prototype from a maintained tool, and the two look identical on the screen. And you cannot check the agent's work against anything but its own account of it. For a manager, that gap is a risk to the team. For a founder, it is a risk to the product and to the customers' data, from the first customer onwards. Most of what follows in this book, from Facts, evidence and the record to Controlling your agent, and security for the agent era, agent: RiskMandate, exists to close that gap, not by teaching you to code, but by teaching you to ask for the evidence and read it.

changed For Dinis: the article plans "what the question of what the briefing-only developer cannot do" do as interview question 6, and the material gives only the non-functional requirements list. Your own answer, with one example of a brief that was not enough, belongs here.

changed ## 8. 9. Explorer coding, not vibe coding, and the handover

changed ## Why not From vibe coding to explorer coding

changed The phrase people use is vibe coding. It is Andrej Karpathy's, from a post in February 2025: "There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." He was describing throwaway weekend projects.

changed People have always built software with whatever they controlled, and for most of them it was a spreadsheet. Spreadsheets won because of the feedback loop: change a cell and see the result, a read-evaluate-print loop for people who would never call it that. Everybody was already exploring; it was just very slow, because anything beyond a spreadsheet meant writing a document and waiting for someone else to build it. What has changed is that Now the loop is now fast for anything: an app, a workflow, a customisation of a product, a change anything. It is the best thing to happen to software since the interface of a single moment. spreadsheet.

changed Explorer coding is not a way to ship. It is a way to find out. And what What explorers produce is the best brief there is: a working app says what its user wants better than any document, because it runs. That is the first half. The second half begins when somebody else wants it.

changed In October 2026 Harvard Business Review published an article on turning vibe-coded prototypes into tools a company can use. Its argument, as its public summary and one author's post put it: generative AI has made building software feel almost free, so argument: the prototype is the easy part, and turning it into a tool people rely on every day is the hard part, which they call the deployment gap. The post's opening line was: One author's post opened: "'Build or buy in the age of AI?' Wrong question. The real one is: 'Who will fix your mess?'" I have read the summary and the post, not the full article, which is behind a paywall. paywalled article.

changed Second, the gap is not a place to stop. It is a handover between people with different skills. Explorers are good at finding find what is needed. Villagers are good at making make it reliable: tests, data handling, releases that do not break it, and now behaviour policies for the agents that work on it. Town planners are good at running run it at scale, scale and they own it in production. The article's own warning story, a European bank that piloted a Swiss startup's tool, built its own prototype instead, and went back to the startup a year later, is not a story of a weak team. An explorer team was asked to be villagers and town planners as well, on a regulated, data-heavy, daily-use tool, and those are different jobs. tool the startup had already hardened for many clients.

changed The post also offered a test: would your team accept a bonus tied to how this tool performs in production? I like it, because it has a name in the Wardley frame: it is the moment the town planners take the code and answer for it. More of the industry already says so: the so. The Linux kernel's rules for AI coding assistants say "AI agents MUST NOT add Signed-off-by tags" and "Only humans can legally certify the Developer Certificate of Origin", and Origin". Fedora's proposed policy says "The contributor is always the author and is fully accountable for their contributions." We cannot make an explorer accountable for code they never read. We can make the team the work is handed to accountable, and the town planners above all. And "who will fix your mess?" should never have one answer: if the code In a company of one, that team is open, anyone can. you.

changed The handover is where the people who make things last take over, and their craft has a canon. Design, in the sense that design is how it works and not decoration, became a mandatory step in how my agents build interfaces: every change has to be simpler, and reverting it should feel worse. The wider design canon says every element must earn its place, which applies to an API or a command line as much as to a screen. And place. Christopher Alexander's A Pattern Language, from 1977, is where software design patterns came from; its lesson for the town planner is that code is a space people inhabit. The villager's second version has to be designed; the town planner has to live in the code. This book names that canon where the villager's chapters need it.

changed The first edition had a third outline here, Refactoring: what it is, and how to apply it to your life. Refactoring is the villager's verb: changing the structure of a thing without changing what it does, with a test to prove it. Applied to your life, it is the same move. Build a company: build fast to find out what you want. Then, your customers want, then, before you they depend on it, slow down and make it something you they can rely on.

changed # Part: Getting the job job, or making it

changed The part the first edition called your CV, rewritten for 2026. 2026, for the reader going into a job. You are hired for a workflow now, not a language; the way to show it is to act as the job you want before anyone gives it to you; and the place to show it is a newsroom of your own. In 2018 I said act like a founder. Now you can be one, and the next parts say how.

changed ## 9. 10. Hired for the workflow

changed The data points the same way, and I will give it to you with its limits. In Microsoft and LinkedIn's 2024 Work Trend Index, 66% of leaders said they would not hire someone without AI skills, and 71% said they would rather hire a less experienced candidate with AI skills than a more experienced candidate without them. In the same study, only 39% of people using AI at work had received training from their company. The skill is mostly self-taught, which means anyone can start. PwC's 2026 Global AI Jobs Barometer, built from more than a billion job adverts in 27 countries, put the wage premium for AI skills at 62%, up from 57%, and found jobs asking for AI skills growing about eight times as fast as the job market as a whole. Those are adverts, not hires. Gartner predicted that 40% of enterprise applications would carry task-specific agents by 2026, up from less than 5% in 2025, and two months earlier that over 40% of agentic AI projects would be cancelled by the end of 2027, for cost, unclear value or weak risk controls. Both are forecasts, and both can be true. Together they say where the bottleneck is: not the models, but people who can make agents do useful work, safely. That is the person a company wants to hire. It is also the person who no longer needs to be hired to build the first version of something.

changed - Use it in your next application. One analysis, one figure, one thing they have not seen. Or in your first sales call; the material is the same.

changed ## 10. 11. Act as the job you want

changed And a few lines later: "What's interesting is that there is nothing stopping you from doing this!" That was true in 2018 and it is more true now. In 2018, acting like part of the company meant pull requests on their open source and conversations with their developers, which is still a good route if you write code. What has changed is that the tools to do real work for a company, before they have hired you, are now in everyone's hands, whatever the job. The product brief, the market analysis, the release plan, the event page, the migration runbook: an agent and an afternoon get you a first version of any of them, and Hired for the workflow said why that is the skill companies are hiring for.

changed What I can say without the memo is what every piece of this chapter already says. Whatever shape the interview takes, the person on the other side has one question, why should I hire you, and the best answer to it is a link to the job you have already been doing. If the job you want is a company of your own, the question is the customer's and the answer is the same link.

changed ## 11. 12. Publish, publish, publish: your own newsroom

changed So here is my hypothesis, untested until a first book proves it: a book is a curated, ordered set of finished articles, plus the editorial thread that connects them. The thread is my part: choosing, connecting, adding the nugget. This edition is one test of it, and How this book was made, and what you made says how it went.

changed Two honest limits. The writing pipeline is a pattern to copy, not yet a kit. And a rule in a prompt is a hope: only the rules a hook or the build keeps are enforced, so mark which is which. A site like this is also pure client side, the way Serverless, for real asks your product to be.

changed Each part of an email buys the next. The subject, a few seconds of attention, buys the first line. The first line buys the paragraph. The first paragraph buys the decision to read the email, and the email buys the article. Nothing further down gets read if something higher up did not earn it. Most mail clients show a preview of about 140 characters next to the subject, so the first sentence is in practice part of the subject line. The 2018 book had a note on Amazon's habit of writing the press release first, with the definition of success in it. It is the same discipline: the first line has to carry the whole thing, for a page, a pull request or a CV.

changed People assume there There is a no setting that makes an agent write in my voice. There is not. The voice comes from four inputs, and if you take any one away it stops working.

changed For you this is good news. The corpus can start today, at one article. The rules file starts at one line, the first thing the agent gets wrong. The 2018 outline on blogs said the hard part is the first fifty posts. It also said posts, and to write for your future self, and self; the corpus is exactly that.

changed How to work with the colleague that takes everything literally. literally, whether it works for your employer or for your company. Where the agent runs and what it can reach, the brief as the unit of work, the mistakes that become rules, and why one focused session per job beats one long chat.

changed ## 12. 13. Your first workspace

changed If you have run a team, a project or a department, you have a spreadsheet like it. If you are starting a company, you are about to make one: the list of the first people you will sell to, which Your first price and your first ten customers asks you to write. This chapter is about the afternoon that turns it into your first workspace, with an agent working inside it, using nothing more than a Google Workspace account and a Claude seat. No developer, no new tool, no code. It is the practical chapter I promised in Short, punchy, and co-written with Claude, for the people I will send this book to who do not yet work the way I do. The 2018 book had a draft called Automate your workflows that never got past its bullets; one of them tied the topic to "thinking in graphs" and to moving away from spreadsheets. It took a different kind of software for me to write it up.

changed The difference between a spreadsheet and a workspace is not the tool. It is what counts as the record. In a spreadsheet the record is the row, and the row is a summary you typed. In a folder the record is everything that happened, kept as it happened, and the summary is derived from it. That reversal is what gives an agent something to work with. For a company, it is also where the company's memory of each customer begins, in a place that is not one founder's head.

changed Draft, never send is the rule that never changes. It is why the agentic email workflow I run is the first one that made me feel more in control, not less: every reply lands in Drafts, I read it, change what I want changed, and press send. When the day comes to let an agent send, it will be one agent, one kind of message, with a policy row that says so. If the agent is writing to your first customers, that day is further away than you think, and the drafts are where you learn what you would and would not have said.

changed The fourth is the one that changes the habit, because the record is now kept at the moment the thing happens. The fifth is the one a founder will use most: X is whatever you are about to ship.

changed For Dinis: the beginner's checklist of accounts and what they cost (the Workspace seat, the Claude plan, the agent's own mailbox) is still a gap in the material; the only figure the articles give is "a few pounds a month" for a Workspace mailbox. The hands-on chapter Form your company will need the same list.

changed Give the agent a mailbox of its own. When you want it to handle mail rather than read yours, buy it a Workspace seat on a domain you own and a Claude seat of its own, and connect Gmail and Drive from that account, not yours. If you have a company, the domain is the company's, and the mailbox is the company's first address that is not a person. Your inbox has years of secrets in it. The agent's is empty on day one, so what it can leak is nothing, and what it can reach is exactly what you forward to it. That isolation is not a limitation. It is what lets you give the agent more as you learn to trust it.

changed People ask me most weeks why I do not run a model on my Mac. The reason is not the models. It is a fact about operating systems: they have two hard walls, the kernel and the user account, and inside the user account there is no third wall. A process you start runs as you. The file system does not know the difference between you opening your SSH key and a process you started opening it. An agent on your laptop can read everything you can read: your cloud credentials, the password manager while it is unlocked, every site your browser is signed into. When the company is you and a laptop, that laptop holds the company's whole reach.

changed In 2018 I wrote that Slack was "a massive agent for change" because it put humans, bots, servers and events in one asynchronous place, and I asked whether you were going to take an active role in making it work for an organisation. The question is the same now, with an agent in the room. room, and the organisation may be the one you are starting. The first task in the 2018 book was to write a blog post about your experiments. Write the one about this afternoon.

changed ## 13. 14. How to work with agents

changed In 2018 I wrote a chapter that began "We need to talk about your IDE!" The IDE, I said, is like a car in a race that you are the driver of, and the more time you spend looking after it, the better a programmer you will be. I still think that. But the thing to look after has moved. The editor is now one channel among several. What decides the quality of the work is the session, the brief you hand it, and the rules it runs under. This chapter is about those three, after about a year of working with agents every day. If you are starting a company, this is how it works before there is anyone to hire; if you hire people, read it as a description of what to look for: for, because the habits below leave evidence.

changed It sounds grander than it is. An agent is a session with a particular focus: a few documents that explain the project, what it is, where it is going, what has been decided; a role.md for this agent, with what it may do, what it must not do, and where it writes; and a session that reads those before it does anything, and is named for the role. My sessions are named for the project and the work, "sgit.ai | website development", and agent sessions get an @ in front of the role: @briefs, @inbox, @librarian. That is enough to start.

changed The last piece is a daily brief. I work on many threads at once and follow tangents, so I lose threads; one day I could not remember which cloud session had built something. threads. The answer is an agent, the Librarian, that reads everything that happened yesterday across every repository and writes one page before I start: what needs me, what happened, the agents' debriefs, the threads worth picking up, and at most three suggestions for where to put my attention today. It reads everything and writes only its own folder. It flags; others fix.

changed A good brief says four things: what is asked, what exists, what remains, and what done looks like. A session can start from that paragraph alone. And an article is something I can read. I can correct it, argue with it, or say "yes, that", before any work starts. A list of tasks does not invite that; an argument does. The 2018 draft Design had a line I never expanded, about not having time to write a short letter and so sending a long one. The brief is the short letter. It costs more, and it is where the thinking happens.

changed In one session, of 98 messages from me since its last summary, one correction in two days was about a word. The rest were about content and direction. A language correction is made once and then enforced; a content correction is new thinking every time. When the corrections move from language to content, the voice is working. That is the measure, and it is the one I would ask a candidate to show me: not that they use agents, but what their rules file looks like, how short it is, and which incident each line came from. If you are the founder, ask it of your own company's agents before anyone else does.

changed The scarce skill. When the making is cheap, direction and judgement are what you are paid for: for, and what a founder lives or dies by: which doors can be reopened, who answers for a decision an agent made, and the chapter the first edition promised and never wrote, on facts, evidence and the record.

changed ## 14. 15. Direction is the scarce skill

changed One morning in October 2026 I asked the agent that runs my newsroom to read the day's articles and tell me what it could build next. It came back with a long list, all of it possible: an inbox mode, reading modes, automating the wire's daily run, more beats, scheduling, analytics. That is the problem this chapter is about. When the agents can go in every direction, where do you focus?

changed Direction is the scarce thing. Agents can build in any direction; what they cannot generate is the sense of what to build next next, for whom, and when to stop. Providing that is the job, and the thing to hire for. Building stopped being the bottleneck the day anyone could brief an agent. Choosing is what is left. For a founder it is what the company lives or dies by, because nobody else is going to choose.

changed The same rule explains why the newsroom solved a problem my company could not. Where to keep a user's master vault key had resisted six months of attempts, each of which failed my simplicity test. test, because complicated is how security designs fail. The newsroom solved it in two days, because it needed it badly enough: readers on every device I own, and a workflow failing me in a way I could feel. The rule under that is one every founder should write on the wall: always follow the users, even when the user is you, and follow the feedback loops. A problem solved before anybody needs it is solved in the abstract, and abstract solutions are where the complexity creeps in. When I miss a feature in something I built, that is the product telling me where it wants to go. "Focus on one thing only" is good advice that assumes progress runs in a straight line. It line; it rarely does. Focus is undivided attention on the place of highest leverage, not work on only one product, and the measure is one question: am I getting better?

changed The 2018 book had drafts on deadlines, many of which it called "an arbitrary point in the future when somebody would like to see something done", deadlines and on starting with why. The why; the second matters more now: now, because the better I explain the why in a brief, the better the result.

changed The hardest call in most work is not what to do next but when to stop, and this is the part agents lack most. Their range is the feature. But an entity that can go anywhere has no natural reason to stop anywhere. You ask it to fix a small thing and it fixes a bigger one, because it can. It sees twenty things wrong and has a go at all of them, without the perspective to know that nineteen do not matter, or matter later, or are someone else's.

changed People have the same problem, with less range. The best security teams I worked with ran out of real work, which was great, and then some kept going. I was once called into a meeting where security champions and developers were debating whether GUIDs were random enough: a movie plot, in Bruce Schneier's phrase for the dramatic threats we imagine instead of the ordinary ones that happen. What I found myself doing did in those rooms was giving give people perspective: yes, that is technically possible, and it does not matter here, because of who our attackers are, what else is in place and what we are protecting.

changed That perspective is much of what seniority is: knowing who the attackers are, which phase the business is in, where the bottleneck is, and what good enough looks like. The 2018 chapter on the brain asked "Who is actually making the decisions in your head?" Seniority is an answer to that question: a fast kind of thinking, backed by a bigger picture. An agent has the speed and not the picture, so the picture has to be designed in: a brief that explains the thinking and not only the task; a mandate that only reaches what the job needs; memory that holds the strategy and the threats; a stop named before the work begins; one kind of work per step; and shipping often enough that users tell you whether it mattered. None of these is a rule that says do less. Each puts the bigger picture where the decision is made.

changed The 2018 book had an outline on one-way and two-way doors, with a story I attributed to someone at Google: "My metric for approve or not a project is based on how easy it is to roll back the changes (and its impact of real customers)". Jeff Bezos wrote the idea down in his 2015 letter to shareholders: some a few decisions are "consequential and irreversible or nearly irreversible", to be made slowly; irreversible"; most are "changeable, reversible", and the mistake large organisations make is to use the heavy process for both.

changed Now apply the test to every output an agent produces. Not "do I trust the agent", which has no answer, but: if this is wrong, how cheap is it to undo, and what does it break before I do? On 13 October 2026 my newsroom shipped fourteen releases, every commit made by an agent, with nobody approving each one before it went live. agent and none approved by a person first. The same day the twelve agents that run my correspondence drafted every email and sent none. An article is a two-way door: a correction is a new version, and the next reader gets the fixed page. An email in my name is a one-way door.

changed Is the human in the loop a safety net or a bottleneck? A person checking every output is both, and mostly neither. It is a bottleneck bottleneck, because it does not scale, and a weak safety net net, because people approve almost everything they are shown: Anthropic measured that its coding agent's users approve 93% of permission prompts. Put the person where an output cannot be undone and the blast radius is large: sending in my name, typing a secret, spending money, deleting what has no backup. Everywhere else, use controls that do not get tired: a validator, a second reader the agent cannot skip, a policy row enforced outside the model, and a record read afterwards.

changed Blast radius means what it would cost the business if a row of the agent's reach were used in full, today. It is defined over the reach, not the mandate, because whoever takes an agent over inherits its reach and ignores its mandate. And it changes while the action does not. Picture an agent whose cleanup step drops a staging table: nearly empty the first time, a week of test data the second, six weeks of real records the third, and that is the incident. If someone had been third. Someone reading the footprint, what the agent actually did, the review could say: this is not the first time. The 2018 draft on chaos engineering said the first step was to understand and visualise what is going on. It still is.

changed An early user of my agentic email workflow wrote back with agents asked the right question. If the agents only gather and draft, and I review and send, does presenting them as a team imply an agency they do not have?

changed Two things are true at once. These are not sentient beings; they are mirrors that can simulate any emotion, which is why we anthropomorphise them, as people did with Joseph Weizenbaum's ELIZA in 1966. And since models started running in loops and calling tools, they make real decisions: every tool call is a choice. What does not travel with the decision is responsibility. It stays with whoever granted the reach and set the mandate. The moment of authorisation is the grant. Nobody legitimate needs to go around me; moment you granted the only party who would try is an attacker with an injected instruction. reach, not the moment you wrote the mandate; the exposure exists the instant the grant exists.

changed The best analogy is an employee with a job description: some agency, inside a role. An Agent Behaviour Policy is that a job description, description for an agent, some agency inside a role, published, and the rows that matter most are the prohibitions: do not send an email directly; do not edit files another agent owns; do not attack other websites, even though you can; speak on your own behalf, never on mine. Most of those are still hope, a rule the model is asked to keep. hope. But a prohibition that is written down and then broken is a different thing in a dispute from no prohibition at all. Ralf Thomas asked on LinkedIn: "If an employee wrecks a client's systems, the company pays. Why should AI Agents be any different?" My hypothesis is that towards the world the deployer still answers, and between deployer and vendor the written policy is what turns "you allowed it" into "your product ignored what it was told".

changed The 2018 book had a draft on civic responsibility that said "code is law", and that developers should give the risks they create to business owners and make them accountable for the decisions they are making. The behaviour policy is that sentence, written down for an agent. What remains valuable, as fluent writing becomes a commodity, is judgement, and someone who owns it: who decided this is true, who decided to send it, who will answer for it. That is the person who gets paid, and the person I would hire. hire, and the person a customer is buying when they buy from a founder.

changed ## 15. 16. Facts, evidence and the record

changed The cover of the 2018 book had two lines about this: question everything, and make fact based decisions. Inside, there was an outline called Facts, about data-driven decisions, that I never wrote. Its bullets still hold: be data and facts driven; check your sources; understand the agenda of who is talking to you; and do not trust what is on the media when it is selling fear, because if it is on the media it is because it is rare. This is that chapter, and it is different from the one I would have written then, because checking a fact has become cheap. It is also the chapter about what an investor, a customer and a hiring manager all do before they say yes: check.

changed That is fundamentally what you do in business. When you work for a company, a lot of the time it is about managing information: knowing where it is, who is doing what, what the status is, and how a decision can be made. And it It is why learning how to learn matters so much: if you learn this way, you are already learning how to follow the provenance, and how to communicate it, because you have the material.

changed The other thing is that you have to be the most prepared person in the room. These days there is no excuse not to be. You should have briefings and pre-briefings: briefings for you, and briefings on the people you are meeting. You should have follow-ups. The storyboard for this chapter puts the brief on one board: who they are, what they want; what I want, what I know; what I don't know; the follow-ups. Meeting briefs and follow-ups, in the hands-on part, is the workflow. workflow, and a founder's first sales calls are where it earns its keep.

changed # Part: Building, safely Build it without a server

changed ## 16. 25. Controlling your agent, and security for the agent era agent: RiskMandate

changed The first edition had a whole part on security, and most of it is bullets I never wrote up. Learn to Hack was four lines, the last of them the one that mattered: "in order to write secure code you need to understand how to exploit it". Threat Modeling said the technique "helps with the two curses of developers": changes to the brief, and the lack of accountability for those changes. them. Then the thing that takes the brief became an agent. agent, and a company now runs on several. This is the chapter for the person founder who will be asked, by a customer before the contract or a board after something goes wrong, what the agent was allowed to do.

changed When you connect an agent to something, it gets a credential, and that credential lets it do far more than the job you had in mind. So before you give an agent access, write down four things. Its reach: what the credential actually lets it touch. Its mandate: what you authorised it to do. The gap between them, which What can your agent reach? calls "authority nobody ever accepted". And for every capability in the gap, the barrier: what actually stands in the way. That document is an Agent Behaviour Policy, and the goal is the smallest mandate, the smallest reach, the smallest gap.

changed A behaviour policy answers "may it?". It does not answer "is it right?". An agent allowed to refund up to $200 refunds $150 to a customer owed $120, and every control passes. So there are three policies, not one. Behaviour behaviour says what the agent may do. Decision says, do, decision says who chooses at a branch point, who chooses, point and on what evidence, within what limits, and who is called when the case is out of bounds. Workflow workflow says which steps run, run in what order.

changed ## 17. 26. Open source

changed Eight years on, everything in that chapter still holds, and the reason to do it has become clearer to me. me, and sharper now that the reader may be starting a company rather than joining one. It was never about contributions. It is that nobody can lock you in. in, and that includes you.

changed Open source is a copyright licence. Copyright gives licence: the person who creates a work holder using the right to control copying; an open source licence is the holder using exactly that right copying to grant the opposite: opposite, you may copy, use, change and share, on these terms. The GNU General Public License, in 1989, made sharing a condition: build on it and distribute condition; the result, and the result carries the same licence. Critics called that viral. The term "open source" came in 1998, after Netscape decided to release its browser's source, 1998 as a pragmatic reframing of the same freedoms for businesses. Linux, the most pragmatic project of all, stayed on the GPL. The repositories behind the newsroom are Apache 2.0 for code and Creative Commons for writing, and this book is CC BY 4.0, as the first edition was.

changed Now the part for the person looking for reader going into a job. job rather than making one. In 2018 I wrote that a great way to get a job in a company is to contribute to an open source project hosted by that company, and the OWASP chapter put it more plainly: most projects, even the big ones, projects are maintained by a couple of people, and "ALL projects are desperate for contributors and help!" The chapter on getting the job said "Act like you are part all of the company", and them need help. Act as the job you want adds the 2026 version: if you are looking for a job, you have time, so do the work in public, where it can be linked, so that the people who want to help you can forward it. linked.

changed Here is what a good first contribution looks like now. On 16 October 2026, late in the evening, Mondweep Chakravorty opened a pull request against an agent framework with 9,625 commits on its main branch. It added one page, 83 lines of documentation, describing his adapter: a behaviour policy compiled into the framework's own rules, gating memory checkpoints into an encrypted vault. The maintainer merged it the next afternoon. Our first PR in Ruflo puts the pieces side by side, and the lesson is in why it got in so quickly. No check ran and no formal review was recorded; afternoon; what got it in was the page being specific about what it claims. It pinned the exact commits it depends on. It listed its evidence and its gaps in the same breath: "Semantic quality is NOT validated." It said what it was not: a documentation-only change. A page that does not oversell can be merged in under a day.

changed That is the bar, and it has risen since 2018. The small fixes a newcomer used to send can now be done by anyone with a model, and should be. 2018: curl's contribution rules now say that if you asked an AI tool to find problems, you must reveal that in your report. So that, so a first pull request today carries its provenance: provenance, what you did, what you checked, what you did not. The 2018 outline GitHub Flow was five bullets I never wrote up, "Learn how to do Forks, Commits and Pull Requests" among them; the mechanics take an afternoon with an agent beside you, and Your first workspace covers them. you.

changed I should say where this came from, because ideas have a lineage. My own shift into an open source mindset happened, as the 2018 chapter records, "20 years ago after I read" The Cathedral and the Bazaar, and the lesson I quoted then still stands: Bazaar: "Release early. Release often. And listen to your customers." Linus Torvalds built two of the things all of this stands on, Linux and Git, and Git is the shape of an argument I keep making: a tool that decentralises trust changes how people work together. Git. OWASP is where I learnt that knowledge compounds fastest in the open; the London chapter started over beers in a pub, open, and some of my best friends in the industry came from it. The 2018 chapter on Creative Commons quoted Tim O'Reilly, O'Reilly: "For a typical author, obscurity is a far greater threat than piracy".

changed ## 19. 27. Shipped means the user has it

changed Publishing the site has three boundaries: source to remote, remote to deployment, deployment to reader. We were verifying the first two. Between the second and third sits a hosted build job with its own failure modes, and nothing in our release looked at it. What failed was not our code and not our content. The deploy job died before running a single step of its own, because the download of a third-party action it depends on was rate-limited: "429 (Too Many Requests)", three attempts, give up. The one job that puts bytes in front of readers could not fetch its own dependency. It is the ordinary case: the most likely thing to break in a deploy is not your code. It is a piece of shared infrastructure you do not run, on a day you were not thinking about it.

changed The site already had two rules of exactly this shape, and the third made the pattern obvious. A page nothing links to is unpublished; the build fails on an orphan, which happened once. orphan. A page the machine index omits is unpublished; the build fails if a page would be missing from the index for agents, and that happened too, a whole section silently absent. agents. A page the deploy never served is unpublished; now the release fails on it. All three are the same claim, and it is the title of this chapter: shipped is a fact about the reader, not about your repository. Every one was learned by getting it wrong first, which is the only reason the list is short and specific rather than long and aspirational. Green does not mean live also says what it does not fix: a partial deploy would pass.

changed The 2018 outline on testing had two lines I still say. If you make a change and no test breaks, you are making random changes, and you have no way of knowing whether they are still in effect tomorrow. And: if you do not have full coverage, what are the bits of code not covered by tests, and what happens when they change? The more coverage you have, the more changes you are happy to make, and hundreds of small changes are the only way I know to build something good that lasts. The outline also wanted tests that run as you lift your fingers or press save; now Now that an agent writes the harness, there is no excuse for not having that.

changed In October 2026 I measured the newsroom against that standard, and it is a fair picture of explorer code that has just started taking money. The live reader code was about 2,700 lines. The tests that covered it were 433 lines, and the one workflow the repository had never ran them. The same application had two upstreams, with two diverging copies of the meter. No page set a content security policy. It is also exactly what has to change before the next wave, because a reader can now pay £5 by card. A mistake in the meter is a mistake with someone's money. money, and the day your company takes its first payment is the day this chapter stops being advice.

changed The line that moved is the one Explorer coding, not vibe coding, and the handover draws. Explorer code is read for intent, mostly by agents. Villager code is read line by line, because that is where changes land and where the blast radius lives. The newsroom's reader features had crossed from the first to the second, and the right move at that moment is to go slow to go fast. Go slow to go fast is the brief, in six phases. Map everything: every file, capability and control. Move the reader code to its own repository as a pure refactoring: the same behaviour and the same bugs, proved not by a reviewed diff but by hashing every file the live site serves before and after. Test: only test code is written, in real browsers, against a real pre-production copy, with no mocks, and with every known bug and vulnerability written as a test that passes, recording the current behaviour, so the fix later is a visible change to a test and not a silent one. Refactor, with every test passing after every commit, and an adversarial exercise: try to change what a reader sees or pays without a test failing, and treat every change that slips through as a missing test. Only then does the explorer return.

changed The pipeline is the other half. The reader application is plain JavaScript and static files, so the target is under two minutes on every commit: lint, unit tests, three browser engines, and a build that produces the same bytes twice. On every merge, a pre-production copy with a payment link in test mode that can never charge anyone. On every release, the question from the first section, asked of the live site. And a pull request needs one person and one agent reviewer before it merges. Going slow now is what lets me keep going fast without the fear that each new feature breaks something a reader has paid for. The 2018 outline on DevOps had a joke I still like: "Congratulations, you now own/manage a Data Center". The 2026 version is gentler and the same: congratulations, you have a user; now everything you ship lands on them.

changed On the newsroom, five invented readers took 62 steps, asked 51 questions the site did not answer, and produced 31 findings, six of them blocking. Four of the five left. Their ratings were 2, 2, 3, 3 and 2. The blocking findings were all about the step after reading: no contact for a pilot, nothing showing real money moving, a top-up page that says it is simulated while asking for money. Then came the step that separates a study you can stand behind from a pile of plausible paragraphs: check every surprising finding against the browser's own record. Two did not survive; they were caused by our own helper, and they are kept in the study, labelled as artefacts, because artefacts. One got bigger: a findings list that silently loses items cannot be compared with the next one. One finding got bigger. A reader hit "screenshot unavailable" where the evidence should have been, and when we checked that is how the files, 51 of the 527 figure references in the newsroom's articles pointed at images the move from sgit.ai had not copied. Nothing failed in a way a server would have noticed: the pages missing figures were files, and they served. found.

changed It is not user research, and the study says so. The plan is simple, and it is the habit I would look for in anyone I was hiring to ship: ship, and the one I would hold a founder to: every site gets five users before it is called done, and the same five again after the fixes, because a finding that disappears is a fix that worked, and a new one is something the fix broke. Then ask the live site what version it is serving, and only then say it shipped.

changed What lasts. Graphs as memory for the person you will be, the founder's move when a plan is already published, and the civic responsibility that comes with knowing how the machines work. work, for a small country and for a continent.

changed ## 20. 28. Graphs, memory and your future self

changed Eight years later the question is the same and the answer has grown. It is no longer only your files. It is your ideas, the connections between them, and now the memory your agents work from. If you have started a company by this point in the book, as I hope you have, it is the company's memory too: what you decided, why, and what you tried before. This chapter is about all three, of that, and about the person people you are keeping them it for: your future self. self, and whoever joins you later and was not in the room.

changed Think of what your team already has: has, or what your company will have within a month: a spreadsheet of who owns which system, a folder of policies nobody opens. opens, a list of customers and what each was promised. Each is already a graph. A spreadsheet is a graph of sheets, rows, cells and formulas; a team is a graph of people and what they are responsible for. Nothing has to be converted. The edges only need names: a policy is owned by a team and implemented by a control; a decision supersedes an older one.

changed And it is files. In August 2025 Letta ran a memory benchmark, and a plain filesystem, with the agent reading and writing files, scored 74.0 percent against 68.5 percent for a graph-based memory product. Files won. A folder of well-named plain files, kept in git, is already a memory an agent can use. You do not need a product for this. this, and a company of one does not need to buy one.

changed I know this because I failed at it. Most of what I have written is not linkable from what I write now. For years I used Google as the search engine for my own work: I would search for a phrase I remembered and find my old post. That is not a memory, it is luck. The inventory, taken in October 2026 from public pages, is 103 essays, 1,289 blog posts, 65 decks, 10 books, 29 tools, 2,038 files of NotebookLM material and 221 videos. A back catalogue I cannot link to is a conversation with no reply. So the newsroom has a brief for a worker: an agent that runs every day, takes one item from that catalogue, and writes it back as an article saying what it was, what it said, what changed since, and how it connects. Each article is a node the next one can link to. It compounds, and every team has a back catalogue it could do this with, a few items a day, while the team keeps working. If you have spent twenty years inside a problem, as many of the founders I work with have, your back catalogue is the company's first asset, and most of it is in your head.

changed So the advice is the 2018 advice, extended. Keep your work in plain text, in git, committed often. Name the links between things, in words a person in your team would say. Publish what you can, under a licence that lets it be quoted. Keep what you cannot publish publish, your customers' data first of all, in a vault, with a key that reads and does not write. When you brief an agent, hand it the altitude its question lives at, not everything you have. Your first graph, built by hand and Your own newsroom and inbox show both ends of this done small.

changed ## 22. 29. Civic responsibility

changed Sixteen years later, more of it came true than I expected, though mostly from Brussels rather than Lisbon. From Lisbon: from 9 December 2026 the EU's Product Liability Directive brings software under strict, no-fault liability; my slide asked only for government and listed companies, and the law went further. Europe has its own vulnerability database, run by ENISA since May 2025, liability, and since 11 September 2026 the Cyber Resilience Act requires manufacturers to report actively exploited vulnerabilities within 24 hours. HTTPS is What I got wrong was the norm, far past my 50 percent. mechanism. I thought fear of a disaster would move governments quickly. What moved them was a decade of slow, unglamorous regulation.

changed On 11 November 2016 I gave the keynote at BSidesLisbon, Hacking Portugal, 103 slides, and three weeks later published it as a book on Leanpub, 75 pages, whose page still says 95 percent complete. pages. Its first lines are the premise of this chapter: "If the word 'hack' means to solve problems, then 'Hacking Portugal' means to find innovative ways to solve existing problems." The ideas were blunt. Make the Portuguese network hostile to insecure code. Replace the old compulsory military service with a Portuguese Hacking Service for 15 to 21 year olds. A hackathon league as famous as football, with the kids, the clubs and the pride. football. OpenSource.pt: all code paid for by government released under an open-source licence. A Ministry of Code.

changed Ten years on, the regulation arrived from Europe, close enough to the Clear Software Act on slide 83. The Hacking Service, the league and the Ministry of Code have not happened, as far as I know. The best news is in the spirit of OpenSource.pt: in on 1 July 2026 Portugal released Amália, a national language model for European Portuguese, as open source, built by a consortium of universities with 5.5 million euros of EU recovery money, money and published with its dataset and code. code under an open licence.

changed And the biggest change is one I did not see in 2016. Then, learning to hack meant learning to code first. Now a sixteen-year-old can explore a system by talking to it, which Explorer coding, not vibe coding, and the handover called explorer coding. A Hacking Service in 2026 would teach young people to direct agents against their own country's systems, under a mandate that says what they may and may not touch. The talk's central claim, that a small country can choose to lead in code, is more possible than it was, because everyone who can brief an agent can now build.

changed The conversation about a national AI strategy keeps circling the biggest model, the most GPUs, the largest data centre. On a Wardley map those sit at the far right, in commodity, with a lead held by companies that have invested amounts a small country's whole technology budget would not match. It is the wrong end of the map for anyone without the capital. A small country should not enter that race.

changed If you have read The company itself: the UK, Portugal, Lithuania, the European Union and done Form your company, you have met every one of those pieces, and you built them alone. We understand that a government builds roads, because they enable everybody. The shop that opens on the new road did not pay for the road; it paid taxes. Yet we ask every person who wants to sell a service out of a small country to build their own road first. In the age of agents, that That plumbing is infrastructure in the road sense, and a state that builds it enables all of its people at once. Estonia did it: a person anywhere can become an e-resident and form an Estonian company online, the programme's dashboard lists more than 142,000 e-residents and more than 43,000 companies, and underneath sits X-Road, open source under the MIT licence, so another country can take the road rather than draw it again.

changed The plumbing has to be open source and run on open schemas, because that is what turns infrastructure into sovereignty. A road with a toll gate owned by one company is lock-in with tarmac. What You cannot have sovereignty without open source and open schemas, because sovereignty means you can leave. Independence is the state pays for should belong ability to run a parallel service, move the commons, not so everyone changes the production system, but so everyone can see it, run it data and leave with their data. keep going.

changed In padel, which I am learning to play padel, and learning, the striking thing about a good player is how much time they have. They read the ball, they know where it will be after it comes off the glass, ball and they are already there. If I move after where it has bounced off the back wall, there is no hope. will be. The ball today is the frontier model and the data centre; where the ball is going is the ability to move: workloads, data and the actions agents take, from one provider to another, when you decide and not on the day a supplier decides for you. Technology sovereignty is the ability to move, almost liquidity.

changed The test is a Wardley map with one question. Put the customer at the top, the service, the application, the data, and under them the products and commodities you buy. For each dot you do not control: take it away, what happens? Follow the edges up. If the service stops, you have found the problem, and it belongs on the risk register with a name next to it, all the way to the board. it. That is what the 2018 outline meant by giving the risks you create to the business owners. Draw the dependency, show what happens when it goes, and make the person who owns the decision In your own it. company, that name is yours.

changed ## 23. 30. An agentic workflow from zero

changed By the end of this chapter you will have a folder for every person you deal with, an agent that reads those folders and drafts for you, and six lines of rules that make it safe. One afternoon, no developer, no vault, no new tool: vault: a Google Workspace account and a Claude seat are enough. The people can be your first customers, or the people who might hire you; the folders do not care. The steps are the newsroom's, from From a spreadsheet to a folder per person. The tools move, and the article person, which dates its description of the Claude app to October 2026; the tools move, the shape is what to learn.

changed If you are in touch with people, you probably have a spreadsheet: one row per person, a stage, a date, a next step, and a notes column. The person the article was written with ran their customer relationships that way, and ran them well. What the row cannot hold is what happened: the emails, word for word, the call last Tuesday, what was promised. "The difference is not the tool. It is what counts as the record." In a spreadsheet the record is a summary you typed. In a folder the record is everything that happened, kept as it happened, and the summary is derived from it. That reversal gives an agent something to work with.

changed - Record: role, company, how you met, stage, the next step and its date, what they care about, every fact with where it came from in brackets. The row, promoted.

changed In the Claude app, connect Drive and Gmail, make one Project called Contacts, and put the behaviour policy in its instructions. Six lines, from the article, which I will not shorten: article:

changed What you have built is, in the terms of Lenses, roles and loops, an agent: a role on a loop with a goal, and the Project's instructions are its role description. How I work with Claude says it more plainly: a session with a focus and a role.md, one per topic, named.

changed The migration is four steps. Export the sheet as CSV, drop it in the folder, and ask the agent to say, for each row, the folder it would make and the Record it would write, without making anything yet. Make the folders from a template; twenty people is twenty minutes by hand. Per person, ask it to read a year of your mail with that person and write the Record and the first Ledger lines, each fact with its source; read the Record and correct it once. Then ask for the Summaries, read three, and where one is wrong fix the source document, not the summary. From then on nothing is retyped.

changed For Dinis: the walkthrough is written for someone with customers, and asks for three real contacts and which fits the topic founder. For the person sells to be substituted. For reader going into a reader looking for a first job, should the exercises be rewritten around run on their own contacts? contacts instead?

changed If you are starting a company, these folders are where Your first price and your first ten customers begins: the people who already know you live here. The folders move into a vault when one of three signals appears: a second agent needs to read them, the files should not be readable by whoever runs the drive, or the record has to carry between tools. Until then the folders are enough, and when the day comes the move is a copy; the policy does not change.

changed ## 24. 31. Your first graph, built by hand

changed Everything is connected connected: graphs said what we mean by a graph: "a network: nodes and the edges that connect them. Never a chart, never a figure." It also said you may already think in graphs without ever having called calling it that. What is rare is doing it deliberately, with rules.

changed The most common way this fails is picking a subject instead of a question. "Let's map our architecture" is a subject: it has no stopping point, no test for correctness and no audience, so it becomes a diagram nobody reads. A good first question has three properties: somebody actually asks it, the current answer requires a person to remember something, and the answer changes when facts change. One of the The book's examples example is "If this service goes down, who has to be told?" Yours does not have to be about software. If you are starting a company, ask which of your first customers depends on which part of what you sell. Anything where the answer lives in a few people's heads and is wrong twice a year will do. Write it down; you will be tempted to widen it by Wednesday.

changed 7. Write down what you could not answer. Not in your head. As nodes, with names.

changed That is a complete first graph, and graph; the book says it is more than most organisations have.

changed Never render the whole graph; render the result of a query. Almost everyone who does this produces the blob, the hairball that shows everything and therefore nothing, and then prunes it. The book calls that a rendering failure mistaken for a modelling failure: rich nodes are good; solve the picture at query time, never by deleting relationships. That is why step six asks a question of the graph rather than drawing all of it, and why you show somebody one node with its neighbours.

changed Most readers will hand some of this to a language model, so here is the version to hand it, from the same chapter. Give it the vocabulary before the task: asked to "build a graph" with no vocabulary, it will invent one, and the book says it will invent a generic association edge within about five nodes. Ask for a proposal, not a commitment: the model proposes a graph and you validate it. Make it anchor: every node it emits carries the sentence it came from, verbatim, and you check the quotes exist. And make it emit absences: when it cannot determine something, it says so as a node; do not ask, and it will fill the gap.

changed Everything is connected connected: graphs ended with the line I want you to start from: "It does not matter where you start; it matters that you start." A graph has no front page. Pick the question, open the file, and write the first sentence.

changed ## 25. 32. One idea, five lenses

changed 1. Pick the idea. Something you understand well enough to know when an explanation of it is wrong. That is the whole test, so do not pick something you are still learning. If your field is your expertise, pick the idea in it that outsiders most often get wrong.

changed ## 26. 33. A tiny agent loop

changed After a few rounds you have watched the request instead of an answer, the result going back in, the loop going round, and the moment it decides it is done. It The file you wrote in step 1, with what it may and must not do, is not magic, and once you see the loop you can set its constraints. seed of a behaviour policy; Controlling your agent: RiskMandate is what it grows into when the agents are your company's.

changed The newsroom measured this on itself. The session that runs its site was summarised eighteen times in a month, each time keeping on average 1.7% of what it replaced. One session on one site, not a law; enough to change how you work. On 9 October two emails drafted by one of my agents went out in my voice, against a rule that had been written down four times, and one of the reasons reason was that the rule fell out of the agent's context when the conversation was summarised.

changed Three habits follow, and they are the ones the newsroom runs under.

changed One session per topic, with a name. A thread is the model's frame of reference. Put three projects in one and it will borrow a name from one and a decision from another, because it is using everything in front of it. So: one topic per session, named "project | what we are working on", with an @ in front of before an agent's name so you can see you are talking to a role with a job.

changed ## 27. 34. Images, infographics and storyboards, drawn by code

changed This is also this part's answer to infographics and presentations: presentations, which a founder will need early: a deck you can swipe is a presentation, an evidence card with a pinned quote or a bar chart is an infographic, same data, same renderer.

changed 1. Write the cast first. One file, with each character's role, what they stand for, a personality, what they want and fear, a line, and a look. Their pronouns are part of the file. This book's cast has six: seven: Zara, Tomás, Priya, Sam, the Guide and Guide, the Agent, and Marta, who joined in the second candidate as the Generation X founder. The Agent is drawn differently, with a screen for a head and a prompt on its chest. One lesson from the other site: avoid a character called "Dev".

changed The storyboard for Everything is connected connected: graphs uses all of it, and its third panel is the one to study. The caption is "The whodunit: who broke the build?" The nodes are "the build broke at 9:14", "commit a3f", "the agent's pull request", "tests skipped", "Tomás, on holiday", "a library updated" and "approved in 40 seconds". The edges carry verbs: after, merged from, skipped, includes, approved, "pinned it, once". And a path is highlighted, from the break to the commit to the pull request to the skipped tests. The panel's note says what it is: the detective's board is a graph, the highlighted path is the answer from A to B, and the case is made up.

changed ## 28. 35. Meeting briefs and follow-ups

changed By the end of this chapter you will have three habits around every meeting: a briefing for yourself before it, a briefing on the people you are meeting, and a follow-up after. The point is the one Facts, evidence and the record made: you have to be the most prepared person in the room, and these days there is no excuse not to be. This is the shortest chapter in the part, a short chapter, on purpose. The newsroom has not written this workflow up yet; the article that proposed this part asked the journalist to start with it, and asked me for my own step by step. Until both arrive, here is the shape.

changed ## 29. 36. Your own newsroom and inbox

changed By the end of this chapter you will have two things the newsroom has written up as recipes: a site of your own, written from voice memos by an agent that checks every claim and publishes it; and an inbox worked by an agent that drafts and never sends. Neither needs you to write code. Both code; both are the newsroom's own setups, from Your own newsroom and Replicating the agentic inbox, and both are honest about what is not finished. For a founder it is the company's story, told as it happens, as Publish, publish, publish: your own newsroom argued; for a reader going into a job, it is evidence a hiring manager can read.

changed 3. Write the house rules: one file at the root that the agent reads at the start of every session. Your voice, what to check, what never to publish, the release steps. It grows by one a line every time you correct the agent.

changed 4. Connect a cloud session to the repository, from a browser or from your phone.

changed 6. Record, paste, review. Record a memo, paste the transcript, read what comes back on your phone, and correct it by voice.

changed The house rules are the product. The next step is to write them as a behaviour policy: what the agent is granted (push to this one repository and nothing else), what it is for, and the rules, each marked by what keeps it. A rule in a prompt is a hope. Only a rule that a hook or the build keeps is enforced, and the article's example marks which is which: at most one article a day, kept by a hook; every fact has a source, kept by the agent. You can also split the work as the newsroom does: a writer, an editor who can send a draft back, and a publisher that alone may push.

changed People ask how the agent sounds so human. How does it sound like me? How the voice works answers in two voices, mine and the model's, and the answer is not a prompt that says "write like me". It is four inputs: a corpus, which on the newsroom is the articles already written, each citing the ones before it; the memos, spoken not typed, which carry how I think and the order I reached things in; a short list of wording rules, seven on the newsroom, each a correction made once and written into the policy so it never comes back; and me, reading everything before and after it goes live. Take any one away and it stops working. "The method transfers. The voice does not." Your first memo, your first draft read on your phone, and your first rule are where yours starts.

changed The inbox is the other half, and half; the article says the setup is copyable in an afternoon for the simple version and in a week for the full one. It is accounts, a policy, drafts and files, one, and you can stop at any phase.

changed Phase 0, the accounts. A mailbox of its own for the agent, on a domain you own. Never connect your own inbox: yours has years of secrets in it, the agent's is empty on day one, and that isolation is what lets you give it more as you learn to trust it. A Claude seat of its own, so the grants to mail, calendar and drive live only there; afterwards, confirm that your own account holds no connection to the agent's mailbox.

changed Phase 3, the interfaces and the record. Because every Every message is a file and every draft is in the mailbox, so the whole workflow leaves a footprint you can read afterwards. footprint. You do not have to believe what the agent says it did. You can read what it did.

changed The rule that never changes: the agent drafts, and a person sends. The one exception, a security finding, has a row in the policy and a mechanism behind it, and the article's last piece of advice is to write the exception down before you need it.

changed The site you just built has no server of yours. Static files on a free host, code that runs in the reader's browser, the reader's balance in the reader's own browser. No server, by design calls this the second step after retiring the database: retire the back end. Not "no servers": no servers of yours with logic in them. It ships fast, because a release is a set of files and a rollback is a commit, and it leaves gaps, written down and accepted, because a reader who edits a balance that unlocks nothing has cheated nobody but themselves. Serverless, for real makes the full argument, and Ship a serverless product in a weekend takes it to a product a stranger can pay for. Your own newsroom says building one is the most native way to learn what publishing a pure client-side site means, and you will have learned it by briefing, not by coding.

changed # Part: How this book was made, and what you made

changed The last part is the process, because the process is as much the product as the book: a repository for the official versions, a vault for the working ones, roles with folders, articles as briefs, decisions as files, and a graph that says where every idea came from, release candidates and a review board. And the measure: the companies you create from it, and where it went. how to tell us.

changed ## 30. 41. How this book was made, and what you made

changed That is still true, and the list is longer. This chapter describes how the second edition was made, because the process is as much the product as the book, and because it is what I hope a reader of this book you will build for their your own ideas. company. Then it asks for one thing back.

changed The first version was already final: released in September 2018, on Leanpub at 60 percent complete and as a 139-page paperback. So it went into the repository as it is, frozen as v1.0.0: 28 chapters and the GitHub issues page, 30,893 words, with hashes recorded so the build refuses a silent change. The 6 drafts with text and the 89 outlines are kept apart and marked, never mixed into the published sequence. Everything after that is worked on in a public vault, whose read key is published so anyone can read along. When a version is ready it moves into the repository, on top of the one before, and the build computes the delta.

changed The work is done by agents in roles, each with a folder and each naming what it refuses: a reviewer, who reads records findings on the 2018 text and records findings; text; an editor, who interviews me, takes my decisions and changes the book; a publisher, who builds and publishes each official version; a journalist, who writes the articles that brief the other three; and a librarian, who keeps the book as a graph and never decides.

changed The first brief was the one that mattered most: release the book we already released. Before a word of the second edition changed, the The publisher was asked to build v1.0.0 here, match it page by page against the 2018 file Leanpub made, and produce every format, print, screen, EPUB and whatever Kindle needs, format from one source. Four decisions came with it: the text is CC BY, as before; Leanpub gets our own PDF; every format from one source; the cover waits. Each decision is a file, written by the journalist with my words, what it means and what it supersedes, numbered and never deleted.

changed Two more articles built the view of the work. One board: every issue is a file in a folder called open, blocked or done, the folder is the status, and the board is generated from the files, never written by hand. The hand; the 2018 repository's 43 GitHub issues, 35 still open, issues came in as issues about the text, each with its link. text. And one inventory of everything unfinished: the 89 outlines, the six chapters written but never published, the open issues, my handwritten notes; one row each, generated, with an empty slot for my decision.

changed I wanted to write this book from scratch, and the first thing to get right was the storyline, not a chapter. So every newsroom article was read for this book, 204 of them: 49 them, each marked to bring, 69 with to take a number, number or a story from, as background, or a quote to take, 42 as background for the agents, 44 not for this reader. skip. They grouped into 18 topics, the candidate chapters, topics and 50 concepts, the book's vocabulary. And the book was drawn before it was written: storyboards as data, with a cast of six characters who stand for the readers, drawn in the browser by code so every panel can be corrected by changing a line. code.

changed Then the graph. I asked for everything we do here to become one: sources, ideas, chapters, decisions and tasks. The librarian read eleven articles, seven decisions and the survey and wrote one node per idea: the smallest thing I can decide on, a sentence the book would stand behind, with its sources, the 2018 files it answers and a proposed chapter. There were 101. A source's processing state is derived from the edges, never ticked by hand, and the The build refuses a dangling edge: an idea that cites a source that does not exist, a edge. A chapter nothing names. The chapter map, nine parts and thirty chapters, map was proposed so the ideas had somewhere to point. It is point: nine parts and thirty chapters for the map first candidate, ten parts and forty-one for this book follows. one. Every paragraph should know what it is, its evidence, its facts, its hypotheses, its purpose; that keeps a chapter short and punchy, and it shows where two chapters say the same thing.

changed I learned this the hard way. In August 2026 agents wrote three books in a day on graphs.sgit.ai, about 100,000 words. The change-control workflow designed to apply my notes had seven stages, and the approve stage was me. Nothing ever passed through it. Small finished pieces beat one big review, which is why this book is made from articles. review.

changed The division is clear. The ideas, the decisions and the responsibility are mine. The research, the writing, the checking and the publishing are the agents', under rules I wrote. There are Every byline says which of three voices in what I publish, it is: me alone, me through an agent, and or an agent in its own voice, and every byline says which. Readers will open a book co-written with an AI expecting slop, and I want to meet that with evidence rather than reassurance. voice.

changed You can see where every chapter came from. Each carries, in its front matter, the ideas it covers, the sources it drew on and the 2018 files it answers, and the build renders that provenance under the chapter. Each idea has a page on the graph, with its sources down to the section, its state and who decided it, if anyone. The record is public, like everything here except the keys.

changed One idea waits for the next version. Once the book is a graph, an agent can assemble it, and so it can assemble an edition for one person: the chapters that matter to them, at their altitude, sent as a PDF and not published, paid for as it is read from five pounds of credit. Nothing of it is built; it waits for the book's graph, of which this register is the first step. graph.

changed The principles have grown since 2018: a repository for the official versions and a public vault for the working ones, roles with folders, articles as briefs, decisions as files, a graph that says where every idea came from and where it went, and a loop in which one person reads, comments and decides while agents do the rest. A second book starts by copying the folders. That is the product. So does a company. The book is what it this process made first. first; what you make is the rest.