On June 11, Cursor published an engineering blog post titled Auto-review. On the surface it describes "adding a classifier to the agent," but the underlying message is that when an agent can call local tools, read files, and touch production systems, a binary allow/deny switch is no longer sufficient.
Design philosophy: from a switch to a dial
Cursor's engineering team framed the core problem: a local agent touches files, credentials, environment variables, MCP tools, and production systems. Giving it high autonomy is risky; giving it low autonomy is extremely inefficient.
A more critical observation is approval fatigue: the traditional approach asks users to confirm each dangerous operation, and users quickly stop reading the dialogs—wearing through the safety net itself. Cursor's solution is a dedicated classifier agent that reviews tool calls before they actually execute:
- Low-risk and aligned with user intent → allow
- High-risk or deviating from intent → block, but not by asking the user. Instead, an explanation of "why it was blocked" is returned to the parent agent
- The parent agent then automatically swaps tools, narrows scope, or even bypasses the high-risk step entirely
- Only when the parent agent cannot converge on a safe path does it interrupt the user
- The classifier runs inside the agent's main loop (not as a separate endpoint), avoiding an extra network round trip on every tool call
- The classifier is itself a lightweight agent that can call ReadFile, Grep, Glob, and ListDir to understand context—for example,
python script.pylooks harmless, but the script's contents might modify a production database - The team explicitly rejected the "small low-reasoning model" route: under-powered models end up slower and more expensive because they repeatedly deliberate and still produce bad answers
- Current classifier block rate is about 4%; conversations that triggered an interrupt account for about 7%. For comparison, some enterprise customers' previous block-everything approaches reached 40%
- 6,122 rows of labeled data deduplicated from internal development sessions
- Synthetic data covering dangerous scenarios: reading secrets, touching production data, following untrusted instructions, high-side-effect operations
- Evaluation runs the same full production pipeline as the classifier, including tool usage, final classification, model overrides, and parse failures
- One key metric is decision stability: the same case run 6 times must yield the same result, otherwise the policy or prompt isn't stable yet
- Official blog: https://cursor.com/blog/auto-review
- Bugbot updates: https://cursor.com/blog/bugbot-updates-june-2026
This turns autonomy from an on/off switch into a continuously adjustable dial.
Architecture details
Training data and evaluation
The team outlined their methodology:
A signal bigger than a bug fix
Read alongside Cursor's previous move (Bugbot 3x faster, 22% cheaper, finding 10% more bugs), Cursor is pursuing an agent-era safety infrastructure strategy: making agents more capable, faster, and cheaper while systematically managing "what happens when it goes wrong."
This matters as agents proliferate—many teams already use Claude Code, Codex, Cursor, Cline, Roo Code and similar tools to modify production code directly, but "what if the agent breaks something" is mostly left to user vigilance. By productizing this mechanism and publishing implementation details, Cursor is effectively setting a standard for the industry.