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.