Autonomy Slider
Expose agent autonomy as a continuous adjustable parameter so the same codebase can span scripted assistant to fully autonomous worker without re-a...
Intent & Description
🎯 Intent
Expose agent autonomy as a continuous adjustable parameter so the same codebase can span scripted assistant to fully autonomous worker without re-architecting.
📋 Context
A product team owns one agent codebase but several deployment contexts: a free tier that should not act unsupervised, a paid tier where the user has opted into automation, an internal beta where engineers want full autonomy to stress-test. Hard-coding the autonomy level per build forks the codebase or branches the prompt.
💡 Solution
Define an autonomy parameter (scalar or vector) the runtime consults before each action. At one end the agent only emits suggestions a human acts on; at the other it acts directly and reports. Intermediate values gate by action type, confidence, or user opt-in. Persist the setting per-tenant or per-user. Surface the current value in the UI so users and operators see at a glance how autonomous the agent currently is.
Real-world Use Case
- One agent codebase needs to serve materially different autonomy contexts.
- Operators need to dial autonomy down quickly without redeploy.
- Users should be able to opt into higher autonomy explicitly.
Source
Advantages
- One codebase serves many autonomy contexts.
- Per-tenant or per-user tuning without redeploy.
- Operators can dial autonomy down quickly in response to incidents.
Disadvantages
- A continuous knob invites micro-tuning that has no clear meaning.
- Multidimensional autonomy is hard to render as a single slider; teams collapse to a slider that loses information.
- Users may not know what setting they are on if the UI hides it.