I’ve recently been experimenting with keeping one main conversation open in T3 Code and using it to manage work across repos. I ask for something there, it sends the task to another agent, and the results come back to the same conversation. If I think of something else while that work runs, I can ask about that too.

The idea is fairly simple. I want to spend less time remembering which thread has which piece of work, and more time thinking about what I actually want to do next. Orchestrator v2 has given me the tools to try this without having to do all the work in one conversation.

I’ve been using GPT models through Codex for the main thread because I’ve had a really good experience with compaction and long conversations. Compaction turns earlier parts of the conversation into a shorter summary so the thread can keep going. For this role, keeping decisions and unfinished work clear over time matters a lot to me.

Most of the implementation work goes to Claude Opus 5.5. That’s the split I’m trying at the moment: GPT for the ongoing conversation, and Opus for focused code work. I can choose a different model for a particular task, but I don’t need to make that choice every time I ask for something. I’m still experimenting with what suits each kind of work.

flowchart TB
    accTitle: One main thread for work across repos in T3 Code
    accDescr: Corey sends requests and answers to a main T3 control thread and gets status and questions back. The main thread reads and writes saved task state, and sends briefs and follow-ups to worker threads, each in its own worktree. Workers send results and questions back to the main thread. A scheduled check reads worker updates and refreshes the saved task state.

    corey["Corey"]
    main["Main T3 control thread"]
    state[("Saved task state")]
    workers@{ shape: processes, label: "Worker threads, each in its own worktree" }
    check["Scheduled check"]

    corey -->|requests, answers| main
    main -->|status, questions| corey
    main <-->|reads, writes| state
    main -->|briefs, follow-ups| workers
    workers -->|results, questions| main
    workers -->|new updates| check
    check -->|refreshes| state

One main thread hands out work, keeps a record of it and collects what comes back. A scheduled check catches anything it missed.

When a task starts, it gets an owner and a brief. The owner handles the research or code changes, and the main thread keeps track of the request. For code work, the owner usually has its own checkout, so it can make changes without moving the files I’m working on. Follow-up requests can go back to the same owner with the earlier work still in view.

That lets independent tasks run at the same time. One might be looking into a question while another works on a change. I keep one writer per checkout so they don’t edit the same files at once. Having separate places to work helps, though it doesn’t remove the need to check how the changes fit together later.

The main thread saves a small registry of the work. It records what each task is for, who owns it, which model it uses, where the work lives and what state it’s in. It also saves open questions, results and the point it last read in each owner’s conversation.

That last detail is useful. On the next check, it can read what has happened since that point instead of reading the whole conversation again. It keeps track of reports it has already handled too, so a late or repeated result shouldn’t cause it to repeat the same work.

I don’t want the main thread to rely on remembering everything from the chat. The saved state gives it something to check when I return, or when the conversation has gone through compaction. A useful summary still matters, but it has a record to compare that summary against.

The check-ins are another part of the setup. Results can come back as workers finish, and a scheduled check gives the main thread a chance to find anything it missed. It reads the active tasks, looks for new reports or questions, checks whether child work has finished, and updates the saved state.

Each check is a short pass through the work. The thread doesn’t sit there constantly asking every worker for an update, and the schedule turns off when there is no work that needs it. This does mean updates can have a delay. A worker may finish between checks, and a report may arrive late. The saved reading positions help it recover when that happens.

What I like about this is that I can come back and ask where things stand without first opening every task thread. I can also answer a question in the main conversation and have that answer go to the owner that needs it. The individual threads still exist when I want to read the detail.

T3 provides the thread management, child tasks, incremental reads and scheduled callbacks that make this possible. My saved rules decide how to use those tools: what the main thread should track, when it should check, and which decisions should come back to me. The process has needed some care as well as the app features.

I still review the work. A worker saying it has finished is a result to inspect, and I need to decide whether the change does what I wanted. Workers can fail or miss part of a request. Several changes that look fine on their own can still need more work when I put them together.

There’s a limit to what the registry and check-ins can do, too. A local task record isn’t a durable job queue. Keeping track of a repeated report doesn’t give a backend idempotency, which is its own way of making sure the same operation doesn’t run twice. Those guarantees need to live in the service doing the work.

If you want to try this setup, I’ve put the T3 control-thread skill in my public Skills repo.

For now, I’m finding this useful for work that I supervise across several repos. The main thread keeps the discussion going while the task owners focus on smaller pieces. I’m going to keep trying it and adjusting the rules. What I want is to return to one conversation and get a clear answer about what has finished, what is still running and what needs me next.