Computer Agent lifecycle and support

Computer Agent lifecycle routes are scoped to the stable Agent account ID: /api/v2/computer/accounts/{targetAccountId} Do not use an agentConfigId in this path. Agent-owned instructions, model selection, heartbeats, knowledge, and assigned skills still use the normal staging and publish lifecycle.

​

Provision and verify

The Computer is shared by the organization’s assigned Computer Agents. Provisioning another Agent can reconcile that shared Computer; restart, upgrade, and deprovision affect every Agent assigned to it. Schedule disruptive work accordingly.

1. Read GET /status before creating work. A 404 means no Computer has been provisioned.
2. Provision only when no usable deployment exists.
3. Omit version and host details. Vida provisions its current published version.
4. Treat the provision response as an asynchronous job.
5. Poll /status until lifecycle.status is succeeded, failed, or canceled.
6. Read /runtime/health and verify the capability the Agent needs.

Restart and upgrade use the same accepted-job pattern. A normal upgrade installs Vida’s current published version and safely refreshes managed workspace templates without replacing customer Canvas or project files. Do not report completion from the initial response.

​

Read bounded runtime evidence

Use the smallest source that answers the question:

• GET /runtime/health for readiness and dependency checks
• GET /runtime/logs for paginated recent activity
• GET /runtime/service-logs for bounded service-startup output
• GET /runtime/diagnostics for stable findings and affected configuration paths

Use cursors and bounds from the endpoint schema. Do not request or retain unbounded logs for routine troubleshooting.

​

Inspect runtime configuration

GET /config returns redacted authored and effective settings, the current revision, and the Agents included on the same Computer. Redacted values confirm that a setting exists without returning its secret. For a supported Computer-wide change:

1. Read /config and save its revision.
2. Submit {revision, patch} to POST /config/patch.
3. Use replacePaths only when intentionally replacing an array.
4. Read /config again and verify the exact resulting paths.

Omit redacted values unless the user explicitly intends to replace them. Do not use runtime configuration to bypass Agent staging and publishing.

​

Diagnose and repair

Run diagnostics when health and bounded logs do not explain the problem. Findings include stable codes and severity even when human-readable details vary. POST /runtime/repair accepts only explicit confirmation. Repair is bounded and asynchronous; it is not an arbitrary command surface. After repair:

1. Poll /status until terminal.
2. Re-read health.
3. Rerun diagnostics.
4. Verify the affected skill, channel, helper, browser workflow, or Task.

​

Back up before risky work

List existing backups before creating another. Poll backup and restore jobs to terminal status, then verify health and account status. Normal deprovisioning preserves saved state. A wipe permanently removes it, requires explicit user intent, and will not proceed without a successful recent safety backup. Confirm the exact shared Computer and every affected Agent before sending a destructive request.