My typical workflow right now includes spinning an agent to get informed on a topic, then splitting the chat to a coordinator and implementor, with the coordinator helping me manage artifact files / instructions and create prompts, while I paste the prompts into the implementor so it does not lose any nuance with the current context. I currently have to do this manually as I do not know how to get an agent to continuously refer to the same agent without starting with a new context every time.
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.
tho why is it that in some occasions a main agent can trigger an already existing subagents chat to continue a conversation? i cannot recreate it tho sometimes it uses the same chat sometimes creates a new subagent
It’s not random. Subagents can be resumed: each run hands back an agent ID, and if the main agent passes that ID on the next turn, the subagent picks up with its full previous context instead of starting over. When it doesn’t pass the ID, you get a brand-new subagent. That’s the “sometimes the same, sometimes new” you’re seeing.
To make it repeatable, tell the main agent to resume that specific subagent (each run returns an agent ID you can reference), e.g. “resume agent and keep going,” rather than leaving it to decide. There’s a short writeup in the Resuming subagents section of the subagents docs.
Two things still hold: a subagent starts with a clean context on its first launch (the parent seeds it with what it needs), and it’s tied to the chat that launched it, so you can’t resume it from a different chat.