Summary

Automatically version the full agent configuration on every save, providing a complete history of changes with the ability to compare versions, view diffs, and restore any previous version.

Problem Statement

Changes to a Rovo agent's configuration are currently destructive - once saved, the previous configuration is lost. There is no way to view what an agent's instructions, knowledge sources, scenarios, or skills looked like at a previous point in time, and no way to revert to a known-good configuration if a change introduces problems.

For enterprise environments where agents are managed as a service, this creates three risks:

1. No rollback capability. If a change breaks the agent, the administrator must manually reconstruct the previous configuration from memory or external documentation. There is no one-click revert.
2. No change auditability. There is no record of what changed, when, or by whom. Governance stakeholders cannot audit the history of an agent's configuration.
3. No linkage between changes and evaluation results. When an evaluation regression is detected, there is no way to determine which configuration change caused it without manually correlating timestamps.

Proposed Solution

Automatic versioning

Every save to any part of the agent's configuration creates a new version automatically. A version is a complete snapshot of the agent's entire configuration at that point in time, including instructions, knowledge sources, scenarios, and skills.

Versions are numbered sequentially (Version 1, Version 2, etc.) and tagged with the timestamp, the user who made the change, and which configuration areas were modified.

Version history page

A new "Version history" item in the Agent Studio sidebar, positioned between Governance and Users and permissions.

The page displays a timeline of all versions with:

• Version number and status - Sequential number with a badge for the current live version. If re-verification triggers are enabled, rejected versions are shown with a "Rejected" badge and red styling.

• Author and timestamp - Who made the change and when.

• Change summary - Tags indicating which configuration areas were modified (e.g. "Instructions modified", "Knowledge source added", "Scenario modified", "Skill added").

• Evaluation results at that version - The evaluation scores (AUP, Boundary, Accuracy) that were recorded for that version, either from a scheduled evaluation or a re-verification trigger. Pass/fail status is shown inline.

• Actions per version:
  • View full config - Show the complete agent configuration as it was at that version
  • Compare - Open the comparison view against another version
  • Restore this version - Promote this version to the current live configuration (creates a new version entry)

Version comparison

A dedicated comparison view showing two versions side by side:

• Version summary - Both versions displayed with their author, timestamp, and evaluation status

• Evaluation comparison - A table showing per-dataset scores for both versions and the delta (improvement or regression)

• Configuration diff - A code-diff-style view showing additions (green), removals (red), and unchanged context for each configuration area (instructions, knowledge sources, scenarios, skills). Sections with no changes are collapsed and labelled "No changes".

Restore behaviour

Restoring a previous version creates a new version entry (e.g. restoring Version 9 when the current version is 12 creates Version 13 with the same content as Version 9). The version history preserves the full audit trail - no versions are deleted or overwritten.

If re-verification triggers are enabled, a restore triggers a re-verification evaluation before the restored version goes live, following the same pending-then-promote flow as any other configuration change.

Design Reference

See attached mockup (mockup-version-history.html) showing:

1. Mockup 1 - Version history timeline showing 5 versions including the current version (blue highlight), a passed version, a rejected/failed version (red border), and older versions. Each entry shows change tags, inline evaluation scores, and action buttons.
2. Mockup 2 - Version comparison view showing Version 11 vs Version 12 side by side with evaluation score comparison table and a code-diff-style configuration diff highlighting added and removed instruction lines.

Interaction with Other Features

• Re-verification triggers: If enabled, rejected versions (those that failed re-verification) appear in the version history with a "Rejected" status. They cannot be restored without passing re-verification.

• Scheduled evaluations: Evaluation results from scheduled runs are associated with the version that was live at the time the evaluation ran.

• Compliance dashboard: The compliance dashboard's trend sparklines are derived from the evaluation results linked to successive versions.

Use Cases

Rollback after regression: A scheduled evaluation detects that the agent's boundary score has dropped from 100% to 93%. The administrator opens version history, compares the current version with the previous passing version, identifies the instruction change that caused the regression, and restores the previous version with one click.

Change audit: A governance review requires evidence of what changes were made to an agent over the past quarter. The version history provides a complete, timestamped record of every change, who made it, and what the evaluation results were at each point.

Root cause analysis: An evaluation fails after a knowledge source was added. The administrator opens the version comparison between the version before and after the knowledge source addition. The evaluation score comparison shows that accuracy dropped from 90% to 72%, isolating the knowledge source change as the cause.

Considerations

• Storage. Full configuration snapshots for every version will consume storage. Consider a retention policy (e.g. keep the last 50 versions, or keep all versions from the last 12 months) with the option for administrators to pin important versions that are excluded from cleanup.

• Restore with re-verification. When re-verification triggers are enabled, restoring a previous version should trigger re-verification to ensure the restored configuration still passes with current knowledge source content. A version that passed 3 months ago may not pass today if knowledge sources have changed.

• Diff granularity. The configuration diff should show meaningful changes, not structural noise. For example, reordering knowledge sources without adding or removing any should not appear as a change.

• Performance. Version history should load the timeline efficiently, with full configuration snapshots and diffs loaded on demand (when the user clicks "View full config" or "Compare").