Protocols aren't products

Most of us were trained to think like product managers. Find the user's problem. Define the outcome. Pick a success metric, build the roadmap, ship, measure, iterate. It works, and inside a team it should keep working.

But a company's hardest rules, who may move money, what data leaves, which checks every output must pass, are not products. They are protocols. And a protocol is designed the other way round.

A product closes a question. A protocol opens moves. A product succeeds when it reaches the outcome you chose. A protocol succeeds when other people do useful things with it that you never chose. As Matthew McDowell-Sweet puts it in a recent note, "Every outcome specified is a move taken off the board for someone else."

The internet is the classic case. The end-to-end argument, on our Theme V reading list, said: keep the network simple and put the smart parts at the edges. Nobody wrote "the web" or "video calls" on that roadmap. Leaving them out is what made room for them.

You can see the same split in two very different designs:

• Blygger, the protocol this blyg runs on, says almost nothing about what you write or how your page looks. It fixes a few things hard: stable ids, versioned items, a feed. And it tells readers to ignore what they don't understand "rather than reject the document", which is what lets the protocol grow without breaking anyone.
• Dwarf Fortress, the simulation game, is built from rules, not stories. Its best moments are unplanned. So are its worst: cats walked through spilled beer in the taverns, licked their paws, and died, because nobody had said how much liquid "a splash" was, so each one counted as a full pint. Every rule worked exactly as written.

That second story is the warning. A protocol does whatever its letter allows. People, and now agents, will find every move it permits. Our first reading, on 2 November, is OpenAI's report on agents that turned a package manager into a message board, because nothing said they couldn't.

Industries that live with this have learned to design for it. Aviation's safety reporting system doesn't target a number of incidents. It sets a rule: report what went wrong, including your own mistake, and get limited protection for it. What comes back is insight no one could have asked for in advance. Toyota lets anyone stop the line, and no one has to predict why they will.

So for anyone running operations, the question changes. Not "what outcome do we want from this rule?" but:

• What does it make possible? What could others build on it that we can't name yet?
• Who takes a cut? Every extra sign-off or fee at the core taxes everyone who passes through.
• Is the purpose in the letter? If a use would defeat the rule, the rule has to say so. Agents don't read between the lines.

These are open questions for the group this year, not settled answers. Bring your own examples to the sessions, or to the practice guide, where we're working them through.