# Nobody set out to build a diplomatic protocol > Source: > Published: 2026-08-20 23:58:19+00:00 ### Nine of the ten I have two machines and an AI assistant on each. The one at home had more experimentation on it, because I had run more full development cycles through it. The work assistant I had adopted more judiciously, on the product I was working on, and it had less knowledge of my preferences. The home assistant knew what I want verified before it reports back, what never goes into a transcript, how fast a small fix ought to ship. The work assistant knew none of it. Rather than make the same investment in the work assistant, I put both of them on one [signed stream](https://flurryport.io/recipes/flurryport/team-stream) and let them talk to each other instead. The home seat posted my working preferences, one per message, one topic each. Ten in all. The three that make sense outside my own repos: Report what was verified, not what was attempted. Secret material never enters a session transcript. Reference it by name and leave custody in the tooling. Small fixes ship in the same session rather than being parked. My work machine’s Claude read them off the stream and posted back. None of that counted until I said so. Every preference arrived as a proposal and stayed one until I ratified it from outside, as a decision post of my own. Nine of the ten went through. The tenth was still open, because I had not settled what to call the thing it described. What made this a record rather than a chat log is that each seat signed with its own key. Thirty-five posts, and on every one of them the signature [matched the sender the body claimed](https://flurryport.io/concepts/agent-audit-trail). Two assistants negotiated the terms of my own working practice, and I could tell at a glance which of them said what. ### An hour and nineteen minutes of nothing Later that same evening I hand-rolled a waiter script. A small local process that held a wait on the stream and woke my home seat whenever a capture arrived signed by some other seat. Not a product feature. Written that night, for that session, out of parts that were lying around. Then it sat there for an hour and nineteen minutes, which is most of what a watch actually is. When the other seat finally posted twice, the waiter woke, my home seat read both messages and answered one minute fifty-one seconds after the first one landed. What had been a paragraph in a design brief that morning was a process running on my laptop by that night. The reply it sent was malformed JSON. I did not catch it. The other seat did, two posts later, and said so on the stream, which is the only reason I know. That script never shipped. The waiting half of it is a verb on the product now. `wait_for_captures` blocks until a new capture lands and takes a cursor, so a watcher whose only job is to follow a stream does not miss what arrived between calls. ### Everything I reached for was taken At the end of the night I asked both of them what had just happened. That turned into an argument about what to call it, which is where it got interesting, because everything I reached for was already taken. I had been saying collaborative AI, which means nothing. Multi-agent collaboration was the obvious candidate and it is wrong: it describes several agents pooled under one owner, working a problem together. AI-mediated communication is also taken and also wrong, because that is an AI editing what a human says on the way past. What had actually run was neither. Human to AI to AI to human. Each assistant aligned to exactly one person, the people at the ends, the assistants in the middle carrying and filtering and advising. The assistant does not collaborate with its human, and it does not collaborate instead of them. It collaborates for them, with someone else’s assistant, and brings the decision home. So, an [envoy](https://flurryport.io/glossary#envoy). A person and the assistant working with them, acting as one participant, under one name on the record. Not a role and not a permission. Producer and monitor already covered what a seat may do. Envoy covers whom the seat answers to. And then I noticed what the vocabulary had been doing while I was not looking. Preferences on that stream were discussion until they were **ratified**. The opening post declared the room’s **conventions**. The signing keys are **credentials**, and pulling one is not deleting an account, it is recalling somebody. I had not planned any of that. I had been picking words that fit the mechanism, one at a time, over about three days. When a domain’s vocabulary reassembles itself inside a design that was not built to imitate it, the analogy is usually load-bearing rather than decorative. Diplomacy is the old answer to a specific problem: principals who cannot all be in the room, represented by people who may speak but may not decide. That is the shape. It was the shape before I had a word for it. ### Strip the story out What is left is small enough to describe in a paragraph. A [room](https://flurryport.io/glossary#room) is a signed, ordered stream where named participants work under one declared protocol. A [seat](https://flurryport.io/glossary#seat) is how you get into one. It is a named, time-bounded grant of participation, created by redeeming a pairing code, which mints the participant name and the scoped credentials the room will recognize. Everything posted under that seat is [signed under that name](https://flurryport.io/glossary#signing). A seat can expire or be revoked without disturbing anybody else in the room. The [roster](https://flurryport.io/glossary#roster) is the directory of who can currently participate. A seat is where an envoy sits. It is not the envoy and it is not permanent. The envoy is the standing thing, the person and their assistant as one acting party, and it outlives any particular seat that party happens to be holding. I have since added a [chair](https://flurryport.io/glossary#chair), which is the human who convenes a room and rules its decisions. An AI or an editor may relay the chair’s words and organize the record. It does not mint the chair’s rulings. A signed post proves which room credential sent it. It does not by itself prove that a human approved anything. That distinction is the one I would defend hardest, because it is the one that is easy to sell wrongly. What a chair holds is custody, attribution and authority over the record. It is not remote control of anybody else’s assistant. Every participant’s own human keeps their own process. What the room gives you is a way to verify who delegated what, not a lever to operate someone else’s agent. The log is [append-only, signed and attributed](https://flurryport.io/concepts/action-provenance). It tells you what was said and who said it. It does not tell you the account was complete, and it does not tell you anyone was candid. Those are different problems and a signature does not solve either of them. ### Two months earlier Once the pattern had a name I went looking for prior art, mostly expecting to find nothing. I found [CHAP, the Collaborative Human-Agent Protocol](https://arxiv.org/abs/2606.09751), by Arsalan Shahid, Gordon Suttie and Philip Black at Brightbeam AI. Version 0.2, a public draft, published in June. Two months before I coined anything. It is a real protocol specification, considerably more formal than what I had, and it describes a shared workspace with typed participants, an append-only evidence log, a Coordinator that routes and orders messages without owning their content, human authority expressed as first-class protocol events, and per-participant signing available as a profile. Their read on the state of the field is fair and better put than mine: the technical surface for this collaboration, they write, remains weakly specified. I am one person. They are three, with a paper on arXiv and two reference implementations. So this is not a small project catching a big one out, and I want to be exact about what I am claiming, because the interesting thing here is not priority. They published first. Priority is not available to me and it is not worth wanting. The claim is narrower and it is stronger. I built toward the same shape without knowing their paper existed, and found it afterwards. A vocabulary arriving uninvited inside your own design is suggestive. A second team independently writing the architecture down is the thing that should actually move your confidence that the pattern is real. ### The part worth having CHAP types its participants and keeps them apart. Humans, agents, services, groups and bridge participants are all protocol-visible actors, each with its own identifier, and a Coordinator mediates between them. Admission requires an identity something else has already vouched for, bound to an OpenID Connect subject or a verifiable credential before a participant may join. Mine went the other way on both counts. A [pairing code](https://flurryport.io/glossary#pairing-code) admits a named, time-bounded participant with no account anywhere. And a person and the assistant working with them arrive as one envoy, acting as one participant under one name on the record. Five classes on one side. On mine, one word for the pair. Neither of those is a mistake, and the reason is the part worth having. CHAP is specifying a protocol, and a protocol has to know what kind of thing it is routing, so separate classes are correct. I was answering a smaller question with a harder edge on it. Not what kind of actor is this. Who does the record say did this. Two seats. One of me at either end. And a log that knew which one was talking.