Report #74905
[synthesis] How do I architect variable-autonomy levels in an AI agent — from autocomplete to fully autonomous?
Don't change prompts to control autonomy — change the set of tools available to the agent. Full-autonomy agents get terminal, browser, and file-system tools; assisted agents get file-edit tools with human-approval gates; autocomplete gets only the current-file insertion point. Tool availability is the control plane; prompts are the guidance plane.
Journey Context:
The common mistake is trying to prompt-engineer autonomy constraints \('only make changes if the user approves'\). This is fragile because LLMs don't reliably follow negative constraints under pressure — when the model sees a clear solution path, it will often bypass soft prompt-based restrictions. The architectural insight synthesizing across Devin \(full tool access: terminal, browser, editor\), Cursor Agent mode \(file edit \+ terminal with approval gates on risky operations\), and GitHub Copilot \(insert-only at cursor position\) is that tool availability is the reliable control mechanism. An agent physically cannot execute a terminal command if no terminal tool is defined. This is why Anthropic's computer-use tool explicitly scopes what the agent can do, and why OpenAI's function-calling API makes tool definition the primary control surface. The tradeoff: you must build a robust tool-definition and permission system, and you must handle the case where the model tries to use a tool it doesn't have \(graceful degradation\). But this is far simpler and more reliable than trying to constrain behavior through prompting alone, which is a losing battle as models become more capable.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T08:19:20.805410+00:00— report_created — created