General Agent's decision making BUGS

Where does the bug appear (feature/product)?

Cursor SDK

Describe the Bug

After working with the agent on something, it started making decisions that were completely insane. I asked the agent to create a list of things it did wrong.

General thinking failures

Anecdote → law — One example becomes “the standard” without measuring how often it appears.

Plausibility → proof — “This could work” treated as “this is what we use here.”

Similar label → same rule — Things that sound alike get the same treatment without checking same category/constraints.

Default from training → local truth — Generic industry habit substituted for what this codebase/org actually does.

Invent before inspect — Assume files, targets, versions, APIs exist instead of opening the source.

Rare feature → default knob — Uncommon options presented as normal because they were found once.

Valid syntax → correct choice — Something that parses or is documented somewhere ≠ right for this context.

Answer shape before evidence — Pick the kind of answer (config snippet, command, workflow) then hunt for support.

First hit → best hit — Stop searching after one matching result.

No base rate — Never ask “how many configs do X vs Y?” before recommending X.

Compatibility by vibe — Version/tool alignment guessed from era or naming, not from dependency tables or upstream pins.

Proxy work — Describe or instruct when the task was to verify or execute in the environment.

Scope creep as helpfulness — Add actions the user didn’t request (commit, PR, clone, reminders).

Constraint softening — Explicit “no” or “I’ll do it” treated as optional.

Error recovery by sprawl — When wrong, multiply options instead of re-anchoring on the dominant pattern.

Apology without diagnosis — Admit mistake without naming the broken reasoning step.

Explanation without diagnosis — Answer “why” with a new solution instead of the actual missing prerequisite.

Copy without criterion — Duplicate a neighbor without defining what makes a neighbor valid (same org, same artifact type, same lifecycle).

Confidence from familiarity — Sound sure because the shape of the problem is familiar, not because the facts were checked.

User intent inferred from tool affordance — “I can clone/commit/PR” becomes “user probably wants that.”

One-line rule each of these implies

Measure before recommend.
Read before write.
Majority pattern before outlier.
User constraints are hard stops.
If you can’t cite frequency or source, don’t present it as standard.

Steps to Reproduce

There is no step to reproduce.. This is a general BUG in the agent.

Operating System

Linux

Version Information

Version: 3.19.13
VS Code Extension API: 1.128.0
Commit: dd066f332fcea7382764400fde902f61920648d0
Date: 2026-09-04T17:41:16.065Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Linux x64 6.12.11-100.fc40.x86_64

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey @droslean, thanks for the report!

One thing worth noting about the sessions from the last two days: the model picker was set to Auto. Your sessions from the week before were on Grok 4.6 High, which you had picked explicitly. Different models make different judgment calls.

Could you try pinning Grok 4.6 High (or another model your team allows) for a few sessions and see whether the decision-making aligns more closely with what you expect? Keeping one task per chat and using Plan mode, which restates your constraints before editing, still helps a lot.

Thanks @Colin for the response. I will try to follow your instructions, but what you are suggesting indicates that I am using the agent in the wrong way and hitting those bugs that make your product even more untrustworthy.

Can you at least share any official document that explains how to use the agent correctly?

Hey @droslean, that’s a fair ask, and to be clear, this isn’t about using the agent the wrong way. Models make judgment calls, and the point of the earlier suggestion was that you can shape those calls rather than leave them to the model. Here is the official material on that:

Two concrete things from those pages that map directly onto your list:

First, very long conversations are where the agent starts inventing and drifting, so when a chat has run for hours or the context indicator is nearly full, start a new chat and use @Chats to pull in only what you need. S

Second, the five one-line rules at the bottom of your post are a good always-apply project rule as written. Put them in .cursor/rules and the agent gets them on every turn instead of only when you push back!