Skip to main content
PATCH
JavaScript
This is how you iterate. Change a prompt, and the next objective uses it. No republish, no new variation, no version to promote.
Running objectives keep the prompt they started with, because each one froze the variation into its configSnapshot at creation. Only new objectives see the change.

The update merges, deeply

Send one field and the rest survive. That holds inside nested messages too: patch modelConfig.temperature alone and modelConfig.modelId stays put.
An empty spec: {} changes nothing and returns 200.

A zero value is invisible without updateMask

Here is the trap. 0, "", and false are proto zero values, indistinguishable from “not sent.” A merge skips them, so the field keeps its old value and you get a 200 saying nothing happened.
A variation cannot be set to temperature: 0, and a description cannot be cleared, by sending the value alone. The request succeeds and the field does not move.
updateMask fixes it. Name the paths you mean, and their values become authoritative, zero or not.
Verified against the live API: temperature moves 0.5 → 0, and description clears to '', only with the mask. Both forms work, in the body or as a query parameter (?updateMask=spec.description). A masked update touches only the masked paths. Everything else is left alone, including fields you happened to include in the body. Comma-separate several: updateMask: 'spec.description,spec.modelConfig.temperature'.

Guards that hold

A model that does not exist is a 404, resolved through the external_id: form the same as everywhere else:
A disabled model is a 400 on spec.model_id, and disabling a model that any variation references is itself a 400. The two guards hold each other up, so a running objective never finds its model pulled out from under it.

What you cannot change here

Assignments and memory layers are not part of the spec. They have their own routes:
  • Add an assignment for tools, tool sets, and sub-agents
  • addMemoryLayer for memory, because position orders the cascade
score and feedbackCount are read-only. They come from feedback and drive weighted selection.

Create a variation

Every field this endpoint can change, and what they do.

Publish an agent

Why an edit goes live without a republish.

List models

What modelId accepts, and what maxInputTokens does to compaction.

Add an assignment

The capabilities that live outside the spec.

Authorizations

Authorization
string
header
required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Path Parameters

workspaceId
string
required

Workspace ID.

Example:

"workspace_01HXKD2E5NQM3T9AYWCF133E3Q"

agentId
string
required

Agent ID. Accepts the canonical agent_… form or the external_id:<value> form.

Example:

"agent_01HXKD2E5NQM3T9AYWCFMGWT9Y"

id
string
required

Variation ID. Accepts the canonical agentvar_… form or the external_id:<value> form.

Example:

"agentvar_01HXKD2E5NQM3T9AYWCF32BSPP"

Body

application/json

Update agent variation request

metadata
object

UpdateResourceMetadata contains the user-provided fields for updating a workspace-scoped resource. Read-only fields (id, account_id, workspace_id, profile_id, created_at) are excluded since they are set by the server.

spec
object

AgentVariationSpec defines the operational configuration for a variation

updateMask
string<field-mask>

Fields to update

Response

OK

AgentVariation resource

metadata
object
required

Resource metadata

spec
object
required

Variation specification

info
object

Read-only summary information