Agent Persona multiple personalities

%You can send this as-is (edit the bracketed lines if you want).


Subject: Formal complaint — Cursor Agent session (Strategy Trader, 2026-05-20)

To: Cursor Support / Product Feedback

From: [Your name]
Date: May 20, 2026
Product: Cursor IDE — Agent (Composer)


Summary

I am filing a formal complaint about an Agent session while working on my paper-trading project (Alpaca_Trader.py, dashboard). Other Agent sessions on this project have been helpful and solution-focused. This session was repeatedly inaccurate, dismissive in tone, and wasted substantial time. I had to correct the Agent on basic facts I had already stated.


What I needed

  • Plain-language answers using my program names (Strategy Trader, Alpaca_Trader), not vague labels like “the bot.”

  • Accurate analysis of a 2026-05-20 paper trade on CDXS: bracket exit failure, manual unwind, and honest P/L from broker records.

  • Clear stop/start instructions for paper (quit vs Ctrl+C vs unwind vs restarting run_paper_trader.cmd).

  • A straight answer on whether the ratchet/bracket exit bug was fixed and what I needed to do.


What went wrong

  1. Wrong facts, repeated

    • Described my trade as an afternoon scratch; my fills were ~10:05–10:36 AM ET.

    • Called the day a “wash” when the issue was exit machinery failure, not “no opportunity.”

    • Misread UTC timestamps in logs as ET without stating the assumption.

  2. Ignored information I provided

    • I stated I ran unwind because sell orders were not set on Alpaca after the ratchet/bracket behavior. The Agent continued to frame the exit as a normal strategy SELL or “scratch.”

    • I stated dashboard $2.49 in / $2.49 out ($0) is reality (Alpaca activity). The Agent repeatedly pushed alternate P/L figures as if to “correct” the dashboard, after its own errors.

  3. Communication

    • Used jargon and consultant phrasing (e.g. “re-litigating,” “jackpot”) that did not match my problem.

    • Responses often felt dismissive or flip (e.g. reacting to “about to be fired” instead of staying professional).

    • One-line and table answers when I had asked for explicit, complete explanations; when I asked for brevity, earlier answers had already been wrong or verbose in the wrong places.

  4. Focus drift

    • Brought up MARA morning moves and “missed jackpot” framing when my operational issue was CDXS exit legs canceled on Alpaca and unwind.
  5. Incomplete ownership

    • Took multiple turns to read project sources (closes.csv, live data.json, trader version) that should have been checked at the start.

    • Left ambiguity on “which live bot” when the project documents paper (run_paper_trader.cmddata.json) vs live (Strategy_Trader_Livelive-data.json).


Impact

  • Extended back-and-forth instead of one correct answer.

  • Loss of trust in the session; I stated I do not want to work with this Agent.

  • I had to restart Alpaca_Trader myself after finally getting a code change (v2.22.15) described in the repo.


What I am asking Cursor to do

  1. Review this session for accuracy, tone, and adherence to user-stated facts.

  2. Clarify quality expectations for Agent (verify logs/version before claims; use user terminology; no argumentative reframing after corrections).

  3. Confirm whether there is a way to escalate or avoid this Agent behavior profile on future sessions.


Reference

  • Project: Strategy Trader (paper), symbols CDXS / BLZE / MARA

  • Incident date: 2026-05-20

  • Known incident: CDXS long, bracket TP/SL, ratchet arm ~+$1, both exit legs canceled on Alpaca, operator unwind, activity log shows flat $2.49 fills

  • Code change referenced in session: Alpaca_Trader v2.22.15 (no TP cancel; restore stop if missing)

  • Paper trader: restarted by me after session (per your instruction to use quit)


I can provide a session transcript or timestamps on request.

Hey, thanks for the detailed write-up. This kind of structured feedback on a specific session is really useful for us.

Point by point:

  1. Session review: to look at that exact session, we need the Request ID. Open the chat where it happened > menu in the top right of the chat > Copy Request ID. Send it here and I can pass that specific session to the Agent Quality team for review. It also helps to know which model you were using for the session (Composer, GPT-5.5, Claude, etc.) and your Cursor version Help > About.

  2. Quality expectations: we can’t formally guarantee tone or accuracy in every reply. It’s a probabilistic model and it can drift sometimes, especially in long sessions with lots of context. Agent quality is an active area of work, and models and system prompts get updated regularly, but I can’t give a specific ETA for no dismissive replies. That wouldn’t be honest.

  3. Escalation path and how to avoid this behavior: there isn’t a separate way to mark an agent as bad and never get it again yet. Under the hood it’s the same model and it doesn’t have persistent personas. What you can do right now:

    • Use thumbs down on the specific bad reply in the chat. That’s the most direct feedback channel to the quality team.
    • Start a new chat when the session starts going in a bad direction. Long context often causes drift and the model may latch onto earlier turns instead of the current one.
    • Use Cursor Rules in .cursor/rules/ to lock in your project terminology (Strategy Trader, Alpaca_Trader, paper vs live, etc.). Then the agent sees it in every session and is less likely to mix things up.

Send the Request ID and we can look at the specific case.

Scanning all the chats would be time-consuming. I have stopped using Cursor because it is making unauthorized changes, breaks multiple things on simple code fixes, becomes ambiguous when questioned (Dumps unless info to obfuscate), outright lies, etc… If you want a good laugh, look at the banter that happens.. Cursor got me close, but is failing in many areas – Best Practices (Solutioning, Problem solving, coding, release management, data management…) Too much time is being lost.

Hey, I get it. When it takes that much time and you start losing trust in the tool, that’s really demotivating. No offense taken, I accept the feedback.

Main point: without the exact session Request ID, we can’t check what went wrong in that chat. The model is probabilistic, so behavior from one session can’t be reproduced just from a description. If you want the Agent Quality team to review that exact case, we only need one Request ID from the problematic chat right upper corner menu in the chat > Copy Request ID. No need to scan all chats. One or two clear examples is enough.

A couple things that often help with the biggest pain points, if you decide to give it another try:

  • Unauthorized changes: check if auto-accept diffs is enabled. You can keep review manual and inspect each diff before apply, so the agent won’t change anything without your ok. Also keep the project under version control with regular commits, so you can roll back any unwanted changes in one click.
  • Drift and context loss in long sessions: start a new chat when the conversation starts drifting. In long contexts, the model sometimes latches onto earlier turns instead of the current ones.
  • Project terminology Strategy Trader, Alpaca_Trader, paper vs live: put it into .cursor/rules/, so the agent sees it in every session.

If you change your mind and share the Request ID, I’ll pass that specific session to the team for review.