Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Orchestrate teams of Claude Code sessions

code.claude.com

Post reply on HN
Print view View original

81–90 of 238 posts

Re: Orchestrate teams of Claude Code sessions

#81

Post by ruined »

bonesss wrote: post #70
pronik wrote: post #58

To the folks comparing this to GasTown: keep in mind that Steve Yegge explicitely pitched agent orchestrators to among others Anthropic months ago: > I went to senior folks at companies like Temporal and Anthropic, telling them they should build an agent orchestrator, that Claude Code is just a building block, and it’s going to be all about AI workflows and “Kubernetes for agents”. I went up onstage at multiple event…

Compare both approaches to mature actor frameworks and they don’t seem to be breaking much ice. These kinds of supervisor trees and hierarchies aren’t new for actor based systems and they’re obvious applications of LLM agents working in concert. The fact that Anthropic and OpenAI have been going on this long without such orchestration, considering the unavoidable issues of context windows and unreliable self-validati…

what mature actor frameworks do you recommend?

Re: Orchestrate teams of Claude Code sessions

#84

Post by jghn »

ruined wrote: post #81
bonesss wrote: post #70

Earlier quoted context omitted.

Compare both approaches to mature actor frameworks and they don’t seem to be breaking much ice. These kinds of supervisor trees and hierarchies aren’t new for actor based systems and they’re obvious applications of LLM agents working in concert. The fact that Anthropic and OpenAI have been going on this long without such orchestration, considering the unavoidable issues of context windows and unreliable self-validati…

what mature actor frameworks do you recommend?

They did mention Akka in their post, so I would assume that's one of them.

Re: Orchestrate teams of Claude Code sessions

#85

Post by Sol- »

RGamma wrote: post #39
Sol- wrote: post #5

With stuff like this, might be that all the infra build-out is insufficient. Inference demand will go up like crazy.

Unlocking the next order of magnitude of software inefficiency! Though I do hope the generated code will end up being better than what we have right now. It mustn't get much worse. Can't afford all that RAM.

Dunno, it's probably less energy efficient than a human brain, but being able to turn electricity into intelligence is pretty amazing. RAM and power generation are engineering problems to be solved for civilization to benefit from this.

Re: Orchestrate teams of Claude Code sessions

#86

Post by woah »

nprz wrote: post #49
ottah wrote: post #32

I absolutely cannot trust Claude code to independently work on large tasks. Maybe other people work on software that's not significantly complex, but for me to maintain code quality I need to guide more of the design process. Teams of agents just sounds like adding a lot more review and refactoring that can just be avoided by going slower and thinking carefully about the problem.

There is research[0] currently being done on how to divide tasks and combine the answers to LLMs. This approach allows LLMs reach outcomes (solving a problem that requires 1 million steps) which would be impossible otherwise. [0] https://arxiv.org/abs/2511.09030

All they did was prompt an LLM over and over again to execute one iteration of a towers of hanoi algorithm. Literally just using it as a glorified scripting language:

```

Rules:

- Only one disk can be moved at a time.

- Only the top disk from any stack can be moved.

- A larger disk may not be placed on top of a smaller disk.

For all moves, follow the standard Tower of Hanoi procedure: If the previous move did not move disk 1, move disk 1 clockwise one peg (0 -> 1 -> 2 -> 0).

If the previous move did move disk 1, make the only legal move that does not involve moving disk1.

Use these clear steps to find the next move given the previous move and current state.

Previous move: {previous_move} Current State: {current_state} Based on the previous move and current state, find the single next move that follows the procedure and the resulting next state.

```

This is buried down in the appendix while the main paper is full of agentic swarms this and millions of agents that and plenty of fancy math symbols and graphs. Maybe there is more to it, but the fact that they decided to publish with such a trivial task which could be much more easily accomplished by having an llm write a simple python script is concerning.

Re: Orchestrate teams of Claude Code sessions

#87

Post by giancarlostoro »

I was working on my own alternative to Beads... then I realized I could do exactly this with something similar to Beads, I'm planning on open sourcing it soon because I like what I have so far, I also made it so I can sync my tasks directly to my GitHub projects as well. I think its more useful to have agent tasks eventually synched back up to real ticketing systems for historical reasons. Besides, its better to have alternatives that are agent agnostic.

Re: Orchestrate teams of Claude Code sessions

#88

Post by sciencejerk »

Der_Einzige wrote: post #27
Sol- wrote: post #5

With stuff like this, might be that all the infra build-out is insufficient. Inference demand will go up like crazy.

Anyone paying attention has known that demand for all type of compute than can run LLMs (i.e. GPUs, TPUs, hell even CPUs) was about to blow up, and will remain extremely large for years to come. It's just HN that's full of "I hate AI" or wrong contrarian types who refuse to acknowledge this. They will fail to reap what they didn't sow and will starve in this brave new world.

Agreed, agent scaling and orchestration indicates that demand for compute is going to blow up, if it hasn't already. The rationale for building all those datacenters they can't build fast enough is finally making sense.

Re: Orchestrate teams of Claude Code sessions

#89

Post by Keyframe »

aqme28 wrote: post #72
ottah wrote: post #32

I absolutely cannot trust Claude code to independently work on large tasks. Maybe other people work on software that's not significantly complex, but for me to maintain code quality I need to guide more of the design process. Teams of agents just sounds like adding a lot more review and refactoring that can just be avoided by going slower and thinking carefully about the problem.

I agree, but I've found that making an "adversarial" model within claude helps with the quality a lot. One agent makes the change, the other picks holes in it, and cycle. In the end, I'm left with less to review. This sounds more like an automation of that idea than just N-times the work.

Glad I'm not the only one. I do the same, but I tend to have gemini be the one that critiques.
Post reply on HN