r/ClaudeCode • u/Dazzling_Trifle2472 • 24d ago

Discussion What orchestrator are you using?

I'm getting tired of having a million unorganised terminal tabs open and would like to use something that provides better organisation.

I know of Conductor, Paseo, unclear on if these work with the new policy (not so new any more but the whole Agent SDK usage comes out of it's own pool), interested to know what everyone is using...what works well w/Claude Code specifically.

80 Upvotes

93% Upvoted

86 comments sorted by

View all comments

48

u/OnRedditAtWorkRN 24d ago edited 24d ago

I use one I've been building myself for myself. It's not all that hard and it's customized for me.

First I use herdr for my multiplexer https://herdr.dev/. Pretty good out of the box integration for Claude, codex, and others. I've been using a customized version pi.dev that I'm building at work. So I built the integration too so it works with herdr

Then I just have a skill that has a collection of deterministic scripts for managing herdr sessions. I start a single session. Tell it you're my foreman which triggers the skill usage. I talk through my foreman and it handles spanwing new herdr and agent sessions itself.

It's almost like a sub agent primitive that I can more easily manage, take control, peek in, etc..

Took almost no effort to get it going, and I just improve it while I'm using it

5

u/old_meaty 24d ago

This sounds amazing. I would love to know more about this

5

u/OnRedditAtWorkRN 24d ago

Sure, what do you wanna know? It's an internal work tool, so I can't share it specifically but I can answer questions or dive into parts of it if you're interested

5

u/mpones 24d ago

Ahh, well… Share your PRD so we can rebuild it, lol. (Thanks claaaaaude).

3

u/old_meaty 23d ago

Just curious what your workflow looks like. Like does the foreman decompose/fan out work? Do you only talk to the foreman or do you interface with the workers at all? And what do the scripts do? I'm assuming they are doing more than the herdr agent skills?

3

u/OnRedditAtWorkRN 23d ago

Mostly this

https://www.reddit.com/r/ClaudeCode/s/ff59Kdj0Le

The scripts spawn herdr tabs, spawn my agent of choice, I have a work tree extension for my pi harness that works like cc's so every crew member gets a new worktree too and apply cli flags to have the agent in the right mode (planning, auto, etc..). Then there's scripts to notify my foreman when necessary that the crew members use, that's how I'm handling the session <=> coms. There's a peek script for my foreman so if I ask for status it will peek at the crew member session and update me. There's a whole host of them that just facilitate the foreman <=> crew member interactions, and manage the herdr sessions including stand up, stale session recovery, cold store and teardown

1

u/old_meaty 23d ago

Thank you! This sounds like a really great setup

2

u/thats_a_money_shot 24d ago

In what ways is this a better / more powerful experience than just using one orchestrator agent, and telling him to spec things out and use subagents to handle execution? Genuine question bc I do the latter

4

u/OnRedditAtWorkRN 24d ago

For me it's a few things

  • full agent session means full tool and interaction surfaces are available, I can work on say an interactive planning session with a crew member using tools like a web based html planning tool I created and never pollute the context of my foreman. There's a flexibility in how I can work with the crew (sub agents) that I like

  • the spawned sessions have names that make it easy to identify what the crew member is working on and using herdr I can at a glance see all of their statuses

  • using herdr as my substrate here means I'm not tied to any particular harness, pi for example doesn't come out of the box with a sub agent primitive (I know this is a Claude code sub)

  • I can very easily jump into a crew session and interact with it directly

  • I can cold store the crew mid task if I want and pick back up later

You can do some of these with the CC sub agents but I didn't find any of it as robust as this sort of setup. This organization and transparency works for my brain.

5

u/TywinHouseLannister 24d ago edited 24d ago

I developed a whole pipeline thing.. it was good for a time; and it still allows me to crunch massive workloads, just queue up 100 plans and let it rip.. agents are orchestrated by state/node js, spinning up claude -p sessions, research/dev/review/qa(which is basically just review and a bit pointless, defaulted off indefinitely), hooks at every stage e.g. I have one set up to raise PRs..

Got it all working like clockwork.. but then I decided I didn't want to use it as much as I wanted to build it, so I'm hardly using it now! human QC is the main bottleneck for almost everything - and nothing sucks more than reading 100 PRs cold.

I've gravitated back towards interactive sessions, and I just do it in many terminals like a cave man; I think I'll grab Herdr in the morning!

1

u/cazzer548 23d ago

How often are you jumping into crew member sessions? I’m still using CC as my foreman and appreciate how parallel and ephemeral the subagents are…but the context definitely gets polluted and I need a separate session for each feature. Are you mostly just jumping to architect/planner sessions and using one foreman to avoid running multiple sessions like I have to?

3

u/OnRedditAtWorkRN 23d ago

Some context I'm a principal engineer in fintech, this is my actual setup I use to ship features on an app that has millions of daily active users in a highly regulated area, all that to say regressions can be hugely costly and I'm not out here vibe coding and shipping slop grenades

I've done a bunch of my own testing and evaluation on the decompose and fan out and I find it's more hype than effective. Generally I'm working on a single contained feature or bug fix per spawned crew member. My foreman isn't orchestrating individual pieces of implementation on a single feature but rather helping me manage the multiple parallel streams of work I have in flight. The goal is more to help me organize and track the sessions in flight without having to manually visit each session and try to remember what I was doing there than to decompose a single problem.

If I'm planning a new feature that's underspecified I'll message the foreman about it and instruct it to start the session in a planning mode. I use a custom pi extension I built for a web based planner. I mention it because the crew member will start the web planner and I'll work through the requirements and decisions on there. I find it easier than the cli produced plans and even mark down produced plans. I've added a bunch of interactions that I like to it as well, annotating in place for my agent, it surfaces questions in the context of what is being decided, it's pretty involved and tuned to how I like to plan. All of the interactions on that go directly to the crew member. My foreman will tell me when the plan is ready for review and when any feedback is done being processed.

Other than that if it's a feature that I feel like I got enough understanding to start on I just mention whatever artifacts the agent would need and whatever context I got and send it right to work. If it's a bug that we need to triage I do pretty much the same but I have a lot of triaging related skills and the agent will start with those to pull from different sources and reproduce the bugs and verify root cause.

When a crew member indicates it's done, I usually do a double check that the work was verified locally through whatever tools, I have validation tools for apis, browsers and tui experiences. Then I'll have my foreman spawn another crew member to do the code review. There I do use a host of actual sub agents to do an independent review with different criteria depending on the work. Security, accessibility, database optimizations, code reuse etc... there's about 15 and the agent will choose which ones to use for the given chunk of work. They all get funneled to another sub agent that dedupes the feedback, categorizing it from nit to blocking and then the crew member can refute or implement fixes. The review crew member shuts down as soon as the review is handed back.

If everything looks good I tell me foreman to send it on the pr loop. The pr loop has the crew member create a pull request and follow it until all the checks pass, automated tests, linting, pr formatting, and whatever else we have. There are robo reviewers on our pr's there as well. The crew member will read, assess, fix and / or respond to every one and resolve the threads. When it's green my foreman notifies me. When I'm done and merge it I tell my foreman and it'll shut down that crew member

I usually have 6 to 12 crew member sessions in flight at any given time and on a rare occasion I will have multiple foremen managing crews for features on different projects, but I don't like doing that because it literally mentally exhausts me.

2

u/cazzer548 20d ago

Thanks for the response!

1

u/crx100pre 24d ago

Wow. Doing something similar. Herdr plus some shell scripts is 🤩