Approvals and plans

The Agent Harness separates three controls that are easy to confuse: execution mode, planning policy, and permission policy. They work together, but each answers a different question.

​

Execution modes

Execution mode does not grant access. Identity, roles, admitted tools, per-tool policy, and plugin rules still apply.

​

Planning policies

​

Standard

standard does not require an explicit plan-review gate. The Assistant or Agent can report progress when useful and remains subject to normal action approvals. Use it for direct questions, small changes, focused investigations, or work whose next step is already clear.

​

Review required

review_required creates a user-review boundary before implementation. The Assistant may use read-only discovery and investigation tools to ground the proposal, then presents a structured plan and pauses. The plan contains future work—not a retrospective list of research already completed. A useful plan identifies targets, implementation steps, validation, and rollout or rollback where relevant. You can:

• Approve the proposed plan and begin execution.
• Submit feedback to revise it without activating the previous proposal.
• Reject it and end that path.

Approval of a plan is not blanket approval for every future side effect. Exact mutations can still require their own action approval.

​

Permission levels

These levels control approval behavior. They do not grant the Assistant or Agent access to data, tools, plugins, or operations that the current identity cannot otherwise use. Capability-specific settings can apply a different level to selected actions.

​

How Auto Review works

RevoShield-1 is RevoEngine’s specialized Auto Review layer. It is designed to preserve the user’s intent while reducing routine approval prompts. Before an eligible action proceeds, it evaluates the exact proposed effect against the user’s request, the authorized context available to the task, and the evidence required for that operation. RevoShield-1 follows these boundaries:

• Read-only investigation can continue without unnecessary interruption.
• Before an approval-sensitive action, RevoEngine checks the concrete target, requested operation, expected effect, and relevant constraints against what the user asked for.
• Each action in a multi-step task is assessed on its own. A necessary step can continue when it is clearly part of the requested outcome, but approval of one step is not blanket permission for later actions.
• Code capable of changing platform data or producing external effects is treated as an action, not as a harmless read merely because it is executed as code.
• If the intent is unclear, the available context cannot establish the effect, the proposal exceeds the requested scope, or the action is too sensitive for automatic approval, the workflow pauses for the user.

For a connected terminal, commands and network access have separate device grants. Ordinary work within the workspace and the available network scope proceeds without a prompt for each step. When the Assistant requests host-level execution or more network access, Restricted asks you directly; Auto Review and Full Access let RevoShield assess the exact action first and ask you when it cannot safely approve it. You can approve one invocation or grant the missing scope for 15 minutes, one hour, eight hours, 24 hours, or the whole thread on that chat, device and workspace. Destructive commands, private-data transfers, and uncertain effects retain their own review boundary. A timed grant ends at expiry, explicit disconnect, or a grant change; whole-thread consent also ends on thread deletion and is not copied to a fork. These decisions do not change the saved terminal permissions or grant access to another workspace. The public contract is the review behavior and the resulting decision evidence. Internal prompts, routing, and provider-specific review payloads are not part of that contract.

​

Action-required states

A thread or run enters ACTION_REQUIRED when it cannot safely continue without a decision. The action can be:

• Approval for one or more compatible side effects;
• Plan review before implementation;
• Clarification when a user-owned decision would materially change the result.

Approval actions can support Approve, Approve all compatible actions for this turn, Reject, or Submit feedback, depending on the action. Clarifications accept a submitted answer rather than an approval. The pending action is durable. Resolving it resumes the work from persisted state, and the decision is retained with the execution history.

​

Review source changes and decisions

Supported Assistant edits include a comparison of the current and proposed source and editable properties. Inspect the inline comparison in the conversation, or open fullscreen for a side-by-side review. Completed edits retain their comparison and decision history. With Auto Review, eligible actions explicitly requested by the user can continue after a successful automatic review. The conversation distinguishes automatic approval, manual approval, and a return to manual review, with a short explanation of the outcome. Unclear intent, insufficient context, or a stale proposal does not silently become approval. The decision applies to the version and effect that were reviewed. If the target changes before application, a fresh proposal is required. The review does not bypass roles, access checks or the configured permission policy. See 1.5.0 for the full update.

​

Outcomes and reviewed plans

Describe the intended outcome in your request and refine it with follow-up messages. A plan is an ordered, reviewable execution contract. The former thread-goal commands and low-code goal methods are no longer part of the supported public surface. Feedback can use different wording or request a structural change, such as fewer steps. The revised plan is judged through the review flow rather than word overlap. Plan review remains distinct from a clarification answer or permission to perform a particular side effect.

​

Recommended patterns