The specific thing you’re picturing, wiring one existing chat into another so it keeps driving the same subagent across chats, isn’t possible today. Subagents start with a clean context and belong to the one chat that launched them, so a second chat can’t take over the same session. You can still get most of that coordinator/implementor flow without the manual pasting:
- Fork Chat (the
...menu on a message): branch your research chat into an implementation chat. The fork keeps all context up to that point with its own history, so you split off the build without re-priming or cluttering the original. - @ Past Chats: pull a previous conversation into a new chat as context instead of copy-pasting prompts.
- Custom agents: define reusable “coordinator” and “implementor” personas as markdown files in
.cursor/agents/(this project) or~/.cursor/agents/(all projects). They show up in the/menu and your main agent can delegate to them by name. See the subagents docs. - AGENTS.md / rules: keep shared standing instructions there so both agents follow them automatically, no re-explaining each turn.
One heads up: a subagent your agent spawns starts fresh each time and doesn’t inherit the chat, so it isn’t a stateful implementor that remembers across turns. The parent seeds it with what it needs.
The “use another existing chat as the basis and keep following up with it” piece is a genuine gap. Two open requests capture it if you’d like to add your vote: Having fork of the main agent as subagent and Agent-spawned side sessions.