Rotating Leads

I don’t have a permanent lead agent.

For some projects, I start with Codex. For others, Claude Code. The choice depends on who has the context, what kind of work is ahead, and sometimes how much of each subscription I’ve used that week.

That last reason is ordinary, but it matters. If I have access to several capable models, I want the freedom to put them to work. I don’t want my process to depend on always starting in the same place.

Scout’s monitor work is a current example of how I choose the roles. Codex is driving it, and I’ve brought Opus in for frontend work along the way. Later, I may want a pass focused on performance: where the interface spends time, what updates unnecessarily, what gets expensive as activity grows.

Codex is still coordinating this feature. The next assignment is open. I can choose who takes it when I understand what it needs.

That’s the principle behind rotating leads: leadership is a role I assign for the work in front of me. It can stay with one agent through a whole project, or move when a different agent has the context and capacity to carry the next stage.

The roles belong to the work. They don’t need to become permanent identities.

Enough workflow for the next step

The same freedom applies to the workflow itself.

Sometimes I want one writer and one reviewer. Sometimes I want several independent proposals before choosing a direction. Sometimes the direction is settled, and I want three reviewers to examine the implementation from different angles.

Those choices answer different questions. Independent proposals help me explore what we could build. Reviews help me assess what we already built.

I want to make that choice in conversation, when the uncertainty is clear. Describe the outcome, assign the roles, and decide what should come back. That is enough structure to begin.

I think of this as a just-in-time workflow. It can last for one stage. If the next stage needs a different arrangement, I can define that next.

A quick collaboration brief

Four things are enough to describe the collaboration I want:

In conversation, that could sound like this:

Codex leads this. Bring Opus in for the frontend, then bring me the implementation and checks. Once that settles, we’ll choose who takes the performance pass.

This is a collaboration brief: a way to make the assignment clear to the agents involved. The later review is still open. I can decide who takes it when we get there.

The revisit point matters. It gives the lead responsibility now and gives us a natural moment to reconsider. We might change the lead, change the shape, or keep both because they still fit.

Context has to travel

Changing the lead has a cost. The next agent needs to understand the goal, the current state, the decisions already made, and what remains unresolved.

A new coordinator shouldn’t have to reconstruct the project from my memory. That means leaving useful work in files and making the handoff explicit. An agent in another harness doesn’t automatically inherit the previous conversation.

Continuity matters more than keeping the same agent in charge.

This is where I want Scout to reduce the effort: make it easier to address the next agent, give it a bounded assignment, and get the result back into the work. The coordination should support the way I want to work across models and their native tools.

My preference is to describe the collaboration as I need it. Codex drives this feature. Opus helps with the frontend. A later pass examines performance. As the work develops, I can change who owns the next question and how many perspectives would help answer it.

I don’t need to choose the permanent shape of my agent team before I know the job. I need a clear owner for the next step, enough context to act, and the freedom to choose again.