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]
co-creator of Conductor here! Conductor is actually a Tauri 2.0 app so it uses the native safari renderer. working on getting remote workspaces working as we speak!
Brutal. I had to renice it and do some shenanigans to make it work crispy but now it's decent. Has a lot of hang ups like if you leave a text input focused for too long the fans on your laptop will start.
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.
I find it funny that as these systems become better at something (i.e. "basic ass CRUD"), people still maintain that they're only good at those and nothing else.
> VIBETENSOR is an open-source research system software stack for deep learning,
generated by LLM-powered coding agents under high-level human guidance. In
this paper, “fully generated” refers to code provenance: implementation changes
were produced and applied as agent-proposed diffs; validation relied on builds, tests, and differential checks executed by the agent workflow, without per-change manual diff review.
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"?
I've been playing with Brad Ross's AISP [1] to get a better quality of llm outputs at strategic stages of our basic design / plan / implementation workflows.
A concrete example of this is our Adviser Skill experiment [2]. In most AI workflows, a "reviewer" agent just dumps markdown feedback. Our Adviser doesn't just "talk"; it outputs an AISP 5.1 document ( a kind of "Assembly Language for AI Cognition" )
This document forces the agent to define:
- Strict Type Definitions for the issues identified (e.g., distinguishing between a gap, an edge case, or a missing requirement).
- EARS Rules (Easy Approach to Requirements Syntax) that determine the verdict. For example, a rule might state: "If any issue has a severity of ⊘ (critical), then the workflow MUST halt."
- Formal Evidence: Every "approve" or "reject" verdict must include a confidence score (δ) and a grounding proof (π) that explains why the change matches the original specification.
By treating the agent's output as a proof-carrying protocol rather than just text, we can chain multiple specialized agents (Architect, Strategist, Auditor) who "triangulate" on the codebase. They must reach a formal consensus where the variance between their scores is low.
This shifts the agent's goal from "Finish the task at all costs" to "Prove that this change is safe and correct." It turns out that iterating on the verification logic is much more effective for building reliable systems than just increasing the number of agents running concurrently.
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.
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.
Replaced beads with a skill reminding Claude it could use gh cli to manage GitHub issues and never really looked back. I had already noticed on smaller projects that a markdown punch list plus the built in todo tool was usually more than enough and between those two didn’t feel the need for beads anymore.
I appreciate the follow up. I'm using Jira as the primary work tracker for my day job, so I'm hesitant to interact with that any more than is necessary. Though we do have a skill for Jira primarily for humans to tell the LLM "hey create a ticket...".
This is the fracture in the industry I don't think we are talking about enough.
It overwhelms everyone's ability to keep track of what it's doing. Some people are just no longer keeping track.
I have no idea if people are just doing this to toy projects, or real actual production things. I am getting the sneaking suspicion it's both at this point.
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
15 comments
[ 3.2 ms ] story [ 41.0 ms ] threadOrchestration 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-...
Brutal. I had to renice it and do some shenanigans to make it work crispy but now it's decent. Has a lot of hang ups like if you leave a text input focused for too long the fans on your laptop will start.
Case in point - https://github.com/NVlabs/vibetensor/blob/main/docs/vibetens...
> VIBETENSOR is an open-source research system software stack for deep learning, generated by LLM-powered coding agents under high-level human guidance. In this paper, “fully generated” refers to code provenance: implementation changes were produced and applied as agent-proposed diffs; validation relied on builds, tests, and differential checks executed by the agent workflow, without per-change manual diff review.
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"?
A concrete example of this is our Adviser Skill experiment [2]. In most AI workflows, a "reviewer" agent just dumps markdown feedback. Our Adviser doesn't just "talk"; it outputs an AISP 5.1 document ( a kind of "Assembly Language for AI Cognition" )
This document forces the agent to define:
- Strict Type Definitions for the issues identified (e.g., distinguishing between a gap, an edge case, or a missing requirement).
- EARS Rules (Easy Approach to Requirements Syntax) that determine the verdict. For example, a rule might state: "If any issue has a severity of ⊘ (critical), then the workflow MUST halt."
- Formal Evidence: Every "approve" or "reject" verdict must include a confidence score (δ) and a grounding proof (π) that explains why the change matches the original specification.
By treating the agent's output as a proof-carrying protocol rather than just text, we can chain multiple specialized agents (Architect, Strategist, Auditor) who "triangulate" on the codebase. They must reach a formal consensus where the variance between their scores is low.
This shifts the agent's goal from "Finish the task at all costs" to "Prove that this change is safe and correct." It turns out that iterating on the verification logic is much more effective for building reliable systems than just increasing the number of agents running concurrently.
[1] Brad Ross AISP : https://github.com/bar181/aisp-open-core
[2] Adviser skill : https://github.com/pnocera/skilld
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.
I'll play with that a bit to see what happens.
It overwhelms everyone's ability to keep track of what it's doing. Some people are just no longer keeping track.
I have no idea if people are just doing this to toy projects, or real actual production things. I am getting the sneaking suspicion it's both at this point.
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