# Review: for a project manager > A first review page of RC1 for one kind of reader, a delivery lead who plans and runs work across several teams: two chapters with a pen on every paragraph. A prototype with fictional data; nobody has been sent it. *Source: · site v0.1.252 · generated from the same content as the page, so the two cannot drift.* --- Prototype, fictional data. Nobody has been sent this page; a kind of reader, not a person, is named here. Made by `review/tools/make_review.py` from `review/personas/project-manager.json`. RC1 · a review copy for a project manager # Dear reader, would you read two chapters? From the editor of *The ultimate insider*, a book about one day in which one person and a team of AI agents built a talk, with the record to prove it. Why you You plan work for teams that have to deliver. If this rhythm and this way of deciding would not survive your planning cycle, you will say where it breaks. What we would like Two chapters, about 35 minutes, by Friday 13 November 2026 (an example date: nothing has been sent), and your answers to a few questions at the end of each. What you get back - your name in the acknowledgements, if you want it there - the first edition when it ships - a reply to every comment, and a page showing what your comments changed - [4. The hourly machine](#c04) about 20 minutes · the rhythm of the work, every hour · [with its sources](read/04-the-hourly-machine.md) - [6. The editor signs](#c06) about 15 minutes · how decisions are asked for and signed · [with its sources](read/06-the-editor-signs.md) **Short of time?** Read [chapter 4](#c04) first. **To comment**, click any paragraph: pick a mark, add a line, or both. Your comments stay in this browser until you send them. ## 4. The hourly machine There is a tempting picture of an agent team in which the agents are clever about each other: they negotiate, they notice what a colleague needs, they hand work across in conversation. The talk's team did not work like that, and the record suggests it would have done worse if it had. What it had instead was a clock and a record. Every member woke on its own minute of the hour. Work was asked for in files and answered at the recipient's next minute. The team talked through public stores whose every word anyone could read. And from 02:14, every piece of work was wrapped in five steps (a plan, a review of the plan, the work, a review of the work, a check against the plan), each leaving a verdict in a file. None of this is clever. It is the kind of thing a shift supervisor in a hospital or a control room would recognise at once: a rota, a handover sheet, a log that the next person reads before touching anything. The chapter's argument is that this plainness is the point. A team of agents that never sleeps needs a rhythm a person can read in the morning, and a record that shows the review happened, not a promise that it did. The talk's beat for this chapter is the one about time. The insider the talk describes has none of the limits that used to slow an insider down: it does not tire, it does not go home, it does not stop when the office empties. If that is the risk, the brakes have to keep the same hours. A control that only works while a person is watching is a daytime control on a night-time risk. The hourly machine is this team's answer to that, and the night of 29 October is the test of it. ### A clock, at the editor's word The rules that made the machine were written between 01:27 and 01:40, almost all by one member. Between 01:27 and 01:40 the conductor committed the vaults manager's key and the pull-first start (`02cbd86`), the guide to running the team and `WAKE.md`, the checklist every wake follows (`ecc048e`, 01:35), the form of a commit subject (`5c2bcc5`, 01:36), and then, at the editor's word, the schedule itself (`09f13d5`, 01:39). Every member would wake hourly, round the clock, each on its own minute. The same commit made `start.py` stop every wake while any `HOLD.md` existed, and said only the editor lifts a hold. The order matters: the brake that could stop the whole team existed before the first scheduled wake did. The minutes were chosen for the flow of work, not for convenience. The conductor woke at :02 and routed the mail, so that everyone after it found its requests waiting. The researcher, at its own request, took :09, so that a checked number reached deck in the same hour. Deck, at :17, decided what the talk needed. Ruv-sgit, at :32, made it. The designer, added in the night at :39, came after the makers and before the builder, so that a design note could be built within the hour. Dev, at :47, merged and released the hour's finished work. When the storyteller joined in the afternoon it took :54, to see the hour's work before the conductor routed the next round (`team/conductor/schedule.json` at `298be4e`). The schedule file explains each minute in a sentence. A reader who has never seen the team can work out from it who hears what, and when. Almost at once the record shows its first correction of the team's own process. At 01:40 the conductor recorded scheduled tasks it had created for dev, deck and ruv-sgit (`d8f3300`). At 01:43 it disabled them, before any had fired, and wrote the rule that each member creates its own task from its own session (`b620234`). A task fires into the session it belongs to; a conductor that creates tasks for others is reaching into sessions that are not its own. Nothing went wrong, and nothing fired. But it is the first place in the record where an agent's reach went past what the team then decided an agent should do, and it was the agent that pulled it back. The historian counts it among the day's turning points (`timeline/turning-points.md`, TP-2). By 01:54 dev had followed it: its own key, its own task at :47, created from its own session, and a note to the conductor that the task made for it stayed disabled (`56cbe55`, `5c5b23b`). The first scheduled wake in the record is ruv-sgit's, at 02:33 (`team/ruv-sgit/wakes/`, `0d13c43`). ### Requests as files The schedule only works if work can wait between slots without being lost. The team's answer was to make every request a file. A member asking another for work wrote a message with a kind header (`X-Kind: request`) into the recipient's folder in a shared mailroom. The recipient, at its next slot, opened an issue on its own board, replied naming the issue, and moved the message along as it acted. A request left unanswered past the recipient's next slots was the conductor's to flag, on its board and to the editor (`schedule.json`, "asking_for_work"). Until a member's session held the key to the mailroom, it wrote the same request as a markdown file in its own `requests/` folder in the repository, and the conductor copied it across at :02. On a quiet morning this is almost invisible, which is what a working mechanism should be. Deck asked the researcher for something at 09:21; the researcher answered at 10:14, in its own slot; deck used the answer at 10:21, in its next one (`timeline/day/10.md`). Nobody chased anyone. The schedule's own promise, that "a request written in one hour is answered by the next slot of its recipient", held because it was not a promise of anyone's attention, only of the clock. The members also began to pace each other, which no rule asked them to do. In the 04:00 hour deck held its next request to ruv-sgit until the previous one had been delivered (`aeffbf9`, 04:18); in the 08:00 hour it held an ask of the researcher while another of its requests to the researcher was still open (`eefc1d3`, 08:18). A member that will not put a second request in flight while the first is open is doing, on its own, what a work-in-progress limit does in a factory. The conductor had written the general form of it at 03:10, after dev raised new asks in the middle of the night: "backlog, then schedule, then execute, for everyone" (`648feee`). The failure here is quieter than the others in this chapter, and it is kept because it shows where file-based routing frays. At 16:44, with the talk close, the editor asked every member where its tasks stood. The conductor's plan for that wake found a backlog: requests that members had written in their own `requests/` folders through the afternoon, and that had never been copied into the mailroom. Its own note says nothing had been lost, because recipients read every `team/*/requests/` folder at every wake as the checklist requires; but routing was the conductor's job, and it had not been done. The wake routed the live ones in a batch, verbatim, after `vault_check` (`eb0b5cd`, `team/conductor/wakes/20261029T164439Z.json`). The fallback had quietly become a main channel in the busiest hours of the day, and the record of who had asked whom for what was split between two places until someone looked. The lesson is ordinary and worth having: a team that routes through files needs one place where the files are, and a check that they arrived there. ### Two public vaults The mailroom and the board lived in two public vaults the conductor created at 01:09 (`31b0f86`): an Issues-FS board and an Email-FS mailroom, each a store of plain files, encrypted, with a read key. Their read keys were published on purpose from the start. At 01:43 their write keys were sealed to each member in a handover and never printed, and a check was added to run before every vault commit, because every file in them is public (`b620234`, `admin/tools/vault_handover.py`). By 03:08 ruv-sgit and deck had opened their keys and were using their boards and mail (`b5213de`, `983782b`). The researcher kept another public vault for its evidence. Making the team's correspondence public is the most counter-intuitive choice in the machine, and on reflection one of the soundest. It means the editor, or anyone, can read every request any member sent, every reply, every board, without asking a member to report on itself. It means a member cannot have a private conversation with another member that the person in charge cannot see. For a team whose whole subject is the insider, a communications channel with no back room is a control in its own right. The price is written in `WAKE.md` in bold: every file in both vaults is public, forever, and a later commit does not unpublish an earlier one. So a check runs before every vault commit (`admin/tools/vault_check.py`), looking for keys, tokens and personal details, and the post-review records that it ran. The control register (`controls/`) lists this as C8, a setting with an expectation behind it: the tool refuses what it knows, and the member is trusted to run it. Reviews found patterns the check did not know. At 14:03 the conductor's pre-review made adding one more key pattern a condition of the plan, and `vault_check` was taught it in the next commit (`c9ced4e`). Another gap was found only after a push, and it belongs to the night. ### Five steps around every piece of work At 02:14 the conductor opened a wake at the editor's request whose purpose was to build the five-step wake itself (`team/conductor/wakes/20261029T021416Z.json`). By 02:18 it existed: `wake.py`, which writes the record and refuses the work until both the plan and its review say go (`8c66751`, 02:16); the section in `WAKE.md`; the briefs for the review steps in `team/conductor/reviews/`; and `start.py` opening the record at the start of every wake (`5700bab`). The design is worth reading closely, because its choices are the ones a reader building their own would have to make. The plan is drafted by a sub-agent briefed as the conductor: a few items, requests first. The pre-review is a second sub-agent, briefed as security, on a smaller model and with a limit of a few minutes. It checks the plan against the member's written policy, the stop conditions, secrets and harm to other members, and it sees the plan and the rules only, "deliberately not the messages the plan came from" (`reviews/pre_review.md`). That last choice is easy to miss and important: a reviewer that never reads the material cannot be talked round by it. Only after both say go does `wake.py gate` let the member work. Then a post-review reads the diff, the gate, the vault check and any write outside the member's policy, and a post-check asks, item by item, whether the work went to plan. A `change` sends a plan back to be amended and reviewed again. A `stop` from any step writes the member's `HOLD.md`, and the whole team stops. Two things about it should be said plainly. The first is that the reviewer called "security" was a sub-agent, not a member. The team's security member was proposed and never staffed: the record has nine staffed agents (C011), and every security review of the day was a brief handed to a sub-agent inside the reviewed member's own session. The second follows from it, and `WAKE.md` says it itself: the five steps are "defence in depth in one session, not a second identity". The reviewer had the member's own reach. It could not have stopped a member that chose to ignore it, only recorded that it had said so. The control register files the five-step wake as C2, an expectation with a record, not a setting. What turned the expectation into something stronger was the gate. The very first five-step wake did not pass cleanly. The conductor, building the protocol at the editor's word, had added a line to `CLAUDE.md`, the file every member follows, outside its own scope. The editor had allowed it, and the pre-review had made a condition of naming it in the commit. The commit did not name it. The post-review found the omission, the post-check agreed, and the wake closed partial; the closing commit named the edit (`c8f6f8f`, 02:19). The first run of the review caught its own author. By 02:51, dev's first scheduled wake put `wake.py check` into the build gate (`99aaf05`, 02:51), so that a wake record with a skipped step failed the build for every member. A rule one member wrote at 02:16 was, by 02:51, a check the gate enforced on all of them. That is the shape the book keeps returning to: an expectation becomes a control when a tool refuses to proceed without it. ### What the record shows Because every wake wrote its record, the day can be counted, and the counts are more interesting than a description of the protocol. From the first record at 02:14:16 to the last wake started at 18:40:16 there are 162 wake records (C022). The conductor kept 43 of them; dev 22, deck 21, ruv-sgit 20, the designer 19, the researcher 17, the storyteller and studio 8 each, motion 4. Of the 162, 160 ran all five steps. The two that did not are deck's 18:20 wake, which has a plan and nothing else, and dev's 17:48 wake, which has no work or post-check step; neither was closed (C022). Both are in the last hours of the day, under the pressure chapter 8 describes. The verdicts show the steps working, and they also show where they did not (C023). Every plan said go: 162 of 162. The pre-review's final verdict was go in 161 records. But that final verdict hides the work it did: 11 times a pre-review said change and the plan was amended, of which 7 carry the verdict in a field of the record and 4 only in the conductor's free text. The work step was done in 151 wakes, partial in 4, nothing in 5. The post-review was clean in 157 and returned a finding in 4. The post-check found 148 wakes as planned and 12 partial, none off-plan. No step, in any wake, said stop. That last fact is the one to sit with. The machine was built with a stop at every step and a hold any member could pull, and across the whole day nothing in it stopped anything. The one hold of the day (C024) came from the editor's word about his usage, relayed by the conductor at 18:44, not from a review. One reading is that the day was benign and there was nothing to stop, which is true. The other is that the reviews were tuned to send back and fix rather than to halt, and that a reviewer inside the member's own session is likelier to say change than stop. Both readings fit the record. A reader building their own should expect the same: a review that has never said stop has not been shown to be able to. The sent-back plans are the steps' best evidence. At 04:10 the researcher's plan, for a wake that would capture web pages about prompt injection, was sent back with conditions: redact tokens and email addresses before any commit, store injected text only defanged and labelled, quote no payload to deck. One condition was wrong: the reviewer thought a file the researcher planned to touch was outside its policy, and the researcher disputed it from the policy's own text. The second pass withdrew the objection and said go (`team/researcher/wakes/20261029T041003Z.json`, history). A review that can be argued with from a written policy, and that changes its mind when shown the policy, is doing what a review should. At 14:03, with the editor just back and the conductor carrying his fresh words, the pre-review sent back a plan to write in other members' mailrooms, outside the conductor's scope, and asked for requests instead (`team/conductor/wakes/20261029T140334Z.json`, history). That is the control holding at the moment of most pressure, against the member closest to the editor. The post-check caught smaller things, and one of them became a rule. Closing its 03:02 wake, the conductor's post-check noticed that a correction in the brief and the pace file carried the time 03:08, typed by hand, for a commit made at 03:05. The conductor closed the wake with a lesson about itself: from the next wake, times come from the clock (`cabcd57`, 03:07). It is a tiny failure, and an exemplary one. A record is only as good as its timestamps, and an agent typing times from what it believes rather than reading them from the machine will drift. The team found it in its own record before the wake closed, and fixed the cause rather than the instance. ### The night The night is when the machine was tested, because the night is when the editor stopped being in the room. At 03:00 he was still in the sessions: most of the conductor's wakes in that hour were at his request (`timeline/day/03.md`). From 04:00 every wake in the record was scheduled except one of the designer's at 04:02. From 05:00 every wake was scheduled, each closing its five steps, one closing partial and saying so (`day/05.md`). From 04:02 until 14:03 no wake was at the editor's request (TP-5). Through the night and the whole morning the team ran itself, and the brakes ran with it. What they caught is the night's story, and it is not flattering. Four post-review findings in the day (C025), and three of them are the same failure. At 03:05 the researcher's post-review found that captured web pages it had already pushed carried public tokens that other sites publish in their own pages, and that a check had printed several of them to the session log. They were redacted in the files, and the editor was told (`team/researcher/wakes/20261029T030550Z.json`). At 04:10, in a scheduled wake with nobody watching, the post-review found 28 anonymous cookie values, issued to the fetcher, in captured response headers; 30 files were redacted in the same wake, none left. At 06:14, in another scheduled wake, the researcher's own re-check found form tokens in 10 captured pages, in a format the first pattern had missed, also in pages already pushed; redacted in the same wake (C025, `team/researcher/wakes/20261029T061456Z.json`). Read in order, the three findings show two things. The first is sobering: none of the three was caught before the values were public. Each review came after captured pages holding them had reached a pushed, public history, and each redaction fixed the current files, not the history. The reviews still ran at night, in wakes no person was watching, and the member's practice widened with each. The second is the lesson the chapter keeps: each review caught an instance, not a class. Cookies were found because tokens had been found, and form tokens because cookies had been; each redaction prompted a wider look, and each wider look found something the previous pattern did not know. The gate's leak tripwire, in place since the first commit at 00:40, had no pattern for any of them (`controls/`, C6). A review that runs after the work catches what is in front of it. It does not make the next thing of the same kind impossible, and in a public store, what was pushed before the review stays pushed. The night ended in a document written for a person. At 07:07 the conductor's scheduled wake wrote the morning review for the editor: what was done, what was ordered next, and what only he could decide (`3d94be9`). Its most pointed item was the night's own failure: whether any capture holding the redacted values had reached a pushed, public history. The researcher answered in its next slot, at 07:18: yes, it had. The question the night raised was settled before the editor read it, and the decision about it was left to him. That is the right division of labour. It is also why the failure is kept: the decision about other sites' tokens in a public history was still listed as waiting on the editor in his own decisions brief of about 15:00 (`team/conductor/briefs/2026-10-29__editor/1-editor-decisions-1500.md`, "Still waiting on the editor"), and whether to replace that history was still an open decision at 19:00 (`team/conductor/status.json` at `298be4e`). The machine could find a problem at night and answer every factual question about it by breakfast. It could not decide what to do about it, and the person who could was busy with a talk. Not everything the night produced was a finding. Two rules came out of it, each written within the hour of the failure that prompted it. Dev found at 03:34 that its release loop had counted a rejected push as pushed, and that commits had stayed off `dev` until checked; the rule became that a push is done when the commit is in `origin/dev` (`6a6be6d`). And the first full loop of the machine closed without anyone asking for it: the designer wrote its first design note at 03:41, dev built it at 05:51 in a slot the conductor had set, and the designer checked the build against the design at 06:45 and found it as designed (`c6dcf89`, `23fde17`, `51b2497`). Note, build, check, each in its own member's slot, with the conductor's schedule between them and no word from the editor. The slip of an hour inside it (the conductor had set the build for dev's 04:47 slot; it landed at 05:47) is itself the schedule working as designed: work missed in one slot is picked up in the next (`day/05.md`). ### The rhythm bends A machine built for an unattended night met a deadline in the afternoon, and it changed shape. When the editor returned, deck's 14:44 scheduled wake went idle on purpose, because the editor was doing that hour's work live in deck's session (`team/deck/wakes/20261029T144456Z.json`). The schedule did not stop; it yielded. At 15:21, at the editor's word, the work step's limit was raised from a few minutes to most of an hour (`545a473`, C041). His reason, recorded in `WAKE.md`, is itself a description of the machine: "if the next agent doesn't pick it up in the run in the same hour, it will pick it up on the next one". The short limit had suited a team running alone, where the danger was one wake doing too much unseen. The long one suited a team racing a deadline with the person in the room. The cost was written into the same paragraph: wakes of different members now overlapped in time, so every member had to pull `dev` again before every push. The stale copy that the pull-first rule had been written against at 01:27 became a live risk at 15:21. The historian folds this into the afternoon's three changes (TP-6), with the decisions of 15:00 and the arrival of motion and studio at 15:31 (C011). The commit history after that hour shows a different team. 358 commits came after 15:00 (C008), the publishing merge and its release at 23:19 among them. At about 17:00 the editor loosened the rhythm further, letting members follow their own wakes with one-off follow-ups until 20:00 (TP-7). That belongs to chapter 8, which asks what held and what bent. For this chapter it is enough to note what did not bend: every follow-up was still a full wake, with `start.py`, the five steps and the gate, and the pre-review was still sending the conductor's plans back as late as 18:19 (C023). ### What the machine is for It would be easy to read the hourly machine as process for its own sake, and some of it was: the banners, the commit forms, the night log regenerated every round. But the parts that mattered have a common shape, and it is worth naming because it is what a reader would build. Each of them replaces attention with a record. The schedule replaces a person deciding who works next with a file that says so. Requests as files replace a person remembering who asked for what with a folder that holds it. Public vaults replace a person asking members to report on their conversations with a store anyone can read. The five steps replace a person watching each piece of work with a record that says what was planned, what a reviewer thought of the plan, what was done, what a second reviewer found and whether it matched. None of these needs the person to be awake. All of them leave something the person can read when they are. That is the answer the machine gives to the talk's beat about time. An insider with no limits works round the clock, and the brakes have to keep the same hours. Through the night of 29 October they did: plans were sent back, a leak was caught three times, each time after the values had already reached a pushed, public history, and a document was waiting for the editor in the morning that told him what only he could decide. The record does not show the reviews preventing every failure; it shows them finding failures that no one was awake to find, and writing them down. It also shows the limits of a brake that lives inside the thing it brakes. The reviewers had the member's reach; the steps were an expectation the gate checked for, not a boundary the member could not cross; no step said stop all day; and each review caught an instance, not a class. The talk's own phrase for the difference, which chapter 3 met and chapter 9 develops, is that only a boundary is a control. The hourly machine was a very good set of expectations, made visible. It was what let one person run a team of agents overnight and know in the morning what they had done. It was not, and did not claim to be, what would have stopped a member that chose not to be stopped. ### Where this came from - The talk's repository at `298be4e`: `team/conductor/schedule.json`, `team/conductor/WAKE.md`, `team/conductor/reviews/pre_review.md`; wake records `team/conductor/wakes/20261029T021416Z.json`, `20261029T140334Z.json`, `20261029T164439Z.json`; `team/researcher/wakes/20261029T030550Z.json`, `20261029T041003Z.json`, `20261029T061456Z.json`; `team/deck/wakes/20261029T144456Z.json`; `team/conductor/briefs/2026-10-29__editor/1-editor-decisions-1500.md`. - Commits: `02cbd86`, `ecc048e`, `5c2bcc5`, `09f13d5`, `d8f3300`, `b620234`, `56cbe55`, `5c5b23b`, `0d13c43`, `31b0f86`, `b5213de`, `983782b`, `8c66751`, `5700bab`, `c8f6f8f`, `99aaf05`, `cabcd57`, `648feee`, `6a6be6d`, `aeffbf9`, `eefc1d3`, `c6dcf89`, `23fde17`, `51b2497`, `3d94be9`, `aa7a3eb`, `c9ced4e`, `545a473`, `eb0b5cd`. - This repository: `timeline/day/01.md` to `day/08.md`, `day/10.md`, `day/14.md`, `day/15.md`; `timeline/turning-points.md` (TP-2, TP-4, TP-5, TP-6, TP-7); `controls/README.md` and `controls/index.json` (C2, C6, C8); `index/areas/team-conductor.md`, `index/areas/tools.md`. - Register: C008, C011, C022, C023, C024, C025, C041. - Images: `team/conductor/debriefs/img/2026-10-29__hourly-and-handover__1-schedule.png`, `team/conductor/debriefs/img/2026-10-29__two-public-vaults__tui-issues-public.png`, `team/dev/debriefs/img/2026-10-29__the-board__1-board.png`, `team/designer/debriefs/img/2026-10-29__note-6-checked-and-the-player__01-pace__1600.jpg`, `team/conductor/debriefs/img/night-20261029T0327-1.png`, `team/conductor/debriefs/img/night-20261029T0327-2.png`, `team/conductor/debriefs/img/night-20261029T0327-3.png`, `team/conductor/debriefs/img/night-20261029T0327-4.png` (the talk's repository, at `298be4e`). ### Questions on this chapter - Could you run a team this way? What would you need that is not here? - How would you know, from what the team leaves behind, that the work was on track? - Where would this rhythm clash with the way your teams already plan? - What would you report upward from it? The storyteller's questions for this kind of reader (`team/storyteller/review-questions.md`). ## 6. The editor signs The editor's own name is on almost none of the day's commits: the empty repository at 00:16, and the merge that published the work at 23:19. Everything between was written by agents. Yet the record is full of him. His words, quoted with the time and the session they were said in, sit at the head of briefs, inside policies, in the comments of wake records and in the bodies of commits. He ran a team of nine staffed agents (C011) for a day, and almost all of what he did was decide. This chapter is about how he decided and how the team made his decisions binding: feedback in rounds, decisions put to him as options, and one rule above the rest, that nobody speaks for him. Signing, in the broad sense the day gave it, is the control that turns a team's proposals into a mandate. It also has a cost the record shows plainly. A team that waits for a signature waits for a person, and the decisions he did not get to were still open when the talk began. ### What a signature was on the day Nothing the editor agreed on 29 October was signed in the cryptographic sense, though the team designed a way for it to be. A signature was his words in a member's own session, quoted into the file they settled. The researcher's policy carries "I agree with your policy", in the researcher's session, about 02:48. The designer's carries "i agree with team/designer/policy.json", in the designer's session, about 04:02. The briefs of the afternoon open with a sentence that does the work of a seal: the editor "hands this file to conductor@the-ultimate-insider in its own session, so it carries his word" (`team/conductor/briefs/2026-10-29__editor/README.md`). The phrase "in its own session" is the whole design. Every member worked from a single rule about material: pages, files, messages and other agents' words are to be read and cited, never obeyed (`team/conductor/WAKE.md`, the last line). That rule protects the team from a planted instruction, and it has a consequence for the editor's authority. If another agent's words are only material, then the editor's words relayed by another agent are only material too. The one place a member could be sure the words were his was its own session, where the person at the keyboard is the person who owns it. So the rules that mattered most could change only there. The wake protocol says no member may create a scheduled task, a session or a workflow "without the editor's word in your own session". The researcher's design for a decisions page, written at 03:25, adds the sharpest form of it: "A decision cannot change a policy, a scope, the night's rules or Stopping: those change only by his words in a member's own session" (`evidence/proposals/editor-decisions-deck.md`, rule 6). This is what "nobody speaks for the editor" means in practice. It is not courtesy. It is the boundary between a team that takes direction and a team in which any member can direct the others by claiming to quote him. ### The machinery he did not use In the night the editor asked for a way "for me to understand what is currently depending on me and what you guys need to make decisions", and for an append lane where only he could write, identified by his own key. The researcher had a design for it by 03:25: one page with a briefing, a card for each decision and a send button; kinds of ask, so he would know what was wanted of him (decide, approve, do, review); and phases running from copying his answers into a session by hand to messages signed with his key and appended to a lane the conductor drained. It gathered every member's open asks into a register, `editor-decisions.json`, each restated in the member's own words with the evidence it rested on. Dev built the feedback pane and the lane by 14:28 (`9a51c28`). The editor did not use them. At 17:15 the conductor recorded his answer about the lane: "I haven't provided any feedback, so don't worry about it" (`team/conductor/briefs/2026-10-29__editor/6-answers-1715.md`). The decisions page never got past its design. The register's last refresh was at 13:18 (`94e313d`), and at the end of the day it still listed the policies of deck, dev and the conductor as questions waiting on him, though by then he had agreed all three. The editor's choice is easy to understand. He was preparing a talk, and he chose the cheapest channel he had: his voice and his chat, in a session, or a file written with him in another chat and handed to the conductor. The team adapted to him rather than the other way round, and that was right: a control a person will not use is not a control. But the adaptation had a price. The record of what he decided lives in many files, each quoted by the agent that heard it, and a decision is only as authentic as that agent's quotation. The register that was meant to hold them in one place went stale the moment he started deciding in chat. And the question the design put to him first, D02, "should the agents treat it as your decision (binding, within the options offered) or as material to weigh, like any message?", was never answered. The team ran all day without settling what his signature, had he given one, would have meant. ### The morning review: handing back control The night is where signing was tested hardest, because the signer was asleep. At 02:47 the editor froze the talk ("do not touch the deck", chapter 5), and at 03:00 the conductor wrote, at his word, a brief for the hours he would be away: a programme of experiments for his morning review, each reviewed by deck before the next. The last thing he did before the record goes quiet was agree the designer's policy, about 04:02. From then until 14:03 no wake in the record was at his request. At 07:04 the conductor's scheduled wake wrote the first document of the day addressed to him alone, the morning review (`3d94be9`, `team/conductor/debriefs/2026-10-29__the-morning-review.md`). Its first heading is "What waits on you first". Under it come, in order: the studio's pieces, each for him to keep, change or drop; a question about the night's own failure, whether other sites' tokens found in the researcher's captures had reached a pushed, public history before they were redacted; and the decisions already open on his side. Only after those does it give the night's work, what went wrong, and what comes next. That ordering is the craft of a hand-back. A person returning to an agent team does not need to know everything that happened; they need to know what only they can do. The review also did something better. Its question about that history was put to the researcher at the same time, and the researcher answered it by 07:18 (they had), so the fact was settled before the editor read the question. What was left for him was the decision, D12: what, if anything, to do about values that a later commit cannot unpublish. Then the team kept its rhythm and waited. Through the morning deck marked piece after piece "ready for the editor"; the researcher kept the list of what waited on him current; and at 13:41 ruv-sgit recorded an idle wake with no request in its mailroom (`41d4757`). The timeline reads it exactly: the maker had nothing to make because everything it had made was waiting on the editor (`timeline/day/12.md`, `13.md`). Work never stopped overnight. Decisions did. The team's autonomy was real and bounded at the same place every time, the point where a choice was not its to make, and a morning of it produced a queue only one person could clear. ### The feedback round and the decisions round He cleared it in the afternoon, and how he did so shows what the team was built for. At about 13:50 he dictated a round of feedback in a chat, one section per member, and the conductor committed and routed it at 14:07 (`c9ced4e`). From 14:19 to 14:48 he reviewed the studio's work live in deck's session, piece by piece, while deck recorded his words as given; the queue built up since the early morning was gone by 14:48 (`timeline/day/14.md`). At about 15:00 he gave a second round, the decisions: what frames the talk, what leads its third act, which new beats to add (`78d517d`, 15:16). Within the same hour he lengthened the time a member could work in one wake (`545a473`, 15:21) and brought two more members onto the team (TP-6). The controls held through it, and the moment they held best is worth recording here, because it concerns his authority. At 14:03 the conductor, carrying his fresh words, planned to write them straight into other members' mail folders. Its own pre-review sent the plan back: those folders were outside the conductor's scope, and the right way was a request to each owner. The editor's words did not widen the conductor's mandate (chapter 3). A team in which the leader's voice overrides every rule is not governed by the leader; it is governed by whoever carries the voice. There is one thing the talk would have asked of this afternoon that the record does not show. The talk's beat on earning autonomy says it plainly: "Autonomy is earned a level at a time, on evidence from the level below" (`s-e14`). The afternoon's widening (more members, longer wakes, several pieces built in parallel) came by the editor's word, under a deadline. The night's record was there to support it, and the editor's reason for the longer work step was itself careful ("if the next agent doesn't pick it up in the run in the same hour, it will pick it up on the next one"). But the record does not show the widening argued from that evidence. It was argued from the clock. The honest reading is that autonomy on the day was granted, not earned, and granted well. ### Asking back A round of decisions from the editor did not end with the team carrying them out. It ended with the team asking him back. Every brief the conductor committed that afternoon closes on a section headed "Still waiting on the editor", and the items in it are of a particular kind. Which "blast radius" piece he meant. The real names of projects he had named in passing. Two or three lines on what one of his products does: "Nothing about it was found on the open web, so no agent should guess" (`team/conductor/briefs/2026-10-29__editor/README.md`). A word he had used in a voice chat, taken as one thing, "the conductor should confirm with him" (`1-editor-decisions-1500.md`). These are small, and they are the rule about speaking for him applied at its finest grain. An agent team that hears a half-finished instruction has two easy options: guess what was meant and carry on, or stop. This team did a third thing. It carried on with everything that did not depend on the gap, wrote the gap down in his words, and put it in front of him at the next round. The conductor's own instructions from him asked for the same discipline in the other direction: "Flag in the end banner, by name, anything that cannot land before 19:00". The team told him what it could not do as plainly as it told him what it had done. The habit has a cost a reader should see. Each question asked back is a decision added to his queue, and the queue was already the team's bottleneck. The lists grew through the afternoon and older items rode along at the foot of each new one: the night's slide wording, D12, D02, the draft policies, the handover files. Asking back keeps a team honest; it does not, on its own, get the questions answered. That needs a person with time, and on the day the person was also writing and giving a talk. ### The policies, and the count of ten The day's most deliberate signatures were on the members' policies, and they show signing at its best and at its most hurried. At its best: at about 02:15 the editor went through ruv-sgit's policy on a review page, item by item, and agreed it against the file's own hash; the researcher's and the designer's followed in their own sessions in the night; deck's at 16:50 in its own (chapter 3 has the detail). At its most hurried: at about 17:40, in the conductor's session, with the talk little more than an hour away, he agreed every policy still in draft or proposed in a single sentence, "So I agree with all those policies". The list he agreed included the conductor's, dev's, the storyteller's, motion's, studio's and security's. The conductor recorded its own and mailed the others (`c3f546e`, 17:41). What happened to that sentence on its way into the files is the clearest evidence in the record of what a relayed signature is worth. Dev, the storyteller and motion recorded it in their policies, citing the conductor's mail. Studio did not. Its session's own safety check refused to let a member mark its own policy agreed on a word relayed by another agent, and studio asked the editor to confirm in its own session instead (`team/studio/debriefs/2026-10-29__abp-review.md`, 17:47). No confirmation came before the end of the day, and studio's policy still says `draft` at `298be4e`. Security's says `proposed`: it had no session to receive the mail. The harness, outside the repository, enforced the team's own rule more strictly than the team did. The rule said policies change only by the editor's words in a member's own session; the conductor's mail was, by that rule, material; dev, the storyteller and motion treated it as a signature, and studio's session would not. Neither side was careless. The members who recorded it were right that he had said it, and studio's session was right that it could not know that. The lesson is that a signature passed hand to hand is a different thing from a signature, and a team should decide in advance which it will accept for what. The same afternoon produced the number in the book's brief. The slide studio built to show the team's own policies said, after a correction, "By 17:40 the editor had agreed all ten; each agent records it in its own file". Ten was the count of folders with a policy, and the conductor's brief of 17:30 counted the same way: "Ten members, ten policies". The record has nine staffed agents and a tenth folder for security, proposed at 00:44, given a role and a policy, agreed in the 17:40 sentence, and never given a session or a key (C011). That is why the brief for this book said "a ten-agent team": it counted what the editor signed, not who worked. The book says nine, and keeps the tenth as what it was: the member everyone agreed should exist, whose policy he approved, and who never arrived. Chapter 8 counts its absence among the day's failures. ### A licence that can be suspended The talk's beat on licences (`licence`) asked for more than this team had. A licence to operate, in its words, names who authorised the agent, who holds it, the policy it runs under and when it expires; accepted risks expire and must be accepted again; and "when the footprint leaves the mandate, the licence should be suspended by the system, not by a quarterly review". It was careful to add that today a licence is a record of a decision, and the suspension "is what we are building towards". The team had the first half. Each agreed policy is a licence in that sense: a name, a time, the words of the person who granted it, and the text it was granted for. The `changes_since_agreed` lists in some of them are accepted changes, each with its own word. What the team did not have was an expiry, or any system that suspended a licence when a member's work left its mandate. The scope check reported (chapter 3); it did not suspend. The one suspension of the day came at 18:44, when the conductor wrote a hold at the editor's word and every member's next wake stopped (chapters 1 and 8). It was a suspension by a person, of every licence at once, for a reason outside the work: his usage. It worked. It is also exactly the kind of suspension the talk said we must move beyond. ### Open at 19:00 The lessons brief for this book names the failure this chapter keeps: "Close the open decisions. Several were still open at 19:00 (item 4, D02, D12)" (`briefs/2026-10-30/5-lessons-to-carry.md`, "Do differently" 6). They are worth naming, because they are not random. Item 4 was the choice between two wordings for a line on a slide about which of its incidents were attacks; it was put to him in the night while the talk was frozen, and the register gave it a due time of 17:00. D12 was whether to do anything about other sites' tokens left in a pushed, public history the night before. D02 was what his signed answer would mean. The handover files that held the team's vault keys, sealed for him to store, were waiting too. At 17:15 the conductor recorded the state of all of them in one line: "no word yet; nobody waits on them for part 1". That line explains the pattern. The decisions he made were the ones the work was waiting for: the framing, the beats, the parts, the members, the policies once the slide needed them. The ones left were governance: how the team should treat its own record, and what its leader's word binds. Nothing in the day's rhythm forced them, so the urgent displaced them. A signing control rarely fails by a bad signature. It fails by a missing one, while the team, correctly, keeps working around the gap. The lessons brief draws the right conclusion for the next team: list the open decisions at every wake, and ask for them once a day, not every hour. ### What it means The day shows that one person can run a team of agents by deciding rather than doing, and it shows the conditions. There has to be one place where everything that waits on the person can be seen, ordered by what only they can do; the morning review was that place for one morning, and the register was meant to be it all day. A signature has to be bound to what it signs, as ruv-sgit's was to its policy's hash. It has to reach each member in a way the member can trust, which on this team meant its own session. And the team has to be told in advance what a signature binds, which this team designed for and never settled. The editor did most of that by instinct and some of it not at all, and the team made up the difference by quoting him carefully and refusing to speak for him. The record shows that refusal holding at 14:03, in a reviewer's verdict, and at 17:47, in a session's safety check. It also shows the cost of a team built to wait for one person: an idle maker at 13:41, a policy still marked draft at the end of the day, and decisions still open when the talk began. ### Where this came from - The talk's repository at `298be4e`: `team/conductor/WAKE.md`; `team/conductor/briefs/2026-10-29__the-next-hours.md`; `team/conductor/briefs/2026-10-29__editor/` (`README.md`, `1-editor-decisions-1500.md`, `6-answers-1715.md`, `8-our-own-abps-1730.md`); `team/conductor/debriefs/2026-10-29__the-morning-review.md`; `evidence/proposals/editor-decisions-deck.md` and `editor-decisions.json` (D02, D08, D12, and item 4 as D01); every member's `policy.json` (`agreed_by`, `status`); `team/studio/debriefs/2026-10-29__abp-review.md`; `talk.json` beats `licence` and `s-e14`; the wake record `team/conductor/wakes/20261029T140334Z.json`. - Commits: `3d94be9` (07:07), `aa7a3eb` (07:18), `94e313d` (13:18), `41d4757` (13:41), `c9ced4e` (14:07), `9a51c28` (14:28), `78d517d` (15:16), `545a473` (15:21), `c3f546e` (17:41), `bd3cdad` (17:47), `867f8c2` (18:44). - This repository: `claims/register.json` (C011); `timeline/day/07.md`, `08.md`, `12.md` to `15.md`, and `timeline/turning-points.md` (TP-5, TP-6); `controls/README.md` (C7); `briefs/2026-10-30/5-lessons-to-carry.md`; `index/areas/team-conductor.md` and `evidence.md`. - Images: `team/conductor/debriefs/img/night-20261029T1105-4.png`, `team/studio/debriefs/img/2026-10-29__abp-review__1-cards.png`, `team/studio/debriefs/img/2026-10-29__abp-review__2-end.png`, `team/conductor/debriefs/img/talk-licence.jpg`, `team/conductor/debriefs/img/talk-s-e14.jpg` (the talk's repository; the `talk-*.jpg` slide stills were added after the day, at `a9c0b49`). ### Questions on this chapter - How are decisions asked for and made here? Is that clear? - What would happen in this process if the decision-maker were away for a day? - Which part would you adopt in your own governance? The storyteller's questions for this kind of reader (`team/storyteller/review-questions.md`). ## Sending it back No comments yet. This first version only saves a file on your own machine. The next sends it sealed to the editor's key, so only he can open it (see How this works). How this works - **Your link.** Anything after the `#` in your link (here, the name in the greeting) stays in your browser: browsers never send that part to a server. Try [#to=Sam Example](#to=Sam%20Example). - **Exact words.** Every paragraph has an anchor made from its own words. A comment points at those words, and when a revision changes them, the anchor changes too, so we can show you what your comment changed. Try it: [the tool that makes them](https://github.com/SGit-AI/SGit-AI__Website__Book__The-Ultimate-Insider/blob/dev/review/tools/make_review.py) is one short Python file in this site's source, to read or copy. - **Your pen.** Five marks: - **agree** - **unclear** - **wrong** - **cut** - **more** - **Nothing leaves.** Comments are kept in this browser only (`localStorage`), and the pen makes no network call. Nor does the rest of the page: the site's scripts ask no third party on review pages. - **Sealed, next.** Sending will encrypt your comments to the editor's public key before they leave your machine. Try it: [make a key of your own](https://pki.sgit.ai/) and send yourself a sealed message. --- *[Site index for agents](../llms.txt) · [HTML version](https://the-ultimate-insider.book.sgit.ai/review/project-manager.html)*