Stop Babysitting One Agent. Conduct a Whole Orchestra

Here's a scene that probably feels familiar. You ask a coding agent to fix a bug. It starts working. You watch it for a bit, then your attention drifts — you check Slack, you read a PR, you make coffee. Twenty minutes later you come back and discover the agent has been sitting there for nineteen of those minutes, blocked on a question it asked you in minute one.

Now multiply that by three agents. That's not a productivity tool anymore. That's a room full of interns quietly waiting for you to notice them.

Elyra Conductor v0.8.0 is about that exact problem. It takes the single-agent workflow and turns it into something you can actually conduct — multiple agents, each on its own branch, each visible at a glance, each able to grab your attention precisely when it needs you and never a moment before.

Three features make it work. Here's the why and how of each.

🌳 Worktrees: give every agent its own room

The first problem with running multiple agents is physical: they share a working directory. Agent A edits auth.js, Agent B runs the test suite, and now they're fighting over the same files on the same branch. Chaos.

Git already solved this years ago, and almost nobody uses it: worktrees. A worktree is a second (or third, or tenth) checkout of the same repository — its own directory, its own branch — all sharing one .git. Isolated working copies, zero duplication of history.

Conductor now makes them first-class. A 🌳 Worktrees button opens a panel where you type a branch name and pick how to open it:

  New branch name: feature/login        from: HEAD      [+ Terminal]  [🤖 Agent]
🌳 master              MAIN   0c308a37   /Users/kh/Code/feed3     🖥 🤖

Click 🤖 Agent and Conductor creates the worktree, spins up an Elyra agent inside it, and that agent now lives in feed3.worktrees/feature-login/ — a completely isolated copy. It can edit, build, and test without ever touching what the other agents are doing.

The Rust side is refreshingly small — it just speaks git's own porcelain:

git -C <repo> worktree add -b feature/login <dir> HEAD

The interesting subtlety we hit: PR branches usually exist only on the remote. Naively creating a worktree would make an empty new branch with the same name. So when a branch exists only as origin/<branch>, Conductor tracks it properly:

git worktree add --track -b <branch> <dir> origin/<branch>

Now the worktree has the real PR contents, and your agent starts from where the PR actually is — not a blank slate.

🤖 The command center: know who needs you, instantly

Isolation solves the collision problem. But it creates a new one: now you have three agents working in three directories you can't see. Which one is done? Which one is stuck? Are any of them quietly waiting for you?

This is the feature I'm proudest of, because it required almost no new code — just paying attention to state the agent panel already knew. Every Elyra agent reports one coarse signal, and the priority order is the whole point:

let presence = exited ? "exited"
: pendingUI ? "waiting"   // ← asked you something, now blocked
: busy ? "working"
: "idle";

waiting wins over everything, because a blocked agent is wasted time. Conductor surfaces it two ways:

• A dot on each tab — blue pulse for working, amber pulse for waiting on you.

• A pill in the tab strip — 🟡 1 waiting · 🔵 2 working — the whole orchestra at a glance. Click "waiting" and you jump straight to the agent that needs you.

And the part that closes the loop: if an agent starts waiting while you're looking at a different tab or another app entirely, you get a notification.

  🤖 Agent needs you
feature/login is waiting for your input

No more interns sitting in silence. The agent raises its hand, and you actually see it.

✅ PR status: the missing half of the picture

So now you've got agents on three branches, each making commits. The natural next question — the one you'd otherwise answer by alt-tabbing to GitHub fifteen times — is: what's the state of each branch's pull request?

With an authenticated gh CLI, Conductor answers it inline. Each worktree shows its open PR right next to the branch:

  🌳 feature/login   a1b2c3d   #42 ✓ 🟢      ← checks green, approved
🌳 fix/cache       e4f5a6b   #41 ✗ 3       ← 3 checks failing
🌳 feat/currencies 9c0d1e2   #19 ○ 2       ← 2 checks still running

It parses GitHub's check rollup into three honest numbers — passed, failed, pending — and colors the badge accordingly. Click it, you're on the PR. Hover, you get the title and review state.

And because we were already listing PRs, we added the inverse: open PRs that don't have a worktree yet. They show up in the same panel with a one-click "check this out as a worktree." So the full arc becomes a single gesture:

See a PR → spin up a worktree tracking it → drop an agent into it → watch its presence and CI status from the same window.

That's the whole loop. PR to agent to green checkmark, without leaving Conductor.

The honest part: a bug we caused, and fixed

Building in the open means admitting the stumbles. The worktree panel shipped first with a nasty one — it got stuck on "Loading…" forever. The cause was a classic Svelte 5 reactivity trap: an $effect called a refresh() function that read the worktree list to decide whether to show a spinner, while also writing the worktree list when the data arrived. Read plus write in the same reactive scope, with an await in between, is an async feedback loop that never settles — and because the await breaks the synchronous cycle, the framework can't even warn you.

The fix was to stop reading the list to drive the spinner, and key the load to "once per open." Two lines. But it's a good reminder that the reactive magic which makes these UIs pleasant also has sharp edges, and the only way to find them is to use the thing.

Why this matters

There's a quiet shift happening in how we work with coding agents. For a while the question was "can the agent do the task?" Increasingly the answer is yes — and the new bottleneck is you. One human, supervising several agents, becomes the constraint. You can only watch one terminal at a time.

v0.8.0 is a bet on that future. Not a smarter agent — Conductor deliberately runs zero AI logic itself; it bundles context and lets Elyra reason. Instead, a better cockpit: isolation so agents don't collide, presence so you know who needs you, and PR status so you know where each branch stands. The tooling that lets one person conduct several agents instead of babysitting one.

The orchestra was always capable of playing. It just needed a conductor who could see the whole stage.

Elyra Conductor v0.8.0 is out now. Existing installs will offer the update automatically — release notes included.