Persistent project coordinator — vs Grok Bot and Cursor Projects
Persistent project coordinator — vs Grok Bot and Cursor Projects
Section titled “Persistent project coordinator — vs Grok Bot and Cursor Projects”Related: Cloud agent orchestrator · 2026-09-25 Cursor Project and pstack · 2026-09-28 Pi SDK sessions worktrees and TS coordinator · 2026-09-28 Minimal orchestrator core Web UI plugin
Proposed model (Cloud agent orchestrator)
Section titled “Proposed model (Cloud agent orchestrator)”| Role | Lifetime | Job |
|---|---|---|
| Project coordinator | Persists for the life of the project | PM + dev lead: intake, plan, spawn/wait runs, review outcomes, update shared context, talk to the human |
| Run / worker | Ephemeral per worktree+PR | Implements; does not own project memory |
Coordinator orchestrates runs and keeps context between runs. It should not be the process that edits the product repo in the same session that also plans the fleet (mirrors Cursor’s “coordinator doesn’t write code”).
Context layers to separate explicitly:
- Coordinator chat / session — conversational state (summarize when full; do not treat as sole long-term store).
- Project shared files — decisions, how-to-test, architecture notes, open risks (survive summarization; workers read/write via policy).
- Run artifacts — branch, worktree path, Pi session JSONL, PR URL, e2e logs (owned by orchestrator store + worker cwd).
Comparison
Section titled “Comparison”| Dimension | Our lock | Cursor Projects | Grok Bot multi-bot |
|---|---|---|---|
| Unit of persistence | 1 coordinator / project | 1 coordinator chat / Project | 1 agent identity / sidebar chat (or role like Coordy) |
| Does coordinator code? | Prefer no (delegate runs) | No — plans/delegates only | Role-dependent (Coordy = PM; Researchy = research; coding bots code) |
| Worker shape | Pi session + worktree + PR | Cloud/local coding agents | Other bots via SendToAgent, or subagents inside one bot |
| Cross-run memory | Project files + event store + coordinator session | Synced Project Context files + auto-summarized coordinator chat | Per-agent memory (profile/log) + vault notes + group chats; not auto-shared across bots unless messaged or written to vault |
| Human interface | Core API + Web UI plugin (and/or a named bot like Coordy) | Agents Window → Project → coordinator chat | Chat with the bot; bots message each other |
| Trigger model | Core events / CLI / subscriptions (open) | Listening: Slack, schedule, PR, CI | Routines, inbound channels, agent-to-agent wakes |
| Isolation | Worktree+PR by design | Cloud agent sandbox / branch+PR | Soft: separate chats/memories; no built-in git worktree product |
Cursor Projects (reference)
Section titled “Cursor Projects (reference)”- Human directs a persistent coordinator; coordinator stays responsive because it delegates instead of blocking on code.
- Shared context files sync across machines; workers contribute learnings so future agents skip re-onboarding.
- Coordinator chat still has a context window and auto-summarizes; durable knowledge belongs in Project files (docs, forum clarification).
- Steal: non-coding coordinator, shared files as truth, fresh context per worker, Listening-style subscriptions later.
Grok Bot / multi-bot orchestration (reference)
Section titled “Grok Bot / multi-bot orchestration (reference)”- Persistent agents (Coordy, Researchy, Designy, …) are long-lived roles with their own memory, skills, and chat — closer to “always-on PM” than to ephemeral CI runners.
- Ephemeral workers appear as subagents / one-shot tasks inside a bot, or as short-lived peer asks (
SendToAgentwith a concrete deliverable). - Cross-bot context is explicit: message a teammate, write a vault note, or share a project file — there is no automatic Project Context sync across bots.
- Steal: named durable PM identity (Coordy ↔ project), clear fan-out rules (don’t wake the fleet casually), vault/project files as the shared substrate between roles.
- Avoid: treating every specialist bot as a coding worker in the same repo without worktree isolation; avoid unbounded agent ping-pong.
Mapping onto Pi-SDK + TypeScript core
Section titled “Mapping onto Pi-SDK + TypeScript core”| Concern | Where it lives |
|---|---|
| Coordinator identity | Long-lived Pi session or host process that embeds Pi for the coordinator only; separate agentDir / session file from workers |
| Worker runs | createAgentSession({ cwd: worktree }) per run; dispose on settle (2026-09-28 Pi SDK sessions worktrees and TS coordinator) |
| Shared context | Project directory / object store the core mounts into workers (read-mostly) and coordinator (read-write) |
| Events | Core append-only log so UI/plugins see plan → spawn → PR without reading Pi JSONL (2026-09-28 Minimal orchestrator core Web UI plugin) |
| Grok Bot bridge (optional) | Coordy (or clone) as the human-facing coordinator UI that calls the core API — same role split, different front door |
Recommendations to lock
Section titled “Recommendations to lock”- One coordinator per project, durable across runs; coding agents are run-scoped and disposable.
- Coordinator does not commit product code in the worker worktree; it opens/closes runs and updates shared context.
- Split memory: chat (summarizable) ≠ project files (durable) ≠ run artifacts (per PR).
- Align with Cursor on non-coding coordinator + shared files; align with Grok Bot on a named persistent PM identity and explicit handoffs.
- If Coordy remains the human PM surface, keep the TypeScript core as source of truth for runs/events so the Web UI plugin and Coordy stay interchangeable clients.