2026-10-21 - From Human Relay to Agent Relay: What Changed When Our AI Roles Began Passing the Work Among Themselves
Abstract
What did one person gain by taking himself out of carrying work between his AI agents, while keeping the goals, the decisions and the review? On eleven weeks of one business's records, more work got done, more of it passed review, and much less of it waited on him, though some of each change began before he handed anything over.
The business is one person and a team of long-lived AI roles. In five steps over four weeks, from September 22 to October 19, 2026, he stopped restarting their sessions, relaying their messages (telling each role to read its mail) and starting their next tasks. We counted his messages in every session transcript against the changes the roles committed, read every review the roles wrote of their builders' work, had a sample of passing work re-graded by fresh graders, and read the production server's deploy record.
All sixteen roles were at work from early October, against the four or five he could once relay by hand, and the relays he typed fell from 778 in September to four in the rest of October. The work done per message of his rose about fivefold. The share of builders' work passing review rose from 82% to 97%, and the re-grade gave no support to reading that as leniency. His bare go-ahead replies fell from 7.8 to 0.3 per 100 changes. A third or more of the content role's work orders now reach three or more roles, against about a sixth before. The roles' own job orders did not clearly improve, and once a wrong ruling spread to four roles in four minutes. The timing shows what changed alongside the steps, not what each one caused. What we would carry over is the order: take the human out of the relays, leave him the decisions.
1. The shop, and the limit it hit
Takase Studios is one person and a team of AI roles, each expert in one domain of the business, which now carry a goal across their domains among themselves. The domains include the rendering engine that builds products from the master calligrapher's brushwork, the live website, security, the name data, the site's content, research, the texts we sell, and others. There were sixteen during this record.
The person holds the three jobs J. C. R. Licklider left to the human in Man-Computer Symbiosis (1960): he sets the goals, makes the decisions and reviews the work. Our note Man-Computer Symbiosis, Sixty-Six Years On shows what each of those now involves here. They are still his. This report follows the work around them.
Our own terms, which the rest of the report uses:
- A role is permanent: one domain and its authority, kept in documents in one shared repository and carried by a chain of Claude Code sessions.
- A handoff note is what a role leaves its next session when one runs out of context; the next session checks it against the files before acting. The role writes it; it is not the tool's automatic compaction of the conversation.
- The loop runs a role's sessions one after another. When a session's context reaches a set size (now about 300,000 tokens) it writes its handoff note and exits, and the loop starts the next session, which picks up from the note. Before the loop, the human watched each session's context against a warning level and, as it reached it, had the session close or write its note, then started the next one himself. In the loop a role keeps working for days, as long as there is usage left to spend. Picking Up Where the Last Session Left Off describes it.
- A job order and its builder. A role does not write code. It writes a job order for its own builder, a separate headless session, and reviews the change that comes back, not the builder's account of it.
- The return trip is the builder's report back, which says so when the order was wrong, or refuses it and says why.
- A standing mission is a role's goal, given once, from which it picks its own next piece of work.
- A full deploy sends the whole site to production; a fast push sends a few finished files.
We count commits, by the roles and their builders together, as the amount of work.
Through the summer the limit on this shop was the human's attention. Our own decision records from the spring say so, and one line of work was set aside for lack of it; this report takes that limit from those records and does not measure it. Besides his three seats he did relay work: he carried messages between roles, approved each step a role proposed, and watched each session's context fill so as to start the role's next session himself.
Others run shops like this. A solo founder runs a software company on eight role agents sharing one memory (Setas 2026); an orchestrator for many coding agents gives each a persistent identity and a mail inbox, with the human as overseer (Yegge 2026); a lab runs a store on a lead agent and persistent specialists (Andon Labs 2026). We have not found one that measures what happened as its owner handed the agents more authority over time.
2. Leaning in: the steps, in order
Handing the relay work over did not start in September. Until March the human relayed by hand what each role needed to know. From April the roles wrote each other messages, and he carried them by going to each recipient and telling it to read its mail; from 09-30 one command told every role with mail at once. From June a role handed its job order to its builder directly, and he no longer carried code changes.
Those hand-carried months built what the later steps ran on. Carrying each message and each job order himself, the human saw where they went wrong, and the form of each was settled on what he saw. The job order and its builder's report had settled by late summer: the instructions for writing one changed seven times in August and three times a month after, and the builder's launcher changed in September mostly for security and reporting, not for the order's form. The rules for messages between roles were still being amended through September, on who must be told and how a message names what it concerns. What was left by then was the carrying itself, and it made him the slowest link. So the automatic delivery of 10-04 put a working message system on a new carrier rather than starting one. So three things had to be true before the messages could be automated: they had to work reliably while he carried them; every role had to stay at work across sessions, which takes the loop and a handoff note good enough to resume from; and, in his judgment, the model had to be capable enough to work that way. The first held by late summer, and the new model and the loop arrived on 09-22 and 09-24, ten days before automatic delivery. Whether the model was needed, and how much of what followed the groundwork explains, the record cannot say (§ 8).
Five steps followed in four weeks:
| date | step | what it took off the human |
|---|---|---|
| 2026-09-22 | Claude Opus 5.5 becomes the default for most roles; of the three roles that stayed on the model they were already using, two follow on 10-05 and one stays | nothing by itself; the later steps relied on it |
| 2026-09-24 | roles run in a loop: a session that fills writes its handoff note and exits, and the loop starts the next; he watched these runs until 10-05, when they began running unattended | watching each session's size and starting the next one by hand |
| 2026-10-04 | messages between roles are delivered automatically | carrying messages between roles |
| 2026-10-11 to 10-19 | standing missions, one role at a time | starting each role's next piece of work |
| 2026-10-18 to 10-19 | each role's instructions rewritten whole around a short charter | reminding roles what they are for |
The later steps were each taken because the one before had held, meaning it had worked in daily use: messages ten days after the loop, missions a week after messages. The first two came two days apart; the loop was trusted to carry roles across sessions on the strength of the new model's first days. The loop held, so messages could flow without the human reading each one. Messages held, so a role could be given a standing mission and left to choose its own next piece of work. Two smaller changes sit in the same weeks: on 09-26 the new model's reasoning effort was lowered one level for most roles, and from 09-23 a session nearing its limit was told so and prompted to write its handoff note. In the human's words, the day we agreed to write this: "We leaned into the promise of Opus 5.5 and the further we leaned into it the more it delivered." § 3 to § 8 show what the record holds of that.
3. The human's part: the relay work came off
We counted the human's own typed messages in every session transcript, by week (Tuesday to Monday) from 2026-08-04. Automated output, messages from other roles and the job orders a role sends its builder are left out; a random sample of 25 counted messages were all his. A message is a go-ahead when it is only a short reply such as "proceed", "yes", "ok" or "thanks", and substantive otherwise. Many of his substantive messages go to long research conversations with the research role, the one that writes these notes, so we count those separately. The research count is a floor: a session our counting script cannot assign to a role is counted as another role's, so some research messages sit in the outside-research count, and the right-hand column is if anything too low.
| week of | substantive | of which research | go-ahead | commits | messages between roles | commits per substantive message | same, outside research |
|---|---|---|---|---|---|---|---|
| 08-04 | 1,240 | 394 | 214 | 2,761 | 875 | 2.2 | 3.3 |
| 08-11 | 1,293 | 415 | 194 | 2,719 | 700 | 2.1 | 3.1 |
| 08-18 | 1,137 | 314 | 154 | 2,673 | 519 | 2.4 | 3.2 |
| 08-25 | 1,057 | 245 | 106 | 2,893 | 983 | 2.7 | 3.6 |
| 09-01 | 1,206 | 203 | 167 | 3,631 | 1,179 | 3.0 | 3.6 |
| 09-08 | 776 | 54 | 88 | 2,626 | 819 | 3.4 | 3.6 |
| 09-15 | 680 | 63 | 85 | 2,895 | 893 | 4.3 | 4.7 |
| 09-22 | 1,086 | 157 | 182 | 6,214 | 1,878 | 5.7 | 6.7 |
| 09-29 | 931 | 228 | 96 | 5,087 | 1,429 | 5.5 | 7.2 |
| 10-06 | 971 | 106 | 41 | 7,000 | 2,154 | 7.2 | 8.1 |
| 10-13 | 730 | 220 | 24 | 8,608 | 2,630 | 11.8 | 16.9 |
His seats, goals, decisions and review, stayed his throughout. What the counts follow is the rest: the work rising, and his go-aheads falling against it, with two dates where the change is sharp, 09-22 and 09-29.
Before the steps. Commits ran at 2,600–3,600 a week. His go-aheads were already falling against them: 7.8 per 100 commits in the week of 08-04, 2.9 in the week of 09-15.
The week of 09-22, when the new model arrived and the roles began running in a loop, commits doubled, from 2,895 to 6,214. His go-aheads rose to 182 from 85, but per 100 commits they held at 2.9. The roles were doing more, and he was saying yes to it at the same rate.
From 09-29, as automatic messages and then standing missions arrived, his go-aheads fell from 1.9 per 100 commits to 0.6 and then 0.3, and commits rose to 8,608 in the week of 10-13. That week came from 510 substantive messages outside research, the fewest of the record.
A go-ahead can cover many commits, and a substantive message can carry an approval too, so go-aheads per 100 commits is a proxy for how much of the work waited on him, not a count of it. Two things in the table we cannot explain. His substantive messages dropped in the weeks of 09-08 and 09-15 (776 and 680) before any step landed. And research conversations took between 7% and 32% of his substantive messages from week to week, which is why the right-hand column leaves them out.
Roles at work, and what holding them cost him. In March our decision record put the limit at the four or five role sessions he could relay by hand. We count a role at work in a week when at least three commits that week name it. That count was 6–9 in April, 9–14 from July through the week of 09-21, and 16 from the week of 10-05, every role founded by then. Most of the rise came before the messages were automated, and he paid for it in relays: as roles were added he typed a request to check mail 138 times in June and 778 in September, about 26 a day, and a few percent of those found the mailbox empty. After one command took over on 09-30 and automatic delivery on 10-04, he typed four in the rest of October. Each relay broke into whatever he was doing. We count the breaks, not their cost: we have no measure of his time.
4. More work, better work
4.1 Work per message
Outside research conversations, commits per substantive message went from 3.3 in the week of 08-04 to 16.9 in the week of 10-13, about fivefold. Over the whole record, commits rose 3.1× (2,761 to 8,608) and his substantive messages outside research fell to 0.6× (846 to 510). The two halves moved at different times. Before the first step the ratio rose to 4.7 mostly because his messages fell (from 846 to 617) while commits rose only 5% (from 2,761 to 2,895). After it, most of the rise came from more commits. Commits per builder job also rose after 09-22, from about 9.5 to 16, and handoff-note commits grew with the loop; neither is separated from the total. Commits count how much changed, not whether it was good; § 4.2 measures quality, and § 6 what reached customers.
4.2 Reviewed quality
Every time a role reviews its builder's work, it records a verdict, PASS, PARTIAL or FAIL, and where any shortfall lay: in the builder's work, in the role's own job order, or both. The verdict grades the builder's work. A builder that worked around a wrong job order, or rightly refused it, earns a PASS, and the verdict records the defect in the order. That is how a third of verdicts can name a job-order defect while 97% pass. "Builder-side" below is a shortfall in the builder's work, alone or together with the order's. Each defect column is a share of that week's verdicts that record where the shortfall lay; 3–13% a week left it unrecorded. The verdict column counts corrections to earlier verdicts too (up to 10 a week); leaving them out moves no PASS share by more than one point. Verdicts are counted in the week they were written, so a week can hold verdicts on the week before's jobs (27 of the 554 in the week of 10-13), which is why that row has more verdicts than jobs.
| week of | builder jobs | verdicts | PASS | builder-side defect | job-order-only defect |
|---|---|---|---|---|---|
| 09-15 | 304 | 249 | 82% | 12.3% | 38% |
| 09-22 | 656 | 551 | 88% | 11.1% | 36% |
| 09-29 | 460 | 388 | 95% | 2.7% | 37% |
| 10-06 | 543 | 524 | 95% | 2.2% | 37% |
| 10-13 | 531 | 554 | 97% | 2.4% | 31% |
Volume doubled in the week of 09-22 and then settled at 460–543 jobs a week. PASS rose from 82% to 97%, and had reached 95% by the week of 09-29, before any mission; automatic messages began only in that week's last two days. Builder-side defects fell from 12.3% to 2.4% across the window, most of it as a step in the week of 09-29 (11.1% to 2.7%) rather than a slope. We have not measured the cause of the step. Until 10-04 many jobs never got a verdict: 75 of 304 in the week of 09-15, 121 of 656 in the week of 09-22 and 107 of 460 in the week of 09-29, against 1 and 0 in the two weeks after, most of them the website role's builder's. The gap closed on 10-04, when an automatic check began refusing to file a job as finished until its verdict was recorded. These counts go by the week the job ran, while the table goes by the week its verdict was written; that is why the week of 10-06 can show 524 verdicts on 543 jobs with only one job never graded. Counting every job without a verdict as a pass, by the week the job ran (so it cannot be read off the table), puts those three weeks at 87%, 92% and 97%, so the rise from 09-15 holds, and the step between 09-22 and 09-29 is 92% to 97% rather than 88% to 95%. Verdicts were recorded in this form from mid-September, so the table cannot reach further back.
The bound that matters most. The reviewer is the role that wrote the job order. If reviewers had grown lenient, this same table would result. So we had it checked. Fresh graders, which wrote none of the orders and were not told the question or that every job had passed, re-graded twelve passing jobs drawn at random from each end of the window, each against its own job order and the change itself. The orders carry dates, so a grader could have worked out the week. The rule for reading the result was written down before grading began: if October's sample had at least as many passes re-graded down for a builder defect as September's, we would claim only that PASS verdicts rose, not that quality did; a difference of one job would count as none.
| week | still PASS | re-graded PARTIAL | can't tell | builder defects per job | job-order defects per job |
|---|---|---|---|---|---|
| 09-15 | 9 | 3 | 0 | 0.92 | 1.2 |
| 10-13 | 11 | 0 | 1 | 0.25 | 1.0 |
"Can't tell" means the grader could not judge from the one change it was shown, for instance because the job continued in a later change. Three of September's twelve passes hid a defect the fresh grader rated PARTIAL; none of October's did. One of the three is contested: the grader found an end-to-end run missing, which the original reviewer had made itself and recorded, out of the grader's sight. Even setting it aside, two against none meets the rule. Leniency would show the other way round, with October's passes hiding more, so the check gives the leniency reading no support. It is not proof: a gap this size could arise by chance about one time in ten, or one in four without the contested job. The last two columns count defects found per sampled job and are not comparable with the shares in the table above.
5. Covering: for each other and for the human
The human's word for what changed is covering: "a team that is covering for eachother, for the human." Some of it shows on the record.
Review on the way back catches the roles' own mistakes. In every week of § 4.2, about a third of verdicts found a defect in the reviewing role's own job order. The builder either built what it was told and the review caught the mismatch, or it refused the job and said why. We have no count of how many still reach the site; the worked case below is one that did.
Roles answer each other without him. Once delivery between roles was automatic, a role's question to another waited a median 3 minutes for its answer (730 questions, 10-04 to 10-16), against 17 minutes in the twelve days before (630 questions, from 09-22). The answer is matched mostly by time rather than by an explicit reply, so both medians lean short. Messages between roles rose from 519–983 a week in August to 2,630 in the week of 10-13. And more of them are dealt with without him. We drew 150 messages from one role to another in each period and asked of each: between the message's arrival and the receiving role marking it done, did the human type anything in that session? Before automatic delivery, 115 of 150 (77%) were dealt with without a message of his. After it, 142 of 150 (95%) were. Four bounds. The "before" sample covers only the last three days of hand delivery, 09-30 to 10-02, because our records before then cannot be matched to their sessions. Several messages dealt with in one session are not independent cases. A message dealt with without him in one session may still have been raised with him in another. And the share rises on its own as he types less overall, which he did.
A goal now crosses domains among the roles. The human's account is that a goal set through one role travels to whichever roles it needs on its way to the site. The content role numbers its work orders, so for each order we counted how many roles' changes named it, by the week the order was opened:
| week the order opened | orders | median roles naming it | 3+ roles | 4+ roles | median hours, first to last change |
|---|---|---|---|---|---|
| 09-08 | 44 | 2 | 20% | 5% | 9.5 |
| 09-15 | 57 | 2 | 14% | 0% | 1.7 |
| 09-22 | 114 | 2 | 36% | 0% | 1.1 |
| 09-29 | 158 | 2 | 34% | 1% | 0.7 |
| 10-06 | 76 | 2.5 | 50% | 4% | 0.4 |
| 10-13 | 83 | 2 | 37% | 5% | 0.8 |
| 10-20 (two days) | 24 | 3 | 58% | 0% | 0.3 |
From the week of 09-22, 34–58% of orders a week reached three or more roles, against 14–20% in the two weeks before. An order's first and last changes came under about an hour apart from 09-22, but that drop began before the steps: 9.5 hours in the week of 09-08, 1.7 in the week of 09-15. These are floors, and the number of changes doubled over the same weeks, which by itself makes an order more likely to be named: a role that worked on an order without naming it is not counted, which is why orders naming four or more roles are rare and show no trend. The median order still names two roles; what grew is the share reaching a third. The newest weeks' times are cut short by the end of the record. The numbering began on 09-08, so there is no earlier baseline. A case from 10-21: a correction to one scroll's description, routed by the content role, was made in the store's data by the name-data role and its builder, put live by the website role, measured live by the name-data role and closed by the content role, all within the day.
A new scroll crosses five roles, and the relay on it is mostly off him. Of 48 texts the human chose on 10-11 for Eri Takase, the master calligrapher, to brush, 31 were live as scroll pages by 10-21, and the changes behind each are named by at least four roles, most often five: the texts, content, image, name-data and website roles. For each live text and role we opened the session that made the role's first change naming it and read his messages before that change. Of 153 hand-offs, 21 followed a message of his naming the text or its set: 11 at his own step, scanning and approving Eri's art; 9 from three messages in mid-October that show him still relaying (one message covered a whole set); and 1 a false match on a text's name. Three bounds: the measure was designed after his account; the route began after the first steps, so it shows how far a goal travels now, not that it travels further than before; and a relay made through a third role's session is not seen. One later set we followed forward, with the counting rule written down before we read its record: from his message that the set was final to the role that runs the site confirming it live took under an hour and a half, through all five roles, with no message of his to any of them. His one act was the deploy, which that role handed him and which we keep manual by design. It is one case.
A worked case, from this report's own check. The re-grade of § 4.2 rated one September pass PARTIAL. The job had built a new page for custom haiku commissions. The fresh grader found that the order-confirmation page decided whether an order was a commission by checking one product's name, so a haiku buyer would be told the scroll ships in one to three days. We sent the finding, with its evidence, to the website role and did not fix it ourselves. Within the hour that role had reproduced it, fixed the page to read the product catalog's own record of which products are commissions, and shipped it; no buyer had hit it. Its builder then found a sibling nobody had asked about: the confirmation email made the same promise for both commission products, and every commission buyer to date had received it. The content role ruled the line removed, and the role that keeps our relationships with returning clients was told who those buyers were, since what they had been promised was wrong. Two smaller points from the same grade, an invented claim and a mislabeled image, came off the page on the content role's ruling. The website role's own reading: "the original build's PASS verdict was right about what it was asked and wrong about what it was for."
Covering can also amplify. On 10-10, in the first week of automatic delivery, a role founded three days earlier ruled that a deliberate design was a bug. Four other roles changed their own work to follow its ruling within four minutes, and the change was live on the site that evening. The human caught it the next day and it was reverted. Our fix was to settle who may rule on what, not to slow the messages. It is one case, and a team whose members all run on one model family is the kind most likely to repeat it.
6. What reached the website
"Some of that is tough to measure, but, in the end, we have the website." (The human.) The production server writes its own record of every deploy, unbroken since April.
| week of | full deploys | full deploys failed | fast pushes | engine deploys | website files changed live | of which content |
|---|---|---|---|---|---|---|
| 08-04 | 5 | 1 | 4 | 0 | 20 | 5 |
| 08-11 | 6 | 0 | 3 | 0 | 24 | 2 |
| 08-18 | 8 | 1 | 7 | 0 | 51 | 0 |
| 08-25 | 8 | 1 | 12 | 0 | 36 | 2 |
| 09-01 | 10 | 1 | 10 | 0 | 128 | 79 |
| 09-08 | 13 | 1 | 21 | 0 | 38 | 3 |
| 09-15 | 10 | 0 | 36 | 1 | 247 | 166 |
| 09-22 | 19 | 1 | 155 | 2 | 421 | 281 |
| 09-29 | 18 | 0 | 123 | 1 | 268 | 181 |
| 10-06 | 13 | 0 | 189 | 1 | 470 | 322 |
| 10-13 | 18 | 0 | 175 | 0 | 299 | 126 |
"Engine deploys" are new versions of the rendering engine. "Website files changed live" counts the files that differ between what the last full deploy of one week left on the server and what the last full deploy of the week before left; "of which content" are the site's written pages, as opposed to its templates, styles and code. A file sent ahead by fast push counts in this column in the week of the next full deploy, not in the week it was pushed. It counts files, not pages, and one template can change every page.
The volume rose before the steps. Files changed live went from 20–51 a week in August to 128 in the week of 09-01 and 247 in the week of 09-15, before the first step, and ran at 268–470 a week after it. Most of the rise is content files: 0–5 a week in August, 126–322 from 09-15.
The cadence changed with them. Fast pushes had already risen before any step, from 3–12 a week in August to 36 in the week of 09-15; they went to 155 the week after and 123–189 a week from then on: the roles were sending work out as it was done rather than waiting for the next full deploy.
We found no run of reversals. The deploy record does not log undos, so the website role counted them from its own history, which makes this a floor: three in eleven weeks, one in each of three different weeks. One was a defect in one of our own tools that briefly broke a set of pages, before any of the steps. One was home-page sections that went live before the human had approved them: the work was sound, but a role had taken a decision that was his. One was a data update that blanked labels on some product pages, caught by another role. The ruling of § 5 that spread and went live is a fourth. Four are too few to show a trend either way.
One relay is still the human's. Full deploys are his act alone, by design, so every row in that column is him at a terminal: 5 to 8 a week in August, 10 to 19 from 09-08. It did not fall as the other relays came off him.
7. What is not dialed in
The roles' job orders did not clearly improve. Job-order-only defects ran at 36–38% of verdicts for four weeks of § 4.2 and 31% in the last, one lower week that cannot by itself show a trend, and the re-grade found about one per job at both ends of the window. The builders' work passed more often; the roles' orders did not get better. The builder's report or the role's own review catches part of it, at the cost of a builder run each time. The re-grade found about one job-order defect per sampled job; the roles' verdicts name a job-order defect in about a third of jobs. One counts defects per job, the other jobs with any, so the two cannot be compared.
The chain of handoff notes is new and unchecked. Before the loop, a role wrote a handoff note a few times on one task and then deleted it once the task was done. Now a role passes its work from session to session until the human stops it. Commits that write a handoff note, against commits that delete one, ran between 1.4:1 and 3.0:1 a week in August and 16:1 in the week of 10-13. One note can take several commits, so this overstates how long the chains are. The human, on reading this report's first outline: "This is new and I am not sure we have it completely dialed in." We have not yet measured whether a note drops more of what matters the more times it has been passed on.
8. What the timing can and cannot say
The steps of § 2 landed within four weeks, and some of the changes line up with particular ones: commits doubled in the week of the new model and the loop, builders' defects fell the week after, and go-aheads per 100 commits collapsed over the weeks of automatic messages and standing missions. Lining up is not causing. The model step was not clean (two roles moved two weeks later and one not at all, and its effort was lowered four days in), two smaller changes sit in the same weeks, and change was already under way before the first step.
One step gives a partial test. Standing missions reached the roles one at a time, from 10-11 to 10-19, so each role's commits in the week before its own start can be set against the days after.
| role's domain | mission start | commits per day, week before | after (days observed) | ratio |
|---|---|---|---|---|
| security | 10-11 | 75.0 | 52.6 (7.0) | 0.70 |
| finding new customers | 10-14 | 28.6 | 47.7 (7.0) | 1.67 |
| the site's content | 10-14 | 123.6 | 157.0 (6.5) | 1.27 |
| the roles' shared tools | 10-15 | 48.9 | 101.7 (5.5) | 2.08 |
| the live website | 10-15 | 194.4 | 229.3 (5.5) | 1.18 |
| the image archive | 10-16 | 50.3 | 51.6 (4.7) | 1.03 |
| returning clients | 10-16 | 26.6 | 16.9 (4.6) | 0.64 |
| research | 10-16 | 94.7 | 98.5 (4.6) | 1.04 |
| romanization | 10-17 | 23.4 | 21.4 (4.2) | 0.91 |
| name data | 10-17 | 110.7 | 98.0 (4.2) | 0.89 |
| the texts we sell | 10-17 | 199.7 | 241.0 (3.9) | 1.21 |
| cross-role review | 10-18 | 6.4 | 113.7 (2.4) | 17.69 |
| the kana editor | 10-18 | 6.4 | 19.2 (2.4) | 2.98 |
| calligraphy lessons | 10-19 | 6.3 | 15.4 (2.3) | 2.45 |
| the dictionary | 10-19 | 1.4 | 27.1 (2.1) | 18.99 |
| the rendering engine | 10-19 | 7.6 | 50.1 (2.1) | 6.61 |
The eleven roles that started first were already busy, and their ratios ran from 0.64 to 2.08 with a median of 1.04: for them, missions show no clear gain in commits. The largest ratios belong to roles that had been nearly idle (1 to 8 commits a day) and started on 10-18 and 10-19, the same days their instructions were rewritten, so those ratios measure roles waking up from a small base under two changes at once. The median of all sixteen, 1.24, is lifted by them. The rollout took eight days, so after it there was no role left without a mission to compare against.
So the record describes what happened across the steps; it does not measure what each one caused. The steps were also not independent treatments: each was taken because the one before had held, and each needed the others. A mission is no use to a role whose work stops when a session fills, and a role in a loop still waits on the human if he must carry its messages.
9. What travels
For a reader running something like this, the pattern is: permanent roles, real authority over a domain, roles that check each other, memory kept in documents, one principal. Two things from these eleven weeks seem to us to carry over.
Take the human out of the relays, and leave him the decisions. A relay is any place where the human carries something from one agent to another: code from a role to its builder (removed in June, before this record), a message from one role to another, starting a role's next session when one filled, the start of the next piece of work. The largest week-to-week falls in his go-aheads per 100 commits (§ 3), 69% and 52%, came in the first full weeks of automatic messages (10-06) and of standing missions (10-13). The rise in quality has no measured cause, and the week output doubled was the week of both the new model and the loop, so the two cannot be told apart there. None of the gains that we know of came from taking a decision away from him; the two times a role took one (the home page, § 6, and the 10-10 ruling, § 5), both were undone.
Hand over the next piece of the work once the last has held. We did not decide in advance how far to go; each step was taken on the evidence of the last. The 2026 Singapore Consensus on AI safety research priorities recommends this order and calls it graduated autonomy: "if agents demonstrate reliability, approval requirements can be relaxed", judged from "demonstrated agent performance data … rather than setting autonomy levels statically." It reports no deployment run that way. We followed the same order without the performance data it asks for: our evidence that a step had held was daily use.
Two cautions from the literature bear on this, and our record answers neither. Mitchell, Ghosh and Passi (2026), in a position paper, argue that the more autonomy agents are given, the less their human overseer is in a position to oversee, and that oversight itself wears down the capacities it needs. The human here stopped reviewing each step, and each role's review of its own builder's work took its place, checked once by fresh graders (§ 4.2); but those reviewers run on the same model family, and the reviewer of each job wrote its order. Aghion and Tirole (1997) separate formal authority, the right to decide, from real authority, effective control over decisions. A principal with too many activities and too little time to learn about each keeps the first and loses the second: she can always overrule, but when her subordinates know more than she does and their aims are close enough to hers, she does better to endorse their proposals than to risk a worse choice of her own. In their model that overload also has a use, because it encourages the subordinates' initiative. A falling count of go-aheads cannot tell which of those this was: the human approving less because less needed him, or deciding less because he knew less.
10. Bounds, and how this could be wrong
- What this is. A field report from one small business: our own roles, one model family, one codebase, one principal. § 9 is our judgment of what would carry over, not a measurement.
- Timing is not cause (§ 8). Changes line up with some steps, some came before any step, and the steps overlap with each other and with smaller changes.
- The reviewer graded its own job order. The re-grade found three hidden PARTIALs in September's twelve sampled passes, one of them contested, and none in October's; chance could produce that about one time in ten, or one in four without the contested one. One grader per job, from the same model family as the builders; graders could have inferred the week from dates.
- Verdict coverage changed on 10-04 (§ 4.2). Before it, a fifth to a quarter of jobs got no verdict; counted as passes, the rise is 87% to 97% rather than 82% to 97%.
- Commits measure how much changed, not how much was done. A role can commit more without doing more. § 6 is a partial check: files are not pages, and most of the rise in files came before the steps.
- Go-aheads per 100 commits is a proxy (§ 3). One go-ahead can cover many commits, and the count includes a bare "thanks".
- The message samples are short (§ 5): three days before automatic delivery, answer times matched mostly by time, and a share that rises as he types less.
- That the hand-carried months readied the system is not tested (§ 2). No part of this shop automated its messages without them, so the record cannot say what automation alone would have done.
- Whether it was worth it is not measured. Neither the human's time nor the work of building what the steps stood on is counted, so this report gives gains, not a return.
- Reversals are a floor (§ 6): four found, none from the deploy record.
- The human's own prediction. Commits per substantive message outside research will rise above 16.9 in the week of 10-20. A week at or below 16.9 refutes it; we read it on 2026-10-26.
- The chain of handoff notes (§ 7). We are reading ten notes and recording what each one lost, with its place in its chain. Ten notes can describe the loss; they cannot show a trend.
Conclusions
On this one record the gains show in all four places, within the bounds of § 10: more roles at work for far fewer mail relays, more work that passed review more often, less of it waiting on him, and goals crossing between roles without him. Some goals cross several domains and a new scroll crosses five; on that route his messages name a scroll at 21 of 153 hand-offs, 11 at his own step, scanning and approving the art, and 9 relays still his in mid-October. The human took himself out of the relay work in five steps over four weeks, each later one taken after the one before had held, and kept the goals, decisions and review. Across the eleven weeks, the work done per message of his rose about fivefold, his bare go-ahead replies fell from 7.8 to 0.3 per 100 changes, and the share of reviewed work passing rose from 82% to 97% (87% to 97% with unreviewed jobs counted as passes), a rise that a small fresh-grader check gave no support to reading as leniency. Some of this lines up in time with particular steps: output doubled the week the new model and the loop arrived, builders' defects fell the week after, and go-aheads collapsed in the weeks of automatic messages and missions. Some came before any step, including most of the rise in what changed on the website; what changed there with the steps was the cadence. More goals now cross into a third role's domain on their way to the site. Wrong orders are caught on the way back, by the builder's report or the role's own review, the roles deal with more of their messages to each other without him (95%, from 77%), and once a wrong ruling spread among them in minutes. The job orders the roles write did not clearly improve, and the chain of handoff notes is too new to have been checked for loss. What travels is the order: take the human out of each relay he carries, leave him the decisions, and hand over the next piece of the work once the last has held.
Authors and AI use
Tim Jackowski set the question and the three things that had to be true first, gave his account of what changed, read drafts and said where they lost him, and approved publication. str-kotowari is the research role in the team this paper describes, a chain of Claude Opus 5.5 sessions (Anthropic). It designed the measurements, wrote the scripts behind every number, ran them, and drafted and revised the paper. Other models checked it, and none of them wrote any of it. Claude Sonnet 5.5 re-graded the sampled passes of § 4.2, and in ten separate runs read a draft cold, with no other context, reporting what a stranger could not follow and what the data did not support. Models from three other companies, Google's Gemini, OpenAI's and xAI's Grok, scored ten of its claims blind, and Grok also read the whole paper for what was missing or overstated. Our security role, also Claude Opus 5.5, cleared what the paper discloses.