← Library

Identities and Organizations

Most software has users, and bolted on beside them some notion of an account or a workspace. thinqOS works the other way round. There is one idea, the identity, and it comes in three kinds: a person, an agent, and an organization. Everything that can own anything is one of those three, and they all own things the same way.

That single choice is what makes the rest of the product straightforward to reason about. A fact your company knows belongs to your company. A credential your agent holds belongs to your agent. Nothing is owned by "the account" in some vague sense, because there is no such thing.

This page is written for three readers in turn: somebody meeting the idea for the first time, somebody who has to run an organization day to day, and somebody wiring agents or their own tooling into it. Read the part you need.

If you are new

An identity is anything that can hold things: knowledge, skills, connected accounts, money, and a Mind of its own. There are three kinds.

The third kind is worth stating plainly, because it is the one people expect to work differently. An organization is not a person and it has no login. You never sign in as your company. You sign in as yourself, and because you belong to the company, you can act on its behalf. What you do for it is attributed to it, rather than to whichever member happened to be at the keyboard.

Take a concrete case. Priya runs a two-person landscaping business. She creates an organization called Ridgeline Landscaping and becomes its owner, then adds her partner Sam as an admin. The price list, the supplier contacts and the standard quote wording go into the business rather than into Priya's own Mind, because those are the business's facts and Sam needs them too. She deploys a scheduling agent into the business. That agent reads the business's knowledge, uses the business's connected calendar, and the business pays for its work.

Later Priya joins her neighborhood association as an ordinary member. She now belongs to two organizations at a different role in each, and neither one can see the other's things. Her personal Mind stays hers throughout. If she leaves the association next year, she keeps her own Mind and the association keeps its own.

None of this is compulsory. Plenty of people use thinqOS alone, belong to no organization, and never think about any of it. Organizations start earning their keep the moment a second person needs the same things you have, or the moment you want the cost of a piece of work to land on a business instead of on you.

If you run an organization

Creating one. Open Organizations in the main navigation and give it a name. Anyone can create one. You become its owner.

Roles. Everyone in an organization holds exactly one of three roles.

One rule the product will not let you break: the last owner cannot be removed or demoted. An organization always has somebody who can administer it.

Adding people. Owners and admins add someone by email address or username, set their role, and remove them again later. Membership is explicit, and it is many to many. A person can belong to no organizations, to one, or to several, at a different role in each.

Join rules. If everyone at your company shares an email domain, add a join rule for it. Anyone who signs up with a matching address is added automatically, at the role you chose. That is how a company of forty people avoids sending forty invitations. Owners and admins add and revoke these rules.

Being found. A new organization is private. It does not turn up in search, and nobody can ask to join it. Turn on Discoverable and it does appear: anyone who finds it can request to join, and an owner or admin approves or denies each request. Requesting is never the same as joining, so making an organization discoverable costs you nothing but the request.

What the organization owns. Domains, agents, connected accounts, and a wallet. Every one of them names the organization and links back to it, so from any agent or any connected account you can see at a glance which organization stands behind it.

Domains are how access is granted. A domain is a folder, and domains nest into a tree. They hold knowledge, skills, connected accounts and agents. You grant a person or an agent one of four roles on a domain: use, read, edit, or admin. A grant reaches every domain beneath it, so access to Finance also reaches Payroll inside it. The practical rule is simple: if two things need different audiences, put them in different domains. Access is the only question a domain answers, and a domain is the only thing that answers it.

Who pays. The organization holds a wallet and pays for the work its agents do. Cost lands on the business, not on whoever happened to start the conversation. That is the reason to put work under an organization even when you are its only member: the spending is the company's, and it is reported as the company's.

If you build agents or integrate

Every unit of work names the organization it serves. A conversation, a background run and a consult each carry the organization they are being done on behalf of, fixed when the work starts. Keep this separate in your head from access. Membership and domain roles decide what an identity may reach; the acting context records who the work was for. The two answer different questions and neither substitutes for the other.

Over MCP. The thinqOS agent can list, create and administer organizations on your behalf, through the generic tools against the me_organizations resource:

So "add Sam to Ridgeline as an admin" is something you can just ask for, in the same conversation where you were already working, rather than a detour into a settings screen.

chat_start accepts an org argument. Pass it, and that conversation, plus every run and consult inside it, is attributed to that organization.

One agent, deployed per organization. An agent is built once and deployed into each organization that wants it: one definition, one instance per organization. Each instance has its own Mind, its own memory, its own data and its own connected accounts. The isolation between two instances is not a filter applied on the way out; each instance is a separate identity, so separating two deployments of the same agent is the same operation as separating two people. That is why it holds.

Learning moves in one direction, and only with permission. What an instance learns while working for an organization flows up to the shared definition only when that organization allows it. Absent that, everything the instance picked up stays with the instance, which is the property that lets one agent serve two organizations that would never want to share a sentence.

Glossary

One identity model for people, agents and the groups they work for.

Read the point of view, or get into the private preview.