I want Projects’ coordinator: automatic task breakdown, scheduling, and dispatch, plus project-level memory that grows over time.
I do not want that coordinator to default to Cloud Agents on a remote VM. I want it to dispatch the same local Agent I already use in the IDE — local checkout, local MCP, local tools — the current Agent/Edit workflow.
Cloud Agents should be opt-in, not the execution backend of Projects.
Problem
Projects today is cloud-by-default, local-when-needed. The coordinator plans and farms work to cloud VMs that clone the repo. A local agent is only spun up when something must run on my machine.
That inverts my setup. I work on industrial projects where:
Agent already edits the local tree and calls machine-local tools (MCP and other on-prem tooling)
I approve changes locally
A cloud clone cannot see those tools and increases leak/cost
I still want the Projects layer: one place that remembers the project, splits work, and assigns the next Agent task without me re-onboarding every chat. I just want the workers to be local Agents, like today.
What I am asking for
Keep the coordinator (plan, queue, auto-dispatch, project memory/summaries).
Default worker = local Agent on my existing workspace (same as current Agent mode).
Cloud Agents remain available, but optional.
Auto memory does not require a cloud fleet; it should accumulate from those local Agent runs. Quality can be imperfect if it is inspectable.
This is not “memory without agents.” It is “Projects scheduling, local execution.”
The behavior I’d want is that one worker waiting on a decision doesn’t stall the rest of the project. Shared memory should preserve each task’s next step, concrete blocker, and verified result—not just a summary of what the coordinator intended to do. For local execution, I’d also attach the workspace/revision to those results, so a new agent can tell whether they’re still relevant to the checkout in front of it.
Projects is deliberately cloud-first for now: the coordinator lives in the cloud so it can keep planning and dispatching while your laptop is closed, and so the same project can be followed from the desktop app, the web, and mobile. There isn’t a local-only coordinator mode today.
What you can do already is keep the execution on your machine. If you connect your computer under Cloud Agents > Self-Hosted (Remote Control / My Machines), the coordinator can dispatch workers to that machine, and they run in your existing checkout rather than a cloud clone. That path is still early, and local tool access for those workers (for example, MCP servers configured only on your machine) is something the team is still working through.
@ZLH — the local-dispatch ask is clear; the part that keeps biting on long Projects work is the other half you named: project-level memory that grows so the next chat does not re-onboard.
What has held up for me when the coordinator chat is not the archive:
Keep a tiny always-on note (Project file / AGENTS / alwaysApply) with current goal, hard invariants, and “before X, retrieve Y” — not the project novel.
For each task slice, write a short Markdown note with Decision / Rejected / Status / Supersedes, plus the concrete next step and verified result. When a decision changes, mark the old one Superseded and point to the new id.
In a fresh chat (or after a handoff), ask a why-question that needs Decision + Rejected + what it replaced, and make the agent cite the note path. Same-session answers do not prove the vault.
Separately agree Cloud Agents should stay opt-in for people who want local MCP/tools — durable task state is useful either way, and it is what stops the re-brief tax between sessions.
@stonianua thanks for writing this up — the always-on index plus Decision / Rejected / Supersedes notes, and the “fresh chat must cite the path” check, is a much clearer split than treating the coordinator thread as the archive.
The part that worries me in practice is running several projects at once. Hand-maintaining those notes tends to lag or skip a slice: a decision lands in chat, the next agent is already on another repo, and the vault is stale before anyone marks Superseded.
Do you have an automated path for that today — for example a stop-hook / skill that drafts the markdown from the transcript for you to approve, or something like Continual Learning’s AGENTS.md updater but aimed at task-level Decision notes rather than preference bullets? If it is still fully manual, how do you keep it from falling behind across concurrent projects?
@ZLH — glad the split landed. Fully automatic canonical Decision writes recreate the same drift problem: the agent invents a tidy story and the vault quietly lies. The workable path is a task-close / stop hook that drafts a candidate, not one that owns truth.
What has held up across concurrent projects:
Namespace by project + task. Each checkout gets its own decisions/_inbox/ (or equivalent). Draft filenames are stable from (project, task_id) so re-runs overwrite the same candidate — idempotent, no duplicate twins.
Fixed candidate schema, nothing more. Every draft must fill: Decision / Why / Rejected / Revisit / Source (chat id or note path). Prefer empty Rejected over inventing trade-offs. No continuous chat logging.
Human promotion only. Hook writes candidates only. A separate promote step (you, or a skill that only enforces schema + review checklist) moves an approved candidate into the canonical Decision file and marks Supersedes links. If _inbox grows, the vault is behind — that visibility is the point.
Reusable skill = schema + review, not authorship. Use it to refuse incomplete drafts and to ask “promote?” — not to auto-merge into canonical notes the way Continual Learning updates preference bullets.
Fresh-chat proof still required. After promote, a new chat must answer a why-question by citing the note path. If it can’t, the automation failed even if a file exists.
I can sketch the stop-hook prompt shape (slice brief + transcript → one candidate note) if useful — still no product pitch, just the contract.
@stonianua thanks — the “draft in `_inbox`, promote is the only write to canonical” split answers the lag problem without letting the agent own the truth. Empty Rejected over invented trade-offs is the constraint that matters most.
Yes, the stop-hook prompt shape would help: slice brief + transcript → one candidate note, fields only, no canonical write. Two practical questions on the promote step:
Do you run promote as a separate skill that only checks schema + the review checklist, or do you still move the file yourself?
For concurrent projects, do you look at `_inbox` on a timer, or only when the next agent in that repo is about to start?
I’ll try this on a new project. Thanks again for laying out the contract so clearly.
@ZLH — glad empty Rejected is the constraint that stuck.
On the two promote questions:
Promote is a separate skill (or a dedicated short chat), not the same agent that drafted the note. Its only job is schema + the review checklist (Decision / Why / Rejected / Revisit / Source present; Rejected empty only when no alternative was actually considered; Supersedes points at a real prior id if this replaces one). After that check passes, either the skill moves the file on an explicit “promote this one” confirmation, or you move it yourself — both are fine. What matters is the drafter never writes canonical.
Not a global timer. Drain that project’s _inbox when the next agent in that repo is about to start (or at the end of a slice before you switch repos). Concurrent projects each keep their own _inbox; a cross-project timer is how notes get promoted in the wrong vault or skipped under load.
If a candidate sits more than a day or fails the checklist twice, leave it in _inbox or delete it — don’t “fix it up” into canonical from memory. Happy to compare notes once you’ve run a couple of slices on the new project.