I created my GitHub account in September 2010. Since then, employers, clients, and open-source communities have granted it memberships and roles, and revoked them when I moved on. Through all of it, the account, its name, and its history stayed mine. Over the same stretch, enterprise workspace suites handed me the opposite deal at job after job: a fresh account on arrival, a suspension or deletion after departure, and whatever lived inside (the mail, the documents, the accumulated record of how I worked) gone with the badge. Administrators can transfer some of it before the account closes, and good ones do. That is the point rather than a caveat on it: whether any of your working record survives is someone else’s operational decision, taken after you have already handed in the laptop.
Those are the two identity models available to multi-user software, and every tool picks one, deliberately or by accident.
The GitHub way: identity belongs to the person. One lasting account per human; contexts (organizations, repositories, teams) grant that account roles; leaving a context revokes the role and touches nothing else. The workspace way: identity belongs to the context. Google Workspace is the familiar example. The organization provisions the account, administers it, and deletes it, and the person exists in the system only as long as the employment does. A career under that model is a series of disconnected identities that happen to share a face.
Fragmentation is a purchase order, not an architecture
The workspace model is not an engineering mistake. It follows from who signs the contract. The employer is the customer, so the employer’s needs shape the account: central control, instant offboarding, legal discovery, handing a departed employee’s mailbox to a successor. Those needs are legitimate. And the pull they exert is strong enough that GitHub itself now sells the workspace model to enterprises that demand it. Enterprise Managed Users are provisioned by the company’s identity provider, administered from it, and disabled from it. The company built on person-owned identity sells both models, because the pressure to fragment the person comes from the purchase order.
Which is why the question needs asking again right now. Multi-user agent tooling (systems where several people and their AI agents share projects, context, and working memory) is being designed and procured this year, and it accumulates the one asset that makes identity models matter most: a record of how a person works. Judgment calls, lessons, preferences, the collaboration a person has built up with their agents over time. When email fragments across employers, you lose old mail, which stings. When agent working memory fragments across employers, you lose a working relationship you spent years building, which compounds. The identity model decides who keeps it.
Sessions got identity before people did
I hit this in my own tooling from an unexpected direction: the machines got durable identity before the humans.
My synthesis engineering work (humans and AI agents working shared projects through durable files, so the record outlives every conversation that produced it) runs on a coordination layer. Parallel agent sessions register on a shared board, claim the file areas they intend to write, and leave messages for one another. That board just shipped durable session identity: every session now carries a time-sortable UUIDv7 plus two aliases that name the same identity, one compact (s-6adk-06yc-yqb2) and one speakable (crater-sunset-alone-okay-23907), so a human can refer to a session out loud. The design is published in my open-source skills project.
Then I read the schema the way a stranger would. Fifteen columns: identity in four spellings, agent, machine, project, two timestamps, mode, worktree, goal, claimed areas, context role, status. No person. Sessions became first-class, with lasting names a person can speak, and the humans they work for appear nowhere in the schema.
At one user, that gap is invisible. Every session was mine, so I was the schema’s unstated constant. It stopped being invisible the day I started designing the team layer, so that colleagues at an organization I work with can share these projects. The next schema revision adds the person column, and a person column forces exactly the choice this piece is about. Identify people by org-issued handles inside org-owned infrastructure, and you have rebuilt the workspace model in new tooling. Identify them by an identifier each person owns, with roles granted per organization, and you have the GitHub model. For a discipline whose premise is that the record outlives the conversation, this choice decides whether the premise survives an employment boundary. Attribution has to keep answering “who did this” (person, agent, and model) years later, across employers, and it cannot if the person half of the answer was deleted with a workspace account.
What the person column decides
The difference stops being abstract at the boundary events: someone joins, someone leaves, someone works two contexts at once.
I have been running the one-person version of the answer for a while, because consulting work forces it. My knowledge base splits into a permanent personal root and per-engagement repositories that are deletion units: when an organization wants its data gone, deleting its folders is the operation. My daily plan is person-scoped, one view of everything on my plate across every organization, but it holds that breadth as pointers. Each organization’s content lives in that organization’s own repositories and stays there. The open-source console I browse it all with (source on GitHub) composes every workspace into a single view for a single person. The view aggregates across contexts. The files never do.
Scale that to a team, and the person column decides who keeps what. If a collaborator’s identity is org-provisioned, their working history sits inside the organization’s control by construction: leave, and the record of how you work stays behind, gets transferred at an administrator’s discretion, or goes away with the account. If identity is person-owned with roles granted per organization, both sides keep what is theirs. The organization keeps the project record, and removing its active working copies from a departed member’s machine becomes deleting known directories rather than hunting through a shared store. That is a smaller claim than it sounds, and worth stating precisely, because the sloppy version of it is a promise nobody can keep: git history, backups, search indexes, and caches all outlive the folder, so what the design buys is a bounded and auditable deletion unit, not proof of erasure. The person keeps the cross-organization record of themselves: their lessons, and their agents’ accumulated understanding of how they like to work. The fragmentation model forces a bad trade, where either the person keeps nothing or the organization cannot cleanly delete. Person-owned identity with content routed by ownership gives both sides a clean exit, and a clean exit is what makes the arrangement trustworthy enough for an organization to adopt at all.
That is what I intend my person column to encode. I am writing it down plainly because nothing about a schema migration makes the choice for you.
Three questions for any identity design
If you are building multi-user agent tooling, or evaluating it for an organization, the identity model gets set early and calcifies fast, often as a side effect of whatever the first enterprise deal demanded. Three questions expose it before it hardens.
Who controls the identifier? If the person creates it and keeps it after leaving, contexts can only grant and revoke roles against it. If the organization provisions it, the organization decides what happens to everything attached to it. Ownership in the legal sense is a separate question, settled by your contract and your IP assignment rather than by who issued the login; plenty of people are surprised to learn those two answers differ. But control is what you feel on your last day, and control follows provisioning. The test is offboarding: does it revoke a role, or remove a person?
What survives leaving a context? The role ends; that part is easy. The organization’s confidential content should leave with the relationship, as an operation you can run rather than a promise you make. The person’s own record (what they learned, how they work, what their agents know about working with them) should walk out the door with the person. Note what that is and is not a claim about. The organization keeps its project record, and what either side owns is set by the contract and the IP assignment, which is where you should look rather than at your login. This is a design argument about what tooling should make easy: it should be possible to carry your own working method across a boundary without carrying anyone’s confidential material, and today most stacks make the opposite easy. The test: the day after departure, what can the collaborator still see of their own working history?
What aggregates across contexts? A person’s working day spans organizations even when each organization would rather pretend otherwise. Tooling that cannot compose one view across contexts pushes the person back into fragments, one login at a time. But aggregation has to happen at the view layer, never the storage layer: pointers rather than copies, so no organization’s content ever rests in another’s store. The test: can one person see everything on their plate today, across every context, while any single organization can remove its active working copies by deleting its own bounded directories?
GitHub’s model looks inevitable in retrospect and was a choice. It is why an account from 2010 still means something, and why a contribution graph could become a working record. Agent tooling is making the same choice now, mostly by default, and the defaults lean the other way: memory scoped per user, per vendor, per chat product; enterprise deployments provisioned like workspace suites. Defaults are how the workspace model wins. I am building my person column the other way, identifier owned by the person, roles granted by the organization, because I have watched what a decade and a half of fragmentation does to a working history, and the colleagues who will share these projects with me deserve to keep theirs.