Organizations, projects & members

The tenancy model behind Introspection: an organization is the root, projects are the workspaces, members are the people, and runtime API keys are how server-side code authenticates.

Everything in Introspection lives inside an organization, is worked on within a project, and is acted on by members or by code holding an API key. These four entities are the scaffolding the rest of the platform hangs off.

Organizations

An organization is the tenant root. Every other entity (projects, runtimes, tasks, members, keys) is scoped to exactly one organization, and tenant isolation is enforced everywhere.

Several things are configured at the org level rather than per project:

Integrations: connections such as GitHub.
Deployments: the data-plane deployments projects are linked to.

Members

A member is a user within an organization, carrying a role (such as owner, admin, or member) that governs what they can do. Members are synced from your identity provider.

Not every member is a person. A member has a type:

Type	Who it is
`business`	An operator: a person at your organization.
`agent`	A system agent member, created per org.
`customer`	A brokered end user, in B2B2C federation setups.

Projects

A project is the workspace most resources hang off. Recipes, runtimes, experiments, tasks, conversations, files, and bindings all belong to a project. An org can have many projects, for example one per product or team.

Each project is linked to a deployment and configures its own display-ID prefixes, so tasks read T-1, observations F-1, and so on.

API keys

An API key is the long-lived credential your server-side SDKs and automation use to run agents. A key belongs to a project, is scoped to one environment (development, staging, or production), and is shown in full exactly once at creation. It’s stored only as a hash, so it can’t be retrieved afterward. The CLI authenticates separately as a browser-approved member.

Capabilities

A public key carries the platform’s single runtimes capability:

Capability	Grants
`runtimes`	Read recipes and runtimes, manage experiments, open runners, and drive runtime-scoped tasks, files, shares, conversations, events, and metrics.

Telemetry write is always granted. Every API key can send telemetry (traces and logs) in addition to the runtimes capability. Telemetry is the baseline an instrumented agent always needs.

remotes is CLI-only. introspection login receives it from the server so introspection dev can attach a working tree; API keys and applications cannot request it.

A key also has a lifecycle (active, rotating, expired, revoked) and an optional expiry, so you can mint short-lived keys and rotate without downtime during a grace period.

Running agents for many end users

A single runtime can serve many end users at once. When you start a run, you attach an end-user identity to it, so the work is done on behalf of that specific user:


const runner = await client.runtimes("support-agent").run({
  identity: { user_id: "user_123" },
});

You can identify a user by user_id (a known, signed-in user), anonymous_id (an unidentified visitor), or conversation_id (continuity tied to one conversation). That identity follows the work through the platform: the conversations it produces, the files the agent reads and writes, and the agent’s memory are attributed to that user and kept separate, within the project, from every other user’s.

This is the building block for multi-tenant agents: you run one runtime, point each request at the right user, and each user gets a private, personal experience. For B2B2C, partners can federate their own end users in as members so the agent can act as the real user against the partner’s systems (see MCP & federation).

How it fits together


Organization              (tenant root: integrations, deployments)
├── Members               (users with roles: owner / admin / member)
└── Projects
    ├── API keys          (env-scoped runtimes capability, telemetry always on)
    ├── Recipes & runtimes
    ├── Tasks & conversations
    └── Files, bindings

Environments: the lane an API key is scoped to.
Runtimes: the deployable agents that live in a project.
API Reference: the REST surface keys authenticate against.
Security: how keys, encryption, and tenant isolation are handled.