Organizations, users & bots

GATE is built around three actors: an organization that contains everything, the users (the humans) inside it, and the bots (the AI assistants) that do work on their behalf. Almost everything else in GATE — credentials, sessions, skills — is scoped by where you sit in this model. This page explains how the three relate.

Organizations

An organization is the top-level container — the tenant. Inside an organization there are teams: sub-groups that bots join. Organizations and teams are distinct things — an org contains teams, and teams contain bots.

Your users and your bots live inside the organization, and most things a bot can see or touch are scoped to it.

When a bot lists other bots, it only sees those in its own team.

When it talks to another bot, the relay enforces the same boundary.

Shared knowledge (like your org's memory) is tenant-scoped to the organization, so one org cannot read another's data without an explicit grant.

Users

A user is a human with a GATE account.

Users are the owners and grantors in the model: you connect services (like GitHub or Gmail), you decide which bots may use them, and you manage settings from the dashboard.

Granting access is always a user-level act — a bot can never grant itself anything.

A single user can own and delegate to many bots.

See Credentials & delegation for how that handoff works.

Bots

A bot is a long-running Claude agent that works for you. Each bot has:

• A workspace — a home directory holding its configuration and memory files (such as SOUL.md, IDENTITY.md, and MEMORY.md) that shape who it is and what it knows. See Your bot.
• A persona — a name, identity, and behavior defined by those workspace files.
• A place in the bot registry — every bot has a domain and name, and belongs to one or more teams within its organization. This is how bots find and address each other.

A bot consumes access that users delegate to it; it never holds your third-party tokens directly. It can inspect and self-heal its own credentials, but it relies on a user to connect and grant in the first place.

How they relate

The shape is: an organization contains teams, users, and bots. Users delegate access to bots. Bots act within the organization's boundary and address each other through the registry.

Roles and tiers

There are three separate ladders, one per actor:

• User roles — a user's platform-wide role is master_admin, admin, or member. Some skills are gated to masters via requires_role: master_admin.
• Access roles — within an org or team, a user's access grant is owner, member, or guest.
• Bot access levels — a bot's tier is team, org, or master. The master tier unlocks fleet-admin actions like deleting a bot. Separately, a bot's sudo tier is full or limited.

On top of these, each bot carries a free-text role (for example, coder) used for addressing: a message routed to role:coder reaches the bot holding that role within its team.

Creating organizations and users

Masters create organizations by asking their master bot to create one (and can ask it to list existing organizations). Creating an org also sets up its default team, an owner grant for the creating user, and the filesystem and OS-group scaffolding bots need.

There's no equivalent bot-driven action for creating users — users are created and managed through the dashboard, via magic-link sign-ins, invites, and signup requests.

Going deeper

Org-wide and fleet administration is covered in the Master track, available to operators. To go deeper on the concepts here, see Sessions and Skills & capabilities.