# Provision mode

:::note
Provisioned containers run on the [Beta runtime](/guides/upgrading-containers/), Wire's next-generation container infrastructure.
:::

Connect mode asks each user to authorize your agent against their own Wire account. Provision mode skips the user entirely: your software creates containers in your own organization, on your own billing, and hands the endpoints to your agents. There is no consent screen and no end-user Wire account, because the containers belong to you.

Use it when Wire is infrastructure inside your product rather than something your users bring along. A support platform that keeps a container per customer, an internal orchestrator that gives each workflow its own memory, a multi-tenant agent product where you own the context layer end to end.

## How the two modes differ

|  | Connect | Provision |
|---|---|---|
| Who authorizes | Your user, in their browser | Nobody. You hold an org API key |
| Who owns the container | The user, in their org | Your organization |
| Who gets billed | The user's org | Your org |
| Container visibility | The user manages sharing | Everyone in your org can view; owners and admins manage |

An agent's mode is chosen at registration and can't change afterward.

## Set up

1. In the dashboard, open **Agents** from your account menu and create an agent with mode **Provision**.
2. Open the agent and generate an **org API key**. It is shown once, so store it in your secrets manager.

The key belongs to your organization, not to whoever generated it. It keeps working if that person leaves, and any org owner or admin can revoke it from the agent page.

## Create a container

<Tabs syncKey="lang">
  <TabItem label="TypeScript">
    ```typescript
    const wire = new WireProvisionClient({
      apiKey: process.env.WIRE_PROVISION_KEY,
    });

    const container = await wire.containers.create({ name: 'customer-1234' });
    // container.id, container.mcpUrl, container.apiUrl
    ```
  </TabItem>
  <TabItem label="REST">
    ```bash
    curl -X POST https://api.usewire.io/api/v1/agent/provision/containers \
      -H "Authorization: Bearer $WIRE_PROVISION_KEY" \
      -H "Content-Type: application/json" \
      -d '{"name": "customer-1234"}'
    ```
  </TabItem>
</Tabs>

`name` is optional; Wire generates one if you skip it. `description` is accepted too.

## Use the container

A provisioned container is a normal container. Your agent connects to `container.mcpUrl` the same way any agent connects to any Wire container, through the standard [MCP](/mcp/overview/) and API paths, using the org API key as the bearer token. The SDK's job ends at handing you the endpoint; how your agent consumes MCP is up to you and your agent.

All five [standard tools](/reference/tools/) work: `wire_explore`, `wire_navigate`, `wire_search`, `wire_write`, `wire_delete`.

An agent can only reach containers it provisioned itself. Another provision agent in the same org, or the same agent with a container it didn't create, gets denied.

## Manage the lifecycle

<Tabs syncKey="lang">
  <TabItem label="TypeScript">
    ```typescript
    // List the containers this agent has provisioned
    const containers = await wire.containers.list();

    // Rename one or update its description
    await wire.containers.update(container.id, {
      name: 'customer-1234 workspace',
    });

    // Delete one
    await wire.containers.delete(container.id);

    // Check a key is live and see who it acts as
    const { organizationId, agentId } = await wire.whoami();
    ```
  </TabItem>
  <TabItem label="REST">
    ```bash
    # List
    curl https://api.usewire.io/api/v1/agent/provision/containers \
      -H "Authorization: Bearer $WIRE_PROVISION_KEY"

    # Rename / update description
    curl -X PATCH https://api.usewire.io/api/v1/agent/provision/containers/GvryOTHdfQKkjCTW \
      -H "Authorization: Bearer $WIRE_PROVISION_KEY" \
      -H "Content-Type: application/json" \
      -d '{"name": "customer-1234 workspace"}'

    # Delete
    curl -X DELETE https://api.usewire.io/api/v1/agent/provision/containers/GvryOTHdfQKkjCTW \
      -H "Authorization: Bearer $WIRE_PROVISION_KEY"

    # Check a key is live
    curl https://api.usewire.io/api/v1/agent/provision/whoami \
      -H "Authorization: Bearer $WIRE_PROVISION_KEY"
    ```
  </TabItem>
</Tabs>

Deletes are soft. The container moves to your org's trash with a 14 day recovery window, same as deleting from the dashboard.

## What your team sees

Provisioned containers appear in the dashboard under a **Provisioned** tab in the container list, attributed to the agent that created them. Everyone in your org can open and inspect them. Org owners and admins can rename, pause, share, delete, and recover them like any other container. Members get read access.

## Billing

Everything a provision agent does bills your organization, with usage attributed to the agent so you can see which agent is doing what in your usage history. Storage and tool calls cost the same as any other container. See [pricing](https://usewire.io/pricing/) for the details.

## Revocation

Revoke a key from the agent's page and it stops authenticating within moments. Disabling the agent rejects all of its keys at once. The containers themselves are unaffected either way; they stay in your org, and your team keeps managing them from the dashboard.

Access follows the agent, not the key. An agent can hold several keys, so rotation is routine: issue a new key on the same agent, roll it out, revoke the old one. The new key reaches everything the agent has ever provisioned. A lost key is the same story, revoke it and issue a fresh one.