Skip to main content
An agent is a reusable, versioned configuration. Each version stores its model, system prompt, skills, tools, and metadata. New agents start with their initial version in production. Publishing another version does not change production until you promote it. All endpoints use x-api-key authentication.

Create an agent

Creates an agent and its initial version.

Request body

Tool objects can be built-in toolsets, MCP toolsets, or custom tools. See Tools for full details. Role objects use this shape: When a session specifies a role, that role’s tools replace the agent version’s top-level tools for approval decisions. Sessions without a role use the version’s top-level tools. Custom tools use this shape: Example custom tool:

Response

Agent list, get, create, update, and rate-limit update responses include rateLimits.

List agents

Returns agents owned by the API key’s organization, newest first.

Get an agent

Returns the latest agent definition and version.

Update an agent

Fully replaces the agent configuration and always creates a new immutable agent version. Use this method when removing skills or tools. Production sessions continue using the current production version until the new version is promoted.

Partially update an agent

Publishes a new immutable version while preserving omitted configuration. Collection entries are upserted instead of replacing the whole collection. This lets you update one skill or tool without fetching and resending every other entry.
The patch may contain name, modelName, systemPrompt, skills, tools, roles, mcpServers, metadata, and expectedVersion. At least one field other than expectedVersion is required. A matching entry is replaced with the supplied object. An entry with a new identity is appended, and all entries not included in the request are preserved. Passing an empty collection does not remove existing entries; use the full POST update when you intend to remove skills or tools. expectedVersion is optional. When provided, it must equal the current version or the request returns 409 conflict. When omitted, the gateway protects the version it read while applying the patch, so a concurrent update also returns 409 instead of overwriting changes. The response is the full agent representation with the newly created version.

Promote a version to production

Moves the agent’s production pointer to an existing version. Existing production sessions resolve this pointer before sandbox acquisition, so an older session cannot switch the subject’s sandbox back to a pre-promotion configuration. Playground preview sessions remain pinned to the version they are testing.
Use the same endpoint with an older version number to roll production back.

Manage development tags

Development tags are mutable names for testing a specific immutable version without changing production:
Calling PUT again moves the tag. Existing tagged sessions remain pinned to the version they started with; only new sessions resolve the moved pointer. Tag names must start with a lowercase letter and contain only lowercase letters, numbers, or hyphens. production, preview, and latest are reserved. List and remove tags with:

Update per-user rate limits

Updates mutable operational policy without creating a new agent version. The change applies immediately to every version and existing session for the agent.
At least one field is required. Conversation limits accept integers from 1 through 300; user-event limits accept integers from 1 through 1,000. The response is the full agent representation. See Rate limits for scoping, counting, headers, and error behavior.

Archive an agent

Archives the agent. New sessions cannot be created from archived agents. Existing sessions remain accessible.

List versions

Returns the version history for an agent, newest first.

Get a version

Returns a historical agent version by version number.

Endpoint summary

Last modified on August 19, 2026