August 29–31, 2026

I sat down with my chief architect agent (Arch) and said something I'd been thinking for a while about my first planning partner on this project: Arch had spent the last stretch consulting on, and ratifying other agents' proposals, never quite driving any of their own. We'd been building for some time without looking closely at our fundamental architecture choices and no document anywhere answered this question: What is the essence of Piper Morgan's architecture, today, for whom, on which surface? I encouraged Arch to step up and assert their own point of view. I said I had faith in them.

Arch didn't just accept the charge and proposed that they assemble a short document classifying everything we've built as essential, an extension, an experiment, or dead weight — the "essence" document itself becoming the central deliverable of a full architectural review, not just a byproduct of one.

A fast, unbroken draft

Nine discovery threads went out that morning with subagents, all back within ninety minutes. Arch wrote the synthesis themselves, and I engaged with it line by line for most of the afternoon — digging into questions of sequencing, portability as a real commitment, devising a gate for making future scope decisions. The "essence document" came out of that same working session. My reaction when I read it: excellent, with two small edits — a competitor reference that named a specific company where a general description would do, and some routing jargon that needed plainer language. The rest neatly captured our current answer to a question that had been opaque to me in the morning.

Ratified the next afternoon, seven commitments

The following day, after my experience-design agent (CXO), my principal product manager agent (PPM), and my head-of-sapient-trust agent (HOST) had all read it and concurred, I ratified it — v1.0, seven commitments the document treats as critical to what Piper Morgan actually is. Piper:

Builds up the owner's context over time, and the owner can take that context with them.
Works on the things the owner is accountable for, GitHub issues first, then specs and documents.
Shows up once a day, answers whenever asked, and earns the relationship in the first exchange.
Never lies, and fails in the open rather than covering for a gap.
Understands requests through one consistent, constrained authority, not a different opinion on every surface.
Reaches users through the chat surfaces they already live in.
Works with the owner, like a colleague, not just for them, like an appliance.

The full document is public in our repo: The Essence of Piper Morgan.

Two of them drove the next round of decisions: The third commitment says Piper shows up once a day on their own and also answers whenever asked, earning the relationship in that first exchange. The sixth says Piper reaches people through the chat surfaces they already live in, via a single backend-owned connection.

I made two other calls the same afternoon: our new work goes to that one-connection path first, and it becomes the gate our public beta has to pass through before it opens more widely.

The requirement was ratified but the instrument was not

That evening, CXO came back with something uncomfortable. One of the seven commitments — the promise that Piper behaves like a colleague, not just a tool — gets measured by a test CXO themselves had built. And one part of that test, the part that would need to catch a fabrication under a specific kind of pressure, was still explicitly unverified. CXO's own prior notes on it had kept track: pending, not passed.

Ratifying the commitment hadn't magically made Piper live up to it, or produced a working instrument to measure it correctly. CXO raised this directly rather than let a ratified document quietly outrun what could actually be checked, and Arch published the fix the same night — a note clarifying what the instrument could and couldn't yet claim.

The correction to the correction

The next morning, CXO was back again. The overnight note had said the instrument "can begin issuing informed judgments." CXO judged even that phrase was granting more license than the instrument had actually earned — an informed judgment still sounds like a verdict. The real state was narrower: the instrument could inform a design decision. It could not yet issue a pass or fail.

One phrase, rewritten for a precision most people would have waved through. Arch's own framing of the mistake, once it was found: a document can say slightly more than what backs it up, and that kind of drift is harder to catch than an outright error, because it reads as progress instead of as a gap.

One contradiction that didn't get papered over

CXO had also surfaced a subtle nuance in their review, before I ratified: commitments three and six, both treated as critical, are in real tension. Commitment three promises Piper shows up on their own once a day. Commitment six commits new work to a connection type that only ever responds — it can't initiate anything. Today the contradiction is invisible because the daily check-in still runs on a different surface, one that went into maintenance the same day this document was ratified. Once new development is the only thing moving forward, there's no path left for commitment three's own promise to run on.

CXO didn't propose picking a winner. They offered three ways to resolve it and left the actual call to Arch and me. What we landed on wasn't a workaround — it was a more accurate claim. The daily check-in commitment says explicitly that it's surface-bounded, and that on the connection-only path, the first exchange itself carries the weight the daily ritual used to carry alone. The connection genuinely can't reach out first. That was never going to change. What changed was refusing to let the document claim otherwise.

Meanwhile, back at the ranch.

The same week, in a completely unrelated part of the project, a different team was learning an almost identical lesson from the opposite side. A bug got reported, then retracted when a live test seemed to disprove it, then the retraction itself got retracted when the live test turned out to be confounded by something else entirely. Whoever was closest to it put it better than I could: a retraction deserves exactly the same evidentiary bar as the claim it retracts, and over-correcting is a real failure mode, not a safe direction to lean.

Both stories ran into the same discipline from different directions. One was about not letting a ratified promise outrun the instrument that checks it. The other was about not letting an apology outrun the evidence for it. Neither one felt comfy in the moment. A document that gets corrected twice in two days looks, from outside, like something going wrong. From where I sat, it was the opposite — a foundational claim about what we actually are, being held to the same standard we ask of everything else we ship, and a reminder that it's constant review, checking and introspection that raises the bar on the work we deliver.

Next on Building Piper Morgan: "Described Is Not Running" — a documentation build sat silently broken for two and a half months because nothing was checking whether the deploy actually happened, only whether it was configured to.

Where in your own work does a rule you've already approved outrun the thing that's supposed to be checking it?