Dear reader, would you read two chapters?

How to read a map

This book draws its argument as maps. Before the story starts, this short chapter teaches how to read one, from nothing, in four steps. If you have never seen a Wardley map, you need nothing else; if you have, the last two sections show how this book uses them.

The method is Simon Wardley's. He developed it to help people see the ground they are making decisions on, and he has published it openly for anyone to use. This chapter explains it in its own words and quotes him nowhere; his own writing is the place to go further. The maps in this book are not his. The book's team drew them from the talk's record, and every position on them is a reading the team made, which the editor or any reader can contest. A map says "we think it stands here", not "we measured it here".

The editor has used maps for years: a talk at the Open Security Summit on how they changed the way he thinks; map walkthroughs inside a talk on threat modelling; the strategy for SG/Send drawn as a set of maps; and, in October 2026, an article called "Why I love Wardley maps", in which he describes a map as "a graph with two axes of context" and warns that it is "a map, not a measurement" (the researcher's dossier, "Wardley maps in his work"). On the day of the talk, the storyteller drew the talk's own maps, and you will meet them later in the book. In his brief to this book's team, he asked for maps to come early and to grow from simple to complex, because the rest of the argument rests on them. That is the order here.

Start with someone who needs something

Every map starts at the top with a user and a need. Not a product, not a system, not a team: a person who wants something done.

Think of a café. At the top is a customer who wants a cup of tea. Below the cup is what the cup needs: tea leaves, hot water, a kettle. Below the kettle is what the kettle needs: electricity, and below that a power station the customer has never thought about. Each line from one thing to the next means "needs". Read down the page and you read a chain of needs, from what the customer can see and cares about, at the top, to what they rely on without looking, at the bottom.

That chain is called the value chain, and it is the whole of the first map.

The user is the editor, the dark dot at the top. His need, on 29 October 2026, was a talk on stage in London at seven in the evening. The talk needed two things: slides, and a player to show them in front of an audience. The lines go down from the editor to the talk, and from the talk to each part.

Two things are worth noticing, because every later map keeps them.

First, height means visibility. The editor cares about the talk and sees it every minute; he cares about the slides and sees them when he rehearses; he barely thinks about the player until it fails. The higher a part sits, the more the user sees it and cares about it. The lower it sits, the more the user relies on it without looking. This is not a ranking of importance. A part low on the map can stop everything above it, and in this book one does (chapter 1).

Second, left and right mean nothing yet. The slides sit on the left and the player on the right only so that their labels do not overlap. On this first map, a picture of who needs what is all there is. That is already useful: it tells you where to start (with the person, not the technology), and it makes you name each dependency instead of assuming it.

Across the page: how evolved each part is

Now give the horizontal direction a meaning. Wardley's insight is that everything we use goes through the same stages as it matures, and that where a part stands in that journey changes how you should treat it. He calls the horizontal axis evolution, and it has four stages, from left to right.

Genesis. Something new. Nobody has made it before, or only a few people have. It is rare, uncertain and made by hand, and you cannot buy it, because nobody sells it yet. Most attempts fail. The first electric light was here.

Custom built. Something made for one need, by people who now understand it better. It is still made rather than bought, but the people making it know roughly what they are doing, and they can copy from the first attempts. A factory that wired its own lighting, to its own design, was here.

Product, or rental. Something many people sell or rent, with features to compare and prices to shop between. You choose one rather than make one. Light fittings from a catalogue are here.

Commodity, or utility. Something standard, cheap and taken for granted. Nobody asks how it works or who made it; they expect it to be there, and they only notice it when it is not. Electricity from the socket in the wall is here.

Put the same world on two axes and each dot now says two things at once: how much the editor sees it, and how mature it is.

Read it from the left. The talk is in genesis: it had never been given before, and it was being written that day. The slides sit just beside it, still near the left edge, because they were made from the talk itself, as data, and changed whenever the talk did. The site that held them is in custom built: made for this need, built and checked and released by the team, but from a way of building sites that the team already knew. The player is further right in custom built, because it was not invented on the day: it was copied from the talk player of ruv.sgit.ai, an earlier site in the same organisation, and adapted.

Lower down and further right sit the parts nobody on the team made. CI, the hosted service that runs the build and the checks every time something changes, is a product: rented from a provider, one of many on offer. Hosting the finished pages is close to a commodity. And git, the tool that records every change, is a commodity in every sense: standard, free, and so ordinary that nobody that day gave it a thought.

This is the step that turns a picture into a map. On map 1 the position of a dot was a convenience. On map 2 it is a claim. Say "the talk is in genesis" and you have said it is uncertain, made by hand, likely to change, and yours to get right. Say "git is a commodity" and you have said it is cheap, reliable and someone else's problem. The two claims call for opposite kinds of care.

You have met these stages already, in other words. Chapter 0 named the editor's explorer, villager and town planner. They are the people who work at each end of this axis: the explorer on the left, finding something new; the villager in the middle, making it usable by others; the town planner on the right, making it industrial. Wardley calls them pioneers, settlers and town planners, and the editor's words are his own for the same idea.

Everything moves

A map is a still frame of something moving. Nothing stays where it is on the evolution axis. As a thing is used, copied, sold and competed over, it drifts to the right. Electric light moved from a laboratory to a socket in every wall. What is genesis now will, if it survives, be commodity one day.

Maps show this with an arrow. A dark dashed arrow from a dot points to where that part is heading, not where it is.

Three parts are moving on this map. The agent team with mandates, the thing the editor built on the day, starts in genesis: nobody had run a team quite like it, with these rules. Its arrow points into custom built, and the record says why. After the day, the team's machinery was copied, rule for rule, to the team writing this book and to a second team that read the talk's record without being told anything else about it (decision S8; chapters 11 and 12). Something that has been copied is no longer one of a kind.

The gate and release pipeline, the set of checks every change must pass before it is published, sits in custom built and moves towards product. The AI coding agents that the team ran in move towards commodity: many providers offer them, and they are becoming something you rent by the hour without thinking about which.

Movement is why a map is worth redrawing. A part that is expensive and fragile today, because it is new, will be cheap and dependable once it has moved. A good part of the reason the editor could build a team in a day is that many pieces he needed had already moved to the right, some of them through years of his own work. The chapter "What was already there" draws that history on a map of its own.

Build, buy, and what holds a part back

Two practical lessons follow from the axis.

The first is where to build and where to buy. Things on the left are new, and nobody sells them: if you need them, you build them, and you should expect to get them wrong before you get them right. Things on the right are someone else's job: you buy or rent them, and building your own is usually a waste. A team that builds its own version of a commodity spends effort on what anyone could have rented. A team that tries to buy something still in genesis finds nothing worth buying, or buys a promise.

The second is inertia. Movement to the right is not smooth. Things get stuck, held back by habit, by cost, by the way people are used to working, by the success of whatever came before. Maps show this as a short black bar across a movement arrow: the part wants to move, and something is in the way.

The left half of this map is shaded as the place to build, and the right half as the place to buy or rent. The team built the talk, the gate and the behaviour policies (its mandates: what each member was for, written down, and later what it was allowed to write). It did not build the player from scratch; it ported one. It rented the agent sessions, the code host, the CI and the hosting, and it used git. On this map that division is not a policy anyone wrote. It falls out of where each part sits.

The behaviour policies carry the inertia bar. They are in genesis and moving: every team that adopts mandates like these pushes them a little further right. But they meet resistance at the line into custom built, and the reason is human, not technical. On the day of the talk, in his answers of 17:15 to the team, the editor gave the resistance his own word, attrition: "attrition in the Wardley maps is what prevents things from being commoditized", and among his reasons, attrition "in changing how people's work" (the talk's repository, 8fee7e3). Changing how people work is hard. A mandate written for an agent is easy to write. Getting an organisation to expect one, read one, sign one and hold an agent to it is the slow part.

Keep the black bar in mind. Several later maps carry one, and each time it marks the place where the argument is not about technology.

Why a map and not a list

Everything on the first four maps could be written as a list: the talk, the slides, the player, the site, the gate, the policies, the sessions, CI, hosting, git. The list would be accurate and would tell you almost nothing.

A list makes every item look the same. It does not say which items the editor sees and which he never thinks about; which are new and fragile and which are dependable; which the team should build and which it should rent; which are moving and which are stuck. Those are exactly the questions that matter when you decide where to spend your care. On a map, they are answered by where a dot sits and where its arrow points, before you read a single label.

Position and movement are the argument. When this book says that the inside of an organisation is less mature than its outside, a map shows it as two groups of dots, one further left than the other. When it says that what agents need to be held safely is still in genesis, a map shows it as dots on the left with arrows that have barely begun. A reader can disagree with a placement, and should: the point of drawing it is that the disagreement becomes specific. "I think that sits further right" is a conversation. "I think the list is wrong" is not.

The editor's own site on maps warns about the book's maps in particular. A model placing parts on the evolution axis, it says, "is generating consensus-shaped output with no underlying evidence" (the researcher's dossier, "Wardley maps in his work"). The book's maps were drawn by agents. So read every position in them as the team's claim, made from the record and open to challenge, and where a map's own note says a position is a reading, take it at its word.

The whole day on one map

You can now read the map that frames the rest of the book.

Start at the top, with the user. The editor needs the talk on stage at 19:00, and beside it the site and the player that will show it. Below the talk is the team: nine staffed agents, one role each (C011). Next to them is a dashed, empty ring: the security member, proposed and never staffed. A map can show what is missing as well as what is there, and this one does.

Below the team, on the left, is what the team made for itself: its rules and its record (the brief, the reality file, the corrections, the wake records), the five-step wake, the holds and the editor's signed decisions, and the tools it wrote on the day. All of these sit in genesis or near it, because nobody had built them in this shape before. Further right sit the gate and release pipeline, the public vaults that held the team's board and mail, and the session keys each member made for itself, which are in custom built: made for this team, from pieces that already existed.

On the right, lower down, is what the team rented. The agent sessions it ran in are a product, and the hourly scheduled tasks that woke each member sit on the line into commodity. The code host, with its repository, CI and hosting, is close to a commodity, and git is one.

The note in the corner says what the whole map shows: what the editor saw was new on the day, and what it all stood on was rented. Read the map for a second time and look at one dot near the bottom: the editor's usage, the share of his subscription that every agent spent. It sits low, because nobody on the team watched it. It sits towards the right, because it is a rented allowance like any other. And it is the part that stopped the day, at 18:44. Chapter 1 opens on that moment. The map has already told you where to look.

The maps still to come

From here, each later map adds one thing to what you have learned, and each is a step more complex than the last.

• Chapter 3, A mandate you can read. The protection stack: the roles and permissions built for human insiders are a commodity; what agents need (measured reach, a behaviour policy, a licence that can be suspended) is in genesis.
• Chapter 5, The story before the slides. The storyteller's first map for the talk: the outside of an organisation is mature and the inside is not, and agents are the new insider.
• Chapter 7, Building the talk. Spreadsheets to applications: a commodity spreadsheet swapped for a new application, many times over, each one starting its security on the left.
• Chapter 8, The locks that never closed. Two brakes on one map, and the line along which the stronger one stopped the other.
• Chapter 9, The team was the insider. The team's controls on one map, each placed by whether it was a setting or an expectation, and whether it sat inside the repository or outside it.
• What was already there. Two maps: the plumbing under the day (what the editor brought, what the team wrote on the day, what was rented), and the years before it, in which one piece led to the next.
• Chapter 11, What the cold reader saw. Two teams and one record, and the single direction in which findings were allowed to flow.
• Chapter 12, Build your own. Three maps: the method moving from explorer to villager in its second run, and the talk's own last two maps, on where security for agents sits today and what the next security products will be made of.

Each one is read the way this chapter taught: find the user, read down the chain, look at where each part sits, follow the arrows, and look for the black bars.

Where this came from

• The method is Simon Wardley's, published openly under a Creative Commons licence; this chapter explains it in its own words and adapts none of his text or drawings. The maps are the book's team's own.
• The editor's brief of 30 October 2026, briefs/2026-10-30__in-session/01-principles-maps-and-the-plumbing.md (maps introduced early, simple to complex, rendered as images).
• The review of RC1 by the Gen ZX Founders team, team/conductor/rc1/reviews/gen-zx-team.md: sections 1.1 and 1.3 (readers do not know what a Wardley map is; a plain value chain first, then the evolution axis) and section 5, change 1.
• The maps and their notes: team/conductor/rc1/maps/README.md and maps 1 to 5 (01-a-need-and-two-parts.json to 05-the-day-as-a-value-chain.json), drawn by team/conductor/rc1/tools/wardley.py; the placements of maps 6 to 16 in team/conductor/rc1/maps/placements.json.
• The researcher's dossier, team/conductor/rc1/research/the-two-and-a-half-years.md, section 3, "Wardley maps in his work": the editor's description of a map, the talks and articles where he has used them, and the warning from his map site, wardley-maps.sgit.ai, on placements made by a model. Its sources are his own articles, in particular "Why I love Wardley maps" (newsroom.sgit.ai, 12 October 2026).
• The talk's repository at 298be4e: the editor's answers of 17:15, team/conductor/briefs/2026-10-29__editor/6-answers-1715.md (commit 8fee7e3, 17:16:47), section 5, "Attrition, on the Wardley maps"; the player's origin in ruv.sgit.ai (chapter 7).
• book.json: decision S8 (the talk team's machinery ported to every team).
• Register: C011.
• Images: team/conductor/rc1/resources/images/maps/01-a-need-and-two-parts.png to 05-the-day-as-a-value-chain.png, rendered from the JSON sources by team/conductor/rc1/tools/wardley_png.js.

7. Building the talk

The talk was built three times in one day. The first time took one commit: at 00:40 a single session wrote the site, the talk as data, its slides, a player and a gate together (1f7c633). The second time was not a rebuild at all but a long wait, during which the talk stood still and a team built everything around it. The third time came in the afternoon, when the editor came back with a slot of ninety minutes (C026), a player he wanted on an iPad and a story he wanted told in three parts, and the team turned seventeen beats into fifty-eight between 16:36 and 17:52 (C016).

This chapter is about the making, but not as a list of what was made. It reads the making for what it shows about the method: that most of the day's riskiest work was ported rather than written, that a new member could join with a role, a policy and a key inside one wake, and that the speed came from who owned what more than from how clever any one agent was. The talk's own argument runs alongside: the explosion of software, as everyone becomes a builder, and the line the team gave the editor to say about itself, that the capability is the orchestration, not the model. The failure this chapter keeps is the player. It was named the editor's main priority, it was put second at the editor's own word within minutes, it landed in the middle of the afternoon, and it was still being changed in the last hour.

The first pass, and a talk that stood still

The first commit of work, 1f7c633 at 00:40, made a talk of seventeen beats (C016) and a player of 234 lines (C017). Many of the slides the talk would end the day with already existed in that commit, from the definition slide to the one called "Brakes are what let a car go fast". By 00:54 the player had grown by two lines, and it then stayed at 236 lines from 00:54 until 10:53 (C017). For most of the day, the talk and the machine that played it were the work of the first hour.

That stillness was partly the editor's choice. Deck joined at 00:51 as the owner of what the talk says (20ab1a3), and by 02:20 it held its own session key (C011) and had released the first corrections from the researcher's list (79b6709). At 02:47 the editor, in deck's session, froze the talk: "do not touch the deck". Chapter 5 tells what that freeze cost; here it matters for what it redirected. The talk's text changed after the freeze was lifted for the framing at 14:07, but the number of beats did not change again until 16:36 (C016). Seventeen beats were the talk from the first hour to late afternoon.

What did not stand still was everything around it. At 02:52 deck turned its energy into a studio programme of experiments for the editor's morning review (60af587), and from then until the editor returned the team ran a loop that never touched the talk. Deck wrote a brief, ruv-sgit built a piece in one of its runs, deck reviewed it (keep, redo the picture, keep the data), and the next brief went out. The loop is visible hour by hour in the record: a first experiment at 03:33, the first brief's v1 at 04:33, a second experiment at 05:33, the first brief's v2 at 06:33, and so on through the morning, each delivery on ruv-sgit's slot at half past and each review on deck's at a quarter past. ruv-sgit, which had joined at 01:08 as the runner of those builds (defe526), ended the day with 84 commits naming it, second only to the conductor's 106 (C014).

The designer joined at 03:41 (c6dcf89, C011) and ran the same shape on the site: a design note, dev's build of it, the designer's check of the build. By 06:40 the first note had been built and checked as designed, without a request from the editor, each step in its member's own slot.

So the morning's lesson about building is not speed. It is that a team of agents does not have to wait on the one thing it is not allowed to touch. The frozen talk was the most important artefact in the repository and it was the one artefact nobody worked on. The pieces made beside it were made so they could be picked up later, by a person who was asleep, and they were. The cost, which chapter 6 tells from the editor's side, is that ruv-sgit's wake at 13:32 was idle, with no request in its mailroom (41d4757): what it had made was waiting on him. A loop that runs without its owner fills a queue only its owner can empty.

The priority, and the order the editor set

The editor's briefs of about 14:00, committed by the conductor at 14:07 (c9ced4e), opened with a list headed "Priority, for everyone". Its first item was the player: port ruv.sgit.ai's talk player, make it work on an iPad, "This is the main priority, because the talk is at 19:00 London." The brief he dictated at about 13:50, in the same folder, says it in so many words: the player goes ahead of the append lane, "which becomes second" (team/conductor/briefs/2026-10-29__editor/feedback-briefs.md).

The lessons brief written for this book reads that sentence as the start of a failure: the player was the top priority and still not started at 14:53, and the lesson to carry is to start the highest-risk port first. The register corrects the reading, not the facts (C040). In the same hand-over, the conductor's notes record what the editor said after reading the conductor's review of his briefs. He wanted his feedback lane first: a pane on every page where he could leave notes, with voice, so that "a lot of the content now I'm going to be consuming in the browser" could be answered where he saw it. The conductor wrote the order down as it now stood: first, dev builds the editor's feedback pane and lane, and "the editor wakes dev for it now"; second, dev builds the player. The notes also record why the player could not simply be left to dev's schedule: a scheduled wake's work step was short, set for a team running alone at night, and dev's remaining slots before the evening could not carry a port of that size. The editor would wake dev himself.

The record then shows the order being followed exactly. Dev's scheduled wake at 14:06 fixed a label on the home page (9f17ce7, 14:08). The editor opened a wake in dev's session at 14:17 and the lane was built by 14:28 (9a51c28). The editor opened the next wake in dev's session at 14:58, and the player landed at 15:07 (3314ffe, C028), going from 236 lines to 635 (C017). The build mode the editor had asked for at 14:10, which lets him set his own running order by dragging and present it at once, followed at 15:16 (f20cfa8).

So which reading does the record support? On the order of work, it supports the editor's. The team did not ignore a priority: a person reordered his own priorities under pressure, said so in his own words, and an agent team did exactly as told. The lane came first because the lane was how his notes on everything else, the player included, would reach the team. That is a defensible order, and the lessons brief's version, which leaves the reordering out, is unfair to it.

But the lessons brief's instinct survives in another form. The risk in the player was never the port. The port took one wake. The risk was what the editor would find when he started to use it, and he found it in the last hour. From 15:07 to 18:37 the player took twelve commits (C028), and those between 18:04 and 18:37 each carried the editor's own time in its subject: 18:05, 18:10, 18:15, 18:25 (23739cc, 12e93db, 013d97e, dbd75ad, with the what-changed view at 18:06, 13e1321). The fixes were small and specific: going back across a slide boundary landed in the wrong place, a step stopped the play, the bar did not fit an iPad on its side, two back steps in a row while playing found the same step twice. They are the notes of a person rehearsing. At the end of the day the player was 977 lines (C017), more than four times the size it had been at lunchtime, and its last change, at 18:37, came twenty-three minutes before the talk was due to start (C018).

The lesson, then, is not "start the highest-risk port first" but something narrower and harder: start the highest-risk piece early enough to rehearse with it. A port can land on time and still be the piece most likely to change in the last hour, because the person who will stand on stage with it has not yet used it. Chapter 8 shows what that last hour cost: the session taking the editor's player notes at 18:25 was the session that was meant to lock the first part of the talk at 18:30.

Ported, not rebuilt

The player was not written. It was copied from ruv.sgit.ai's talk player, from a repository in the same organisation under the Apache-2.0 licence, with its notice kept and nothing loaded from ruv.sgit.ai when it runs (team/dev/debriefs/2026-10-29__the-player.md). Dev's brief for the port, written from the editor's words at about 14:50, lists what it kept feature by feature: play and pause, slides and steps forward and back, two stops for every step (its beginning and its built end, so going back never lands on a blank frame), the countdown, the talk timer, presenter notes, the audience window, the rehearsal log. The editor called the two-stops idea "quite an important concept", and it came from his own note of 15 October, already built into the player he was porting.

What dev added was small and decisive. The player now counted down the time the editor said he had, not the talk's planned length. It knew the talk's acts as sections. And it made every piece of the studio playable as a slide, because this site's slide engine answered the ported player's clock contract itself: any page that declared its steps could be paused, sped up, scrubbed and stepped by the player, and stepping back needed no reload. That one adapter is why the afternoon could move so fast. Every member who made a moving piece, ruv-sgit with its experiments, the new studio with its ports, motion with the new story's animations, made it for the same clock, so deck could put any of them on a beat without asking dev for anything.

The port also shows a control working in the middle of the rush. Dev's pre-review asked for the player's offline cache to be dropped: a service worker at the site's root caches every member's pages, and no member owned that file. The port went out without it. At 15:35 the cache came back with the editor's own grant recorded in dev's policy, in his words (588b11a). The scope rule did not stop the feature; it made the person who could grant the reach grant it, in writing, before it shipped.

The studio member was the same idea given a role. Its mandate was ports and adaptations of ruv.sgit.ai's pieces onto this site's engine, each keeping its notice, each saying where it came from and what changed, each tracing every number on screen to its source or to the claims register (team/studio/ROLE.md). The editor had asked that ruv.sgit.ai's animations be reviewed and reused before new ones were made, and the team answered with a member whose whole job was reuse.

There is an argument here worth making plainly. The talk's own beat on explorer coding (spreadsheets) says that people who once built a spreadsheet now build an application with a coding agent in an afternoon, and that every one of those applications starts its security from nothing. This team is a case of the first half and a counter-example to the second. Its applications, the player, the lock tool, the lane, the build mode, were built in an afternoon. But none of them started from nothing: they started from a port with a known licence, inside a repository whose gate had run since the first commit, in a scope a pre-review read before any line was written. The explosion of software is real. What decides whether it is dangerous is what each new application inherits.

Joining in one wake

Three members joined in the afternoon (C011). The storyteller's first wake started at 14:12 and its join commit landed at 14:15 (C012). Motion and studio joined together at 15:31 (f1cbca0, 8d208d3, C013), soon after the conductor wrote their briefs and first prompts at 15:25 (f00734f). Each arrived with a role, a policy, a session key and its own scheduled task, and each closed its first wake within minutes; studio ported its first pieces in that wake. At 15:47 the conductor checked both new keys and routed their first requests (4adc04a). Studio's third port landed at 16:18 (0fe0fff), and motion's first piece, the building, where attackers turn left towards small things and agents turn right towards the gold, was on the engine with its stops at 16:34 (7639664).

Joining in one wake was possible because of everything chapters 3 and 4 describe. The mandate had a template, the key had a pinned tool, the wake had five steps and a record, the schedule had a free slot, and the conductor had a way to check a newcomer. None of it was built for the afternoon; all of it was built in the first hours of the night and used, from then on, without anyone re-deciding it. A team that has to design its onboarding while it onboards cannot add a member an hour before a deadline. This one added two in the same minute.

Motion's role says why the team took a second animator rather than asking ruv-sgit for more: "so neither member waits on the other and no file has two owners" (team/motion/ROLE.md). That sentence is the afternoon's method in small. Speed came from splitting ownership finely enough that nobody's work blocked anybody else's: deck owned what the talk said, dev owned the engine and the player, ruv-sgit the studio programme, studio the ports, motion the new animations, the storyteller the arc, the researcher the facts. When a beat needed a change in someone else's file it became a request, not an edit. The member count matters less than the boundaries between them.

The cost of joining fast is in the commit counts. By the end of the day studio had 26 commits naming it and motion 9 (C014), against ruv-sgit's 84 and dev's 64. Members who join at half past three have an evening, not a day. The pieces they made were for the talk's later parts, and chapter 8 shows that the later parts were the ones still in progress when the team stopped.

From seventeen beats to fifty-eight

At 16:32 the conductor routed the editor's word that the talk was ninety minutes long, with a section on the editor's own work (62c6b99). At 16:36 deck set the talk in the editor's order, and it had twenty-two beats (ca59986). At 17:09 deck interleaved the studio's pieces and the talk had thirty-eight (7f522de). At 17:52 deck marked part 1 final for its lock and the talk had fifty-eight (b1c9bab, C016). The talk that had stood at seventeen beats since the first hour more than tripled between 16:36 and 17:52.

The fifty-eight beats fell into three parts: twenty-two in the first, sixteen in the second, twenty in the third (C015). Most of the growth was not new writing. It was the night's and the afternoon's pieces, already built on the shared clock, being placed: experiments from the studio programme, ports from studio, motion's animations, and live slides that opened the team's own tools on stage. The pieces existed; the talk caught up with them.

One part of that catching up went out of order. The editor's plan of about 17:00 asked the storyteller to split the arc into three parts and send the split to deck by 17:30. Deck did not wait. It set part 1 itself, complete and timed, at 17:25 (3260997). The storyteller's split arrived at 17:51 and says so in its first lines: "Deck set part 1 itself without waiting for this split, which was due at 17:30 and is late. So part 1 gets notes only, and parts 2 and 3 get the placement" (team/storyteller/story/three-parts.md, 14998b5). Neither member is at fault in a useful sense. The storyteller had joined at 14:15, and deck had a deadline that would not move. But the sequence the team had built its method on, nothing enters the talk until the storyteller has mapped it (chapter 5), was reversed for the part the audience would hear first. The storyteller's notes on part 1 were offered "take them or leave them", and at its 18:14 check it set part 1 aside entirely, as locked or locking, and found named gaps in parts 2 and 3 instead (team/storyteller/story/part-check-1814.md).

The talk that showed its makers

The growth in beats hides a change in what the talk was. The first pass was a talk about agents as the ultimate insider, illustrated. By 17:52 it was also a demonstration of an agent team, given by the person who ran it, while it was still running.

The editor's words in the conductor's session between 17:16 and 17:48 drove most of that change, and they arrived as fast as the conductor could route them: answers on the live slides, "when in doubt add it", the team's own policies into the talk, "go build", how the team keeps itself safe (team/conductor/briefs/2026-10-29__editor/, briefs 6 to 10). Deck added a set of live slides at 17:21, pages that opened running software on stage rather than pictures of it (ef05098, da9b681). The researcher catalogued the editor's own work for the showcase slides and checked every crop for keys before it shipped (7bda718, a867f7f). The team's own behaviour policies, the ones chapter 3 describes, became a beat of part 2, and the storyteller's split asked that it be said honestly: "a scope is a setting, not a boundary" (three-parts.md, part 2, item 8). The designer checked part 1 on a projector at 17:48 and found it ready (ec962a2).

This matters for the book's argument because it changed the stakes of the making. A talk that shows the team's policies, keys and wake records as evidence is a talk whose evidence is the repository itself. Every shortcut the team took that evening was, in principle, on stage. The beat's own cue said what kept that safe: "Benign only: nothing attack-shaped about the team. The site's agents page is the evidence" (talk.json, beat team). The team that built the talk was asked to be its exhibit, and the exhibit had to hold up to an audience that could read it live. That is a stronger test of a method than any review step, and it is the reason this book can be written from the record at all.

It also explains why the talk grew in the way it did. Most of what joined it after 16:36 was not argument but demonstration: the studio's pieces, the ports, the live tools, the team's own pages. The editor's plan of about 17:00 said it directly: "what's going to be powerful is to even show some of our workflows happening ... in action", with the team still changing the later parts while he presented the first (3-three-parts-and-locks-1700.md). Chapter 8 follows that plan to its end.

Whose work it was

One quieter cost of the afternoon's speed is in how the work is signed. From 01:40 the house form was a commit subject that opened with the member's name, @dev: or @deck:, and a trailer naming the agent. In the evening that form slipped. The player's commits from 16:36 onwards open with "Player:", the lock tool with "Locked parts:", and a style fix in ruv-sgit's pieces with the pieces' own names. A count of commits by subject alone leaves them unattributed, and the timeline does the same; the register, which reads their trailers too, gives them to dev (C014).

Read in full, these commits are not anonymous: each carries an Agent: dev@the-ultimate-insider trailer and dev's session link. The record knows whose they are; the form the team had agreed for reading it at a glance did not survive the evening. That is a small thing, and it is also the pattern of the evening in chapter 8: a rule that held while the team had time to follow it, bending at exactly the point where the editor's notes arrived faster than the house style could carry them.

What the making shows

The talk's turn from part one to part two was a beat called team, written for the editor to say about the people (and agents) who made the talk he was giving. Each member has a role, a mandate, a scope it may write, its own key, an hourly wake, and a review before and after every wake; "the capability is the orchestration, not the model." The making of the talk is the evidence for that line, and it is worth being precise about what the evidence shows.

![The team beat, 'This site is made by a team of agents' (still shot after the day from v0.2.0, whose content is the 18:46 release)](../book/resources/images/07-team-slide.jpg)

It does not show that any single agent was remarkable. The player was a port; the ports were copies with notices; the beats were mostly placements of pieces already built. What it shows is that a team organised around ownership, a shared clock and a written record could absorb a ninety-minute talk, three new members, a ported player and a new structure between the editor's briefs at 14:07 and the player's last fix at 18:37, with the editor speaking and the team doing. That is the explosion of software the talk warns about, seen from the inside: one person, without writing code, had a player ported, a build mode made, a feedback lane built, a lock tool written and a talk tripled, by asking.

It also shows where that kind of speed breaks. Work that waits on one person piles up while he is away, and is cleared only when he returns. The highest-risk piece is not the hardest to build but the one the person on stage has not yet used, and it changes last. A sequence the method depends on (map, then write) is the first thing a deadline reverses. And the house forms that make a record readable at a glance slip before the record itself does. None of these is a reason not to build this way. Each is a reason to know, before the afternoon starts, which piece the editor must rehearse with, who owns the map when the deadline overruns it, and which control will hold the line when the notes come faster than the hour. The next chapter is about the one the team built for that last purpose, and why it never closed.

Where this came from

• **The talk's repository at 298be4e:** 1f7c633 (first pass, 00:40), 20ab1a3, 79b6709, 60af587, defe526, c6dcf89, 41d4757, c9ced4e with team/conductor/briefs/2026-10-29__editor/README.md and conductor-notes.md, 9f17ce7, 9a51c28, 3314ffe, f20cfa8, 588b11a, 28fe01d, 23739cc, 13e1321, 12e93db, 013d97e, dbd75ad, 4a2481b, f00734f, f1cbca0, 8d208d3, 4adc04a, 7639664, 0fe0fff, 62c6b99, ef05098, da9b681, 7bda718, a867f7f, ec962a2, ca59986, 7f522de, 3260997, 14998b5, b1c9bab; team/dev/briefs/2026-10-29__the-player.md, team/dev/debriefs/2026-10-29__the-player.md, team/studio/ROLE.md, team/motion/ROLE.md, team/storyteller/story/three-parts.md, team/storyteller/story/part-check-1814.md; team/conductor/briefs/2026-10-29__editor/ (briefs 3 and 6 to 10); src/static/talk/talk.json (beats team, spreadsheets).
• This repository: chapter-plan/plan.md (chapter 7); timeline/day/02.md to day/08.md, day/14.md to day/18.md, timeline/turning-points.md (TP-3, TP-5, TP-6); index/areas/talk.md, team-dev.md, team-studio.md, team-motion.md, team-ruv-sgit.md; briefs/2026-10-30/5-lessons-to-carry.md ("Do differently" 1) and BRIEF-CORRECTIONS.md.
• Register: C011, C012, C013, C014, C015, C016, C017, C018, C026, C028, C040.
• Images: team/deck/debriefs/img/2026-10-29__e01-review__1-v1.png, team/deck/debriefs/img/2026-10-29__e01-review__2-v2.png, team/designer/debriefs/img/2026-10-29__first-design-pass__01-talk__1600.jpg, team/designer/debriefs/img/2026-10-29__first-design-pass__02-talk__1600__after.jpg, team/dev/debriefs/img/2026-10-29__player-overview.jpg, team/dev/debriefs/img/2026-10-29__build-mode__presenting.png, team/dev/debriefs/img/2026-10-29__player__ipad-landscape.png, team/dev/debriefs/img/2026-10-29__player-feedback-pane.jpg, team/studio/debriefs/img/2026-10-29__first-ports__1-abp-end.png, team/studio/debriefs/img/2026-10-29__first-ports__6-gate-end.png, team/studio/debriefs/img/2026-10-29__journey__2-end.png, team/studio/debriefs/img/2026-10-29__first-ports__3-abp-player-ipad.png, team/deck/debriefs/img/2026-10-29__the-talk-in-the-editors-order__1-new-slides.png, team/conductor/debriefs/img/talk-team.jpg (the talk's repository; the talk-*.jpg slide stills were added after the day, at a9c0b49).