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.
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.
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