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

> ## Agent Instructions
> Company name is Akhara AI (never Rubric AI). Keep lowercase rubric/rubrics only when meaning grading criteria.
> Expert Review (docs path talent/) is enterprise BYO experts for audit and review: invite customer specialists; do not pitch Akhara recruiting or a public expert career portal. RLHF and domain writing are secondary work types.
> Prefer concrete API examples against public hosts: Environments eval API https://agi.akhara.ai, Control plane PDP https://api.akhara.dev, Evaluation https://app.akhara.ai / https://api.akhara.ai, Expert Review portal https://talent.akhara.ai.
> Do not invent a public hostname for private orchestrators or env API internals.
> Do not confuse control-plane latches with Environments confirmation latches.
> Environments SDK/API examples: curl against https://agi.akhara.ai. Evaluation SDK: from akhara import Akhara and AKHARA_API_KEY.
> Start with /llms.txt for the docs index and OpenAPI links; fetch individual pages as .md exports.

# Environment provisioning

> Sandboxed worlds (simulated services, seed data, and transport) for deterministic, replayable runs.

An **environment** is the sandboxed world a task runs against: the simulated
services, the seed data, and the transport the agent and user use. Environments
give you deterministic, replayable runs without touching production systems.

## Environment shape

```json theme={null}
{
  "id": "env_support_desk",
  "name": "Support Desk",
  "port": 8931,
  "service": "support-sim",
  "userTransport": "android-emulator",
  "cats": ["support"],
  "tags": ["pii", "refunds"],
  "version": "1.2"
}
```

Installed env ids are derived from the hub id with dashes → underscores
(`support-desk` → `env_support_desk`).

## Provision one

<CodeGroup>
  ```bash CLI theme={null}
  akhara init my-support-env --template support-desk
  cd my-support-env
  akhara deploy        # boots the sandbox, prints the env_id + port
  ```

  ```http Per-agent theme={null}
  POST /api/agents/support-ai/provision
  ```
</CodeGroup>

## The provisioning flow

Provisioning runs a fixed five-step boundary setup, surfaced live in the console
diagram (**Simulated Services → Agent → User transport**):

```mermaid theme={null}
flowchart LR
    I["1 · image<br/>resolve env image"] --> S["2 · sandbox<br/>start boundary"]
    S --> D["3 · seed<br/>seed sample data"]
    D --> A["4 · agent<br/>wire profile + GATEWAY"]
    A --> R["5 · ready<br/>open for runs"]
```

| Step | Key       | What happens                                     |
| ---- | --------- | ------------------------------------------------ |
| 1    | `image`   | Resolve the environment image.                   |
| 2    | `sandbox` | Start the isolated sandbox boundary.             |
| 3    | `seed`    | Seed sample data (accounts, orders, catalog, …). |
| 4    | `agent`   | Wire the agent profile and inject `env.GATEWAY`. |
| 5    | `ready`   | Environment ready for runs.                      |

<Info>
  Step 4 injects a `GATEWAY` env var (e.g. `https://api.akhara.dev`) so the PEP
  inside the sandbox reaches the PDP, enforcement stays in-path even in an
  isolated boundary. Created environments persist to
  `akhara.created-environments.v1`.
</Info>

## The boundary

The agent's runtime `boundary` (for example `android-emulator`) determines how
the user transport and simulated services are wired:

```mermaid theme={null}
flowchart TB
    subgraph Boundary["Sandbox boundary"]
        SVC["Simulated services<br/>support-sim :8931"]
        AGENT["Agent profile"]
        SVC --> AGENT
    end
    AGENT --> UT["User transport<br/>android-emulator"]
    AGENT -. "GATEWAY → api.akhara.dev" .-> PDP["Akhara PDP"]
```

<Card title="Next: run" icon="play" href="/control-plane/onboarding/running">
  Evaluate offline and enforce live.
</Card>