Skip to main content
An organization is the top-level account. Projects contain agents and configs, and control which shared resources they can use through grants. Each person has one organization role and, optionally, a role in individual projects.

Roles

Org roles — held by every member: Project roles — granted per member, per project: Operate agents means launching agents, sending inputs, resolving interactions, and stopping work. Manage project means creating and changing project resources, such as configs, profiles, and project-owned secrets. Manage access means assigning project roles and managing grants for shared resources such as models, machines, and pools. Organization owners and admins automatically have full access to every project, so they do not need separate project roles.

Organizations

Your first org is created during onboarding. Creation atomically sets up the org, a default project, and your owner membership.
The examples assume the client, $ORG/orgID, and $PROJ/projectID setup from the quickstart.
omnara whoami and GET /me (getCurrentUser in the SDK) list the organizations you belong to, and omnara config select switches the CLI’s default organization and project. Deleting an organization (omnara orgs delete {org-id}, DELETE /orgs/{orgID}, deleteOrganization) is owner-only and removes everything in it.

Projects

Project lists include only projects you can access. Each project includes access.can_read, can_operate, can_manage, and can_manage_access, so clients do not need to recreate the role matrix.

Invite people

Invitations are org-scoped and email-addressed. Invite as admin or member (owner is never grantable — ownership is established at org creation).
Organization admins can list pending invitations with omnara members invites list or GET /orgs/$ORG/invitations (listOrgInvitations), and revoke one with omnara members invites delete {invitation-id} or DELETE /orgs/$ORG/invitations/{invitationID} (deleteOrgInvitation).The invitee can list and accept invitations through their own account:
Accepting creates the organization membership. The invitation is then removed from the pending list.

Manage members

The response includes each member’s user ID, email, display name, and organization role. Use the user ID to change their role or remove them:
The last owner cannot be demoted or removed. Removing another member permanently deletes the secrets and skills they own in this organization. Removal fails if one of their secrets is still used by another resource.

Give members project access

Organization members need a project role to access a project. Owners and admins already have access to every project. Use operator for teammates who should run agents and handle approvals without changing configs, profiles, or project-owned secrets.
There is no CLI command for project roles yet. PUT creates or changes the member’s role:
GET …/projects (listMemberProjectAccess) lists the member’s explicit project roles. DELETE on the same project path (removeMemberProjectAccess) removes one.
Full schema and playground: Organizations and Projects · Members · Invitations.