FRESH

Hacker News

Agent orchestration for the timid

125 points by markferree

by px1999

4 subcomments

Imo there's a huge blind spot forming between 6 and 8 when talking to people and in reading posts by various agent evangelists - few people seem to be focussing on building "high quality" changes vs maximising throughput of low quality work items.
My (boring b2b/b2e) org has scripts that wrap a small handful of agent calls to handle/automate our workflow. These have been incredibly valuable.
We still 'yolo' into PRs, use agents to improve code quality, do initial checks via gating. We're trying to get docs working through the same approach. We see huge value in automating and lightweight orchestration of agents, but other parts of the whole system are the bottleneck, so theres no real point in running more than a couple of agents concurrently - claude could already build a low quality version our entire backlog in a week.
Is anyone exploring the (imo more practically useful today) space of using agents to put together better changes vs "more commits"?

by LordHumungous

1 subcomments

Do people actually have success with agent orchestrators? I find that it quickly overwhelms my ability to keep track of what its doing.

by xyzsparetimexyz

3 subcomments

What kind of basic ass CRUD apps are people even working on that they're on stage 5 and up? Certainly not anything with performance, visual, embedded or GPU requirements.

by myleshenderson

1 subcomments

Given the infancy of all of these tools, it makes sense to experiment. So trying out everything that is not gas town is reasonable.
I haven't yet tried gas town (or any of the mentioned tools) as I don't need so many agents that I need something like that plus the cost concerns. I've been rolling my own very light orchestrator (mostly just worktrees/branches/instructions) and relying on claude itself to manage the sub agents as necessary.
I was a bit surprised by the "ripping out beads" sentence from all of the article, as beads does seem to serve a purpose independent of the orchestration tools. Giving agents a ticketing system independent of what us humans use makes a lot of sense to me.
I've experimented with using Jira/Linear to handle the "current work todos" and using beads just seems so much better. No mcps and remote api calls is pretty great.
I'll be curious to see how the other orchestration tools are handling this, because it seems like they will have to handle it.

by sathish316

0 subcomment

Pied-Piper is another Subagents orchestration system that works from a single Claude code session with an orchestrator and multiple agents that handoff tasks to each other to follow a workflow - https://github.com/sathish316/pied-piper
It has Playbooks for repeatable workflows using which you can model both generic SDLC workflows (Plan-Code-Review-Security review-Merge) or complex workflows like Language migration, Tech stack migration (Problem breakdown-Plan-Migrate-IntegrationTest-TechStackExpertReview-CodeReview-Merge)
Hopefully, it will have the least amount of changes once Claude Swarm and Claude Tasks becomes mainstream

by magicmicah85

0 subcomment

When I want to learn code or understand a new architecture, I stick at stage 1. When I want to validate an idea, stage 5 and beyond makes perfect sense to go YOLO. I might have to try one of these orchestrators one day, but only when I'm regularly getting stopped cause I've hit my credit limit. For my current usage, I'm pretty happy where I'm at.

by MarcelOlsz

2 subcomments

Worth looking into Conductor.build and Sculptor as well, though I believe both are electron and run like sh*t but Conductor is quite good. Going to give this Vibe Kanban a go, thanks.
Orchestration is cool but a sane orchestration setup with VM's is where it's at.
I've been working on orchestration for the past little while and I've got a very tight loop going where everything is in worktrees and containerized, all services are isolated, so I can easily work on db schema/migration stuff while a few other agents do frontend work etc. Getting Conductor to play nice with vm's was very tricky as their docs say they have no intention of implementing vm's and wrote a "trust me bro, it won't erase your system" blurb about it in their docs [0]
[0] https://docs.conductor.build/faq#what-permissions-do-agents-...

0 subcomment