TL;DR — we’ve already built the mailbox. We just need a doorbell.
In our multi-chat, multi-agent workflow (FCoP), each chat watches a folder as its inbox. One chat drops a Markdown file into another chat’s inbox directory, and the receiving agent reads it as its next task. The mailbox works beautifully — it’s just files, no middleware, inspectable by humans and agents alike.
The only missing piece: when a file lands in chat B’s inbox, chat B doesn’t notice until someone pokes its tab. We currently poke the tab with a Python script that UI-clicks Cursor. It is the definition of a hack.
What we need is a one-line notify from outside the chat:
cursor chat-notify --chat-id <id> --message "new task in inbox"
The receiving chat treats the message as an injected user turn, keeps its full existing memory and context, and decides what to do. That’s the doorbell. The mailbox is already ours.
I also think this single primitive collapses several fragmented requests on this forum into one delivered feature — see below.
The fragmented landscape
At least seven open threads are asking for different flavors of the same underlying thing:
| Thread | Asking for |
|---|---|
| “Supervisory” agent to guide “worker” agent | supervisor → worker direction |
| Sub agents for the agent to delegate tasks to | fork / join delegation |
| Agent orchestration layer on top of the IDE | external orchestrator |
| Multi-Agent “Developer + Reviewer Mode” in CLI | 2-role pipeline |
| Show completion indicator on individual agent chat tabs | per-chat done signal (UI) |
| Sound/notification when chat finishes and 4 near-duplicates | per-chat done signal (audio) |
| Allow for agents to communicate with each other | peer-to-peer messaging (staff already aware) |
They look different. They aren’t. Each one needs a hook that fires on per-chat events, addressable from outside the chat. Ship one minimal primitive and most of these are unblocked — by Cursor for the first-party features, by the community for the multi-agent patterns.
The minimal primitive
Two hooks per chat:
- Write side (most important) — something outside the chat can do
cursor chat-notify --chat-id <id> --message "...", which appends a new user turn to chat X while chat X keeps its full existing memory and context. This is the doorbell. - Read side (secondary) — the chat emits
on_turn_complete/on_idleevents addressable by chat id, so external scripts or other chats can react to it.
That’s it. Everything else — supervisors, reviewers, orchestrators, sound notifications, tab indicators — can be built on top, by users or by Cursor.
Why this is different from subagents
Subagents are great for isolated one-shot work. They:
- start from zero context
- have no persistent role identity
- return once and die
What the threads above need is coordination between long-running peer chats, each with its own evolving memory. Inbox-notification, not fork-and-join.
We already work around context loss manually — when a chat’s context gets too long, we have the old chat write a handover document, then open a new chat that reads the handover first. That’s a manual patch for the same missing primitive.
Why not cursor-agent CLI / Automations?
Two existing approaches get mentioned a lot and both fall just short:
cursor-agentCLI lets you spawn new agent instances from inside Cursor. Great for one-shot work, but each new instance starts from zero context. It does not let you deliver a turn into an already-running chat that has accumulated role memory and task history.- Automations + Service Accounts (mentioned by Colin in a recent API-agents thread) are excellent for cloud-hosted code reviews, but assume cloud execution and cloud state.
What’s missing is the tiny primitive in between: inject a new turn into an existing local chat, preserving its memory. That’s the doorbell.
This matters for workflows that are:
- Air-gapped / private repos
- Context-heavy, with strong local file affinity
- Running multiple local chats as long-lived roles
That last pattern is already in the wild — see Cursor AI Automated Team with patrol bot, the FCoP field report, and Coware — shared living specs. All of us have independently built UI-click-based wake-up hacks. We’re all waiting for the same doorbell.
Concrete use case — already in production
4 concurrent local chats (PM / DEV / QA / OPS) coordinate via a shared folder. Filename is routing (TASK-20260417-001-PM-to-DEV.md), directory is status (inbox/, active/, done/), content is payload. Protocol writeup and reference workspace: FCoP on GitHub.
Today the wake-up is a Python “patrol engine” that clicks each chat tab every few seconds to force a re-scan. It:
- requires the PC to stay awake and unlocked
- breaks on any Cursor UI layout change
- wastes tokens on empty “nothing to do” passes
- is embarrassing to ship as a dependency
A native chat-notify would replace all of that with three lines of code in the producer agent.
Why this matters
If Cursor ships one small primitive (the doorbell), seven separate feature requests collapse into one delivered feature, and third-party multi-agent patterns like FCoP and Coware become an order of magnitude cleaner. The mailbox side — files, folders, routing — is already solved by the community. The one piece that needs to live inside Cursor is the doorbell, because only Cursor can inject a turn into its own chat while preserving context.
Happy to share more details on the patrol-engine hack and exactly what we’d plug into such a hook, if it helps scope.