I’ve been quiet this week because after seeing the potential of Claude Code’s fast subprocess orchestration, I took the plunge to build my own framework - one designed for solo practitioners or small teams.
Very cool! I came across this project yesterday. It's not an orchestration framework, but defines different roles similarly to your project. I really like how you specify communication patterns between different personas.
Speaking of collaboration. Wonder if there could be opportunities to bring some ideas from Team Topologies book, they specify collaboration styles between different teams. I now they are working on a different level of abstraction - multiple teams vs multiple individuals / agents, but figured I'd mention it since it came to my mind.
What would be very interesting to observe is to vary different capabilities and to see if there are improved results. For example, from your definition about engineer:
What Engineer Agent Does NOT Know: Business strategy or market positioning
I understand that you are trying to constrain each role, with the idea that orchestration will take care of things like business strategy. However, for humans, we do want to make sure that engineers have some understanding of business strategy, partially as part of motivation to work at the company,, and also in hopes that they can make low-level tradeoffs to align with the strategy. So as a result, a truly great engineer will come up with ideas that are on-strategy that were not specifically asked for (and of course work with PM to incorporatre into projects or roadmap ).
So it would be interesting to see if you changed some of these constraints, if you'd see improved results, or whether constraining rules, but then investing in improved coordination would produce superior results.
To take yet another step back, among other things, this is truly fascinating because we can now perform experiments that we can't really perform in real life - performing the same tasks with different collaboration patterns and see which results are optimal.
I noticed from the video that you are running Claude in YOLO mode, are you running in a dev-container? If so, would you mind sharing it? I'd love to check this out, but in a restrained environment.
Very cool! I came across this project yesterday. It's not an orchestration framework, but defines different roles similarly to your project. I really like how you specify communication patterns between different personas.
https://github.com/NomenAK/SuperClaude
Speaking of collaboration. Wonder if there could be opportunities to bring some ideas from Team Topologies book, they specify collaboration styles between different teams. I now they are working on a different level of abstraction - multiple teams vs multiple individuals / agents, but figured I'd mention it since it came to my mind.
What would be very interesting to observe is to vary different capabilities and to see if there are improved results. For example, from your definition about engineer:
What Engineer Agent Does NOT Know: Business strategy or market positioning
I understand that you are trying to constrain each role, with the idea that orchestration will take care of things like business strategy. However, for humans, we do want to make sure that engineers have some understanding of business strategy, partially as part of motivation to work at the company,, and also in hopes that they can make low-level tradeoffs to align with the strategy. So as a result, a truly great engineer will come up with ideas that are on-strategy that were not specifically asked for (and of course work with PM to incorporatre into projects or roadmap ).
So it would be interesting to see if you changed some of these constraints, if you'd see improved results, or whether constraining rules, but then investing in improved coordination would produce superior results.
To take yet another step back, among other things, this is truly fascinating because we can now perform experiments that we can't really perform in real life - performing the same tasks with different collaboration patterns and see which results are optimal.
Looks very impressive, but the readme is a bit repetitive.
Hey Bob,
I noticed from the video that you are running Claude in YOLO mode, are you running in a dev-container? If so, would you mind sharing it? I'd love to check this out, but in a restrained environment.
Running it on my laptop. Have not had any issues.