Summary

Allow designated users (e.g. requesting team members) to view and propose changes to an agent's instructions without the ability to apply changes directly. Proposed changes go through automatic re-verification evaluation and then platform team review before taking effect.

Problem Statement

In enterprise environments where a platform team centrally manages Rovo agents on behalf of requesting teams, instruction changes are currently all-or-nothing: a user either has full edit access to the agent's configuration (including the ability to save changes directly) or no edit access at all.

This creates a workflow bottleneck. Requesting teams frequently need minor instruction adjustments - updating a redirect URL, adding guidance for a new query type, or refining a deflection message. Each change requires the requesting team to describe the change to the platform team, who then makes the edit. The requesting team cannot see the current instructions, cannot draft the change themselves, and cannot verify the wording without the platform team's involvement.

The platform team needs a way to delegate editing capability without delegating approval authority.

Proposed Solution

New permission level: Editor

A new permission level for Rovo agents between "Viewer" and "Administrator":

Permission Viewer Editor Administrator View agent overview, insights, conversation review Yes Yes Yes View instructions (read-only) Yes Yes Yes Edit instructions and submit proposals No Yes Yes Approve/reject proposals No No Yes Save changes directly (no proposal required) No No Yes Manage evaluation, governance, version history No No Yes Manage users and permissions No No Yes

Editors can see the full instruction set (including inherited organisation instructions as read-only) and make edits. When they save, the change is submitted as a proposal rather than applied directly.

Proposal workflow

The proposal follows a four-step process:

1. Submitted - The editor saves their change. It is recorded as a proposal with a note describing the reason for the change.
2. Re-verification - The evaluation engine automatically runs the agent's configured datasets against the proposed instruction change. If re-verification fails, the proposal is automatically rejected and the editor is notified with the failure details. No platform team review is needed for failed proposals.
3. Awaiting review - If re-verification passes, the proposal enters the review queue. Platform team administrators receive a notification.
4. Decision - A platform team administrator reviews the proposal, including the diff, the re-verification results, and the proposer's note. They approve (applying the change as a new version) or reject (with an optional comment explaining why).

Proposal review interface

Platform team administrators see a "Proposals" item in the agent's sidebar, with a badge showing the count of pending proposals. The review interface shows:

• The proposer's note explaining the change

• The re-verification evaluation results (current vs proposed scores per dataset)

• A diff view showing exactly what instruction lines were added, removed, or modified

• A comment field for the reviewer

• Approve and Reject buttons

Approved proposals create a new version in the version history, attributed to both the proposer (who drafted the change) and the reviewer (who approved it).

Design Reference

See attached mockup (mockup-delegated-editing.html) showing:

1. Mockup 1 - Editor view (requesting team member). Shows the instruction editor with a purple info banner indicating editor access, read-only organisation instructions, editable agent instructions, a proposal note field, and a "Submit proposal" button.
2. Mockup 2 - Administrator view (platform team). Shows the Proposals sidebar item with a pending count badge, a list of proposals including one awaiting review and one previously auto-rejected by re-verification, and a progress stepper showing the four-step workflow.
3. Mockup 3 - Review detail view (platform team). Shows the proposer's note, re-verification results comparing current vs proposed scores, the instruction diff, and the approve/reject interface with an optional comment field.

Use Cases

Requesting team updates agent guidance: A requesting team notices that users are asking their agent about Jira field configurations and the agent isn't handling it well. The team's designated editor drafts an instruction addition, describes why it's needed, and submits the proposal. Re-verification passes automatically. The platform team reviews the diff, confirms the wording is appropriate, and approves. The change goes live as a new version.

Bad change caught by re-verification: An editor accidentally removes an out-of-scope deflection rule while editing. Re-verification detects that the boundary dataset has regressed and automatically rejects the proposal. The editor is notified with the specific failure. The platform team is never involved - the automated gate caught the problem.

Platform team rejects with feedback: An editor proposes an instruction change that is technically correct but uses wording inconsistent with the agent's tone. The platform team reviewer rejects the proposal with a comment explaining the tone issue and suggesting revised wording. The editor revises and resubmits.

Interaction with Other Features

• Re-verification triggers: Proposals use the same re-verification evaluation engine. The re-verification step in the proposal workflow is functionally identical to the re-verification that runs on direct administrator saves.

• Version history: Approved proposals create a new version entry, tagged with both the proposer and the approver.

• Organisation instructions: Editors can see inherited organisation instructions as read-only. Proposals can only modify agent-level instructions.

Considerations

• Multiple pending proposals. If multiple editors submit proposals for the same agent, later proposals should be evaluated against the current live configuration, not against earlier pending proposals. Only one proposal can be approved at a time. Approving one proposal may require re-evaluation of other pending proposals.

• Proposal expiry. Consider auto-expiring proposals that have been pending review for longer than a configurable period (e.g. 30 days) to prevent stale proposals accumulating.

• Notification channels. Editors should be notified when their proposal is auto-rejected (re-verification failure), approved, or rejected by a reviewer. Administrators should be notified when a new proposal passes re-verification and enters the review queue.

• Scope. This feature request covers instruction editing only. Knowledge source, scenario, and skill changes remain administrator-only. These areas have higher risk profiles and are less likely to need frequent adjustments from requesting teams.