Agent revisions

Use revisions to apply Agent configuration changes and check what was deployed. Saving a Configuration or changing which Configuration an Agent uses does not change a running Agent. Each accepted deployment creates a new, immutable revision; a worker activates it later. Multiple Agents can share a Configuration, but you must deploy each Agent that should use the change.

Update and deploy

Use the OCC CLI with an identity that can read the Agent, read and update its Configuration, and deploy the exact Agent. The Namespace must be ready. Reading revision history requires permission to read the returned revisions. The selected model credential may require additional permissions. The commands below also use jq.

Set the Namespace and Agent IDs and find the Agent's Configuration:

bash

export OCC_NAMESPACE='<namespace-id>'export AGENT_ID='<agent-id>'CONFIGURATION_ID="$(occ agent get "$AGENT_ID" --output json | jq -r .configurationId)"occ configuration get "$CONFIGURATION_ID" --output json |  jq '{values: .values}' > configuration-update.json

Edit configuration-update.json. Keep the entire values document: the update replaces it, so any setting you omit is deleted. Omit secretBindings to preserve the existing bindings; send {} only if you mean to clear them. Never put credential values in the file. Use Secret references and bindings.
Save the Configuration and review its new generation. Then deploy:
bash
```
occ configuration update "$CONFIGURATION_ID" --file configuration-update.jsonocc agent deploy "$AGENT_ID" --output json
```
Save the returned revision id, revision number, and configurationGeneration. An accepted request means the control plane stored the revision and queued deployment; it does not mean the Agent is running. If the response is lost, check revision history before retrying: a second accepted request creates another revision.
Check whether the worker selected that revision:
bash
```
occ agent get "$AGENT_ID" --output json |  jq '{desiredRuntimeState, activeRevisionId}'
```
activeRevisionId should match the revision ID from deployment. If it does not, run occ agent deployment-status "$AGENT_ID" '<revision-id>' to see where work stopped. The deployment status reference defines each result. An active revision does not prove that the model responds; use the runtime verification guide.

Inspect an earlier revision

In the console, open the Agent's Versions list. Current version marks the revision selected by OCC; selecting a version shows its read-only details beside the list. Create new version opens the current saved Configuration; Deploy new version uses those saved settings and Agent plugin selections. Viewing an older version does not select it for deployment. The HTTP API also lists and reads revisions; the CLI has no revision history command.

The Plugins tab shows the saved Agent selections in Create new version and the frozen selections in an admitted revision. Change and save draft plugin policies before deploying; editing the reusable Configuration JSON does not update these Agent-owned selections.

The public API has no rollback operation. To return to an earlier configuration, restore the settings you need from your saved source file, using the older revision for comparison, then deploy. A Sandbox Driver can transform the configuration before the revision is stored, so avoid copying its snapshot wholesale. The new deployment uses current permissions and dependencies; Secret references do not restore earlier credential values. See the revision contract for what it captures.