> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orcapods.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Agents
> Create, import, edit, publish, and manage the full lifecycle of your agent profiles.
The **Agents** screen is the catalog and lifecycle hub for your [agent profiles](/concepts/profiles) — the reusable definitions of a runtime, model, prompt, skills, and tools that make up an agent.
## The catalog
The main table lists every agent in the org with **filter/search** and pagination. Columns:
| Column | Description |
| -------------- | ------------------------------------ |
| **ID** | Stable identifier. |
| **Name** | Human-readable name. |
| **Runtime** | `claude`, `codex`, or `general`. |
| **Model** | e.g. `anthropic:claude-sonnet-4-6`. |
| **Status** | Live status of the agent. |
| **Visibility** | Whether it's published, and to whom. |
### Top-level actions
* **New agent** — opens the create dialog (below).
* **Import YAML** — create an agent from a profile document.
### Per-row menu
Each row's overflow menu offers **Publish…**, **Copy public URL**, **Manage** (or **View**) publishing, and **Delete agent**.
**Publish** and **Delete agent** are **admin-only**. Members see the row and its detail but cannot publish or delete.
Click any row to open its **detail sheet**.
## New agent dialog
The **New agent** dialog (also used when editing) captures the full profile.
Four fields are always visible:
* **Name**
* **Runtime** — `claude`, `codex`, or `general`
* **Model** — e.g. `anthropic:claude-haiku-4-5`, `anthropic:claude-sonnet-4-6`, `openai:gpt-5.2`, `google:gemini-2.5-pro`
* **System prompt**
Everything else lives in four collapsible sections below them. Each section
collapses to a single row showing a summary of its current setting, and opens
automatically when the profile being loaded (a template, or an existing agent
being edited) already configures it.
Multi-selects for **Skills** and **Capabilities**. Collapsed summary reads e.g. `2 skills, 1 capability`, or `Default capabilities, no skills` when both are empty.
Attach servers from the catalog. Collapsed summary reads e.g. `3 servers` or `None attached`.
Two toggles. **Run the worker per session** boots the agent-worker once per session and closes it with the session; leave it off to use the default shared, always-on worker pool. When it is on, **Runs in** picks the sandbox provider the worker boots on. **Give the agent a shell** enables a [sandbox](/concepts/sandboxes) and configures its **provider**, **template**, **CPU**, **memory**, **disk**, **idle-pause**, and **environment variables**. The first is about where the agent process runs, the second about what the agent can run. Collapsed summary reads e.g. `Per-session worker on daytona, e2b shell`.
**Runs in** lists sandbox providers only, and the worker always saves one. The profile field also accepts `docker` and `process` and the picker deliberately omits both: neither is a sandbox (docker needs a daemon socket no cloud runner has, process runs the worker on the runner's own host), so they are local-iteration substrates set through the API. Offering them beside the providers turned "which sandbox" into what read like "sandbox or not", a question the toggle above had already asked, and an inherit option labelled *runner default* completed the illusion. Saving no substrate at all is what produced agents reporting `This agent names no substrate. No runner in this fleet launches sandbox workers, so nothing will start.` An existing profile that names `docker` or `process` keeps showing it rather than being silently rewritten.
**Limit to specific mounts** gates the agent to the mount prefixes you list. Off (the default) gives it the whole shared file tree. Collapsed summary reads `Full access` or e.g. `Limited to /agents, /kb`.
Agents using sandbox-worker placement carry a **sandbox** badge beside their runtime in the catalog. Existing and imported profiles default to static placement when `workerMode` is omitted; imports accept only `static` or `sandbox`.
## Import YAML
**Import YAML** lets you **paste or upload** a profile document. It's **schema-validated** before anything is created — you'll see **errors and warnings** inline and can only commit once the document is valid.
Import is the fastest way to move an agent between orgs or restore one from version control.
## Agent detail sheet
Opening an agent reveals a tabbed detail sheet:
| Tab | What's inside |
| -------------- | --------------------------------------------------------------------------- |
| **Config** | The full profile as formatted YAML/JSON. |
| **Sessions** | The agent's [sessions](/concepts/sessions) — list, start new, or shut down. |
| **Runs** | Filterable list of runs; open any in the [Workbench](/dashboard/workbench). |
| **Memory** | Per-agent memories from the [Memory Bank](/dashboard/memory-bank). |
| **Changes** | An audit diff of edits over time. |
| **Publishing** | The publish panel (below). |
| **Metrics** | Usage and performance metrics for the agent. |
## Publishing
Publishing exposes an agent as a callable public endpoint. See [Publishing](/concepts/publishing) for the concept; the panel controls:
Set the **URL slug**, **visibility**, **allowed origins**, a **rate limit (requests per minute)**, and the **sync max duration**.
Publish the agent, then **copy the public URL** to share it.
Mint API keys for authenticated callers.
Unpublishing takes the endpoint offline and **revokes issued keys**.
Publishing and unpublishing are **admin-only**.
## Related
What an agent profile contains.
How published endpoints and keys work.
Attach reusable skills to agents.
Run and inspect your agents.