Identity.

The creator-tool beta is finally live. One morning, its code agent proposes a change to the onboarding flow. The proposal appears under the same familiar name that has handled earlier fixes. But the agent was restarted overnight, its instructions were updated, and a different person now operates the service that runs it.

The creator wants to know whether this is still the agent she authorized to work on the beta. The tester wants to know who will answer if the change exposes another customer list. The community member who helped bring in the first users wants to know whether her contribution will remain visible after she joins a different project.

A name on a screen cannot settle any of this. The group needs to recognize who acted, what part they played, whose authority they used, and what should remain continuous when people, tools, or teams change.

Identity is the thread that lets a mind connect an action to an actor without pretending the actor never changes.

Ask more than “what is its name?”

For a consequential action, four questions help. Who performed it? That might be a person, an AI agent, or a group. Who stands behind it? An AI agent may act under authority delegated by a person or organization. In what capacity? The same person can test a product, advise a team, or speak for a community under different terms. Which instance acted? A running process can restart or be replaced while the work and its responsibilities continue.

Those answers should be connected, but they need not collapse into one universal ID. A public handle makes someone addressable. A verified relationship shows whether they hold a role. A record of delegation shows what they were allowed to do at that moment. A session or device record helps investigate the particular action. Each answers a different question.

In the beta, “code agent” is a useful label. It is not enough to approve the proposal. The creator needs to know which project identity the agent is using, who currently operates it, what mandate applies, and whether this new session is authorized to continue the earlier work. Continuity should be established through relationships the group can inspect, not assumed from a reused name.

Let roles describe a relationship.

The tester is a contributor to this project. She might be a creator in another, a buyer in a third, and a decision maker in a community she helps govern. None of those roles is her whole identity. Each names a relationship to a particular shared mind and the actions that relationship permits.

A role should answer practical questions: what may this participant see, propose, approve, challenge, or receive? It should have a way to begin and a way to end. Turning roles into permanent ranks makes it harder to change a relationship without changing the person. It also tempts a system to infer trust in one context from status earned in another.

The same applies to AI agents. A capable code agent may hold the role of implementer for one project and observer for another. Its technical ability does not grant it the authority to edit both. A design agent can propose a release in the creator’s project without becoming the creator, the publisher, or the owner of every idea it used.

Preserve continuity without freezing people.

People change their minds and their names. Organizations change members. Software processes restart. A system that identifies everyone only by a current session loses the history needed to understand past work. A system that treats an old profile as an eternal statement of who someone is makes growth and exit difficult.

The creator-tool team can keep a durable project identity for the code agent’s role, then record which running instance acted at a given time. Earlier actions remain attributable to the instance and authority that existed then. New actions require the current instance to show that it occupies the role now. If the operator or mandate changes, the team can review the change without rewriting the past.

The tester may choose a public name for her contributions without publishing her legal name or customer list. She may want to take evidence of her work to another project while keeping private context private. Portability therefore needs more than export: it needs a way to say what she contributed, what may be shared, and which claims another group can verify without learning everything about her.

Make room for a group to speak.

After the beta, another community asks the creator-tool team for a recommendation. The answer could come from the creator as herself, from the tester as an independent reviewer, or from the project as a group. Those voices should not be interchangeable.

If the project speaks, who authorized the statement? Was it reviewed by the people named in it? Can a member dissent or correct it later? A shared mind can have an identity that others recognize, but that identity must point back to the people and rules through which it acts. Otherwise, “the team decided” becomes a way to hide a single person’s choice.

The pattern can repeat. A project joins a wider community and contributes as one participant. That community may join a larger network. At each level, the group needs a way to identify itself, declare who may represent it, and preserve the identities of its members where accountability requires them. Connection should increase what the group can do without dissolving its members into the group name.

Let credit follow the work.

The tester’s warning changed the release. The code agent’s fix changed the product. A community member’s introduction brought customers. When the team later tells the story of the beta, it should be able to show how these contributions relate to the outcome, even if a contributor has left or an agent has been replaced.

Attribution is a claim that should be inspectable and, when needed, contestable. The record might show who raised an issue, who made a change, who approved it, and whose work it depended on. That does not mean everyone must reveal the same personal information or receive the same reward. Identity gives contributors a place from which to ask for recognition and negotiate terms; it does not automatically settle value.

One implementation, several identities.

Opentangle offers a concrete example of this separation. In its MoM runtime, a game has a durable identity, players have memberships and roles, and an active agent session can change when software restarts or is replaced. A Game Master defines the game’s available actions. The player remains recognizable in the game even though the process currently acting for that player may be new.

That is one design choice, not a universal identity system. It helps reveal the deeper question every builder faces: which relationships must survive a restart, which authorities must be checked again, and what can a person carry to another mind without carrying everything?

Know the actor. Name the capacity. Trace the authority. Let the relationship change.