I’ve been experimenting with a workflow where one Codex thread (session) acts as the chief, and separate driver threads work on individual changes. I mainly use it for cctop, my macOS menubar app for monitoring AI coding sessions, where I often have several features/bug fixes going at once.

So far, this helps me spend way less time explaining how I want agents to work. The chief keeps that workflow context and passes the relevant parts to each driver.

In this post, I want to share my setup and the reasons behind it. It’s very subjective, but I hope some of the ideas can provide inspiration for your agent setup.

Project context & workflow context

Project context explains what cctop is and how its code works. Workflow context explains how I want changes developed: planning, design review, testing, and getting a PR ready.

The workflow context is harder to maintain with just instructions or skills and trusting that agents will always invoke them at the right time. Additionally:

  • I want to have a companion to talk about development processes for the project and help me improve it.
  • I want to capture why each step exists so I can see whether it works and keep changing it. But AGENTS.md and skills aren’t good places for recording that reasoning.
  • When testing a new workflow, I don’t always want it to affect every thread. Updating a shared skill makes it hard to control which running threads pick it up.
  • I want to compare how we worked last week with how we work now. But I’m too lazy to keep a workflow journal myself.

So I started using a long-running thread to help me improve the workflow itself.

What the workflow looks like

In my setup, there are 3 main roles:

  • Chief thread: keeps project and workflow context across changes, delegates work, and tells me when I need to take actions.
  • Driver thread: a separate thread (NOT subagent), usually with its own worktree, branch, and persistent goal, that implements the change and gets its PR ready to merge.
  • Watchdog thread: checks progress on a schedule and helps the chief keep up with drivers.

The chief has its own worktree for saving context. After me, the chief thread knows the most about the project and its workflow. Both the chief and drivers can use subagents.

I often talk directly to drivers to test changes and give feedback. Sending every message through the chief would be very inefficient.

sequenceDiagram
  accTitle: Feature development
  accDescr: I approve the direction with the chief, which delegates to a driver. The driver implements and tests, then reports back through the chief. I may test and give feedback directly to the driver, then get an updated summary from the chief before merging.
  actor Me
  participant Chief as Chief thread
  participant Driver as Driver thread
  participant Work as Project work and PR

  Me->>Chief: Discuss and approve direction
  Chief->>Driver: Delegate the work
  Driver->>Work: Implement and test

  Driver->>Chief: Report progress, blockers, and readiness
  Chief->>Me: Summarize status

  opt Direct testing or feedback
    Me->>Driver: Test and give feedback
    Driver->>Chief: Report updated status and readiness
    Chief->>Me: Summarize status and report when ready
  end

  Me->>Work: Merge

For cctop, I ask task drivers to:

  • Start UI changes with an HTML prototype for me to approve, optionally asking a subagent using design skills like Impeccable to spot things I may miss.
  • Test the branch’s app end to end, for example with Computer Use to start real AI sessions and check how cctop shows them.
  • Fix problems found during app testing before opening a PR, then stay with it until CI and agent review pass.

I then manually test every user-facing change before merging it myself.

What I use the chief for day to day

I can open the chief thread and ask for an update on everything: what each driver is doing, which PRs are blocked or waiting for review, and who needs my decision.

After one PR merges, 3 other branches may need rebasing. I tell the chief once, and it asks each driver to rebase and continue its work.

I also dump future ideas there and ask it to save them in a file. We can focus on the current release, then return to that discussion later.

Updating workflow skills

The chief helps me choose which drivers should adopt a change to our shared guidance (usually a skill), so I can try workflow changes selectively.

sequenceDiagram
  accTitle: Updating workflow skills
  accDescr: I approve a workflow change with the chief. It records the change in shared guidance and sends it to affected drivers. They report adoption or problems, and the chief summarizes the rollout for me.
  actor Me
  participant Chief as Chief thread
  participant Guidance as Shared guidance
  participant Drivers as Affected driver threads

  Me->>Chief: Approve a workflow change
  Chief->>Guidance: Record the change
  Chief->>Drivers: Share the relevant update
  Drivers->>Chief: Report adoption or problems
  Chief->>Me: Summarize the rollout

