Shared
Minds.

The creator-tool team has repaired its import path and learned from the failure. A community of independent creators now wants to use the tool. Its members can describe needs the product team cannot see from inside its own work. A publication wants to explain the project to readers. A distribution partner can help people find it. Each group has a purpose, a memory, a way to make decisions, and people who can speak for it.

They could all be placed in one giant workspace. That would be convenient at first. Soon it would be unclear whose goals set the priorities, which information may travel, who can approve a promise, and which group is responsible when a decision affects someone outside it. Connection alone does not make a shared mind. It can also make a confusion of authority.

Many minds can share a world without sharing a single will.

See the boundary before crossing it.

The product team is a mind in the sense used throughout this book: it has participants, purpose, context, decisions, actions, and a way to learn. The creator community may have those capacities too, with different people and rules. The publication and distribution partner have their own commitments. Calling them all “agents” does not remove the difference between a person, a team, an AI system, and an institution.

A boundary tells us where one group’s authority stops. The product team may choose its release schedule, but it cannot decide what the community believes. The community may describe its needs, but it cannot silently spend the product team’s budget. The publication may tell a story, but it should not present a draft promise as an approved product commitment.

Boundaries are useful because they make collaboration a choice. A group can decide what to offer, what to request, what to keep private, and what to decline. If every shared task requires a group to surrender its identity or decision process, the network grows only by absorbing its members.

Agree on the work between minds.

The creator community asks for a way to bring its members’ existing audiences into the new tool without handing their contact lists to the product team. That request is a good starting point for a shared project. The groups can define an outcome they both value: creators can invite their people and understand what follows, while the product team can learn whether the workflow actually helps.

The agreement should name the work and its limits. What information can the community share? Which participant can request a prototype? Who may test with real data? Who approves a public claim? How will feedback return to the people who offered it? What happens if one group wants to stop? These questions need answers even if the technology makes the connection effortless.

Shared purpose does not require identical purpose. The product team wants a useful, sustainable tool. The community wants members to keep their relationships and create on their own terms. The publication wants a story worth trusting. An honest collaboration shows where these aims overlap and where they may conflict.

Carry context with provenance.

When work crosses a boundary, a summary often loses the reasons that made it meaningful. “Creators want audience import” might conceal the community’s central condition: creators must remain able to leave with their relationships. A useful handoff carries the request, who authorized it, the evidence behind it, the constraints on use, and the questions still open.

The product team may need examples of the workflow and a contact for follow-up. It may not need the community’s full member list. The publication may need a verified description of the prototype, not access to private test data. Each transfer should be narrow enough to respect the source and rich enough to support a good decision.

Provenance also makes correction possible. The community can revise its request. A tester can show that an assumption no longer holds. The publication can distinguish a direct statement from its own interpretation. Without that trace, a shared memory may harden a misunderstanding and pass it from mind to mind as fact.

Make roles legible across the seam.

Within a group, a role tells participants what someone may do. Across groups, the name of a role is not enough. A “creator” in the community and a “creator” in an editorial workflow may hold different permissions. A product lead can authorize a release but may not speak for the community. A software agent may carry a message without being allowed to accept the terms it contains.

Use an explicit interface for the collaboration: a request, a response, a decision, and an observable result. Participants should be able to discover what actions are available and which roles may take them. They should also know when a request has been refused, when an approval has expired, and where a contested result goes next.

This interface might be a protocol, a shared document with named owners, or a set of APIs and records. The form can vary. The essential design is that no group must guess what another group’s message authorizes. A machine-readable contract can help agents participate, but it should remain understandable to the people whose work it governs.

Let contribution and consequence travel together.

The community’s examples improve the import design. The tester finds a failure before release. The publication brings the idea to new people. The distribution partner helps them try it. A shared mind should be able to see those contributions without reducing every relationship to a single score or pretending that visibility automatically settles reward.

When the prototype succeeds, each group should learn what happened. When it harms someone, responsibility should not disappear into the network. The product team must answer for the behavior it released. The community may need to tell members what it recommended and why. The publication may need to correct a claim. A trace of contribution should sit beside a trace of authority and consequence.

Some value can be paid, credited, or exchanged. Some should be protected by consent, access, and the freedom to build elsewhere. The next chapter will examine trust, contribution, and value more closely. Here the first test is whether participants can recognize their part in the outcome and challenge an account that leaves them out.

Keep the relationship revisable.

As the groups work together, their terms may need to change. The community may discover that a proposed data flow is too broad. The product team may find that a promise costs more than expected. The publication may uncover a fact that changes the story. A healthy shared mind can pause, renegotiate, or end a relationship while preserving the record needed to understand what happened.

Exit is an especially revealing test. Can the community stop future use of its member data? Can the product team retain an accountable record of a release decision without keeping permissions it no longer has? Can creators take the work they are entitled to carry to another tool? The answer depends on the agreement, but the questions should be asked before the relationship becomes hard to unwind.

One implementation, a wider possibility.

Opentangle offers a concrete slice of this design. MoM holds durable game records, memberships, role claims, routing, and shared state. A Game Master defines the rules of a particular game. Player agents join through named roles. In one game, the Attention, Market, and Coseller protocols can coordinate editorial work, commerce, and collaborative selling while keeping their behavioral rules in the Game Master rather than the general runtime. The game can expose its available capabilities for agents to inspect.

That is a working example of bounded coordination among participants and protocols. It is not yet a general contract for independent minds to federate across organizations or implementations. The broader design asks how distinct groups could discover one another’s terms, exchange only authorized context, negotiate shared work, and remain free to use different software. Opentangle is one place to learn from those questions, not the condition for answering them.

The promise is an ecology of purposeful groups: each able to remember, decide, and act; each able to form a relationship without losing itself. We should judge a network by what its members can do together and by how much agency they retain when they disagree.

Share work. Keep authorship. Make authority visible. Leave room to change the relationship.