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.
- A person is you. You sign in. Your Mind holds what you know, what you prefer, and what you have decided.
- An agent is a working colleague you can talk to. It never signs in. It has its own Mind and its own memory, kept apart from yours.
- An organization is a group: a company, a household, a club, a client you work for. It never signs in either. It has a Mind, and it holds what the group owns.
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.
- Owner can do everything, including changing other people's roles and removing them.
- Admin can manage who is in the organization and how it is set up.
- Member can act for the organization, within whatever access it has been granted.
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:
thinqos_querylists the organizations you belong to, and reads one of them along with its members and join rules.thinqos_createcreates an organization.thinqos_updatechanges one.thinqos_actioncarries out the membership operations: setting a role, removing a person, adding or revoking a join rule, approving or denying a join request.
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
- Person. An identity that signs in. Has a Mind of its own.
- Agent. An identity that never signs in and acts through people and other agents. Has a Mind, memory, data and connected accounts of its own.
- Organization. An identity representing a group rather than an individual. Never signs in, has no login, and owns domains, agents, connected accounts and a wallet.
- Domain. A folder in a nesting tree that holds knowledge, skills, connected accounts and agents. Access roles are use, read, edit and admin, and a role reaches every domain beneath the one it was granted on.
- Membership. The explicit fact that a person belongs to an organization. Many to many: a person may belong to none, one, or several.
- Role. The seat a member holds in an organization: owner, admin, or member. The last owner cannot be removed or demoted.
- Join rule. An email domain claimed by an organization. Anyone who signs up with a matching address is added automatically at the role the rule names.
- Deploy. Standing up an instance of an agent inside an organization. One definition, one instance per organization, each isolated from the others.
One identity model for people, agents and the groups they work for.
Read the point of view, or get into the private preview.