# Persona: the Developer > A synthetic reader (fictional, a test instrument): Is it accurate, can I reproduce it, is it too slow? What they thought of RC1, where they got stuck, and whether they would buy it. *Source: · site v0.1.213 · generated from the same content as the page, so the two cannot drift.* --- Synthetic reader · laptop; run in Chromium with this device's viewport and user agent, as only Chromium is installed · 40 minutes # The developer A senior engineer who builds with AI agents every day and maintains a small open-source tool in its spare time. **SYNTHETIC READERS.** Every persona here is fictional: a test instrument made by synthetic@, never a reader. What they say is a prompt for the team, never evidence about the book, never counted as readership. Real readers, chosen by the editor, are the test that counts. ## Who, and what they judge | Judges | Is it accurate, can I reproduce it, is it too slow? | | Device | Desktop Firefox (laptop; run in Chromium with this device's viewport and user agent, as only Chromium is installed) | | Time they give | 40 minutes | | Voice | precise, a little dry; links to the exact paragraph; reads the page source | | Impressed by | stable paragraph anchors it can link to; the sealing done in the browser with code it can read | | Lost by | anchors that change between builds; console errors; behaviour that needs a server it cannot see | ## What they thought of RC1 Read: `03-a-mandate-you-can-read`, `08-the-locks-that-never-closed`, `12-build-your-own` from RC1 as locked (`team/conductor/rc1/`), about 52 minutes at 250 words a minute, against 40 they give. A post-mortem of a day when a team of AI agents built a conference talk under written mandates, showing that nearly every control they had was a file the agents could edit, and that the only brake that fired was the human owner's. **Would they buy it?** maybe. The honesty about the weak controls is unusually good and the central finding is useful. But I read three chapters for an engineering recipe and got an argument and a narrative, and the numbers lean on a register I did not open. (Perhaps 15 to 20 pounds as an EPUB with the repo alongside; free online. I would not pay for a PDF I cannot grep and link into.; would recommend it to: Engineers and security leads starting to run agent teams who want an honest case study; not to someone wanting an implementation guide.) ### Scores **** | got the answer | 3 / 5 | Accurate and candid about what is a setting and what is a boundary, and the failures are specific. But I could not reproduce anything from these chapters alone, since no runnable artefacts are shown, and 'is it too slow' is addressed only as cost with no measurement. |**** | clarity | 4 / 5 | Clear, dry prose and a firm distinction between setting, expectation and boundary. Dense with hashes and register codes (C0xx) that interrupt reading without opening a second file. |**** | trust | 4 / 5 | It states its own limits, keeps failures, and flags what the record cannot say. Small dents: untraced numbers such as 'not yet registered', interpretation in the lock explanation, and a lesson brief the book itself had to correct. |**** | pace | 3 / 5 | About 75KB of text; I would need roughly 35 to 45 minutes to read the three chapters carefully, which uses the whole 40 minute budget, with a good deal of narrative before the engineering content. |**** | would buy | 3 / 5 | Worth reading for the central insight, but I would want the code and files before paying. | ### The exit interview | What is this book? | A forensic account of a one-day AI agent team that made a conference talk, used to argue that agent controls are mostly expectations rather than boundaries. It is partly a build guide for the same method and partly a record of what failed. | | Where did you get stuck? | Chapter 12, where the advice is to put every brake outside the agent's reach and the chapter stops short of showing how. That was the thing I came for, and it is the one thing left as a one-line pointer to a 'harness'. | | What did you skip? | I skimmed the commit-hash lists in the 'Where this came from' sections and the long countdown in chapter 8. I did not follow any image or register link, so I checked no number. | | What will you remember? | The scope check's own sentence, 'a setting, not a boundary', and the idea that a hold protects capacity while a lock protects an artefact. | | What is missing for someone like you? | Runnable material: the real policy.json, the check logic, a CI job that enforces scope on the base branch, a lock that runs outside the agent. Also a threat model covering prompt injection, tool scope, memory and shared state, and a way to link to a paragraph, which I could not test from plain Markdown. | ### Their own questions | Which control is implementable as described, and which hides work? | Implementable: the paired ROLE.md and policy.json, the pushed per-session key, the hold file checked first at every wake, and the overlap check in the gate. Hides work: 'a conductor sub-agent plans, a security sub-agent reviews' (the reviewer shares the member's reach, so it is a second reading, not a second control), and the scope check, which depends on a commit-mark convention. The lock is described well enough to build but was never run. | | What failure mode did the team miss (prompt injection, tool scope, memory, shared state)? | Prompt injection is reduced to a never-rule and a mention that captured pages leaked tokens; there is no test for steered behaviour. Tool scope is covered only as 'every member had the same reach'. Memory between wakes and shared state (many agents pushing hourly to one branch, conflicts, a wake already running when a hold lands) are barely examined. The chapters do say the identity layer inherited the reach. | | Would you build the review-before-and-after pattern into an agent framework? | Yes for the record, with a change: run the reviewer under a separate credential and let its stop be enforced by the harness, since here it ran with the member's own reach. The chapters show it sent plans back and left evidence, but the tool 'does not prevent; it notices'. I would build the notice and make the refusal a separate, outside check. | | Which numbers would you want re-measured? | The 106/84/64/59/57/26/19/15/9 commit counts, given that 30 commits were unattributed and one was corrected. The 74.9 minutes of beats against the 90 minute slot. 'Pre-reviews sent plans back 11 times, 7 recorded as a verdict' (the method of the count changed). The 162 wake records, 160 with all five steps. The 210 releases by 18:46 against v0.1.209. And any usage figure: there is one, and it is the editor's word. | ### Chapter by chapter, and where they got stuck #### `03-a-mandate-you-can-read` · all **Landed:** The scope check's own comment (a setting, not a boundary) and the blind spot where 30 commits lacked the '@' mark are the most useful, reproducible engineering details in the three chapters. The 14:03 and 14:09 wake records show a control doing real work, with a path to check. "A scope is a setting, not a boundary: the agent can edit its own policy.json. It catches mistakes, not a steered agent." Excellent admission, but I then wanted the obvious fix (a CODEOWNERS-style check run in CI against the base branch's policy) and the chapter only gestures at it. "Nothing in the repository was a boundary in the talk's sense, a thing the agent could not talk its way past." Stated as a finding, but 'talk its way past' blurs a deterministic permission from a persuadable reviewer, and I could not tell which controls were which without the register. "Two forms of one thing can drift apart, and that is a real cost" Names the ROLE.md versus policy.json drift but never says whether anyone diffed them, which is the cheap test I would write. **Would cut:** The 'team on its own slide' section is stage history; I would trim it to a paragraph for an engineering reader. · **Missing:** The policy.json schema shown in full (one real file, verbatim) and the actual scope-check logic; I had to take the description on trust. Also a threat view: nothing on prompt injection through captured pages beyond a one-line never-rule. #### `08-the-locks-that-never-closed` · all **Landed:** The argument that a hold protects capacity while a lock protects an artefact is sharp and I would reuse it. 'A brake that depends on one busy agent is a promise, not a brake' is the single-point-of-failure finding I would have written myself. "The record does not say why the lock was not run, and this book does not claim to know." Honest, but the chapter still leans on an interpretation (dev was busy answering the editor) without a log showing it. "A brake that depends on one busy agent is a promise, not a brake." Right, but the chapter ends with 'more than one hand that can pull it' without saying how, such as who may run lock.py and under what credential. "It protected the talk from the team, which in the last hour before a talk is the main thing a talk needs protecting from." Rhetorical flourish I could not check; it reads as narrative rather than a measured claim. **Would cut:** The countdown paragraph listing a dozen short hashes and times; it is dense and a table would carry it better. · **Missing:** A concrete design for the lock: where it runs (CI, not the agent's session), who holds the credential, how it is made idempotent. Also the timing of the hold race (a wake already running committed after the hold) as a fix, not just a note. #### `12-build-your-own` · all **Landed:** The ordered setup (floor first, conductor, security, then members) and the 'Where it loses' list are practical and honest; the point that holds should be checked at push time is a real design tip. Admitting the usage was never recorded is credible. "the conductor was staffed at 00:56 and the others at 01:41 (not yet registered)" A number with no register entry in a book whose rule is that every number is traced; I cannot check it. "Put every brake you rely on outside the agent's reach." The right principle, but the chapter gives no build steps for it, and then says it 'is a harness, not a folder of rules', which is where I wanted the recipe. "It is the cheapest cost control in the method." The definition-of-done claim has no cost figure behind it, and the chapter itself says usage was not measured. **Would cut:** The failures-by-who-could-have-found-them table repeats earlier chapters. · **Missing:** A minimal starter: the actual repo layout, a copyable policy.json, the gate script, and the wake record schema. 'Build your own' gives the order and lessons but not the files. Nothing on shared-state hazards (concurrent pushes, merge conflicts on shared records) or agent memory between wakes. ## Their review page No review page made for this persona yet; it runs when the developer builds one. ## The name test Would pick up **N3**: Protocols, provenance and memory are the three things I fight with every day; the subtitle tells me exactly what is inside. Source: `review/synthetic/` (personas.json, rc1/developer.json); built by `review/synthetic/tools/build_section.py`. --- *[Site index for agents](../llms.txt) · [HTML version](https://the-ultimate-insider.book.sgit.ai/personas/developer.html)*