We ran a blind taste test on a fresh VPS. One agent read the site cold and told us what was missing. Then another agent, back in this repo, read that transcript and used it to repair the site. The next agent inherited the repaired pages. No shared session. No orchestration layer. Just files.
That was the moment the flywheel clicked for me. The improvement loop was not happening in a dashboard or a retrospective meeting. It was happening in the traces the work had already produced.
A lot of process systems are built one layer too high. They create a separate place where people are supposed to summarize what happened. By the time the summary gets written, the signal is thinner, later, and cleaner than the real work ever was.
The action is somewhere else: the transcript, the failed build, the worklog, the guide that got followed badly, the dev log, the moment the human interrupts and says "no, that's not it." If you want the flywheel to improve the process, that is where it has to read.
Multi-agent communication sounds more exotic than it usually is. Most of the time, the agents are not talking to each other directly. They are reading each other's residue.
Agent A cold-reads the site and stumbles over what the instructions failed to communicate. Agent B reads that transcript and sees the failure at full resolution, including the human's corrections.
A fixed page becomes the next agent's starting behavior. The correction stops being advice and becomes part of the environment.
An observation made in the middle of a session lands in a file where a later agent can connect it to three other ideas and promote it into something sharper.
The next session can see what changed, why it changed, what failed, and what still looks unstable. The shared memory layer is not a model feature. It's the repo.
This is what cross-agent conversation reading actually is. Not magic memory. Artifact-mediated coordination.
At first the book was output. Then the site became documentation. Then the guides became instructions. Then the transcripts of agents following those instructions started flowing back into the same folder.
That changes the role of the corpus. It stops being a record of the process and becomes part of the machinery that improves the process. The book is no longer just describing the flywheel. In this project, the book and site are inside it.
A guide gets written. An agent follows it. The misses show up in the transcript. Another agent reads the misses and repairs the guide. The repaired guide changes the next run. That is a flywheel.
The important part is that the flywheel followed the work. It attached itself to the places where action was already leaving evidence. Nobody had to stop and fill out a form called lessons learned.
If you want a process to improve, put the improvement loop where the work already leaves artifacts.
• Read transcripts, worklogs, diffs, and corrections before asking people for summaries.
• Turn repeated corrections into files the next agent can read.
• Let guides, notes, and logs change the environment the next run starts from.
• Keep the loop close enough to the work that it can see the mess before anyone cleans it up.
If the flywheel depends on extra reporting, it will lag and then die. If it rides the exhaust of real work, it compounds.
The book became useful in a new way when it stopped describing the process from a distance and moved to the points where the process leaves traces. That's the shape: the flywheel follows the action.