[unsaved159]

What use cases did you find this approach works for, and what doesn't? Any observations on what topologies work better?

I tried doing the same for the cases of maintaining OSS projects. So far, best I could manage is to get the agents to autonomously do %80~ of the work. But then, I have to review manually each potential PR, and almost in every case to further work with an agent providing it with guidance live to fix it. This takes about as much time as without the swarm. So far I found that the usefulness of the swarm is mostly for the initial scouting, to map out what work needs to be done in first place, and store it in a nice JSON file.

From my observations, all it takes is one mistake for an agent to make, from there, the architecture just snowballs into chaos as the future work builds on top of incorrect initial approach.

[mschwarz]

Yeah I can definitely relate with the snowballing. I am mostly building web apps (python/typescript) so ymmv. Have you tried to pair codex with claude? This is like the gateway drug for doing agent topologies. This is definitely worth trying. Claude is better at understanding your intent, but at the expense of it makes lots of mistakes. Codex makes less mistakes but at the expense of over-engineering. Together they are not perfect but significantly more accurate. They complement each other well. So Codex reviews claude, using TDD is even better because codex will gate each change claude makes. You can apply this pattern to implementation, reviews, PM, even research, etc. OpenRig has a spec called implementation-pair which lets you try this pretty easily. There is another one called adversarial-review which is the same topology just different starter context / instructions to make them less constructive, more combative. You'll get a feel for which one you need for a task pretty quick. But lots of people have made this pattern into skills. I think OpenRig is probably the easiest happy path to try it because the 2 agents can literally type into each others terminals using "rig send" and "rig capture" and see each other screens using tmux, as if you were the one typing the commands. But now you just sit back and watch them find and fix bugs. You dont need OpenRig to do this, just tmux, but raw tmux is a little fiddly to get working which is why i made the rig send command as a tmux wrapper.