> ## Documentation Index
> Fetch the complete documentation index at: https://docs.agent-loadout.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Managing Your Organization and Members – Agent Loadout

> Learn how Agent Loadout's org ownership model works, how to add team members, and how to use org keys to provision agents programmatically.

Your organization is the top-level container for everything in Agent Loadout — agents, inboxes, credential vaults, tokens, machines, and audit history. Resources belong to the organization, not to any individual member, so your team retains full access to every agent even as people join or leave.

## Ownership Model

Agents, inboxes, tokens, and history are all org-level resources. When a member creates an agent or issues a token, those objects are owned by the organization. Any member with the right permissions can view, modify, or revoke them from the dashboard, independent of who originally created them.

This design means:

* Revoking a token or reassigning an agent does not require action from the original creator.
* Audit history and inbox mail are retained by the org, not by individual accounts.
* Billing, spend caps, and usage limits are managed at the org level.

## Team Members

<CardGroup cols={2}>
  <Card title="Free Sandbox" icon="seedling">
    **1 team member** — the account owner only.
  </Card>

  <Card title="Pro" icon="rocket">
    **Unlimited team members** — no per-seat charge for people.
  </Card>
</CardGroup>

Members can view the dashboard, manage agents and their tokens, and handle mail that has been quarantined by the mail screening system. Each member keeps their own **unread state** independently from the agent — marking a conversation read as a member does not affect the agent's unread count, and vice versa.

<Note>
  Quarantined messages are held for member review. Only members (not agents) can release or permanently reject quarantined mail.
</Note>

## Organization Keys

Organization keys are a special credential type issued from **Settings → Organization keys**. Unlike agent tokens, org keys can create new agents and issue tokens on their behalf — making them the right tool for programmatic onboarding workflows and multi-tenant setups.

<Warning>
  Treat org keys like root credentials. Store them in a secret manager, not in source code or environment files that are committed to version control.
</Warning>

### Create an Agent with an Inbox

Use an org key to provision a new agent and its inbox in a single API call:

```bash title="Create agent + inbox" theme={null}
curl -s -X POST https://agent-loadout.com/api/v1/inboxes \
  -H "Authorization: Bearer $AGENT_LOADOUT_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "username": "support",
    "display_name": "Support",
    "metadata": {"tenant": "acme"}
  }'
```

The response includes the new agent's ID and its assigned inbox address.

### Issue a Token for the Agent

Once the agent exists, issue a scoped token for the MCP client or REST consumer that will drive it:

```bash title="Issue an agent token" theme={null}
curl -s -X POST https://agent-loadout.com/api/v1/agents/<AGENT_ID>/tokens \
  -H "Authorization: Bearer $AGENT_LOADOUT_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "claude-code",
    "capabilities": ["email:read", "email:send"]
  }'
```

Grant only the capabilities the agent actually needs. Available scopes are:

| Scope            | What it allows                                     |
| ---------------- | -------------------------------------------------- |
| `email:read`     | List and read messages                             |
| `email:send`     | Send, reply, forward, and manage the mailbox       |
| `vault:metadata` | List the agent's accounts without values           |
| `vault:use`      | Read agent-readable credentials and one-time codes |
| `vault:write`    | Create and update the agent's own credentials      |
| `wallet:read`    | View cards, rules, and activity                    |
| `wallet:pay`     | Reveal card details to pay                         |
| `compute:read`   | List machines and read files on them               |
| `compute:run`    | Start, stop, resume machines and run commands      |
| `compute:admin`  | Delete machines and open their desktop             |

<Tip>
  Tokens issued via the API appear under the agent's **Tokens** tab in the dashboard and can be revoked there at any time — including through the standard OAuth revocation endpoint.
</Tip>

## Spending and Pay-as-You-Go

Pay-as-you-go overages are **disabled by default**. An owner must explicitly set a spend cap in **Billing & usage** before any overage charges can accumulate. Without a spend cap, sending and mailbox imports pause when the org reaches its plan limits.

## Audit History

All agent activity is logged at the organization level.

| Plan                          | Visible history |
| ----------------------------- | --------------- |
| Pro                           | 30 days         |
| Pro + Extended History add-on | 365 days        |

History is readable by any member in **Billing & usage → Activity**. After a paid subscription ends, a 90-day read and export window applies to historical data.