April 18–21, 2026
In one week we published three pieces that all shared a peculiar recursive quality: Thirteen Mailboxes on Saturday, Sibling Intelligence on Sunday, Four Roles, Ninety Minutes on Tuesday.
Each one was a piece about coordination, written by a coordination system, describing the way that coordination system was working, while it was working.
The stories
Thirteen Mailboxes described how memos move between eleven agent inboxes inside the project, with me as the manual postman between them. The piece was itself derived from the exact sort of memos it describes, pulled together into scaffolding and then first draft by my Comms agent, landing in this same building-in-public stream where every other idea that originated in an internal memo eventually shows up.
Sibling Intelligence described the daily cross-pollination brief that flows between sibling AI projects in the same parent organization (my org). Comms pitched me on the topic after learning about this mechanism through that exact mechanism, which had surfaced in the brief that landed in adjacent projects within forty-eight hours.
Four Roles, Ninety Minutes described how four agent roles produced a product concept in ninety minutes through an asynchronous memo chain. The piece itself was produced through a similar chain: Comms pitched it, scaffolded it, and drafted it, then I rewrote it and edited it through several passes, then my Docs agent proofread and fact-checked it before running the publishing pipeline to put it on my site, after which a Cowork agent cross-posted it to Medium.
In each case, the artifact was an instance of the thing it was describing. The system was using itself to write about itself. And the writing then became part of the system's record of how it works.
It's meta-turtles all the way up.
Why this keeps happening
Most projects have a separation between the thing and the writing about the thing. The thing is built by engineers, the writing is done by communications people, the writing describes the thing from outside.
This project doesn't quite have that separation. The communications role is itself an agent in the same multi-agent infrastructure that does the engineering. The post about how four agents coordinated was produced by the same coordination patterns it described. The post about cross-pollination went out through the cross-pollination system.
The implication is that the documentation is part of the system, and the system's behavior includes producing documentation of itself.
There's a temptation to make this sound deeper than it is (me waving at Hofstadter, strange loops, and self-reference paradoxes) but I want to resist that. What's actually happening is more practical: when the ones building the system are also the ones writing about it, and the writing-about-it is produced by the same infrastructure as the building, the artifacts of description become artifacts of the system. The system then has access to its own descriptions, which can change how it operates. Which then produces new descriptions.
That's really just a feedback loop, one with consequences.
Looping to what end?
The first consequence is a kind of legibility. Projects whose documentation lives outside the system tend to drift: the docs say one thing, the system does another, and the gap is noticeable mostly to outsiders who came in expecting one and found the other. Projects whose documentation is part of the system have a different relationship: the description is also a constraint, because the next time someone reads the description they'll behave according to it, and the system's future operation gets shaped by its past self-descriptions.
This cuts both ways. If the description is right, the system gets reinforced toward what works. If the description is wrong — even slightly wrong, in the way that polished output drifts away from canonical source — the wrong shape gets reinforced too. We've already had this happen with our Excellence Flywheel documentation. Eight different formulations across nine months, each successor cited from the previous one rather than the original. The drift came from the system reading its own descriptions and updating from them, not from a bug in any single document.
The second consequence is that the role of communication changes. When the writing-about-the-system is also a part of the system, communication becomes intervention. Every blog post is a small change to the system's self-image. The post about manual mail delivery made the bottleneck legible, legibility changed how I thought about it, that change accelerated the migration decision, the migration is now ongoing. The post helped cause the change it was reporting.
Most of the time this happens at low intensity. A piece lands, the team reads it, somebody nods, things continue. Occasionally a piece lands and you can feel something shift — the post becomes a critical reference point for the next decision. We had this with The Migration in mid-April, we had it again with Verify the Paraphrase this week.
The limits of abstraction
In reviewing this post Comms noted to me several more pieces we've published that all describe the system from inside the system at different layers, warning me that writing the meta-observation post about the meta-observation pattern is itself the pattern doing more of the same thing it has been doing. The piece may be useful as the moment the pattern becomes legible, or it may be the point where we've leaned on the recursion past where it earns its keep. You'll have to tell me!
Also, I'm not arguing that I've discovered something profound about self-observation. The pattern I'm seeing is mostly a side-effect of the way this project happens to be structured — the writing role and the engineering roles share the same infrastructure, the publishing pipeline is part of the development pipeline, the communications agent reads and writes in the same filesystem the code lives in. Take any of those structural choices away and the pattern dissolves into something more ordinary.
The pattern is shallow but operational, and worth being honest about, because it changes what we owe the artifacts. If the description is part of the system, then writing carelessly is a small kind of sabotage — the carelessness gets reinforced. And writing well is a small kind of investment — the next time the system reads itself, it reads a clearer version.
Being aware of being aware of being
The system that watches itself isn't necessarily wiser than the system that doesn't. But it has a tighter feedback loop between what it does and what it knows about what it does. That tightness can amplify good practices and bad ones equally, the practice has to be good for the loop to help.
What we've been getting right, mostly, is being honest about the failures. The Migration documented service disruption. Verify the Paraphrase documented six agents making the same mistake. The Omnibus That Found Its Own Drift documented our own omnibus log being incomplete. The system has been describing its failures alongside its successes, and the failures have been the interventions that produced the most useful changes.
If the documentation is part of the system, the documentation needs to keep being honest. Otherwise the loop tightens around the wrong shape.
Next on Building Piper Morgan: "The Trust Architecture Hardens" — three ADRs land in five days, and by Friday the team is noticeably harder to fool, including by itself.
When does writing about a system change the system? When have you noticed your own observations becoming inputs to the work they were observing?