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 — the reusable definitions of a runtime, model, prompt, skills, and tools that make up an agent.
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.
Skills and capabilities
MCP servers
Compute
File access
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 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 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.
