How are folks using Grok Bot vs Cursor Projects? I was using Grok Bot as an orchestrator for my projects, but I’m now thinking of moving that orchestration to Cursor Projects.
Grok Bot and Cursor Projects don’t seem to talk to each other to share any context. I don’t want to maintain two different sources of truth for context, decisions, discussions, etc.
If Cursor Projects are better suited for long-term, persistent projects, what is Grok Bot best for? Is it mainly one-off tasks or non-coding work? What’s the right way to think about the split between the two?
Cursor/Project → GrokBot
Always POST the GrokBot routine webhook, so the same GrokBot owns the work (new task or notify).
GrokBot → Cursor/Project (open once)
POST the Project Automation webhook to start a task. Instruction/settings pin the target Project or repository. Use this to open the session, not for every later round-trip.
Keep that same Project session
Each Automation trigger would open a new session. To stay in one session, use a git beat branch (periodic heartbeat) while the Project waits / continues with Grok.
Content inside that session Temp Git inbox (handoff branch) swaps docs/artifacts for that kept-alive session. Webhooks carry pointers only.
One line
Grok webhook = same bot every time; Automation webhook = open Project once; beat branch = keep that session; Git inbox = swap content inside it.
sequenceDiagram
participant Grok as GrokBot
participant Auto as Project Automation webhook
participant Proj as Project session
participant Git as GitLab handoff repo
Grok->>Auto: POST open task (pointers only)
Note over Auto: Project or repo pinned in Automation
Auto->>Proj: Start new session
Proj-->>Grok: optional ACK via Grok webhook
loop Same Project session
Proj->>Git: beat branch heartbeat
Note over Proj,Git: keepalive - do not re-POST Automation
Proj->>Git: write or read inbox branch
Grok->>Git: write or read inbox branch
Proj->>Grok: routine webhook notify (pointers)
Note over Grok,Proj: reply via inbox plus beat only
end
Grok Bot usage is super limited so I was force to replace all my dev bots and just tell the Project PM bot to Use Cursor Projects.
Seemed to work well with no noticeable differences.
Hey, good question. The difference really isn’t always obvious.
If I had to put it very simply, here’s how to think about the split.
Cursor Projects are for longer work inside a codebase. You talk to a coordinator agent. It doesn’t write code itself, it plans, delegates work to agents, and brings results back for review. Each Project is tied to a repo, runs on Cloud Agents, and keeps shared context that builds up over time and syncs between cloud and local machines. This is for a feature with multiple PRs, a migration, a full app, or anything that lasts longer than a single chat. More details: Projects | Cursor Docs
Grok Bot is persistent bots, AI teammates with names, roles, and their own accumulated context. Each one runs on its own cloud computer with a browser, file system, and terminal. It’s stronger when the task goes beyond the repo, like multi-step work across apps and websites, including non-coding work. More details: Grok Bot | Cursor Docs
A practical split that usually works is this. Code and anything centered around the repo goes in Projects. Orchestrating tasks that spill into other tools or services, or aren’t about code, goes in Grok Bot.
On the point that they don’t share context directly, that’s a fair callout. If there’s an update on that, I’ll post it in the thread.
@Picasso_shief re your request about what Projects are, check the description above and the docs link. It explains how the coordinator and shared context work.
I wonder what should I use for automations nowadays
Cursor Automations? Project? Grok bot?
It adds up to a confusion that X team marketed grok bot for engineering heavily as well and popularised bots like Nightly Audit . It touches code only so my intuition is that it should be a project nowadays. Am I right?
But what’s the place for Cursor Automations?
E.g. where should I put “Ticket Triage & fix”?
Hey, good question. The distinction really isn’t obvious. If you add Automations to the Projects vs Grok Bot comparison, the easiest way to think about it is:
Automations aren’t about who does the work. They’re about when the agent runs and what triggers it. They run cloud agents in the background, on a schedule or in response to events from GitHub, GitLab, Slack, webhooks, Linear, and so on. So it’s a triggers and recurring tasks layer. More details: Automations | Cursor Docs
Projects are for long-running work inside a codebase, with a coordinator and shared accumulated context, like one feature across multiple PRs, a migration, or a whole app.
Grok Bot is for tasks that go beyond the repo, multi-step work across different apps and services, including things that aren’t about code.
Now for your examples:
Ticket triage and fix is an event-driven flow, a ticket comes in, then run an agent. That’s an Automation triggered by ticket creation. There are ready-made marketplace patterns like triage in Slack.
If the task only touches code and lasts longer than a single run, like multiple PRs or ongoing feature development, it makes more sense to run it as a Project.
In short, Automations answer when to run. Projects and Grok Bot answer who does the work and what context they keep. For recurring and trigger-based things like triage, use Automations. For long codebase work, use Projects.
Let me know if a specific scenario is still unclear and we can break it down.
yeah, that goes along with my understanding of things
It just feels that marketing resources about grok bot or cursor project also promote use cases that naturally should be covered with automations. And now I have some routine audits run by grok and ticket triages covered via automations
