Trust & autonomy
Beyond the core pipeline, Studio lets you configure how much human attention each goal actually needs, where speculative work is allowed to land, and how many alternatives get explored before you commit to one. These are independent, composable settings — each goal can use a different combination.Review policy — who approves a proposal
Set per goal in the Goal Workspace (or as a session default in Model & Agent Studio).Two gates, set independently
There are two review policies, not one, and they gate different boundaries:
Both default to
Human Required. Because they’re independent, you can let a fan-out
of workers merge among themselves without being asked, while still requiring a human
before anything reaches your working tree.
Session defaults are nodalmerge.defaultTaskReviewPolicy and
nodalmerge.defaultWorkspaceReviewPolicy in VS Code settings.
The three values
Each gate takes one of:
Under
Hybrid, the reviewer runs inline and — on approval — schedules a timer and
blocks the immediate apply. The timer service re-fires the apply at expiry, by which
point the proposal is already Approved. A human rejecting before expiry cancels the
timer.
The countdown is overridable per work unit via TaskReviewHybridTimeoutMinutes /
WorkspaceReviewHybridTimeoutMinutes; only the field matching the gate actually in
play is consulted.
Optional execution gates — verify before proposing
Independent of review policy, a work unit’s branch can be required to build and/or test clean before it’s even allowed to submit a proposal (toggled in Exploration Settings). Failing evidence is attached to the proposal either way, so reviewers — human or agent — always see it. The requirement is also passed to the harness in its kickoff contract, but that is a hint only — an efficiency measure, so an agent that knows the standard fixes its own build before exiting. The guarantee is a mechanical policy rule evaluated when the proposal is created, which fires identically whether the branch was edited by Studio’s native loop or by an external CLI harness that has no knowledge of these settings.These two toggles are session-wide today, not per-work-unit. A single goal can’t
yet be held to stricter verification than the rest of the session.
Retry budget — how many automatic attempts before a human
Max auto-retries (Exploration Settings) caps how many automated attempts a work unit gets — both a reviewer rejecting a proposal (which sends it back for a revise) and a worker outright failing count against the same budget — before it stops and dead-letters into Blocked Explorations for a human to pick up.1 means one shot
then escalate; a higher number is more lenient auto-fixing before it asks for help.
Human or explicit retries (the Retry action in the Activity Center) are never
capped by this — it only governs the unattended loop, so a fully autonomous run can’t
spin forever on a task it can’t solve.
Promotion branches — a safety layer above “main”
When enabled (session-wide, with a per-goal override), proposals never apply directly tomain. They land on a shared candidate branch instead:
Reconciling candidate conflicts
Multiple agents proposing changes onto the samecandidate branch will
occasionally touch the same file paths. Studio calls this a Candidate
Conflict (or, when it’s between two fan-out sibling work units of the same
parent goal rather than session-wide, a Task Conflict — scoped to that one
goal instead of the whole candidate branch). Either way, the losing proposal
doesn’t just disappear — it shows up in the Activity Center with three ways
forward:
- Reconcile — spawn a dedicated reconciliation work unit whose goal is built automatically from the conflicting proposals’ diffs (plus any steering notes you add). If a Reconciler agent profile is configured in Model & Agent Studio → Agent Topology, it auto-spawns; otherwise the goal is created for you to spawn manually. This is the “let an agent sort it out” path.
- Restart — reject the losing proposal and restart its goal in Revert mode (a clean branch snapshot, not the Revise default) with your steering notes as the only new context. This is the “let it try again from scratch” path.
- Resolve manually — submit the resolved file content yourself. It’s written straight to the candidate branch and recorded as a synthetic merged proposal that supersedes the losing one(s) — no new work unit spawned at all.
Experiments — explore several approaches in parallel
A goal can fan out into 2+ sibling work units that run concurrently and converge into a side-by-side comparison:
Each fork runs to its own proposal; the Decision Tree shows a fork-count badge and a
Compare Results view. Pick Winner accepts the chosen fork’s proposal and
rejects the others — all recorded in the decision log.
Steering — redirect a running agent without losing its history
Instead of stopping and re-prompting an agent from scratch, you can pause a running work unit, inject a constraint or correction (“use Redis instead of SQLite”), and the system forks a sibling work unit that resumes with that constraint in its plan context. The original work unit’s decision log is untouched — steering never rewrites history, it branches from it. You can also fork from any specific node in Trajectory Replay, not just the live edge.Counterfactual replay — “what would a different model do here?”
From any completed work unit, Run with different model branches from that proposal’s base state and re-runs the same goal under a different profile. The result is a new sibling work unit; selecting it shows a Compare with Original view (proposals, confidence, file coverage side by side) without disturbing the original.Putting it together
A typical autonomous run: you describe a goal, pickAgent Approval (or Hybrid)
so it doesn’t need you at the merge gate, turn on the candidate branch so nothing
touches main directly, optionally require build+test evidence before any proposal
is even accepted, and — if you’re unsure which approach is best — launch it as a
Multi-Model or Architecture experiment instead of a single run. You can walk away;
when you come back, either a completed merge is waiting on candidate for you to
promote, or a decision (a rejected proposal, a paused agent awaiting your steering
input, or a set of forks awaiting Pick Winner) is waiting in the Decision Tree.
For a goal that’s really several subsystems at once, raise Max plan depth (or the
per-goal Plan depth) so the planner decomposes each subsystem in its own focused
pass and the pieces reconcile bottom-up — see
Guides → Multi-agent profiles → Recursive planning.
Set Max auto-retries to bound how long the unattended loop tries before it hands
a stuck work unit back to you.
See Reference → Control Tower UI for every control these
features expose in the extension, and Reference → API surface
for the full MCP/REST surface behind them.