Agent configuration fields
| Field | Description |
|---|---|
customer_id | Required. Your identifier for the customer this agent serves. One agent per customer is the recommended model |
name | Required. A human-readable name for the deployment |
system_prompt | Required. Defines the agent’s behavior and persona. Distinct from user messages, which describe the work to be done. Keep fast-changing product knowledge in skills and live data behind MCP tools instead |
model | The model that powers the agent, in provider/model form, such as anthropic/claude-sonnet-4.5. No provider lock-in — memory, skills, and files live outside the model, so you can switch it anytime without losing what the agent has learned |
runtime | The agent harness. Currently hermes (default) |
sandbox | The isolated container the agent runs in — see Sandbox |
mcp_servers | MCP servers exposing your first-party tools — see MCP |
skills | Markdown playbooks that supply domain expertise — see Skills |
secrets | Connector credentials as secret references — see Secrets |
features | Runtime capability toggles: memory, dreaming, automations, steering, filesystem webhooks — see Features |
Create an agent
The following example defines a media generation agent with one MCP server and one skill. See Deployments for the full parameter reference.deployment_id, status, the default thread_id, the filesystem layout, and the SSE events URL:
Update an agent
Update a live deployment’s configuration withdeployments.update. Changes apply to the agent’s next run — memory, files, and conversation history are untouched.
Update semantics
- Omitted fields are preserved. Only include the fields you want to change.
- Scalar fields (
name,model,system_prompt) are replaced with the new value. - Array fields (
mcp_servers,skills) are fully replaced by the new array. Pass an empty array to clear one. To modify them incrementally instead, use the Skills and Tools APIs. secretsis merged at the key level. Keys you provide are added or updated; keys you omit are preserved. Set a key tonullto remove it.featuresis merged at the key level, so you can toggle one flag without restating the rest.- No-op detection. If the update produces no change, the existing deployment is returned unchanged.
customer_idandruntimeare immutable — create a new deployment instead.
Sandbox
Each deployment runs in its own container with a persistent filesystem:| Field | Default | Description |
|---|---|---|
enabled | true | Run the agent in an isolated container |
type | docker | Sandbox backend |
persistent_filesystem | true | Keep /workspace across sessions, restarts, and deploys |
Features
| Feature | Default | Description |
|---|---|---|
memory | true | Observational memory that persists across sessions |
dreaming | false | Idle-time self-learning between sessions |
automations | true | Scheduled and recurring runs the customer can create in chat |
steering | true | Human-in-the-loop approvals before consequential actions |
filesystem_webhooks | false | filesystem events on the SSE stream when workspace files change |
Secrets
Connector credentials are passed as references, never raw values:sec_...) provisioned by the Prism team. Raw credentials never appear in prompts, logs, or the agent’s filesystem. Ask your Prism contact to register secrets for your workspace — book a call if you don’t have one yet.
Per-customer deployments
Create one deployment per customer (customer_id). Each gets its own container, filesystem, memory, and automations, so no customer’s context can leak into another’s. Use List Deployments with the customer_id filter to manage your fleet.
Next steps
Tools
Built-in capabilities and how to add your own.
MCP
Register your product’s tools via MCP servers.
Skills
Teach the agent your domain playbooks.
Quickstart
Deploy and message your first agent.

