by giancarlostoro
2 subcomments
- I feel like there's two camps:
* Throw more agents
* Use something like Beads
I'm in the latter, I don't have infinite resources, I'd rather stick to one agent and optimize what it can do. When I hit my Claude Code limit, I stop, I use Claude Code primarily for side projects.
by raniazyane
2 subcomments
- I wonder if there’s a third camp that isn’t about agent count at all, but about decision boundaries.
At some point the interesting question isn’t whether one agent or twenty agents can coordinate better, but which decisions we’re comfortable fully delegating versus which ones feel like they need a human checkpoint.
Multi-agent systems solve coordination and memory scaling, but they also make it easier to move further away from direct human oversight. I’m curious how people here think about where that boundary should sit — especially for tasks that have real downstream consequences.
by killbot_2000
1 subcomments
- Running 70+ specialized agents locally here. The key insight for me was specialization over generalization - each agent handles a narrow domain (docs, testing, deployment, etc.) rather than trying to make one super-agent do everything. The orchestration overhead is real, but Herald-style message passing between agents with clear domain boundaries has worked better than shared context approaches. The observation problem mentioned in comments is solved by logging everything to a central activity stream - you can't watch 20 agents in real-time, but you can review what happened. Curious what coordination overhead you're seeing at scale?
by clairekart
1 subcomments
- What’s the failure mode you see with single-agent Claude Code on complex tasks? (looping, context drift, plan collapse, tool misuse?)
by miligauss
1 subcomments
- It's a more of a black box with claude, at least with this you see the proof strategy and mistakes made by the model when it decomposes the problem. I think instead of Ralph looping you get something that is top-down. If models were smarter and context windows bigger i am sure complex tasks like this one would be simpler, but braking it down into sub agents and having a collective --"we already tried this strategy and it backtracked"-- intelligence is a nice way to scope a limited context window to an independent sub problem.
- Great work! I like the approach of maximum freedom inside bounded blast radius and how you use code to encode policy.
- The first screen of your signup flow asks for "organization" - is that used as a username or as an organization name or both (I can't tell what if anything will be on the next screen)
If your registration process is eventually going to ask me for a username, can the org name and user name be the same?
- Can you add a license.txt file so we know we have permission to run this (eg MIT and GPL V3 are very different)
- Impressive! Are there any boilerplates that people know of for running something similar to this using open offline models? Would be cool to run this (or a single agent version) on a VPS that has some leftover compute resources.
by christinetyip
2 subcomments
- Cool, what’s a good first task to try this on where it’s likely to beat a single agent?
by slopusila
1 subcomments
- seems like it requires an API key to your proprietary Ensue memory system
- “How does progress subscription work — are agents watching specific signals (test failures, TODO list, build status), or just a global feed?”
Hacker News