Is conducting agents in tmux tabs or Claude Squad wrong?

No. Manually driving parallel agent sessions is a legitimate workflow, especially for a solo developer with a few streams. It only becomes a bottleneck when the hand-offs between agents start consuming more of your time than the work itself.

What makes Fleet an orchestrator rather than a conductor?

Fleet is event-driven. GitHub labels publish fabric events, agents subscribe to those events, and one agent's completion event triggers the next. The reactive chain replaces the human who would otherwise route work between sessions.

When is orchestration genuinely worth the added complexity?

At team scale, when hand-offs dominate your time, when multiple people depend on the workflow, or when you need an audit trail. Below that — solo, few streams — the simpler conductor model is often the better call.

Does orchestration mean I give up control?

You trade step-by-step control for throughput and an audit trail. You still set the policy — which roles exist, what they subscribe to, where the gates are — but you stop manually routing each hand-off. The chain enforces what you declared in config.

From Conductor to Orchestrator: The Shift in Agentic Coding

Name: Fleet
Author: Fleet

The first way most people run multiple AI coding agents is by conducting them. You open a few Claude Code sessions in tmux tabs, or use a tool like Claude Squad or Conductor to lay them out side by side, and you move between them — prompting one, checking another, merging a third. It works, it is honest, and for a solo developer juggling two or three streams it is often all you need. The human is the scheduler, the router, and the memory of what happened.

The shift to orchestration happens when that human becomes the bottleneck. An orchestrator is event-driven: a label on a GitHub issue starts an agent, that agent finishes and emits an event that starts the next agent, and the chain runs without anyone clicking between tabs. This guide explains the difference, when each approach is the right one, and how Fleet implements the orchestrator model — with every mechanism grounded in what the tool actually does.

Before you start

Experience running at least one Claude Code agent on real work
A sense of how many independent streams of work you typically have in flight
A GitHub repository with an issue-and-PR workflow
Fleet installed if you want to follow the orchestrator configuration (`fleet init`)

Recognize the conductor model for what it is

Manually driving parallel agent sessions — tmux tabs, Claude Squad, Conductor — is a legitimate workflow, not a mistake. You hold the plan in your head, prompt each session, and stitch the results together. Its strength is total control and zero infrastructure. Its ceiling is you: every hand-off between agents passes through your attention, so throughput is capped by how fast you can context-switch.

# The conductor model, conceptually:
# tab 1: claude  -> you prompt the backend change
# tab 2: claude  -> you prompt the frontend change
# tab 3: claude  -> you paste the diff and ask for a review
# You are the router between every tab.

Spot the moment conducting stops scaling

The signal is simple: you are spending more time routing work between agents than doing work yourself. PRs wait because you have not gotten around to pasting them into a reviewer session. An agent finishes and sits idle because the next step needs your prompt. When the hand-offs dominate, you have outgrown conducting and the next lever is to make the hand-offs automatic.

# Symptoms you have outgrown the conductor model:
# - agents idle, waiting for your next prompt
# - PRs stacking up unreviewed while a reviewer session sits empty
# - you, not the work, are the rate limit

Replace yourself as the router with the reactive chain

Fleet's orchestrator model is a reactive event chain. A maintainer adds the ready label to a GitHub issue. The watcher detects it and publishes a ticket_ready event, which starts the developer agent. The developer opens a PR and labels it needs-review, producing pr_needs_review, which starts the reviewer. The reviewer publishes pr_approved, which starts the release-manager, which merges and the issue is shipped. No tab-switching — the events are the router.

# ready          -> ticket_ready        -> developer starts
# needs-review   -> pr_needs_review     -> reviewer starts
# (reviewer)     -> pr_approved         -> release-manager starts
# (merge)        -> ticket_shipped      -> issue closed

Wire the chain with subscriptions

The orchestrator is just declarative config. Each agent's subscribes_to field names the fabric event that should start it. The watcher's subscription processor matches incoming events to these subscriptions and fires the right agent — the mechanism that used to be your attention is now a few lines of YAML.

agents:
  - name: backend-dev
    role: backend-developer
    subscribes_to: ticket_ready
  - name: tech-lead
    role: tech-lead
    subscribes_to: pr_needs_review
  - name: release-manager
    role: release-manager
    subscribes_to: pr_approved

Start the engine and let labels drive it

Start the watcher daemon. From here, a single human action — labeling an issue ready — sets the whole chain in motion. The watcher polls GitHub roughly every two minutes and processes the Fabric event bus every ten seconds. You moved from prompting every step to triggering the first one.

fleet watcher start --supervised

# The only manual step left:
gh issue edit 42 --add-label ready

# Watch the chain run itself:
fleet log --type decision --since 1h

Keep the audit trail orchestration gives you

Conducting leaves its history in your terminal scrollback and your memory. Orchestration records every hand-off as a structured decision event. fleet log --type decision is a replayable trail of who did what and when — which is exactly the governance and audit capability that conducting cannot offer once more than one person depends on the workflow.

fleet log --type decision --since 7d
fleet log --agent tech-lead --since 24h

Common pitfalls

Orchestration is not strictly better than conducting — it trades control for throughput. For a single developer with two or three streams, the conductor model has less to break and may genuinely be the right choice.
An event-driven chain only moves if the watcher is running. If `fleet watcher status` shows it stopped, labels accumulate and nothing fires — the failure is silent, unlike a conductor who notices an idle tab immediately.
Subscriptions match event names exactly. A typo in a `subscribes_to` value means that agent never fires and there is no error. Use only real event names like `ticket_ready`, `pr_needs_review`, `pr_approved`, and `ticket_shipped`.
The chain coordinates through the reactive event bus, not through a rigid sequential pipeline you script up front. Trying to model it as fixed stages with hard ordering fights the event-driven design instead of using it.
An agent that exits without publishing its outgoing event stalls the chain. Orchestration removes the human from the loop, so it also removes the human who would have noticed — monitor `fleet log` during the first runs.

When Fleet is the right tool

Stay a conductor when you are solo, the streams are few, and you value direct control over every step — that is a real and reasonable place to be. Move to an orchestrator when the hand-offs between agents (and between agents and people) are eating your time, when more than one person needs to depend on the workflow, or when you need an audit trail and governance that terminal scrollback cannot provide. Orchestration earns its complexity at team scale; below that, it can be overkill. The honest framing: conducting scales with your attention, orchestration scales past it.