Thread cleanup and retros

Before archiving finished threads, I ask the chief to read their conversations and find workflow improvements we can discuss.

sequenceDiagram
  accTitle: Thread cleanup and retros
  accDescr: I ask the chief to review finished driver threads. It brings lessons and cleanup candidates back to me. After my approval or revisions, it records the approved lessons in shared guidance and archives confirmed finished threads.
  actor Me
  participant Chief as Chief thread
  participant Tasks as Finished driver threads
  participant Guidance as Shared guidance

  Me->>Chief: Request a retro and cleanup
  Chief->>Tasks: Review completed work
  Chief->>Me: Present lessons and cleanup candidates
  Me->>Chief: Approve or revise
  Chief->>Guidance: Record approved lessons
  Chief->>Tasks: Archive confirmed finished tasks

For example, cctop drivers had separate worktrees but their tests still shared the running app. The chief found repeated collisions across their conversations, so we added a queue that lets one driver test at a time. The watchdog manages the queue, and the chief handles priorities and exceptions.

Watchdog thread and why I added it

Keeping the chief up to date shouldn’t depend on me remembering to ask.

I use a separate watchdog thread with a lower thinking level. A Codex automation wakes it every 5-10 minutes, like a cron job, to check the task status log where drivers record progress and blockers.

sequenceDiagram
  accTitle: Watchdog monitoring
  accDescr: The chief shares context with the watchdog, and drivers record progress and blockers in a task status log. On a schedule, the watchdog checks the log. It sends routine reminders directly to drivers and reports important changes to the chief, which coordinates the next step.
  participant Chief
  participant Watchdog
  participant Drivers
  participant Status as Task status log

  Chief->>Watchdog: Share task context
  Drivers->>Status: Record progress and blockers

  loop Scheduled monitoring
    Watchdog->>Status: Check the latest status

    alt Scenario 1: Routine attention is needed
      Watchdog->>Drivers: Send a reminder or runtime notice
    else Scenario 2: Important change or exception
      Watchdog->>Chief: Report what changed
      Chief->>Drivers: Coordinate the next step
    end
  end

Routine reminders can go straight to the drivers without interrupting my conversation with the chief. The log also lets me look back at which drivers got blocked or lost, and whether our workflow changes helped.

Some guardrail examples

I also use skills to define each role’s responsibilities, including the chief’s. A few examples:

  • The chief never changes product code itself, no matter how small the change.
  • Each driver owns its branch/PR and works within an agreed scope. It asks before expanding that scope.
  • Drivers need passing tests, CI, and agent review before calling a PR ready. For app changes, they also show evidence from the build they tested.

The chief’s own skills tell it how to delegate work and check progress without taking over implementation. When it starts new drivers, it includes the relevant skills when it briefs each driver, checks its reports, and asks it to complete any missing steps.

I still sometimes have to remind the chief of its own rules. But I rarely need to do that now.

Why I use Codex/ChatGPT

This setup requires the harness to let sessions communicate with and manage each other: creating a visible thread with its own worktree, reading and messaging it later, and running scheduled automations, etc.

When I tried this with Claude Desktop/Claude Code, I couldn’t find a supported way for one conversation to create a fresh coding session and reliably read/message it later, but Codex/ChatGPT could.

That said, the workflow would likely work in other highly customizable harnesses such as Pi.

Final thoughts

Now that this setup has stabilized for cctop, I want to try parts of it in my other projects. I’d review the drivers’ work more closely there and make more of the coding style and architecture decisions myself. I’m not yet sure how much chiefs will help with that workflow.

And part of why I’m writing this post is so I can point my agents to it when setting up other chiefs.