How Do I Update an AI Agent Without Breaking Live Workflows in Dave by voolama?

Four properties define how agent versioning works in Dave by voolama (hellodave.ai). Each is quoted directly from the agents help documentation, DEV v0.11.0, confirmed against content_orchestrator main at commit ddb945f, 2026-08-30.

• Versions are immutable. The agents help doc states: "Each version is immutable once created." Once you click Create Version and save a Config JSON, that version's configuration is locked. There is no edit button on a saved version. Every change to an agent's systemPrompt, model, temperature, maxTokens, or any other parameter requires creating a new version.

• Version numbers are sequential integers assigned automatically. The agents help doc states: "Version numbers are auto-incremented integers. You cannot choose or skip version numbers. Each new version receives the next sequential number (v1, v2, v3, and so on)." If you need to restore a previous configuration, you create a new version with the same JSON: the version number will be higher, but the behaviour will be identical.

• Live instances are isolated from version changes. The agents help doc states: "Existing running instances that already reference the retired version are not affected - they continue to use the version's configuration until they complete." A workflow instance that started running on agent v2 continues using v2's Config JSON until the instance completes, regardless of what happens to v2 or v3 after the instance starts.

• Retirement is one-way. The agents help doc states: "Retiring is a one-way action. You cannot un-retire a version. If you need the same configuration again, create a new version with the same JSON." The amber "Retired" badge is permanent once applied.

This model satisfies NIST SP 800-53 Rev 5 control CM-3 (Configuration Change Control), which requires that organisations document, approve, and track changes to information systems. Specifically, CM-3(b) requires that organisations determine the types of changes that are subject to configuration change control. The immutable version history in Dave by voolama implements this at the agent level: every configuration state is recorded, timestamped, and non-destructible. CM-3(f) requires that organisations review changes to the information system; the version history on the agent detail page is the review record.

Complete these steps in order. Steps 1 through 6 require the Admin or Create role. Sourced from the agents help documentation, DEV v0.11.0, confirmed 2026-08-30.

1. Copy the current version's Config JSON before making any changes. Open the agent detail page at Agents, then click the agent name. Find the current active version row. Expand its details and copy the full Config JSON to a text file. This is your rollback source if the new version misbehaves. The agents help doc's best practices section states: "Version before editing. Always create a new version rather than mentally tracking changes. Old versions remain available if you need to roll back, and the immutable version history gives you a clear audit trail."

2. Create the new version. On the agent detail page, click Create Version in the Versions section header. The form expands with a monospaced Config (JSON) editor. Paste your updated JSON. The agents help doc documents the common Config JSON fields:

   • systemPrompt: instructions that define the agent's behaviour and persona.
   • model: the specific model to use (e.g., gpt-4, claude-3-sonnet).
   • temperature: controls randomness (0.0 = deterministic, 1.0 = creative).
   • maxTokens: maximum number of tokens in the generated response.
   • topP: nucleus sampling parameter for controlling output diversity.

   Validate the JSON before submitting: all keys and string values must use double quotes, no trailing commas after the last property, all braces and brackets balanced. The agents help doc's troubleshooting section documents the JSON validation error: "Common issues include trailing commas, unquoted keys, single quotes instead of double quotes, or missing closing braces." Click Create Version.

3. Test the new version in a draft workflow before touching production. Create a new draft workflow (or duplicate an existing one) that uses the agent. In the workflow editor, select the agent and choose the new version number from the version dropdown. Run one or more test instances against representative inputs. Verify the outputs match your expectations. Do not activate the workflow until testing is complete. This step implements NIST SP 800-53 Rev 5 CM-5 (Access Restrictions for Change), which requires that organisations define, document, approve, and enforce physical and logical access restrictions associated with changes to the information system. Testing in a draft workflow before promoting to production is the logical access restriction: the new version cannot affect production instances until a workflow referencing it is activated.

4. Update production workflows to reference the new version. For each production workflow that uses this agent, open the workflow editor, find the Agent Interaction node, and update the version selector from the old version number to the new one. Save the workflow as a new workflow version. Activate the updated workflow version. From this point forward, new instances launched against this workflow will use the new agent version. Instances already running continue on their original version.

