# Organizations and projects

An organization contains members and projects. Each project contains the resources, credentials, and production results for a set of agents.

## Organizations

An **organization** is the highest level account in Introspection. Its members,
projects, GitHub integration, and Data Plane deployments are separate from
every other organization.

Each member has an organization role such as `owner`, `admin`, or `member`. The
role controls what the member can change. Members can sign in through the
dashboard or the CLI.

### Adding a teammate

Organization membership gives a member access to every project in the
organization. You cannot invite a member to only one project.

An owner or admin can invite someone by email from
[organization settings](https://app.introspection.dev/organization/settings).
The person sending the invitation assigns the `owner`, `admin`, or `member`
role. Only an owner can assign the `owner` role. Introspection rejects an email
domain that another organization has already claimed.

To remove access, disable the member. Disabling a member revokes their access
and keeps their name on earlier work. You can enable the member again later.
Delete a member only if the account was created by mistake.

## Projects

An **Introspection project** groups resources and controls access within an
organization. Every recipe, runtime, binding, task, conversation, file, judge,
and experiment belongs to one project. An organization can use separate
projects for different products or teams. You can also use separate projects
when resources must remain isolated.

Do not create an Introspection project for every workspace in your product. A
full stack application normally uses one project and passes the signed in
product user as the [runner](/platform/glossary#runner) identity. Keep product
organization and workspace IDs as application metadata unless you need those
workspaces to use separate Introspection resources.

## Principals

A **principal** is a person or application that can act within a project. Each
principal has a different purpose:

| Principal | Role |
| --- | --- |
| **Member** | A person who uses the dashboard or CLI. |
| **Agent member** | The stable identity used by an API key or application when it runs an agent. The agent member also owns the local development overlay that connects development tasks to a specific local recipe commit. |
| **API key** | A credential for one project and environment. It is linked to an agent member and is intended for trusted backend automation. |
| **Application** | A service account or federated caller linked to an agent member. Use an application for a full stack application or a business that serves another business's customers. |
| **Customer member** | An end user of your product. Introspection creates a customer member when a runner provides a `user_id` or `anonymous_id`, or when federation proves the user's identity. The customer member owns the user's tasks, files, memory, and connections. The agent member records which agent acted for the user. |
| **End user identity** | The user, anonymous visitor, or conversation that owns the runner's saved work. Introspection resolves the identity to a customer member. |

See [Authentication and identity](/platform/authentication) to learn how each
caller signs in and how Introspection establishes an end user's identity.

## Which project a command acts on

Before a CLI command runs for a project, it selects the project in the following
order:

1. The project passed with `--project`.
2. The project set in `INTROSPECTION_PROJECT`.
3. The default project for the current login.

The `bindings` and `api-keys` commands are exceptions. See
[Administer the platform with the CLI](/sdk/cli/admin#projects-and---project)
for details.

## How it fits together

```text
Organization
├── Members
└── Projects
    ├── API keys and applications
    ├── Recipes, runtimes, and bindings
    ├── Tasks, conversations, and files
    └── Judges and experiments
```

## Related

- [Authentication and identity](/platform/authentication)
- [Runtimes](/platform/runtimes)
- [Security and data](/platform/security)

Organizations and projects

An organization contains members and projects. Each project contains the resources, credentials, and production results for a set of agents.

Organizations

An organization is the highest level account in Introspection. Its members, projects, GitHub integration, and Data Plane deployments are separate from every other organization.

Each member has an organization role such as owner, admin, or member. The role controls what the member can change. Members can sign in through the dashboard or the CLI.

Adding a teammate

Organization membership gives a member access to every project in the organization. You cannot invite a member to only one project.

An owner or admin can invite someone by email from organization settings . The person sending the invitation assigns the owner, admin, or member role. Only an owner can assign the owner role. Introspection rejects an email domain that another organization has already claimed.

To remove access, disable the member. Disabling a member revokes their access and keeps their name on earlier work. You can enable the member again later. Delete a member only if the account was created by mistake.

Projects

An Introspection project groups resources and controls access within an organization. Every recipe, runtime, binding, task, conversation, file, judge, and experiment belongs to one project. An organization can use separate projects for different products or teams. You can also use separate projects when resources must remain isolated.

Do not create an Introspection project for every workspace in your product. A full stack application normally uses one project and passes the signed in product user as the runner identity. Keep product organization and workspace IDs as application metadata unless you need those workspaces to use separate Introspection resources.

Principals

A principal is a person or application that can act within a project. Each principal has a different purpose:

Principal	Role
Member	A person who uses the dashboard or CLI.
Agent member	The stable identity used by an API key or application when it runs an agent. The agent member also owns the local development overlay that connects development tasks to a specific local recipe commit.
API key	A credential for one project and environment. It is linked to an agent member and is intended for trusted backend automation.
Application	A service account or federated caller linked to an agent member. Use an application for a full stack application or a business that serves another business’s customers.
Customer member	An end user of your product. Introspection creates a customer member when a runner provides a `user_id` or `anonymous_id`, or when federation proves the user’s identity. The customer member owns the user’s tasks, files, memory, and connections. The agent member records which agent acted for the user.
End user identity	The user, anonymous visitor, or conversation that owns the runner’s saved work. Introspection resolves the identity to a customer member.

See Authentication and identity to learn how each caller signs in and how Introspection establishes an end user’s identity.

Which project a command acts on

Before a CLI command runs for a project, it selects the project in the following order:

The project passed with --project.
The project set in INTROSPECTION_PROJECT.
The default project for the current login.

The bindings and api-keys commands are exceptions. See Administer the platform with the CLI for details.

How it fits together


Organization
├── Members
└── Projects
    ├── API keys and applications
    ├── Recipes, runtimes, and bindings
    ├── Tasks, conversations, and files
    └── Judges and experiments