# Admin

Manage the credentials, people, repositories, connectors, and shared artifacts around your agents.

These commands use your [login](/reference/cli#log-in) and your member role.
The model behind them is [Identity & access](/identity). `files delete` with
several ids and `automations --runtime` need CLI 0.52.0 or later.

## Projects

Projects are created in the dashboard; there is no `projects` command. A
project-scoped command uses `--project`, else `INTROSPECTION_PROJECT`, else the
login project. `bindings`, `api-keys`, `automations`, and most `connectors` commands always
use the login project and ignore the other two (a stderr note warns you), so
log in to the intended project first. `members` acts on the organization.

## API keys

```text
introspection api-keys create --secret-file <path> [--name <name>] [--environment <env>] [--capabilities <list>] [--member-id <id>] [--expires-at <rfc3339>]
introspection api-keys list [--expiring]
introspection api-keys update --key <key-id> [--name <name>] [--member-id <id>]
introspection api-keys acknowledge --key <key-id>
introspection api-keys revoke --key <key-id> [--expires-in <seconds>]
```

| Flag | Default | Effect |
| --- | --- | --- |
| `--secret-file` | required | New file (mode `0600`) for the one-time secret; never overwritten, never printed. |
| `--environment` | `production` | `development`, `staging`, or `production`. |
| `--capabilities` | `runtimes` | The complete set: `runtimes`, `evals`, or both. Only `evals` carries file delete. |
| `--member-id` | system agent | Agent member the key acts as. |
| `--expires-at` | none | RFC 3339 expiry. |

If the file was written but acknowledgement failed, run `acknowledge`.
`revoke --expires-in` revokes after a grace period.

## Applications

```text
introspection applications create --type <service-account|jwks|spa|native> --name <name> [--environment <env>] [--redirect-uri <uri>]... [--allowed-origin <origin>]... [--allowed-scope <scope>]... [--agent-member-id <id>] [--issuer <url>]
introspection applications list | get <id> | delete <id>
introspection applications update <id> [--name ...] [--redirect-uri ... | --clear-redirect-uris] [--allowed-origin ... | --clear-allowed-origins] [--allowed-scope ... | --clear-allowed-scopes] [--agent-member-id <id>]
introspection applications secrets create|list|revoke --app <id> [--secret <id>] [--expires-in <seconds>]
introspection applications idps create|list|delete --app <id> [--idp <id>] [--issuer <url>] [--provider <name> --client-id <id>] [--audience-client-id <aud>] [--scope <scope>]... [--wait]
introspection applications keys create|list|delete --app <id> [--key <id>]
```

| `--type` | Use it for |
| --- | --- |
| `service-account` | A backend that vouches for its users with a client secret (`secrets create`; shown once). |
| `jwks` | A backend that exchanges your identity provider's token (`--issuer` or `idps create`). |
| `spa` | A browser app with hosted sign-in; needs `--redirect-uri`; optional brokered IdP via `idps create --issuer --client-id`. |
| `native` | A mobile or desktop app with email-code sign-in. |

`jwks`, `spa`, and `native` need a Max or Enterprise plan. `--environment` is
fixed at creation. Pass a brokered provider's secret through
`INTROSPECTION_IDP_CLIENT_SECRET`. Choosing a type:
[Sign-in for your users](/identity/applications).

```bash
introspection applications create --type spa --name web \
  --redirect-uri https://app.example.com/callback --allowed-origin https://app.example.com
```

## Members

```text
introspection members list [--external-user-id <id>]... [--limit <n>]
introspection members get <member>
introspection members create [@FILE] [--member-type business|customer] [--email <email>] [--name <name>] [--role <role>] [--external-user-id <user:id|anon:id>] [--policy-attributes <json|@FILE>]
introspection members update <member> [@FILE] [--name <name>] [--role <role>] [--policy-attributes <json|@FILE>]
```

`<member>` is a member id or an external user id such as `user:sam@acme.example`.
A business member is invited by `--email` and a full `--name`; a customer
member is keyed by `--external-user-id` and is the same member a runner
identity with that id reaches, so you can prepare it before its first session.
`create` and `update` also take the whole request as JSON or YAML (`@PATH`, or
`@-` for stdin) in the API's field names; a flag beside it overrides that field.

`--policy-attributes` (gated: contact us before relying on it) sets the Cedar
attributes a recipe's `policies/` read about this member, as a JSON object; on
`update` it replaces them.

```bash
introspection members create --member-type customer \
  --external-user-id user:sam@acme.example \
  --policy-attributes '{"level": 5}'
```

`create` and `update` need an owner or admin.

## Repositories

```text
introspection repositories list
introspection repositories add <owner/name | github-url> [--integration-id <id>]
introspection repositories remove <owner/name | id>
introspection repositories contents <repository> [<path>] [--ref <ref>] [--out <path>]
introspection repositories commits <repository> [--path <path>] [--ref <ref>] [--limit <n>]
introspection repositories commit <repository> <sha>
```

Registering lets recipes grant a repository; it clones and grants nothing by
itself ([Repositories](/ship/repositories)). `runtimes create` registers
the recipe's own repository. `add` and `remove` need a member login; `remove`
returns `409 repository_in_use` while a recipe is pinned in it.

## Connectors

```text
introspection connectors list | get <connector> | delete <connector>
introspection connectors create [@FILE] --name <name> --provider <slug> --auth-mode <mode> [--environment <env>] [--scope <s>]... [--api-host <host>]... [--client-id <id>] [--client-secret-from-env <NAME> | --client-secret-from-file <path|-> | --client-secret-from-stdin] [--issuer <url>] [--metadata KEY=VALUE]...
introspection connectors update <connector> [@FILE] [--name ...] [--scope ...] [--api-host ...] [--status ...] [--webhook-url ...] [--client-secret-from-env ...] [--signing-secret-from-env ...]
introspection connectors authorize <connector> [flags]
introspection connectors authorize-url <connector> [flags] [--return-url <url>]
introspection connectors describe <connector> [--connection <id>]
introspection connectors test <connector> --connection <id>
introspection connectors connections list|get|create|token|revoke --connector <connector>
```

`<connector>` is an id or slug. `authorize`, `authorize-url`, `describe`, and
`test` accept `--project`; the rest use the login project.

| `--auth-mode` | Token source |
| --- | --- |
| `static` | A token you store with `connectors connections create`; sent as a bearer. |
| `oauth-stored` | Three-legged OAuth; stored per connection and refreshed. |
| `client-credentials` | An aggregator such as Pipedream: a short-lived token per session. |
| `identity-assertion` | The connector's application signs a JWT for the task's member. |

- `create` is idempotent on the slug (`--slug`, else derived from `--name`). `--issuer`
  discovers OAuth endpoints, or pass `--authorization-endpoint` and
  `--token-endpoint`. The CLI does not apply dashboard provider templates.
- `update` cannot change provider, slug, environment, auth mode, client id, or
  OAuth endpoints. Omitted secrets are unchanged; secrets are never returned.
- Pass the client and signing secrets with `-from-env`, `-from-file`, or
  `-from-stdin` (CLI 0.54.0 or later). The plain `--client-secret` and
  `--signing-secret` still work but leave the value in shell history and `ps`.
- A provider app that sends webhooks is registered in two passes: create the
  connector, register `{control-plane-host}/v1/webhooks/{provider}/{connector-id}`
  with the provider, then `update --webhook-url --client-secret-from-env --signing-secret-from-env`.
  Slack: [Put your agent in Slack](/patterns/slack).
- Pipedream: `--provider pipedream --auth-mode client-credentials
  --metadata provider_workspace_id=<pipedream-project-id> --client-id --client-secret-from-env`.
  Authorizing needs `--runtime` and `--app <slug>`; the callback writes the MCP
  endpoint itself, so skip `bindings mcp connect`.

| Authorize flag | Effect |
| --- | --- |
| `-r, --runtime <runtime>` | The runtime that replies. Required for Slack (else `422`). |
| `--app <slug>`, `--allow-progressive-scopes` | Pipedream only. |
| `--subject app\|user` | `app` (default): organization-owned, the fallback for every task. `user`: your own member. Not the same as `tasks create --subject`, which names an end user. |
| `--user-id`, `--anonymous-id` | Record your end user as the grant's author (a label; with Pipedream, the subject). May `409` at the member limit. |
| `--expires-in <duration>` | Link lifetime (`30m`, `1h`, `1d`; 60 s to 24 h); default ten minutes. Pipedream app links are capped at 4 hours. |

`authorize` opens a browser and waits; `authorize-url` returns
`authorize_url` for someone else to open, one fresh single-use link per call.
`describe` prints a Pi MCP declaration; with `--connection` (and `test`) it runs
MCP discovery, which needs exactly one MCP endpoint whose server id is the
connector slug. `connections create @FILE` stores a token you already have
(`access_token`, optional `refresh_token`, `token_expires_at`,
`scopes_granted`, `subject_type`); it is the `app` connection unless
`subject_type: user` binds it to your member, one per subject, and is refused
for Slack and Pipedream. A task uses its owner's own connection first, else the
`app` connection. `connections token` can return a live credential; prefer
`test`.

## Files

```text
introspection files list [--filter KEY=VALUE]... [--limit <n>] [--next <cursor>]
introspection files get <file-id>
introspection files content <file-id> [--out <path>]
introspection files create --name <name> --content-file <path|-> [--mime-type <type>] [--metadata '<json>'] [--ttl-seconds <n>]
introspection files upload --file <path> [--name <name>] [--file-type <type>] [--metadata '<json>'] [--ttl-seconds <n>]
introspection files update <file-id> [--name <name>] [--metadata '<json>']
introspection files delete <file-id>... [--yes]
introspection files versions list|get|create <file-id> ...
```

`upload` is the only way to send binary. Writing an existing name adds a
version; there is no restore. `--ttl-seconds` makes a file expire. `delete`
takes several ids, asks once, removes every version of each, and stops at
the first failure, naming the files already deleted. See [Files](/observe/files).

### Filter files

| `--filter` key | Values |
| --- | --- |
| `task_id`, `conversation_id` | One task or conversation. |
| `category` | `output`, `memory`, or `file`. |
| `file_type` | `upload`, `filesystem`, `other` (no `--file-type` flag on `list`). |
| `name`, `name_contains` | Exact name or substring. |
| `tag`, `metadata` | `tag=key:value`, `metadata=key:value`. |
| `content_format`, `versioned`, `storage_path` | Format and storage. |
| `member_id` | One owner's files. Privileged credentials only: an owner or admin login, or an Admin Agent key. |
| `created_before`, `created_after`, `updated_before`, `updated_after` | ISO timestamps. |

```bash
introspection files list --filter task_id=<task-id> --filter category=output -o table
```

Memory files are named `memory/<environment>/member:<member-uuid>/...`, or
`conv:<conversation-id>/` for `conversation_id` tasks. To delete one owner's
memory, list the ids (follow `--next` for more), then pass them to `delete`
([Memory and deleting data](/patterns/memory-and-data)):

```bash
introspection files list --filter category=memory \
  --filter name_contains=member:<member-uuid> --query "[].id" -o table
introspection files delete --yes <file-id-1> <file-id-2>
```

## Shares

```text
introspection shares list [--filter KEY=VALUE]
introspection shares get <share-id>
introspection shares create --resource-type <file|conversation|issue> --resource-id <id> [--member <member-id>] [--tag <tag>] [--visible-from <rfc3339>]
introspection shares update <share-id> (--visible-from <rfc3339> | --clear-visible-from)
introspection shares delete <share-id>
```

Who a share admits and the visibility rules: [Sharing](/identity/sharing).
`list` filters on `resource_type`, `resource_id`, `granted_member_id`,
`granted_tag`, `created_by_me`, and `granted_to_me`.

## Tags

```text
introspection tags list --kind <access|annotation> [--search <text>]
introspection tags get|delete <access|annotation> <name>
introspection tags create|update <access|annotation> <name> [--color <hex>] [--description <text>]
```

Access tags group tasks and members and are what tag shares target. Annotation
tags are reviewer labels and need `--color`.

## Automations

These commands need a credential with the automations scopes. No CLI login or
API key carries them, so with either they return 403. Owners and admins create
automations on the dashboard's project **Automations** page
([Run on a schedule](/patterns/schedule)), or pass `--token` with an
application or runner token that carries the scopes.

```text
introspection automations list [--kind observation_synthesis|observation_clustering] [--enabled true|false] [--scheduled true|false]
introspection automations get <id> | delete <id> | trigger <id>
introspection automations create --name <name> (-r <runtime-slug> | --runtime-group <group-id>) --prompt <text> [--task <task-id>] (--cron <expr>... [--timezone <tz>] | --at <rfc3339>) [--disabled]
introspection automations update <id> [-r <runtime-slug> | --runtime-group <group-id>] [--prompt ...] [--task ...] [--cron ...] [--timezone ...] [--at ...] [--enable | --disable]
```

```bash
introspection automations create --name nightly --runtime <runtime-slug> \
  --prompt 'Summarize yesterday' --cron '0 6 * * *' --timezone Europe/London
```

`-r, --runtime` takes a runtime slug or group id and looks up the group for
you; `--runtime-group` takes the group id itself.

`--cron` (repeatable) makes a recurring automation, read in `--timezone`
(UTC by default); `--at` makes a one-off; neither makes one that runs only on
`trigger`. With `--task`, each firing posts the prompt into that existing task
instead of creating a new one. A firing is skipped while the task awaits the
user. A project's default platform automations can be disabled but not
deleted.

Owners and admins create schedules on the dashboard's **Automations** page,
shown when Operator is enabled for the organization
([Run your agent on a schedule](/patterns/schedule)); an agent schedules its
own follow-ups from its sandbox
([Let your agent schedule its own follow-ups](/patterns/agent-follow-ups)).

## Next

- [Identity & access](/identity): who acts and who sees what.
- [Deploy & operate](/reference/cli/deploy): bindings, runtimes, and tasks.

Admin

Manage the credentials, people, repositories, connectors, and shared artifacts around your agents.

These commands use your login and your member role. The model behind them is Identity & access. files delete with several ids and automations --runtime need CLI 0.52.0 or later.

Projects

Projects are created in the dashboard; there is no projects command. A project-scoped command uses --project, else INTROSPECTION_PROJECT, else the login project. bindings, api-keys, automations, and most connectors commands always use the login project and ignore the other two (a stderr note warns you), so log in to the intended project first. members acts on the organization.

API keys


introspection api-keys create --secret-file <path> [--name <name>] [--environment <env>] [--capabilities <list>] [--member-id <id>] [--expires-at <rfc3339>]
introspection api-keys list [--expiring]
introspection api-keys update --key <key-id> [--name <name>] [--member-id <id>]
introspection api-keys acknowledge --key <key-id>
introspection api-keys revoke --key <key-id> [--expires-in <seconds>]

Flag	Default	Effect
`--secret-file`	required	New file (mode `0600`) for the one-time secret; never overwritten, never printed.
`--environment`	`production`	`development`, `staging`, or `production`.
`--capabilities`	`runtimes`	The complete set: `runtimes`, `evals`, or both. Only `evals` carries file delete.
`--member-id`	system agent	Agent member the key acts as.
`--expires-at`	none	RFC 3339 expiry.

If the file was written but acknowledgement failed, run acknowledge. revoke --expires-in revokes after a grace period.

Applications


introspection applications create --type <service-account|jwks|spa|native> --name <name> [--environment <env>] [--redirect-uri <uri>]... [--allowed-origin <origin>]... [--allowed-scope <scope>]... [--agent-member-id <id>] [--issuer <url>]
introspection applications list | get <id> | delete <id>
introspection applications update <id> [--name ...] [--redirect-uri ... | --clear-redirect-uris] [--allowed-origin ... | --clear-allowed-origins] [--allowed-scope ... | --clear-allowed-scopes] [--agent-member-id <id>]
introspection applications secrets create|list|revoke --app <id> [--secret <id>] [--expires-in <seconds>]
introspection applications idps create|list|delete --app <id> [--idp <id>] [--issuer <url>] [--provider <name> --client-id <id>] [--audience-client-id <aud>] [--scope <scope>]... [--wait]
introspection applications keys create|list|delete --app <id> [--key <id>]

`--type`	Use it for
`service-account`	A backend that vouches for its users with a client secret (`secrets create`; shown once).
`jwks`	A backend that exchanges your identity provider’s token (`--issuer` or `idps create`).
`spa`	A browser app with hosted sign-in; needs `--redirect-uri`; optional brokered IdP via `idps create --issuer --client-id`.
`native`	A mobile or desktop app with email-code sign-in.

jwks, spa, and native need a Max or Enterprise plan. --environment is fixed at creation. Pass a brokered provider’s secret through INTROSPECTION_IDP_CLIENT_SECRET. Choosing a type: Sign-in for your users.


introspection applications create --type spa --name web \
  --redirect-uri https://app.example.com/callback --allowed-origin https://app.example.com

Members


introspection members list [--external-user-id <id>]... [--limit <n>]
introspection members get <member>
introspection members create [@FILE] [--member-type business|customer] [--email <email>] [--name <name>] [--role <role>] [--external-user-id <user:id|anon:id>] [--policy-attributes <json|@FILE>]
introspection members update <member> [@FILE] [--name <name>] [--role <role>] [--policy-attributes <json|@FILE>]

<member> is a member id or an external user id such as user:sam@acme.example. A business member is invited by --email and a full --name; a customer member is keyed by --external-user-id and is the same member a runner identity with that id reaches, so you can prepare it before its first session. create and update also take the whole request as JSON or YAML (@PATH, or @- for stdin) in the API’s field names; a flag beside it overrides that field.

--policy-attributes (gated: contact us before relying on it) sets the Cedar attributes a recipe’s policies/ read about this member, as a JSON object; on update it replaces them.


introspection members create --member-type customer \
  --external-user-id user:sam@acme.example \
  --policy-attributes '{"level": 5}'

create and update need an owner or admin.

Repositories


introspection repositories list
introspection repositories add <owner/name | github-url> [--integration-id <id>]
introspection repositories remove <owner/name | id>
introspection repositories contents <repository> [<path>] [--ref <ref>] [--out <path>]
introspection repositories commits <repository> [--path <path>] [--ref <ref>] [--limit <n>]
introspection repositories commit <repository> <sha>

Registering lets recipes grant a repository; it clones and grants nothing by itself (Repositories). runtimes create registers the recipe’s own repository. add and remove need a member login; remove returns 409 repository_in_use while a recipe is pinned in it.

Connectors


introspection connectors list | get <connector> | delete <connector>
introspection connectors create [@FILE] --name <name> --provider <slug> --auth-mode <mode> [--environment <env>] [--scope <s>]... [--api-host <host>]... [--client-id <id>] [--client-secret-from-env <NAME> | --client-secret-from-file <path|-> | --client-secret-from-stdin] [--issuer <url>] [--metadata KEY=VALUE]...
introspection connectors update <connector> [@FILE] [--name ...] [--scope ...] [--api-host ...] [--status ...] [--webhook-url ...] [--client-secret-from-env ...] [--signing-secret-from-env ...]
introspection connectors authorize <connector> [flags]
introspection connectors authorize-url <connector> [flags] [--return-url <url>]
introspection connectors describe <connector> [--connection <id>]
introspection connectors test <connector> --connection <id>
introspection connectors connections list|get|create|token|revoke --connector <connector>

<connector> is an id or slug. authorize, authorize-url, describe, and test accept --project; the rest use the login project.

`--auth-mode`	Token source
`static`	A token you store with `connectors connections create`; sent as a bearer.
`oauth-stored`	Three-legged OAuth; stored per connection and refreshed.
`client-credentials`	An aggregator such as Pipedream: a short-lived token per session.
`identity-assertion`	The connector’s application signs a JWT for the task’s member.

create is idempotent on the slug (--slug, else derived from --name). --issuer discovers OAuth endpoints, or pass --authorization-endpoint and --token-endpoint. The CLI does not apply dashboard provider templates.
update cannot change provider, slug, environment, auth mode, client id, or OAuth endpoints. Omitted secrets are unchanged; secrets are never returned.
Pass the client and signing secrets with -from-env, -from-file, or -from-stdin (CLI 0.54.0 or later). The plain --client-secret and --signing-secret still work but leave the value in shell history and ps.
A provider app that sends webhooks is registered in two passes: create the connector, register {control-plane-host}/v1/webhooks/{provider}/{connector-id} with the provider, then update --webhook-url --client-secret-from-env --signing-secret-from-env. Slack: Put your agent in Slack.
Pipedream: --provider pipedream --auth-mode client-credentials --metadata provider_workspace_id=<pipedream-project-id> --client-id --client-secret-from-env. Authorizing needs --runtime and --app <slug>; the callback writes the MCP endpoint itself, so skip bindings mcp connect.

Authorize flag	Effect
`-r, --runtime <runtime>`	The runtime that replies. Required for Slack (else `422`).
`--app <slug>`, `--allow-progressive-scopes`	Pipedream only.
`--subject app\|user`	`app` (default): organization-owned, the fallback for every task. `user`: your own member. Not the same as `tasks create --subject`, which names an end user.
`--user-id`, `--anonymous-id`	Record your end user as the grant’s author (a label; with Pipedream, the subject). May `409` at the member limit.
`--expires-in <duration>`	Link lifetime (`30m`, `1h`, `1d`; 60 s to 24 h); default ten minutes. Pipedream app links are capped at 4 hours.

authorize opens a browser and waits; authorize-url returns authorize_url for someone else to open, one fresh single-use link per call. describe prints a Pi MCP declaration; with --connection (and test) it runs MCP discovery, which needs exactly one MCP endpoint whose server id is the connector slug. connections create @FILE stores a token you already have (access_token, optional refresh_token, token_expires_at, scopes_granted, subject_type); it is the app connection unless subject_type: user binds it to your member, one per subject, and is refused for Slack and Pipedream. A task uses its owner’s own connection first, else the app connection. connections token can return a live credential; prefer test.

Files


introspection files list [--filter KEY=VALUE]... [--limit <n>] [--next <cursor>]
introspection files get <file-id>
introspection files content <file-id> [--out <path>]
introspection files create --name <name> --content-file <path|-> [--mime-type <type>] [--metadata '<json>'] [--ttl-seconds <n>]
introspection files upload --file <path> [--name <name>] [--file-type <type>] [--metadata '<json>'] [--ttl-seconds <n>]
introspection files update <file-id> [--name <name>] [--metadata '<json>']
introspection files delete <file-id>... [--yes]
introspection files versions list|get|create <file-id> ...

upload is the only way to send binary. Writing an existing name adds a version; there is no restore. --ttl-seconds makes a file expire. delete takes several ids, asks once, removes every version of each, and stops at the first failure, naming the files already deleted. See Files.

Filter files

`--filter` key	Values
`task_id`, `conversation_id`	One task or conversation.
`category`	`output`, `memory`, or `file`.
`file_type`	`upload`, `filesystem`, `other` (no `--file-type` flag on `list`).
`name`, `name_contains`	Exact name or substring.
`tag`, `metadata`	`tag=key:value`, `metadata=key:value`.
`content_format`, `versioned`, `storage_path`	Format and storage.
`member_id`	One owner’s files. Privileged credentials only: an owner or admin login, or an Admin Agent key.
`created_before`, `created_after`, `updated_before`, `updated_after`	ISO timestamps.


introspection files list --filter task_id=<task-id> --filter category=output -o table

Memory files are named memory/<environment>/member:<member-uuid>/..., or conv:<conversation-id>/ for conversation_id tasks. To delete one owner’s memory, list the ids (follow --next for more), then pass them to delete (Memory and deleting data):


introspection files list --filter category=memory \
  --filter name_contains=member:<member-uuid> --query "[].id" -o table
introspection files delete --yes <file-id-1> <file-id-2>


introspection shares list [--filter KEY=VALUE]
introspection shares get <share-id>
introspection shares create --resource-type <file|conversation|issue> --resource-id <id> [--member <member-id>] [--tag <tag>] [--visible-from <rfc3339>]
introspection shares update <share-id> (--visible-from <rfc3339> | --clear-visible-from)
introspection shares delete <share-id>

Who a share admits and the visibility rules: Sharing. list filters on resource_type, resource_id, granted_member_id, granted_tag, created_by_me, and granted_to_me.

Automations

These commands need a credential with the automations scopes. No CLI login or API key carries them, so with either they return 403. Owners and admins create automations on the dashboard’s project Automations page (Run on a schedule), or pass --token with an application or runner token that carries the scopes.


introspection automations list [--kind observation_synthesis|observation_clustering] [--enabled true|false] [--scheduled true|false]
introspection automations get <id> | delete <id> | trigger <id>
introspection automations create --name <name> (-r <runtime-slug> | --runtime-group <group-id>) --prompt <text> [--task <task-id>] (--cron <expr>... [--timezone <tz>] | --at <rfc3339>) [--disabled]
introspection automations update <id> [-r <runtime-slug> | --runtime-group <group-id>] [--prompt ...] [--task ...] [--cron ...] [--timezone ...] [--at ...] [--enable | --disable]


introspection automations create --name nightly --runtime <runtime-slug> \
  --prompt 'Summarize yesterday' --cron '0 6 * * *' --timezone Europe/London

-r, --runtime takes a runtime slug or group id and looks up the group for you; --runtime-group takes the group id itself.

--cron (repeatable) makes a recurring automation, read in --timezone (UTC by default); --at makes a one-off; neither makes one that runs only on trigger. With --task, each firing posts the prompt into that existing task instead of creating a new one. A firing is skipped while the task awaits the user. A project’s default platform automations can be disabled but not deleted.

Owners and admins create schedules on the dashboard’s Automations page, shown when Operator is enabled for the organization (Run your agent on a schedule); an agent schedules its own follow-ups from its sandbox (Let your agent schedule its own follow-ups).

Identity & access: who acts and who sees what.
Deploy & operate: bindings, runtimes, and tasks.