# How agents act

An agent acts as an agent member, for one owner, and reaches only what that owner and its grants allow.

Every task has an **owner** (whose work it is) and may have an **actor** (the
agent member that did it). This page decides who owns your tasks and how far a
partner should trust the end user.

**You need:** an API key or application ([Credentials](/identity/credentials)).

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

## Choose the agent member a credential acts as

| Agent member | Reaches | Who can bind a credential to it |
| --- | --- | --- |
| **Member Agent** (default) | Only the work it owns or acts on, plus shares | Anyone who can create the credential |
| **Admin Agent** | Every conversation, task, and file in the project, only when no end user is named | Owners and admins |

API keys and applications pick one at creation or with `update`
(`--member-id`, `--agent-member-id`). Connectors always act as the Member Agent. Which
credential can steer whose task:
[When someone else approves](/patterns/approve-outside#4-tell-the-agent-what-happened).

### Create an Admin Agent key

An owner or admin finds the Admin Agent's ID, then creates the key:

```bash
introspection members list --query "[?name=='Admin Agent'] | [0].id" -o table
introspection api-keys create --member-id <admin-agent-id> --name approvals \
  -e production --capabilities runtimes --secret-file ./approvals-key.txt
```

The key reads and steers every task in the project. Keep it server side, use
one key per job, and revoke it when the job ends
(`introspection api-keys revoke --key <id>`).

## Run a task for an end user

Name the end user when you start the task; their work and memory are then
theirs. A credential that proves a person always wins over a named identity.

| Started by | Task owner | Memory |
| --- | --- | --- |
| API key or service account + `user_id` | `customer` member `user:<id>` | Yes |
| API key or service account + `anonymous_id` | `customer` member `anon:<id>` | Yes |
| An end user signed in through an [application](/identity/applications) | That end user | Yes |
| Slack channel or DM | One `customer` member per channel or DM | Yes |
| API key or service account + `conversation_id` only (backend jobs) | The agent member | Per conversation |
| API key or service account, no identity | The agent member, visible to every identity-less caller | None |
| Dashboard or CLI login (even with `--subject`) | The teammate | None |

Memory lives per owner and environment ([Files and memory](/observe/files)).

Per-user connections and self-scheduling, by starter

- **`user_id` / `anonymous_id`:** per-user connections (Pipedream only), authorized with `--user-id` or `--anonymous-id`.
- **Signed-in end user:** per-user connections from your app. The task can schedule its own follow-ups if the application's allowed scopes include `automations:read` and `automations:write`; no other starter can.
- **CLI login:** the teammate's own connections (`--subject user`), else shared.
- **No identity, `conversation_id` only, or Slack:** shared connection only.
- **`conversation_id` only:** never use it for browser visitors; every caller without a user identity can see the task.

## Decide how much a partner trusts the end user

| Trust level | JWT `type` | How the end user was established | Partner should |
| --- | --- | --- | --- |
| **Attribution** | `identity_attribution` | An API key or service account named them | Accept only if it trusts your backend to pick end users |
| **Assertion** | `identity_assertion` | Introspection verified them (federation, hosted login, native app) | Accept when it needs a proven end user |

How to send the JWT is in
[Tell a partner who the end user is](/identity/applications#tell-a-partner-who-the-end-user-is).

## What an agent can reach

Only its owner's work plus [shares](/identity/sharing), the hosts
[the sandbox](/build/sandbox#what-it-can-reach) allows, and the repositories
its `runtime.github` grant names ([Repositories](/ship/repositories)). It never
holds a secret ([Secrets](/build/sandbox#secrets)).

## Next

- [Serve many customers](/patterns/multi-tenant)
- [Sign-in for your users](/identity/applications)
- [Sharing & tags](/identity/sharing)

How agents act

An agent acts as an agent member, for one owner, and reaches only what that owner and its grants allow.

Every task has an owner (whose work it is) and may have an actor (the agent member that did it). This page decides who owns your tasks and how far a partner should trust the end user.

You need: an API key or application (Credentials).


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

Choose the agent member a credential acts as

Agent member	Reaches	Who can bind a credential to it
Member Agent (default)	Only the work it owns or acts on, plus shares	Anyone who can create the credential
Admin Agent	Every conversation, task, and file in the project, only when no end user is named	Owners and admins

API keys and applications pick one at creation or with update (--member-id, --agent-member-id). Connectors always act as the Member Agent. Which credential can steer whose task: When someone else approves.

Create an Admin Agent key

An owner or admin finds the Admin Agent’s ID, then creates the key:


introspection members list --query "[?name=='Admin Agent'] | [0].id" -o table
introspection api-keys create --member-id <admin-agent-id> --name approvals \
  -e production --capabilities runtimes --secret-file ./approvals-key.txt

The key reads and steers every task in the project. Keep it server side, use one key per job, and revoke it when the job ends (introspection api-keys revoke --key <id>).

Run a task for an end user

Name the end user when you start the task; their work and memory are then theirs. A credential that proves a person always wins over a named identity.

Started by	Task owner	Memory
API key or service account + `user_id`	`customer` member `user:<id>`	Yes
API key or service account + `anonymous_id`	`customer` member `anon:<id>`	Yes
An end user signed in through an application	That end user	Yes
Slack channel or DM	One `customer` member per channel or DM	Yes
API key or service account + `conversation_id` only (backend jobs)	The agent member	Per conversation
API key or service account, no identity	The agent member, visible to every identity-less caller	None
Dashboard or CLI login (even with `--subject`)	The teammate	None

Memory lives per owner and environment (Files and memory).

Per-user connections and self-scheduling, by starter

user_id / anonymous_id: per-user connections (Pipedream only), authorized with --user-id or --anonymous-id.
Signed-in end user: per-user connections from your app. The task can schedule its own follow-ups if the application’s allowed scopes include automations:read and automations:write; no other starter can.
CLI login: the teammate’s own connections (--subject user), else shared.
No identity, conversation_id only, or Slack: shared connection only.
conversation_id only: never use it for browser visitors; every caller without a user identity can see the task.

Decide how much a partner trusts the end user

Trust level	JWT `type`	How the end user was established	Partner should
Attribution	`identity_attribution`	An API key or service account named them	Accept only if it trusts your backend to pick end users
Assertion	`identity_assertion`	Introspection verified them (federation, hosted login, native app)	Accept when it needs a proven end user

How to send the JWT is in Tell a partner who the end user is.

What an agent can reach

Only its owner’s work plus shares, the hosts the sandbox allows, and the repositories its runtime.github grant names (Repositories). It never holds a secret (Secrets).