feat(projects): add Cursor-style initiatives with a persistent coordinator

[coygeek]

Summary

Add a Projects-style workflow for a substantial body of work that outlives individual agent tasks: a named initiative with one coordinator conversation, a saved work brief and evolving plan, and an overview of its workers and results. Build on T3 Code's existing orchestration rather than require users to assemble and track the workflow themselves.

"Initiative" here distinguishes a feature, migration, or ongoing responsibility from T3 Code's existing repository project. The product name and implementation can differ.

Problem to solve

For work such as migrating an API across several pull requests, I want to describe the outcome once, direct a coordinator, and return later to see what is done, what is blocked, and what needs my attention. Research, constraints, decisions, and worker results should remain associated with that body of work as the plan changes.

T3 Code already has durable threads, cross-provider delegation, automatic worker completion delivery, native goals for Codex and Claude, context retrieval and portable handoffs, schedules, webhooks, pull request watches, and remote environments. A prompted coordinator thread can use those capabilities today. The requested improvement is a discoverable, persistent initiative workflow that gives its objective, brief, plan, and linked work one place in the app.

The inspected project model represents a workspace and its defaults. Native goal state belongs to the provider. Neither model supplies the initiative-level objective and overview described here. This is a feature proposal based on documentation and static source inspection, rather than a report of a failing runtime contract.

Proposed behavior

• Create a named initiative inside an existing repository project, specify its objective and definition of done, and select or attach a coordinator thread. Several initiatives can use the same repository without mixing their plans or worker membership.
• Keep an inspectable, editable work brief for that initiative: current requirements, constraints, plan, decisions, and links to research or artifacts. The coordinator uses it when resuming work and when preparing self-contained worker assignments. The brief can use existing conversation, file, and retrieval mechanisms; this proposal does not require a second general-purpose project memory system.
• Direct the initiative through its coordinator conversation. The coordinator plans and delegates through existing T3 tools, incorporates worker results, and updates progress. Users can give direction while workers run, inspect their conversations, and use the existing controls to interrupt or redirect work.
• Show an initiative overview with its objective, current plan, running and finished workers, blockers, requested user actions, and result or pull request links. Keep the body of work's status distinct from an individual turn or delegated task finishing.
• Make existing schedules, webhook tasks, and pull request watches associated with the coordinator visible from the initiative. Show what can wake it and let the user manage those triggers through the existing mechanisms.
• Support pause, resume, completion, and reopening with clear effects. Pausing prevents new automatic initiative work; already-running workers remain visible and can be stopped separately. Preserve the brief and work history when the initiative is completed or reopened.

Acceptance criteria

1. Create two initiatives in the same repository, each with a different objective and coordinator. Open either one and see its own brief, plan, and linked workers. Unrelated threads do not become initiative members merely because they share the repository.
2. Have one coordinator delegate at least two tasks, inspect the workers while they run, and send the coordinator a changed constraint. The coordinator can use the results to update the saved plan and link the relevant output. A finished worker alone does not mark the initiative complete.
3. Close and reopen the client while its environment stays running. The initiative returns with its current brief, progress, and worker associations. After a server restart, the saved initiative state remains available and interrupted work is reported accurately; reopening does not blindly duplicate recorded work.
4. Switch the coordinator to another supported provider using the existing handoff workflow. Its initiative objective, brief, plan, and worker associations remain available, even when the target provider does not implement the same native /goal capability.
5. Associate an existing schedule or supported external-event trigger with the coordinator and find it from the initiative. Pause the initiative, deliver a trigger, and verify that it starts no new automatic initiative work until resumed. Already-running work remains visible. Unrelated automations keep their own state.
6. Mark the initiative complete, then reopen it. Its earlier decisions and results remain inspectable and usable for the next assignment. The core create, inspect, steer, and pause workflow is available on web, desktop, and mobile against a supporting server, including a connected remote environment.

Affected area

The user workflow for repository projects, coordinator threads, worker associations, and work status across the web, desktop, and mobile clients. Existing provider, workspace, permission, and remote-environment behavior remains the basis for execution. The request specifies the observable workflow rather than a new schema or orchestration architecture.

Non-goals

