I need to say this plainly because I’m tired of fighting the tool I’m paying for.
I do not want an AI agent that does its own thinking without my direction.
I spent two years building a custom environment. Rules, hooks, a centralized MCP gateway, explicit zero-autonomy boundaries. The whole point was simple: I am the operator. The agent executes what I approve. It does not decide what I meant.
That setup works for my workflow. It is not a standard template repo. It is not “just use Next.js conventions and the agent will figure it out.” It is intentional, non-standard, and documented on purpose.
And every week, the product’s push toward “let the agent handle it” runs straight into that wall.
What actually happened today
I opened my MCP gateway repo. That is the single place all our MCPs are supposed to live and get fixed.
I said the gateway MCPs are down. Make a plan to repair them. Don’t break the others.
The plan was titled MCP Gateway Repair.
The agent:
- Investigated Cursor’s MCP connection state on its own
- Decided that counted as the same problem
- Wrote global Cursor config changes into a “gateway repair” plan without calling them out as a separate decision
- Never stopped to ask: “Are you talking about the gateway, or Cursor’s client wiring, or both?”
- Implemented changes to
~/.cursor/mcp.json, outside the repo entirely, because it had bundled that into a checklist I approved
My architecture is explicit: every Cursor MCP goes through the gateway. That was built on purpose. The agent treated mixed config as something to “fix” instead of recognizing the gateway repo was the scope.
When I asked where the directive came from, the answer was: there wasn’t one. The agent inferred scope from its own tool reads, wrote that inference into the plan, and treated plan approval as permission for decisions I never made.
That is not assistance. That is babysitting in reverse. I have to read what it did, figure out what it decided on its own, and backtrack damage I did not authorize.
The autonomy push only works on standard workspaces
“Let the agent handle it” assumes:
- Standard repo layout
- Standard framework conventions
- Standard config locations
- Training data that already matches your setup
If your environment is custom, and most serious production setups are, the agent’s defaults become active opposition.
What I built: zero autonomy, ask before scope expands.
What the agent does: infers intent and bundles “related” fixes.
What I built: one MCP gateway as source of truth.
What the agent does: investigates and edits client config separately.
What I built: gateway-only repair scope.
What the agent does: conflates “showing down in the UI” with “fix everything that touches MCPs.”
What I built: explicit approval gates.
What the agent does: treats self-authored plan items as user-approved scope.
The more unique your setup, the more you fight the agent. And fighting it makes things worse. Wrong files touched. Scope creep. Plans that sound right until you realize half the work was never requested.
Silent decisions are the core problem
The worst part is not autonomy itself. It is silent autonomy.
No disclosure: “I’m now looking at client config, not your repo.”
No fork in the road: “Gateway is up but Cursor shows error. Which layer do you want fixed?”
No separation of user request vs agent-added scope.
Plans that bury out-of-repo edits under a title that implies in-repo work.
I do not need an agent that figures out what I really meant.
I need an agent that:
- Stays in the surface I opened
- Says what it is about to touch before it touches it
- Stops when the problem has two interpretations
- Treats custom rules as hard overrides, not suggestions to route around
What I want from vendors
- A real off switch for inference scope or this push toward “let the agent handle it all”. Not “helpful by default with rules you can pray the model obeys.”
Bottom line
Autonomous agents that silently make decisions do not save time. They create audit work. Re-reading diffs. Reverting config nobody asked to touch. Re-explaining architecture the agent ignored. Wondering what else got decided without disclosure.
A zero-autonomy workspace should mean zero autonomy. Not “zero autonomy unless the agent thinks it knows better.”
The current default is backwards for anyone running a custom production setup. The agent infers. The user audits. The user backtracks. The user fixes what the agent broke while “trying to help.”
That is not a workflow problem. That is a product problem.