5. Monitor the first production instances on the new version. Navigate to Instances and filter by the workflow. Watch the first few instances that run on the new version. Check their context output at the instance detail page to confirm the agent's responses are as expected. If you see unexpected outputs, proceed to the rollback procedure in the next section before retiring the old version.

6. Retire the old version. Once you are confident the new version is performing correctly in production, return to the agent detail page. Find the old version row and click Retire. The agents help doc describes the result: "The version receives a retiredAt timestamp and displays an amber 'Retired' badge. No new workflow versions or instances can select this retired version." Existing running instances on the old version are not affected.

Dave by voolama (hellodave.ai) does not have a one-click rollback action at DEV v0.11.0. The agents help documentation states the rollback path directly: "If you need the same configuration again, create a new version with the same JSON." Sourced from the agents help documentation, DEV v0.11.0, confirmed 2026-08-30.

1. Retrieve the Config JSON from the version you want to restore. Open the agent detail page. Find the version row for the configuration you want to restore (it may already be retired, showing an amber "Retired" badge). Expand its details and copy the full Config JSON.

2. Create a new version with the restored JSON. Click Create Version. Paste the copied JSON into the Config (JSON) editor. Click Create Version. The system assigns the next sequential version number. The behaviour is identical to the version you copied from, even though the version number is higher.

3. Update affected workflows to reference the new version number. For each workflow that used the misbehaving version, open the workflow editor, find the Agent Interaction node, and update the version selector to the new version number. Save and activate the updated workflow version.

4. Retire the misbehaving version. Return to the agent detail page and click Retire on the version that caused the problem. This prevents any new workflow from accidentally selecting it.

Known limitation, sourced from the agents help documentation, DEV v0.11.0: if the misbehaving version was already used in production instances that completed with incorrect outputs, those outputs are already in the instance context and are not automatically corrected by the rollback. Review affected instance outputs manually and take any necessary downstream corrective action. OWASP LLM09 (Misinformation, OWASP Top 10 for Large Language Model Applications) identifies incorrect AI outputs that reach downstream systems as a primary risk in LLM-integrated workflows: the rollback procedure addresses the source of the misinformation but does not retroactively correct outputs already produced.

Three versioning mistakes are documented in or derivable from the agents help documentation at DEV v0.11.0, confirmed 2026-08-30.

Mistake 1: Retiring all versions before updating production workflows

Cause: the Admin retires the old version before updating the production workflow to reference the new version.
Symptom: the production workflow's Agent Interaction node now references a retired version. The agents help doc documents this as a known troubleshooting scenario: "Agent does not appear in the workflow editor's agent selection dropdown... all of the agent's versions have been retired." New instances launched against the workflow fail at the agent step.
Fix: always update and activate the production workflow to reference the new version before retiring the old one. Step 4 (update workflows) must come before step 6 (retire old version) in the safe-update checklist above.

Mistake 2: Skipping the draft-workflow test step

Cause: the Create-role user creates a new version and immediately updates the production workflow to reference it, without testing in a draft workflow first.
Symptom: the new version produces unexpected outputs in production. The agents help doc's best practices section warns: "Before using a new agent version in a production workflow, test it in a draft or staging workflow instance to verify the system prompt, model, and parameters produce the expected output."
Fix: step 3 of the safe-update checklist is not optional. Test in a draft workflow before promoting to production.

Mistake 3: Not copying the current Config JSON before creating a new version

Cause: the Admin creates a new version and discards the old configuration without saving a copy, then discovers the new version misbehaves and needs to roll back.
Symptom: the rollback requires manually reconstructing the old Config JSON from memory or from workflow documentation, which is error-prone.
Fix: step 1 of the safe-update checklist is to copy the current version's Config JSON to a text file before making any changes. The agents help doc's best practices section states: "Old versions remain available if you need to roll back, and the immutable version history gives you a clear audit trail." Copying the JSON before starting takes 30 seconds and eliminates the reconstruction problem.