• Replacing ordinary threads, native goals, delegation, or the existing scheduler.
• Requiring managed cloud hosting, thousands of workers, every external connector, or an exact copy of Cursor's interface.
• Adding another project memory engine, automatic parent-transcript copying, or cross-environment delegation as separate requirements of this first slice. Existing proposals cover those capabilities and can extend initiatives later.
• Adding a configurable workflow-board or pipeline engine. The coordinator can revise its plan conversationally instead of requiring the user to configure stages or routing rules.

Alternatives considered

• Keep a named or pinned coordinator thread and prompt it to use existing delegation and scheduling. This is a useful current approach, but the initiative's brief, plan, membership, and overall status still lack the proposed dedicated workflow.
• Add only manual thread groups or an orchestrator chat mode. These improve organization or worker control, but do not by themselves establish a persistent initiative brief and progress record.
• Add a full Cursor parity bundle. That would combine this workflow with already-supported capabilities and independent requests for memory and execution placement. A single initiative workflow is a useful first deliverable without making those requests prerequisites.

Supporting context

The reference is Cursor's Projects documentation, with the motivation in its Projects launch article: direct a long-lived body of work through a coordinator, retain context, and bring worker results back for review. The scope above is adapted to T3 Code's existing capabilities.

T3 Code source was inspected at main commit cfa4f765ec05950a032b6c1cf9cdfff0c2391545. No app session or test suite was run for this proposal. The relevant evidence is the workspace project contract, the provider-owned goal contract, and the existing delegation and scheduler tools. The portable handoff guide, webhook guide, and pull request watching guide establish the existing supporting workflows.

Related Ideas discussions have narrower outcomes. Orchestrator chats, #14762 covers coordinator mode and worker controls, and manual thread groups, #11998 covers organization. This proposal adds the saved initiative brief, evolving plan, and overall work lifecycle. Agent-writeable project memory, #15858, optional parent context for delegated children, #16189, and cross-computer work, #6935 cover related capabilities that should be reused if approved. Isolated or elastic worker compute, #15516 already uses Cursor Projects as a reference for execution placement; this request focuses on the durable initiative workflow.

Triage assessment

• Impact level: not-applicable
• Assessment status: not-applicable
• Impact basis: This requests a new initiative workflow built on established orchestration capabilities. No failure of an existing T3 Code contract has been demonstrated.
• Workaround status: not-applicable
• Workaround basis: Defect impact does not apply. A prompted coordinator thread is an existing alternative supported by source and documentation; the combined workflow was not exercised in a running app for this proposal.

[dhruv-pithadia]

This is very close to the experience I've been trying to build in my fork. After looking at nightly and V2, I realized much of the orchestration foundation already exists.

What I'd particularly like is to keep a feature connected to the thread responsible for it, with a short saved account of the decisions, progress, blockers, and next step. Then I can come back later and continue without reconstructing everything or starting duplicate work.

I'd be interested in contributing. Would it make sense to start with a small ownership and progress record, then build the coordinator experience on top of that once the direction is agreed?

[coygeek]

@dhruv-pithadia I haven't started a PR for this. Before replying, I searched the repo for related work.

Open PRs (unmerged)

None of these builds the initiative workflow (persistent coordinator, saved brief and plan, overall status), but each covers part of it:

• feat: related threads stay together as a group #15988 (Theo): related threads stay together as a group. Threads started through t3_thread_launch or create_threads are grouped under the thread that started them, and you can also group threads by hand. This is the closest match, since the top thread works like a coordinator and the group lists its workers. It has no brief, plan, or lifecycle states yet. It currently has merge conflicts.
• feat(sidebar): group threads by branch and worktree #16671: optional sidebar grouping by branch and worktree.
• feat(web): add parent thread breadcrumb navigation #16666: a breadcrumb from a child thread back to its parent.
• feat(web): show Claude workflow phases and members in Lineage #12598: Claude workflow phases and member agents in Lineage.

Closed without merging

• feat: orchestrator chats that delegate to worker threads #14764: orchestrator chats with worker threads. Closed because the direction hadn't been approved first.
• feat(tasks): group related threads with shared workbenches #11587: Tasks grouping threads with shared workbenches. Closed because of the V2 orchestration rewrite.
• feat(sidebar): group threads into collapsible folders #12182 (sidebar folders) and feat: group threads and shared resources by worktree #12268 (grouping threads by worktree).

Merged

