Feature request for product/service
AI Models
Describe the request
Summary
Cursor already aggregates models from multiple providers. The next step is not just more model choices, but an agent stack that learns how to use those models, retains context across sessions, and drives long-running work toward an outcome without the user micromanaging every turn.
This post proposes three optional capabilities, each behind its own toggle so power users keep full control:
Adaptive subagents — pick a model pool; let the parent agent assign roles dynamically and learn which models fit which tasks
Persistent memory — project-level recall so new chats do not start from zero
Goal mode — discuss an objective, then let the agent plan and execute toward it (not a loop with a finish-line checker)
These three pieces reinforce each other. Memory is the foundation. Adaptive subagents improve execution. Goal mode provides scheduling and replanning on top.
Problem: multi-model aggregation creates configuration debt
Today, subagents must be created manually. Each one binds a specific model and a fixed persona (Plan, Debug, Implement, etc.). Explore is the exception. That works well for users who want fine-grained control.
It breaks down when Cursor is used as a multi-model platform. A user with access to Claude, GPT, Gemini, and Composer faces questions like:
Which model should handle debugging?
Should Plan and Debug use different models?
Do I create four or five debug subagents, one per model, to compare them?
A fixed persona per subagent makes this worse. Debug, planning, implementation, and review need different behaviors. One static system prompt cannot serve all task types well. Professional mode is valuable, but a single persona does not generalize across roles.
Proposal 1: Adaptive subagents
Not a “simple mode.” This is an adaptive mode: the user configures which models may be used as subagents, not what each subagent’s personality is.
How it would work
The user selects a pool of models eligible for subagent dispatch.
During a session, the parent agent calls subagents as needed.
The parent agent injects the task-appropriate persona at dispatch time (debug, plan, review, etc.) rather than relying on a persona frozen at subagent creation.
After a subagent completes work, feedback is collected:
Parent-agent evaluation: comprehension, output quality, fit for the task, overthinking on simple problems, giving up on hard ones
User feedback: thumbs up / thumbs down on that subagent’s contribution to the current task batch
Over time, signals feed into memory (see Proposal 2): which models perform well on which task types, stylistic tendencies, recurring failure modes.
Why this fits Cursor’s positioning
Cursor aggregates models. Requiring users to duplicate subagent definitions for every model × every role turns that advantage into setup overhead. Adaptive mode keeps the model roster user-controlled while letting the system learn who is good at what.
Professional mode (current behavior) remains for users who want fixed personas, custom instructions, and explicit subagent definitions. Adaptive mode is for users who want to manage models, not characters.
Proposal 2: Persistent memory (toggle)
The pain point
Non-technical users struggle with a pattern that technical users have learned to work around: every new chat starts cold. They must re-explain what happened in the last session. Even with third-party memory plugins, agents often repeat mistakes on similar problems.
Memory is hard. Stale facts, conflicting entries, and wrong lessons getting reinforced are real risks. That does not make it optional for long-running agent work.
Suggested shape
A built-in, opt-in memory layer (not another plugin users must discover):
Layer What it stores Example
Project facts
Architecture decisions, rejected approaches
“Do not use axios; project standard is fetch”
Task continuity
Where work left off
“OAuth callback implemented; tests pending”
Model profiles
Scores from adaptive subagent feedback
“Composer strong on UI refactors; Claude strong on legacy code reading”
Toggle levels:
Off — current behavior; clean sessions
Light — automatic project summary injection; minimal user friction
Full — includes model profiles, error lessons, and explicit “remember this” entries
Memory should integrate with Goal mode (Proposal 3). A goal that runs twenty turns loses most of its value if turn twenty-one starts in a fresh chat with no recall.
Proposal 3: Goal mode — beyond loop with a completion checker
Claude Code and Codex both recently shipped goal-style features. They solve a real problem: the user should not have to type “keep going” after every turn. Worth acknowledging.
What existing implementations do well
Claude /goal: sets a completion condition; after each turn, a small fast model evaluates whether the condition is met; loops until yes or the user clears it.
Codex Goals: similar pattern with a richer contract (outcome, verification surface, constraints, iteration policy, blocked-stop condition).
Both are useful for tasks with a verifiable end state and evidence already in the thread (tests pass, benchmark under threshold, queue empty).
Where they stop short
Both are fundamentally turn loop + completion evaluator:
work → check condition against thread evidence → continue or stop
The user still writes the goal as a contract. The agent does not first discuss the objective, decompose it into milestones, assign steps to subagents, or replan when assumptions break. Iteration policy is either implicit (Claude) or user-authored (Codex). Neither ties into a learned model roster or cross-session memory by default.
That is a meaningful upgrade over manual prompting. It is not the same as goal-oriented orchestration.
What Goal mode in Cursor could add
- User and agent discuss the objective (can start vague)
- Parent agent decomposes into milestones, acceptance criteria, and dependencies
- Parent agent orchestrates execution:
- which steps it handles directly
- which steps go to which subagent (informed by adaptive model profiles)
- which steps need user approval
- Progress continues with replanning when blocked or when new information changes the path
- Goal state is shared or handoff-friendly between local IDE and Cloud agents
Loop repeats on a timer or blindly between turns. Existing goals repeat until a written condition passes. Goal mode (as proposed here) maintains a living plan toward an outcome and adjusts the plan when the outcome requires it.
Cursor Cloud agents already cover “send it off and let it run.” Goal mode in the IDE would cover “stay in the loop without issuing a command every turn” — complementary, not competing.
How the three proposals connect
User confirms Goal
↓
Parent agent plans milestones and picks subagents (from model pool + historical profiles)
↓
Subagents execute with dynamically assigned personas
↓
Parent agent scores work; user gives thumbs up/down
↓
Memory updates (project facts, task state, model profiles)
↓
Next dispatch and next Goal iteration use accumulated knowledge
None of the three stands alone. Adaptive subagents without memory forget which model worked last week. Memory without goals still leaves the user stepping through each action. Goals without adaptive dispatch still force manual subagent configuration.
Relationship to existing features
Existing Proposed relationship
Manual subagent creation
Kept as “professional mode”; adaptive mode is additive
Explore subagent
Unchanged; read-only exploration stays lightweight
Cloud agents
Goal state should be relayable; cloud for unattended runs, IDE for supervised goals
Rules / @docsdocs / handoff patterns
Memory layer reduces the burden on users who do not know these workflows
Open questions for the team
Memory conflicts: how to invalidate or supersede stale entries when the codebase changes?
Feedback noise: how much weight do user thumbs and parent-agent scores carry before profiles stabilize?
Goal boundaries: budget limits, tool permissions, and when to escalate to the user vs. replan silently?
Evaluator trust: parent-agent self-scoring of subagent output could be biased; should a separate lightweight evaluator model handle scoring?
Closing
Cursor’s strength is bringing many models into one agent workflow. The friction today is that users pay for that aggregation in configuration cost, context loss, and turn-by-turn supervision.
Adaptive subagents, persistent memory, and true goal-oriented orchestration would let that aggregation compound over time: better model selection, less repeated context, and progress toward outcomes instead of progress toward the next prompt.
