Releases and change control
How a change to an agent reaches production, and how to roll it back.
Next release
The change operations answer 501 not_implemented until change control ships.
Everything that shapes an agent's behaviour (instructions, skills, tools, models, knowledge bindings and guardrails) is data. Changing it goes through the same gate as a software release.
- Draft a change:
POST /v1/admin/projects/{project_id}/drafts. - Validate it: schema, references, limits, and a lint for injected instructions and leaked
secrets:
POST /v1/admin/drafts/{draft_id}/validate. - Evaluate it against its tests and the platform suites:
POST /v1/admin/drafts/{draft_id}/evaluate. - Review the diff, including the change in quality, tokens and cost:
GET /v1/admin/drafts/{draft_id}/diff. - Request approval:
POST /v1/admin/projects/{project_id}/change-requests. A second admin approves; the author cannot approve their own change. - Publish to an environment:
POST /v1/admin/change-requests/{id}/publish. This creates an immutable Release. - Roll back at any time:
POST /v1/admin/projects/{project_id}/rollback.
Runs already in progress finish on the Release they started with. A Release cannot reach an environment unless its evaluation suites pass.