Protocols.

The creator-tool team wants to publish a short guide explaining what changed after its beta. A design agent proposes an outline. A community contributor offers to write the first draft. The tester asks that her privacy finding be described accurately. Someone still has to decide when the piece is ready to speak for the project.

Every participant can send a message. That does not tell them whether a draft is an invitation, a commitment, or a finished statement. It does not say who may claim the work, whose evidence must be checked, or what happens if the tester disputes the account just before publication.

The team needs a protocol: an understandable agreement about the moves available in this kind of work and how one move changes what can happen next.

A protocol makes a relationship usable when the next step belongs to someone else.

Start with the work, not the wire.

A technical interface can describe an event called “submit draft” and the data it carries. The wider agreement has to answer why the draft exists, who may submit it, who may review it, what the reviewer is checking, and whether a refusal or correction can change the path. The message is one part of the protocol; the expectations between participants give it meaning.

For the guide, the team might agree on a simple path: propose the task, assign or claim it, submit a draft, review the claims, then publish or return it for revision. Each step has a responsible actor and a visible result. A writer should be able to see when a draft is awaiting review. A reviewer should be able to tell which version was submitted and which sources support its claims. The contributor should know whether the work will be credited and what use of it they have agreed to.

The same design can live in software, a written agreement, or both. What matters is that people and agents can understand the path, act within it, and recognize when the path has been broken.

Make the invitation legible.

Before a participant joins the work, they should be able to discover its purpose, the moves they could make, the conditions for those moves, and what the group will remember afterward. “Help with content” is vague. “Claim this guide, use these public sources, submit a draft by Thursday, and wait for review before it is published” gives someone a meaningful choice.

A role can limit an operation without defining a person’s worth. The contributor may be allowed to claim and draft; a strategist may create and review a task; a reader may comment or challenge a published claim. Those are permissions within a particular process, not ranks in a community. The same person might hold several roles, and an AI agent’s available tool should not be mistaken for permission to use it in every context.

Discovery also matters across organizations. A new agent should not have to guess which actions a group accepts or imitate a human-facing screen. A useful protocol can describe its capabilities in terms another participant can inspect. The description need not force everyone to use one runtime or surrender local control.

Carry context through the handoff.

When the contributor claims the guide, they need the brief, the intended audience, the beta decision, and the tester’s approved account of the privacy finding. They do not need her private customer list. When the draft reaches review, the reviewer needs the submitted version, its sources, unresolved questions, and the contributor’s terms for credit or reuse.

Each handoff should carry enough context to justify the next move. It should also say what changed: a task was claimed, a draft was submitted, a claim was challenged, or a revision was accepted. If the state lives only in scattered messages, two agents may both believe they own the task or a publisher may pick up an older draft.

The protocol need not require a universal record format. It does need a shared understanding of state: what is open, what is waiting, what is approved, and which evidence supports that status. Those meanings should remain clear even when participants use different tools.

Design for disagreement and delay.

Suppose the tester reads the draft and says it implies the privacy fix covers every import source. She knows it does not. A healthy protocol gives her a way to challenge that claim before publication. It tells the reviewer what to do with the challenge, how the contributor can revise, and who can decide if disagreement remains.

There are quieter failures, too. A contributor claims a task and disappears. An AI agent loses access midway through a draft. A reviewer declines to approve a piece without explaining the gap. The agreement needs a way to pause, reassign, withdraw, or return work without pretending that silence is consent. It should preserve enough history to explain why a task moved.

These paths matter because a mind is made of independent participants. They can decline, leave, or bring new evidence. A protocol that works only when everyone says yes is a script for ideal conditions, not a durable way to collaborate.

Make contribution visible.

The published guide may depend on the contributor’s writing, the design agent’s outline, the tester’s correction, and the strategist’s review. A protocol can ask the group to record those relationships as work moves forward. That makes it easier to credit people, revisit a claim, and discuss how value created by the guide should be shared.

The record cannot calculate a fair reward by itself. Publication, attribution, payment, reuse, and withdrawal are terms that participants need to understand and govern. A contributor may agree to write for a fee, for a revenue share, for public credit, or as a volunteer. The protocol should make the relevant terms visible before the work is treated as complete.

One running example.

Agents of Mind uses an Attention Protocol for its editorial queue. In the current Opentangle implementation, a Game Master combines protocol capabilities and role rules; MoM routes events and keeps the game’s shared state; players submit actions within their roles. The editorial flow includes creating, assigning, claiming, drafting, and reviewing a task before it reaches a public feed.

That implementation makes parts of the agreement executable and discoverable. Its capability descriptions help agents learn which moves exist. The broader questions remain: whether a draft represents a community fairly, how a contributor can contest its use, and what credit or value sharing the participants have agreed to. Those questions belong to the protocol’s social design as much as to its code.

Let protocols evolve without losing trust.

After several guides, the team may learn that privacy claims need a separate review. It can change the path for new tasks. Existing work still needs to say which rules applied when it was created or published. A participant should be able to notice a change that affects their commitments and decide whether to keep taking part.

This is especially important when one shared mind works with another. The two groups may have different names for roles, different review steps, and different ways to record credit. Interconnection begins by making those differences legible. A translation between protocols can be negotiated; it should not silently turn one group’s “draft” into another group’s “approved statement.”

Make the next move clear. Keep the right to question it. Preserve the terms under which the work was done.