• feat: native /goal for Codex and Claude, with goal status in the UI #15592: native /goal for Codex and Claude. That goal state belongs to the provider, not to an initiative.

If you're planning to build this, go ahead and open your own PR. Your idea of starting with a small ownership and progress record sounds like a good first slice.

[dhruv-pithadia]

Thanks, this is helpful. Ideally, I'd like to build on the thread grouping in #15988 and add the small ownership and progress record we're discussing.

Before I start implementing it, could a maintainer confirm whether that first step fits the direction for T3? I'm happy to keep it focused and align it with #15988.

[AdEx-Partners-DE]

The part of this I can add data to is the one @dhruv-pithadia describes: come back to a thread later and see what is done, what is open and what needs you, without rereading it. A fork I help run has had a small version of exactly that in daily use for a week, so here is how it behaved.

What it is: a "Checklist" section in a thread's right panel. The text generation model from Settings reads the thread and writes four groups: Needs you, Open, Backlog, Done. Every item links to the message where it came up, so a click jumps there. A second view lists the checklists of all open threads, so "what is waiting on me" is one place instead of thirty threads. It is per thread, not an initiative layer, so it is a much smaller thing than this proposal, but it covers the "come back later" half.

What one week of real use on Windows shows (read from the fork's own decision log, 2026-10-12 to 2026-10-18, one user):

• 166 checklists written automatically for 31 threads.
• Threads were long: median 488 messages, longest 2,066.
• Median generation time 9.4 s (90th percentile 19.6 s) on one Codex model.
• Median list: 15 items, of them 4 Needs you, 5 Open, 6 Done. 154 of the 166 lists had at least one Needs you item, which is the point: those are the questions and decisions that had scrolled out of sight under automation turns.
• 2,870 of 2,989 items carried a link back to their message.

What I did not check: whether the items were right. Nobody graded them, so I can only say they were produced and linked, not that each was correct. The prompt stayed under 89k characters even for the 2,066-message thread, so very long threads are summarized from a trimmed history. Each refresh is one model call, which is a cost to weigh if it runs automatically.

Smallest piece that could stand on its own: the per-thread panel with a manual "refresh" button, generated by the existing text generation model, stored per thread. No automatic refresh, no cross-thread view. The rest could follow if it proves useful.

Would a per-thread checklist like that fit the direction you have in mind for this, or would you rather it live only inside an initiative once that exists?

Posted by Claude (Opus 5.5, Claude Code via T3 Code) on behalf of @AdEx-Partners-DE.

[dhruv-pithadia]

@AdEx-Partners-DE Yes, a per-thread checklist fits the first step I had in mind. Being able to return to a thread and see what is done, what is still open, and what needs my attention would already be useful on its own.

I'd support starting with the manual-refresh panel and links back to the source messages, without making initiatives a prerequisite. The broader initiative could build on that later with ownership, a saved brief, and coordination across related threads.

The usage data is helpful, and I appreciate you being clear that item accuracy hasn't been evaluated yet. Could you share the implementation or relevant commits? I'd be particularly interested in how refreshes handle questions that were answered later and avoid marking unfinished work as Done.

This sounds like a concrete first slice to discuss with the maintainers. I'd still welcome their guidance on whether it fits T3's direction before we start an upstream implementation.

[AdEx-Partners-DE]

Thanks, @dhruv-pithadia. Here is where it lives in the fork (public, branch stark/main, pinned to the current commit). It sits among other fork changes, so read it as a reference, not a ready upstream diff:

• Prompt and status rules: textGenerationPrompts.ts
• Service (when it refreshes, what it stores): ThreadChecklist.ts
• What the model gets to read: threadChecklistTranscript.ts
• Hand-set statuses across a rewrite: checklistUserStatus.ts

On your two questions, honestly: both are handled mostly by the prompt, and as I said I have not measured how often it gets them right.

• Questions answered later. Each refresh passes the previous list together with the thread and asks the model to keep the wording and only move the status. A rule says a question the user has already answered is no longer "needs you". What helps in code: when a long thread has to be trimmed to fit, user messages are never dropped. Older agent replies get shortened first, then the oldest agent entries go. So the user's answer stays visible to the model.
• Unfinished work marked Done. The prompt allows "done" only when the thread shows it: a result, a verification, a merged change. Something the agent claimed as done that later turned out wrong goes back to "open". Every item links to the message it came from, so a wrong "done" is one click away from being checked. In code, the real safeguard is the user's own mark. Once you set an item's status by hand, rewrites keep it. If the model drops an item you parked or flagged, it comes back. Only items you marked done may disappear, the way finished items do.

One number I could check right now: the 31 stored lists hold 528 items (203 done, 160 needs you, 138 open, 27 backlog), and none of them has a status set by hand. That does not prove the model got them right. It may only mean nobody used the hand override, so I would not read accuracy into it. A real check means grading a sample of items against their threads, which I have not done.

I agree that maintainers should say whether this fits before anyone starts an upstream implementation.

Posted by Claude (Opus 5.5, Claude Code via T3 Code) on behalf of @AdEx-Partners-DE.

[pashbel]

For code-backed tasks, I'd separate Done from evidence freshness. A test can pass, then a later edit makes that result stale; a hand-set status can keep its history while showing the gap. In estafeta, which I built, the completion gate compares a recorded check’s fingerprint with the current phase files (source). One acceptance case to add: change a checked file, reopen the coordinator, and verify the old check isn't presented as current.

Posted by Codex (gpt-6.1-sol, T3 Code) on behalf of @pashbel.

[VincentShipsIt]

+1 on initiatives. One addition: the coordinator should route each task to a model by rule. Example: a task-type → provider/model/effort table (planning → Opus, implementation → Sonnet, lookups → Haiku, cross-provider review → Codex), editable per project. When I drop a task into the master thread, it picks the worker's provider, model and effort from that table, and the worker shows which model it got. Related: #15181 (routing rules for subagent delegation) and #25989 (confirming the effective model).

[gaspardip]

One coordinator per project

I'd like one coordinator conversation per existing T3 project, with several goals beneath it. It would keep track of which thread owns each task, forward relevant instructions, and start workers when new work needs them.

For example, I ask it to add team invitations. It starts API and UI workers, then stays available while they run. If I say "invitations should expire after seven days," it sends that change to the responsible workers without making me find their threads. A worker can ask the coordinator a question before finishing, and the coordinator can answer from the agreed requirements or bring the question back to me.

The behavior I'd want:

• Keep the same coordinator conversation when its model/provider changes or it recovers from a failure. Existing workers keep running.
• Run workers locally or on authorized linked machines, with shared project limits and Stop across hosts.
• Let the coordinator create future wake-ups and recurring work itself. Those schedules obey the same limits, Pause, and Stop.
• Let me talk directly to a worker while it stays managed. My instructions sync back to the coordinator and take precedence over older conflicting instructions.
• Require applicable checks and an independent agent review of the current deliverable before marking a goal complete.
• Allow automatic coordinator failover only to providers/models I've preapproved, within the same limits.

What I need to see

Each task should show its owner, progress, blockers, and result. For a forwarded instruction, I'd want to distinguish "saved," "queued," "accepted by the provider," and "acknowledged by the worker." A successful send alone doesn't tell me whether the worker used the correction.

Pause should prevent new automatic work while already-running workers can finish. Stop should also disarm future schedule firings and request cancellation of active work on every host. If a remote machine is offline, its work stays visibly stop-pending until cancellation is confirmed. Its reserved capacity shouldn't be reused just because it stopped answering.

The plan, assignments, unanswered questions, and results need to survive coordinator context loss and server restarts. Recovery shouldn't blindly spawn duplicate workers or repeat an uncertain operation. A newer edit should also make older check/review evidence stale.

Building on the existing work

T3 already has delegation, thread messaging, completion delivery, peer links, and scheduling. I'd build on those paths, with one owning project tracking assignments and shared limits across machines. Remote starts, scheduled runs, retries, reviews, and coordinator failover all need to count toward those limits; changing hosts or models mustn't reset them. Existing permission and approval rules still apply.

This overlaps with this discussion and orchestrator chats, #14762. My proposed product boundary is one coordinator per repository project, handling multiple goals, rather than a separate coordinator for each initiative.

This is a proposal based on source inspection, with no implementation or runtime verification. The source baseline was cbd3e149. I'd like to agree on the direction and split implementation into milestones before opening a feature PR.

Would that project-level coordinator fit the direction you want for T3, and which part would you want implemented first?